RPi4 Status and sysutils/rpi-firmware [BETA4 with *.dtb start4.elf fixup4.dat updates works in my context, no u-boot update]
Mark Millard
marklmi at yahoo.com
Tue Mar 2 20:33:37 UTC 2021
> On 2021-Mar-2, at 10:50, Mark Millard <marklmi at yahoo.com> wrote:
>
So I tried to start an approximate replicate-problems sequence,
documented below.
> 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
I made a FreeBSD-13.0-BETA4-arm64-aarch64-RPI.img on
a microsd card and replicated this.
>> 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.
I did not try the issue 1518 files: Skipping (5) and (6).
>> 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 ?)
Here I also included the *.dtb files relevant to
RPi4B's (and analogous), resulting in the following
files being updated on the otherwise BETA4 media:
# ls -Tldt /boot/msdos/*
-rwxr-xr-x 1 root wheel 49090 Feb 27 03:24:30 2021 /boot/msdos/bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root wheel 48794 Feb 27 03:24:30 2021 /boot/msdos/bcm2711-rpi-400.dtb
-rwxr-xr-x 1 root wheel 49202 Feb 27 03:24:30 2021 /boot/msdos/bcm2711-rpi-cm4.dtb
-rwxr-xr-x 1 root wheel 5448 Feb 27 03:24:28 2021 /boot/msdos/fixup4.dat
-rwxr-xr-x 1 root wheel 2228800 Feb 27 03:24:28 2021 /boot/msdos/start4.elf
. . . (others unchanged) . . .
(That u-boot required the more modern *.dtb's was something
I knew from past list activity: the newer *.dtb's provide
something that u-boot uses to decide to handle the potential
lack of the eeprom for the xhci.)
>> 8/ Boot that and now you find that u-boot is failing in its synchronous
>> abort handler.
>
With the *.dtb files included, boots fine and supports my USB SSD being
plugged in:
ugen0.3: <OWC Envoy Pro mini> at usbus0
umass0 on uhub0
umass0: <OWC Envoy Pro mini, class 0/0, rev 3.00/1.00, addr 2> on usbus0
umass0: SCSI over Bulk-Only; quirks = 0x0100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number 000000000011
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
. . .
root at generic:~ # gpart show
=> 63 62333889 mmcsd0 MBR (30G)
63 2016 - free - (1.0M)
2079 102312 1 fat32lba [active] (50M)
104391 62228537 2 freebsd (30G)
62332928 1024 - free - (512K)
=> 0 62228537 mmcsd0s2 BSD (30G)
0 57 - free - (29K)
57 62228480 1 freebsd-ufs (30G)
=> 40 468862048 da0 GPT (224G)
40 2008 - free - (1.0M)
2048 413138944 1 freebsd-ufs (197G)
413140992 9437184 2 freebsd-swap (4.5G)
422578176 204800 3 efi (100M)
422782976 46079112 - free - (22G)
=> 40 468862048 diskid/DISK-000000000011 GPT (224G)
40 2008 - free - (1.0M)
2048 413138944 1 freebsd-ufs (197G)
413140992 9437184 2 freebsd-swap (4.5G)
422578176 204800 3 efi (100M)
422782976 46079112 - free - (22G)
. . .
root at generic:~ # mount -onoatime /dev/gpt/RPi4Broot /mnt
root at generic:~ # ls -Tld /mnt/*
-r--r--r-- 1 root wheel 6109 Jan 7 08:22:59 2021 /mnt/COPYRIGHT
drwxr-xr-x 2 root wheel 1024 Feb 9 21:52:22 2021 /mnt/bin
drwxr-xr-x 22 root wheel 1536 Mar 2 20:07:27 2021 /mnt/boot
dr-xr-xr-x 2 root wheel 512 Mar 30 12:25:14 2020 /mnt/dev
-rw------- 1 root wheel 4096 Mar 2 20:07:27 2021 /mnt/entropy
drwxr-xr-x 27 root wheel 2560 Feb 9 21:53:45 2021 /mnt/etc
drwxr-xr-x 5 root wheel 2048 Feb 9 21:52:12 2021 /mnt/lib
drwxr-xr-x 3 root wheel 512 Feb 9 21:51:38 2021 /mnt/libexec
drwx------ 2 root wheel 512 Jul 25 04:28:53 2020 /mnt/lost+found
drwxr-xr-x 2 root wheel 512 Mar 30 12:25:14 2020 /mnt/media
drwxr-xr-x 2 root wheel 512 Sep 26 05:03:33 2020 /mnt/microsd_efi
drwxr-xr-x 2 root wheel 512 Mar 22 19:19:37 2020 /mnt/microsd_ufs
drwxr-xr-x 2 root wheel 512 Mar 30 12:25:14 2020 /mnt/mnt
drwxr-xr-x 2 root wheel 512 Mar 30 12:25:14 2020 /mnt/net
dr-xr-xr-x 2 root wheel 512 Mar 30 12:25:14 2020 /mnt/proc
drwxr-xr-x 2 root wheel 2560 Feb 9 21:52:12 2021 /mnt/rescue
-rw------- 1 root wheel 137380424 Aug 9 03:09:20 2020 /mnt/restoresymtable
drwxr-xr-x 21 root wheel 4608 Feb 27 21:40:06 2021 /mnt/root
drwxr-xr-x 2 root wheel 2560 Feb 9 21:52:30 2021 /mnt/sbin
lrwxr-xr-x 1 root wheel 11 May 2 02:22:54 2018 /mnt/sys -> usr/src/sys
drwxrwxrwt 61 root wheel 3584 Mar 2 20:07:26 2021 /mnt/tmp
drwxr-xr-x 2 root wheel 512 May 20 01:52:47 2020 /mnt/usb_efi
drwxr-xr-x 17 root wheel 512 Mar 30 12:25:13 2020 /mnt/usr
drwxr-xr-x 26 root wheel 512 Mar 2 19:48:16 2021 /mnt/var
drwxr-xr-x 3 root wheel 512 Sep 18 20:04:15 2018 /mnt/wrkdirs
> 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?)
Turns out to be a lack of *.dtb updates instead of u-boot
itself.
Of course, this does not validate any other context that
sysutils/u-boot-rpi-arm64 is intended to support.
But it does indicate that a "with *.dtb" sysutils/rpi-firmware
update and its used would fix the RPi4B for the USB issue on
RPi4B 8 GiByte machines.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list