Date: Wed, 3 Mar 2021 04:00:32 -0800 From: Mark Millard <marklmi@yahoo.com> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Re: RPi4 Status and sysutils/rpi-firmware [BETA4 with *.dtb start4.elf fixup4.dat updates works in my context, no u-boot update] Message-ID: <5DA731CD-9EFC-440F-9BDF-615CB7D289ED@yahoo.com> In-Reply-To: <20210303090531.3bc790d12f456ee45c470825@bidouilliste.com> References: <20210302122057.86ba62bb1daa7f922134ecd9@bidouilliste.com> <3399FAC5-6594-4AF6-B9F1-F2CFAB3E64EA@yahoo.com> <A04DE97F-AE75-4283-9266-36DB1F2FE1CD@yahoo.com> <20210303090531.3bc790d12f456ee45c470825@bidouilliste.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@yahoo.com> wrote: >=20 >>=20 >>=20 >>> On 2021-Mar-2, at 10:50, Mark Millard <marklmi at yahoo.com> wrote: >>>=20 >>=20 >> So I tried to start an approximate replicate-problems sequence, >> documented below. >>=20 >>=20 >>> On 2021-Mar-2, at 03:20, Emmanuel Vadot <manu at bidouilliste.com> = wrote: >>>=20 >>>=20 >>>> 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. >>>=20 >>> Thanks for the past effort of supporting the RPi*'s. >>> I can easily understand the frustration. >>>=20 >>> 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. >>>=20 >>>> . . . >>>>=20 >>>> 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 >>=20 >> I made a FreeBSD-13.0-BETA4-arm64-aarch64-RPI.img on >> a microsd card and replicated this. >>=20 >>>> 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-77935532= 0) >>>> and copy them to the sdcard. >>=20 >> I did not try the issue 1518 files: Skipping (5) and (6). >>=20 >>>> 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 ?) >>=20 >> 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: >=20 > 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 =3D 1614679337 +SHA256 (raspberrypi-firmware-1.20210222.g20210222-cb8cbb2_GH0.tar.gz) =3D= bb34b5d0cb04d4ec2161954af78310825ee7f6a580f313af523ff50ddd71fa52 +SIZE (raspberrypi-firmware-1.20210222.g20210222-cb8cbb2_GH0.tar.gz) =3D = 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) . . . >>=20 >> (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. >>>=20 >>=20 >> With the *.dtb files included, boots fine and supports my USB SSD = being >> plugged in: >>=20 >> 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 =3D 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=3D0x2<NO_6_BYTE> >> . . . >> root@generic:~ # gpart show=20 >> =3D> 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) >>=20 >> =3D> 0 62228537 mmcsd0s2 BSD (30G) >> 0 57 - free - (29K) >> 57 62228480 1 freebsd-ufs (30G) >>=20 >> =3D> 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) >>=20 >> =3D> 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@generic:~ # mount -onoatime /dev/gpt/RPi4Broot /mnt >> root@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 >=20 > 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.) >>>=20 >>> 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: >>>=20 >>> RPi: BOOTLOADER release VERSION:c305221a DATE: Sep 3 2020 TIME: = 13:11:46 >>>=20 >>> 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. >>>=20 >>> 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?) >>=20 >> 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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5DA731CD-9EFC-440F-9BDF-615CB7D289ED>