Comment 4 for bug 1848247

Revision history for this message
Dave Jones (waveform) wrote :

I'm at a similar place; currently digging into the simplefb side of things. My current thoughts are as follows:

1. Ideally I want to ditch the vc4-fkms-v3d overlay; firstly this resolves the 3A+ booting issue, secondly it's something that should be an option rather than mandatory to the boot procedure

2. It appears the vc4-fkms-v3d overlay also prevents u-boot from operating the framebuffer correctly. Which is just another reason to get rid of it :)

3. I note that the simplefb is only set up during the bootm phase, i.e. at the *end* of u-boot's run. However, long before that (without the overlay in place) u-boot is happily displaying things on the framebuffer. Which makes me wonder if the simplefb is needed at all; bcm2708_fb is obviously capable of generating its own framebuffer (given the kernel can be launched without u-boot).

4. In the device-tree generated by the simplefb code I note that the physical dimensions of the framebuffer it creates include overscan margins; when the overlay is in place I don't see any overscan margins. Incorrect dimensions (or strides) is something that could well produce the sort of corruption we're seeing.

Anyway, my next step is going to be a crude excision of the simplefb code from u-boot (or the code that calls it) to see if that fixes things. If it does it'll still be a bit of a hack, but a better hack than the overlay. Obviously I'd ultimately like to fix the framebuffer code "properly" (not least, including on the Pi4 where u-boot's framebuffer doesn't operate at all) but I'll take a better hack that enables 3A+ to boot in the meantime.