zasdf22

Yes I have a fdt /chosen/framebuffer@XXXXXX but when I write anything to its memory, it is not updated on the HDMI output as I (novice) would expect. All it does...

``` U-Boot> fdt list /chosen chosen { user-warnings = [64 74 65 72 72 6f 72 3a 20 20 20 6f 76 65 72 72 69 64 65 20 69...

> Would you mind posting the rest of config.txt, or at least the dtoverlay/dtparam lines? There are some interesting messages encoded in your fdt: > > ``` > dterror: override...

GP32-33 is just a plain uart for modbus. I should clean up this file a little. ``` $ cat m41t80-overlay.dts /dts-v1/; /plugin/; / { compatible = "brcm,bcm2711"; fragment@0 { target...

Any idea what's going wrong? does start.elf lock the memory or prevent the buf from being written to/updated or is this entire process so complex that it's hard to describe?

> > The VPU (and hence start.elf) has no way to prevent the ARM cores from accessing regions of memory, so that can't be the cause of what you are...

okay. do the vc/v3d drivers do any fiddling with the gpu to be able to write to the fdt-provided fb or does it just work, if you happen to know?

``` $ cat /etc/modprobe.d/blacklist-vc4.conf blacklist vc4 blacklist v3d ``` dmesg ``` Populating /dev using udev: [ 4.347940] udevd[141]: starting version 3.2.14 [ 4.380809] udevd[143]: starting eudev-3.2.14 [ 4.571718] vc_sm_cma: module...

> Note: The rainbow is not displayed in the framebuffer. It is a simple 2x2 pixel test pattern scaled up. > > If you are seeing the rainbow then you'll...

> The normal procedure is for the rainbow to be replaced with that framebuffer before the kernel is launched, but that is not happening with your configuration for some reason....