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
Wed Mar 3 12:00:41 UTC 2021
On 2021-Mar-3, at 00:05, Emmanuel Vadot <manu at bidouilliste.com> wrote:
> On Tue, 2 Mar 2021 12:33:29 -0800
> Mark Millard <marklmi at yahoo.com> wrote:
>
>>
>>
>>> 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:
>
> I also did that, sorry if I wasn't clear.
> I've updated all the start* fixup* *dtb and bootcode.bin files on the
> sdcard as this is what would have been done if the ports was updated
> on the futur images that we provide.
I just looked at your patch and it specified the version
before the updates to the firmware were released, likely
explaining our differing results:
+TIMESTAMP = 1614679337
+SHA256 (raspberrypi-firmware-1.20210222.g20210222-cb8cbb2_GH0.tar.gz) = bb34b5d0cb04d4ec2161954af78310825ee7f6a580f313af523ff50ddd71fa52
+SIZE (raspberrypi-firmware-1.20210222.g20210222-cb8cbb2_GH0.tar.gz) = 192229572
https://github.com/raspberrypi/firmware/commits/master shows . . .
cb8cbb2 is:
Commits on Feb 22, 2021
kernel: Bump to 5.10.17
Then there are 2 more relevant updates . . .
7872272 is:
Commits on Feb 24, 2021
firmware: platform: vl805: Get BAR2 address from PCIe BAR2 registers
(That is the one for fixing issue 1518 but it has another
issue that solidly needs a fix. See below.)
5985247 is:
Commits on Feb 25, 2021
firmware: arm_loader: Return all borrowed DMA channels
(Specifically DMA channel 6 is known to have been messed
up by the firmware.)
I used materials originally taken from 5985247 so we did
not match in what we tested.
>> # 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.)
We did not match for start4.elf and fixup4.dat . The .dtb tested
was newer as well, but might not have made a difference given
those two mismatches. My notes over emphasize the *.dtb .
>>>> 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
>
> Ok well the fact that it works for your board and not mine confort me
> that there is some difference in boards and that it's hard to maintain
> this port for someone who doesn't really care about this platform tbh.
Looks to me like file version differences, not necessarily board
differences in this case.
>>> 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.
I got that "turns out" wrong because I assumed that we had
a start4.elf and fixup4.dat match. I should have validated
the status at the time.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list