RPi4 Status and sysutils/rpi-firmware

[Mark Millard]

On 2021-Mar-2, at 03:20, Emmanuel Vadot <manu at bidouilliste.com> wrote:


> Over the past years I've handled the update of the
> sysutils/rpi-firmware and sysutils/u-boot-rpi* ports.
> For that I've bought a lot of different RPI to ensure that we could
> boot on all different models that the RPI Foundation folks deliver to
> us.

Thanks for the past effort of supporting the RPi*'s.
I can easily understand the frustration.

Do not take the below as a request for any action on
your part. They are just notes about the current
context as seen from my somewhat different environment.

> . . .
> 
> 1/ Take the latest BETA4 image for RPI and burn on your sdcard
> 2/ Boot with or without hdmi screen.
> 3/ You will see that u-boot fails to init usb :
> starting USB...
> Bus xhci_pci: probe failed, error -110
> No working controllers found
> If you drop to u-boot prompt and do 'usb list' it will say that the
> usb system is stopped and you can of course not start it without having
> the above error.
> 4/ If you boot to FreeBSD everything that we support seems to work
> except for usb (of course).
> 5/ Take the two files proposed as a fix from upstream
> (https://github.com/raspberrypi/firmware/issues/1518#issuecomment-779355320)
> and copy them to the sdcard.
> 6/ Boot that and you will see that usb is working again in u-boot and
> in FreeBSD, perfect.
> 7/ Update the ports using [1] or download the files from
> github.com/raspberrypi/firmware and copy them on the sdcard (The issue
> should be fixed right ?)
> 8/ Boot that and now you find that u-boot is failing in its synchronous
> abort handler.

I use sysutils/u-boot-rpi4 with a patch for an issue that
I've reported to the lists in the past, one that makes sure
u-boot internally avoids the same pages that the kernel is
told to avoid. (I'm still at "U-Boot 2020.10 (Dec 13 2020 -
08:04:27 +0000)" for such.)

In this context I did not see a problem when I updated to the
recently published start4.elf and fixup4.dat . The context is
a RPi4B 8GiByte, USB-SSD based boot without a microsd card
involved, based on the RPi4B bootloader eeprom content:

RPi: BOOTLOADER release VERSION:c305221a DATE: Sep  3 2020 TIME: 13:11:46

Similarly, I've used https://github.com/pftf/RPi4 v1.24 that
uses the published start4.elf and fixup4.dat files and have
had no problems with the UEFI/ACPI based boot.

I expect that this overall suggests a u-boot problem for (8)
instead of a start4.elf / fixup4.dat problem. (But possibly
a different vintage of RPi bootloader eeprom content?)

> 9/ Ok, maybe updating u-boot to the latest version will fix that,
> apply patch from [2] or used the compiled file from [3].
> 10/ And this isn't fixed

I've not rebuilt based on the 2021.04 u-boot, I normally track
the port but with the patching that I've reported to the lists.

> There is probably a new or different node in the dtb that causes that
> and usually I look at what the problem is and fix it, but now I'm tired
> of doing that.

My context suggests otherwise but more testing would be
needed to know for sure.

> Updating rpi is too much time consuming for me,
> especially since I don't really care or like to work on this platform.

Again, thanks for the past time and effort on the RPi*'s.

> . . .
> 
> Links :
> 1. https://people.freebsd.org/~manu/rpi-firmware-20210222.patch
> 2. https://people.freebsd.org/~manu/u-boot-rpi-arm64-2021.01.patch
> 3. https://people.freebsd.org/~manu/u-boot-rpi-arm64-2021.01.bin

I've not used the above 3 links: I already had a context
going before today's note went out. Based on what I'd seen,
I had not expected the reported problem sequence from
(7)-(10).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)