Date: Tue, 6 Dec 2022 13:32:21 -0800 From: Mark Millard <marklmi@yahoo.com> To: adr <adr@SDF.ORG> Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on RPI4 B 8G rev 1.4 Message-ID: <6A1481BE-7312-4912-A353-F2CF71B20060@yahoo.com> In-Reply-To: <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG> References: <9c587c3-b6e5-fbe2-7dcc-f7d98dd47ace@SDF.ORG> <047DB634-2D87-402D-A65C-A4F517E042BD@yahoo.com> <3ebd7048-213e-8920-dfe5-44f6a1e5f3ac@SDF.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 6, 2022, at 12:25, adr <adr@SDF.ORG> wrote: > On Tue, 6 Dec 2022, Mark Millard wrote: >>> I'm giving a try again to freebsd in arm (I'd problems before) >>> looking principally for system stability and a reasonable state of >>> the ports tree, something I can't find anymore in other BSDs, at >>> least with arm. >>>=20 >>> I'm using at this moment an Rpi4 B 8G rev 1.4. The only way I can >>> run this board no matter of using 13 release, stable or current >>> is with the EDK2 uefi firmware, in acpi mode only, and only with >>> the ram limit. >>=20 >> I assume this means you run into some sort of failure(s) in some >> kind(s) of contexts. But you do not describe the contexts and >> their kinds of failures. >=20 > Yes, I could be more specific. When I said "the only way > I can run..." I mean the official images don't even boot. How? Fails at what point? I have USB3 NVMe based boot media that that fail to be found in U-Boot. I build and use a patched U-Boot that provides a usb_pgood_delay value of 2000 that is sufficient to allow that media to boot. As near as I can tell, the media requires more time for something than the USB3 standards indicate. The usb_pgood_delay value happens to give it more time in U-Boot in a sufficient manor. (There may be other, more appropriate settings for all I know.) But, again, without your reporting the likes of the serial console text leading up to the failure, I've no clue if this is relevant to your context vs. not. (The ACPI booting works with the USB NVMe based media just fine, no adjustments to the internals of EDK2.) (I have other USB3 SSD based media that do not require the usb_pgood_delay assignment. But I use the same U-Boot for them all --where I use U-Boot.) > The errors differ but they were related to xhci I think. I'll make > some test with the u-boot in ports, but after reading your experience > with other rev 1.4 boards I wonder if this could be related with > the eeprom firmware, if this is even possible. I currently use rpi-boot-eeprom-recovery-2022-04-26-vl805-000138a1 , which is one of the official releases listed at: https://github.com/raspberrypi/rpi-eeprom/releases There is a newer release listed as of yesterday: rpi-boot-eeprom-recovery-2022-11-25-vl805-000138a1 I've not tried it. I use RaspiOS64 (my abbreviation of their naming) to deal with such EEPROM updates, not FreeBSD. > The xhci|pci dma bug on the 2711B0 is well known, and if it is not > dealt with, you know the hell that is coming specially if your root > file system is in a usb device. All my normal boot media for booting FreeBSD on the RPi4B's (4 GiByte and 8 GiByte) the are USB3 media. I do not use a microsd card for booting such at all. The whole/only UFS or ZFS file system normally used is on that media. Again, I've only seen the > 3 GiByte problem via a FreeBSD not patched for ACPI DMA range handling but that was being used in an ACPI context. (Wording ignores the time frame of original effort to handle the > 3 GiByte issue via u-Boot FDT style booting.) (The patch supporting ACPI use is actually someone else's that failed in my testing [the huge file duplication tests] and I later figured out what the issue was and how to adjust it.) > Also ufs+su+j seems to have a funny > way to recover states with zeroed files, but that's another > discussion. For UFS I use UFS+SU (no J). Other boot media uses ZFS (for bectl use, not redundancy). I'll note that: git: 78f412987605 - main - Enable taking snapshots on UFS/FFS = filesystems using journaled soft updates. is only as of 2022-Nov-13. See: = https://lists.freebsd.org/archives/dev-commits-src-main/2022-November/0109= 19.html >> If you want help, describe the context and symptoms for the failure. >=20 > Just take it as a report... to the list. >=20 Well, even if you were not after help, I can not tell if you have found a different problem than I've ever seen. There is no way for me to know, given what has been reported vs. not. (I've definitely seen a variety of boot failures over different stages on the RPi4B's in a varienty of U-Boot and ACPI based booting.) I was surprised at the reference to standard FreeBSD builds (or other port U-Boot based contexts) failing to boot (presuming it got past U-Boot finding the USB boot media after its reset of the bus). The U-Boot context surprise, mixed with lack of being able to tell if something new to me was being reported, lead to my sending out the notes. Even for ACPI, I would expect it to boot without the 3 GiByte limit. But other forms of testing would show the context to be bad [e.g., the huge file duplication tests]. =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?6A1481BE-7312-4912-A353-F2CF71B20060>