Re: FreeBSD on RPI4 B 8G rev 1.4

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.
>>> 
>>> 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.
>> 
>> 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.
> 
> 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/010919.html

>> If you want help, describe the context and symptoms for the failure.
> 
> Just take it as a report... to the list.
> 

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].


===
Mark Millard
marklmi at yahoo.com