Date: Sat, 29 Jul 2023 13:38:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: ykla <yklaxds@gmail.com> Cc: freebsd-uboot@freebsd.org, FreeBSD ARM List <freebsd-arm@freebsd.org> Subject: Re: Some issues related to the port of Raspberry Pi. Message-ID: <301B53AB-47CD-4BCE-9888-2BEF2F2F8437@yahoo.com> In-Reply-To: <CA%2BPGaYApMXqVtDrgMa2qwo6wQ7SCbR2r1sxxLyDKDv6Vi2YFmw@mail.gmail.com> References: <CA%2BPGaYA-irqcFFW3K59rSwqwUTFu78XGmq2UiKFsngV=GY-jPg@mail.gmail.com> <B2DB655F-49E3-4C52-A971-E1F62D6CD5DE@yahoo.com> <CA%2BPGaYApMXqVtDrgMa2qwo6wQ7SCbR2r1sxxLyDKDv6Vi2YFmw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 29, 2023, at 11:30, ykla <yklaxds@gmail.com> wrote: > In = https://github.com/FreeBSD-Ask/freebsd-ports/tree/main/sysutils/rpi-firmwa= re we are indeed using the same version of Raspberry Pi firmware i.e. = 1.20230405, I am using freebsd 13.2 release of u-boot, FYI for 13.2-RELEASE (at least the RPi* aarch64 image): Its U-Boot was specially built/installed, avoiding the problematical version. After mounting the msdosfs file system from the 13.2-RELEASE RPi* aarch64 media that I have: # strings /mnt/u-boot.bin | grep "U-Boot 20" U-Boot 2022.10 (Apr 07 2023 - 02:47:36 +0000) > which one are you using? I already indicated my U-Boot context in the material that you replied to: QUOTE I actually use my own U-Boot build, in part because some of my USB3 boot media require something like a usb_pgood_delay for U-Boot to tolerate them. My in-use build is based on 2023.01 : # strings /boot/efi/u-boot.bin.2023.01.arm64 | grep "U-Boot 20" U-Boot 2023.01 (Feb 06 2023 - 08:06:49 +0000) END QUOTE I'll note that one way to identify the RPi* firmware build in the tagged release is to do the likes of: # strings /boot/efi/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 10:50:39 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Mar 17 2023 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 82f3750a65fadae9a38077e3c2e217ad158c8d54 (clean) on the start*.elf file of interest. Sometimes a new tagged release is for changes elsewhere and this part does not change. The above from 1.20230405 is actually unchanged from the prior 1.20230317 tagged release, for example. Another thing that is involved is the RPi* EEPROM content's vintage. The tagged versions of the files used to update the EEPROM can be accessed via: https://github.com/raspberrypi/rpi-eeprom/tags/ An oddity of the last release for this is that it has 2 tags for bf7419c: a) 1 based on YYYY.MM.DD (normal): v2023.01.11-138c0 and: b) 1 based on YYYY.DD.MM (unusual): v2023.11.01-138c0 Again, if I can, I tend to use tagged releases of these, not development versions. I'm not aware of being able to use FreeBSD to manage the EEPROM contents. I use RaspiOS64 (my abbreviation) for such management. > Mark Millard <marklmi@yahoo.com> =E4=BA=8E 2023=E5=B9=B47=E6=9C=8830=E6=97= =A5=E5=91=A8=E6=97=A5 =E4=B8=8A=E5=8D=882:07=E5=86=99=E9=81=93=EF=BC=9A > On Jul 29, 2023, at 09:23, ykla <yklaxds@gmail.com> wrote: > >=20 > > Hi, > > However, strangely, when I replaced the rpi4-firmware in the ports = with the latest version from the official Raspberry Pi source and copied = it to a USB drive, the system started to loop with the following code. > >=20 > > --------------- > >=20 > > Net: eth0:ethernet@7d580000 > > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > > starting USB=E2=80=A6=E2=80=A6 > > Bus xhci_pci:Reglster 58000420 NbrPorts 5 > > Starting the contorller > > USB XHCI 1.00 > > scanning bug xhci_pci for devices... Unexpected XHCI event TRB, = Skipping I'll note that I've never gotten that "Unexpected XHCI event TRB" message historically. So I'm not familiar with what leads to it. > > 6a0 000000004 01000000 01008401) >=20 > That output looks like U-Boot output, before FreeBSD's UEFI loader > has been loaded. (I'd be more sure if there was more context.) Of > course the RPi* firmware and .dtb starts being involved before > U-Boot starts and, so, is involved. >=20 > I actually use my own U-Boot build, in part because some of my USB3 > boot media require something like a usb_pgood_delay for U-Boot to > tolerate them. My in-use build is based on 2023.01 : >=20 > # strings /boot/efi/u-boot.bin.2023.01.arm64 | grep "U-Boot 20" > U-Boot 2023.01 (Feb 06 2023 - 08:06:49 +0000) >=20 > (My config.txt references that name.) >=20 > So, the later material below is not based on the same U-Boot that > you are using. >=20 > > --------------- > > The original author seems to have abandoned the project, so I forked = a copy from the ports archive. You can find it here: = https://github.com/FreeBSD-Ask/rpi3-psci-monitor and = https://github.com/FreeBSD-Ask/freebsd-ports/tree/main/sysutils/rpi-firmwa= re > > I don't understand programming very well. Can someone help me with = this problem? > >=20 > > Additionally, the author of raspberrypi-userland (who is the same = person as the firmware's port author) has also deleted the project. = There is currently no upstream for this project > >=20 > > The current Raspberry Pi 4B 8GB version has issues with booting. The = current u-boot booting process gets stuck at the rainbow screen.see also = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272792 > > If someone could provide assistance, I would be very grateful. > >=20 > > I'm not sure if the upstream has made any fixes for this issue. > >=20 >=20 > I expect that you may not be using an officially tagged release > but instead are using a development version of the RPi* firmware. > I avoid the development versions when I can. >=20 > I had no trouble with the firmware-1.20230405 materials, the > most recent tagged release available. The RPi4B context is > the 8 GiByte Rev 1.5 with the "C0T" part number label on the > top of the SOC. >=20 > The tagged versions are available via: >=20 > https://github.com/raspberrypi/firmware/tags/ >=20 > The most recent there is: >=20 > https://github.com/raspberrypi/firmware/releases/tag/1.20230405/ >=20 > I downloaded: >=20 > = https://github.com/raspberrypi/firmware/archive/refs/tags/1.20230405.tar.g= z >=20 > and did: >=20 > # tar -xf 1.20230405.tar.gz firmware-1.20230405/boot/ = firmware-1.20230405/README.md > # rm ~/firmware-1.20230405/boot/kernel*.img >=20 > to extract the relvent material. >=20 > I updated one of the RPi4B USB3 boot media to have this firmware > (and .dtb's) in its msdosfs file system. >=20 > It booted the 8 GiByte RPi4B Rev 1.5 just fine (based, in > part, on my U-Boot build, however). >=20 > The media I picked to test with has not had its FreeBSD updated > in a while: >=20 > # uname -apKU > FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #90 = main-n261544-cee09bda03c8-dirty: Wed Mar 15 20:25:49 PDT 2023 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400082 1400082 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?301B53AB-47CD-4BCE-9888-2BEF2F2F8437>