Date: Sat, 9 Jan 2021 14:26:45 -0800 From: Mark Millard <marklmi@yahoo.com> To: "portscout@freebsd.org" <portscout@FreeBSD.org>, freebsd-arm <freebsd-arm@freebsd.org> Cc: uboot@freebsd.org Subject: Re: Rpi-firmware notes Message-ID: <893B108B-3FDC-499B-97C4-CBF1D4EF0272@yahoo.com> In-Reply-To: <C40616FF-7FEF-4B4B-95DC-8C1F9021C659@yahoo.com> References: <202101090902.10992SRO077874@portscout.nyi.freebsd.org> <C40616FF-7FEF-4B4B-95DC-8C1F9021C659@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-9, at 11:41, Mark Millard <marklmi at yahoo.com> wrote: > On 2021-Jan-9, at 01:02, portscout@freebsd.org <portscout at = FreeBSD.org> wrote: >=20 >> Dear port maintainer, >>=20 >> The portscout new distfile checker has detected that one or more of = your >> ports appears to be out of date. Please take the opportunity to check >> each of the ports listed below, and if possible and appropriate, >> submit/commit an update. If any ports have already been updated, you = can >> safely ignore the entry. >>=20 >> You will not be e-mailed again for any of the port/version = combinations >> below. >>=20 >> Full details can be found at the following URL: >> http://portscout.freebsd.org/uboot@freebsd.org.html >>=20 >>=20 >> Port | Current version | = New version >> = ------------------------------------------------+-----------------+-------= ----- >> sysutils/rpi-firmware | = 1.20201201.g20201201| 1.20210108.master >> = ------------------------------------------------+-----------------+-------= ----- >>=20 >>=20 > . . . >=20 > I will note that pftf/RPi4 (the UEFI/ACPI software) has > reverted to using RPi firmware from before 2020.12.08 as > of 3 days ago. For why, see: >=20 > https://github.com/raspberrypi/firmware/issues/1518 >=20 > For what they changed in what they extract: >=20 > = https://github.com/pftf/RPi4/commit/8fcd5bc6fd04e78cf8460f5176739340751672= 4e >=20 > pftf/RPi4 is now using: >=20 > = https://github.com/raspberrypi/firmware/raw/08ed7a0c9ad4d9db559aaec462520a= b435c7ce1c/boot/ >=20 > to select just start4.elf and fixup4.dat . Turns out that https://github.com/pftf/RPi4/releases/tag/v1.22 has a more explicit note: QUOTE Important Note: The start4.elf and fixup4.dat used in this release are = the 2020.12.01 ones, as using newer versions broke xHCI initialization = (raspberrypi/firmware#1518, raspberrypi/firmware#1495) with newer = revisions of the Bcm2711 SoC. Do not be tempted to use more recent = versions of start4.elf, as, unless you are using an old Pi 4 model, this = will most likely break USB support. END QUOTE As for v1.22 update, it reports: Raspberry Pi 4 UEFI Firmware v1.22 =E2=80=A2 Fix settings not being stored or being corrupted on = reset (#78, #82) = [tianocore/edk2-platforms@94e9fbatianocore/edk2-platforms@ae6c236] =E2=80=A2 Add internal changes for the eventual support of CM4 & = Pi400 [tianocore/edk2-platforms@100e360] =E2=80=A2 Fix type of PMU GSIV in GICC (#103) = [tianocore/edk2-platforms@734fed7] =E2=80=A2 Switch back to the old coloured logo = [tianocore/edk2-non-osi@3d1bb66] =E2=80=A2 Fix cursor appearing on top of logo (#115) = [tianocore/edk2@b585238] As I understand, start4.elf and fixup4.dat reverting were associated with the "Fix settings not being stored or being corrupted on reset". Other notes if anyone that might want to use material extracted from v1.22: So far as I know, FreeBSD use of UEFI/ACPI via the v1.22 means of = booting should still have the 3 GiByte limitation in place for reliable = operation, otherwise things like unreliable file copies can silently happen in FreeBSD. (So far as I know, no one is systematically trying to support UEFI/ACPI booting for the RPI4B's in FreeBSD: the effort is primarily = going to u-boot based booting.) I am using the rpi-firmware subset of the UEFI/ACPI materials from = v1.22, even for booting via my u-boot build. bcm2711-rpi-4-b.dtb is recent = enough to allow the 8GiByte RPi4B's to boot via a USB3 SSD, no microsd card involved. (I've got things set up so that just swapping config.txt content swaps between u-boot and UEFI/ACPI based booting.) So far, historically, I've (eventually) learned more about the = rpi-firmware problems and what vintages work better via monitoring the UEFI/ACPI project's information about such then I have learned other ways, at = least fairly generally. =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?893B108B-3FDC-499B-97C4-CBF1D4EF0272>