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 08:05:35 UTC 2021


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.

> # 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

 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.

> > 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)
> 


-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at FreeBSD.org>


More information about the freebsd-arm mailing list