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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1848247 Title: 3A+ boot failure on Eoan To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-firmware-raspi2/+bug/1848247/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
