RPi4 Status and sysutils/rpi-firmware [BETA4 with *.dtb start4.elf fixup4.dat updates works in my context, no u-boot update]
Emmanuel Vadot
manu at bidouilliste.com
Wed Mar 3 12:12:22 UTC 2021
On Wed, 3 Mar 2021 04:00:32 -0800
Mark Millard <marklmi at yahoo.com> wrote:
>
>
> 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.
Crap, yes indeed, I first did this patch when I saw a commit with
updated files but did not test at that time and didn't looked again
later ...
Well, I'll test this update and commit an update if that fixes things
for me but this will still be my last update on this ports.
Thanks for looking deeper ;)
> >> # 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)
>
--
Emmanuel Vadot <manu at bidouilliste.com> <manu at FreeBSD.org>
More information about the freebsd-arm
mailing list