[RESEND PATCH v3 0/3] rpi: Convert to standard boot

[Simon Glass]

Hi Peter,

On Tue, 10 Oct 2023 at 08:58, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Peter,
>
> On Sun, 8 Oct 2023 at 14:20, Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Peter,
> >
> > On Sun, 8 Oct 2023 at 12:02, Peter Robinson <pbrobinson at gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > > > So with more testing of 2023.10 in Fedora we found a regression where
> > > > > the display dies when the vc4 module loads in the kernel. With further
> > > > > debug it was found that it was due to the new U-Boot and with
> > > > > bisecting it myself I have found this series is the cause of the
> > > > > regression.
> > > > >
> > > > > The testing I have done is with recent RPi firmware, U-Boot 2023.10
> > > > > and kernel 6.5.x, but also seen with 6.4.x, with a minimal text only
> > > > > image. I can also reproduce it by using the F-38 GA image, no updates
> > > > > and purely just changing the U-Boot component. I've done my testing on
> > > > > the RPi4.
> > > > >
> > > > > Let me know if you need more information, I believe you have a RPi you
> > > > > can test with.
> > > >
> > > > Thanks for the report. Which rpi should I test with? I take it that
> > > > vc4 is a kernel module? Do you have the error message?
> > >
> > > Well I've been testing on the RPi4 (as I mentioned above), there's no
> > > direct error message that's directly linked but the screen goes blank
> > > and turns off, even on a text only install, and yes, on the rpi4 the
> > > vc4 kernel module deals with driving the HDMI and other output
> > > interfaces (whereas the v3d is the driver for the render unit), and on
> > > rpi3 and older vc4 also runs the 3D render module too.
> >
> > OK I have an rpi4, but I don't get that far:
> >
> > >>>
> > U-Boot 2023.10-00111-g7d1e5aacdb4 (Oct 08 2023 - 14:14:10 -0600)
> >
> > DRAM:  948 MiB (effective 3.9 GiB)
> > RPI 4 Model B (0xc03111)
> > Core:  205 devices, 16 uclasses, devicetree: board
> > MMC:   mmcnr at 7e300000: 1, mmc at 7e340000: 0
> > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> > In:    serial,usbkbd
> > Out:   serial,vidconsole
> > Err:   serial,vidconsole
> > Net:   eth0: ethernet at 7d580000
> > PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> > starting USB...
> > Bus xhci_pci: Register 5000420 NbrPorts 5
> > Starting the controller
> > USB XHCI 1.00
> > scanning bus xhci_pci for devices... 3 USB Device(s) found
> >        scanning usb for storage devices... 1 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > U-Boot> bootfl scan
> > Card did not respond to voltage select! : -110
> > ** Booting bootflow 'usb_mass_storage.lun0.bootdev.part_2' with efi
> > Card did not respond to voltage select! : -110
> > Failed to load EFI variables
> > ERROR: invalid device tree
> > Boot failed (err=-22)
> > <<<
> >
> > Do you know what that might be? I ask because it seems that you are
> > actually able to boot.
> >
> > I'll keep looking.
>
> This was apparently a corrupted uSD card as I tried again and it booted.

It boots up and I see a strange greenish cloud picture. But the image
disappears every 10 seconds or so. Is that the problem you are seeing?

Then I tried again with bootstd disabled and it booted with the fedora
thing in the top left. No flicker.

Then I tried again with bootstd enabled and it booted with the fedora
thing in the middle No flicker.

So I am not sure what is going on here.

I noticed this in the output when booting from Fedora (without updating U-Boot):

Found EFI removable media binary efi/boot/bootaa64.efi
Found DTB mmc 0:2 /dtb/broadcom/bcm2711-rpi-4-b.dtb

The first line looks OK, but I cannot see the second line anywhere in
the distro scripts. Also I know of no mechanism to use a DT from a
different partition than the EFI app. Could Fedora be doing something
strange here?

One last thing is that Fedora has the DT files in the root dir of
partition 1. They should be in the dtb/broadcom directory, I believe.

Regards,
Simon