[Bug 1848247] Re: 3A+ boot failure on Eoan

[Dave Jones]

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
Foundations Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848247

Title:
  3A+ boot failure on Eoan

Status in linux-firmware-raspi2 package in Ubuntu:
  Triaged

Bug description:
  The current Eoan image hits a kernel panic when booting on a Raspberry
  Pi 3A+. Unfortunately it does so before the serial console has been
  enabled so there's no useful output beyond what scrolls by rapidly on
  the framebuffer console.

  It is notable that the start.elf bootloader (prior to u-boot), loads
  the device-tree for the 3B+ because no device-tree specific to the 3A+
  exists (in the 27*.dtb set; there is one in the 28*.dtb set but I'm
  not convinced those are used by anything); u-boot proceeds
  successfully but then the kernel panics.

  This occurs on both the armhf and arm64 architectures.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware-raspi2/+bug/1848247/+subscriptions