You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why no LCD/framebuffer support in your build ? It would be a kind yet simple addition to your patches.
Since you have made your way through emcraft kernel then there is not that much to do to make it work, and alongside with XiP it doesn't take up that much on the available ram. Remember this stm32f769 implementation dedicated to even running the proxmark3 clientnwith crapto1 computation and directly on the device: https://youtu.be/4jI3O-egG0w
As I remember that's only a rewrite of the 429 FB driver + the addition of the near as-is DSI driver from the stm32cubeMX HAL. Then you need to work a.bit on patching fbcon and a few other bits to ensure the ARGB8888 is well working and voila.
Or is it a choice to avoid the framebuffer/dsi/LCD implementation? That's annheavy loss for the device.
The only thing I can think of which would benefit from a more or less user land implementation would be to make it more flexible to implementn Chromeart Accelerator functions.
Did I miss something here ?
The text was updated successfully, but these errors were encountered:
If any interest shows up enough I'll made these patch available again.... meaning I've got enough memory on bow and what to do but would have to start from scratch again. Straightforward but still a a full working day of work.
Hello,
Why no LCD/framebuffer support in your build ? It would be a kind yet simple addition to your patches.
Since you have made your way through emcraft kernel then there is not that much to do to make it work, and alongside with XiP it doesn't take up that much on the available ram. Remember this stm32f769 implementation dedicated to even running the proxmark3 clientnwith crapto1 computation and directly on the device: https://youtu.be/4jI3O-egG0w
As I remember that's only a rewrite of the 429 FB driver + the addition of the near as-is DSI driver from the stm32cubeMX HAL. Then you need to work a.bit on patching fbcon and a few other bits to ensure the ARGB8888 is well working and voila.
Or is it a choice to avoid the framebuffer/dsi/LCD implementation? That's annheavy loss for the device.
The only thing I can think of which would benefit from a more or less user land implementation would be to make it more flexible to implementn Chromeart Accelerator functions.
Did I miss something here ?
The text was updated successfully, but these errors were encountered: