Re: FreeBSD on RPI4 B 8G rev 1.4

On Dec 6, 2022, at 08:56, adr <adr@SDF.ORG> 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. If you want help, describe the context
and symptoms for the failure.

Given the lack of background information, my notes below may
reference things that do not apply to your context: general
notes.

One issue is that you can not use modern RPi* firmware. You
should use the RPi* firmware that is in the ports tree. The
official FreeBSD build materials are based on that. (I tend
to use something somewhat newer but I self support such and
did my own testing.) The FreeBSD kernel mishandles the modern
Device Tree content ordering, leading to a crash.

Note: PCIe is internally involved with the XHCI (USB3) hardware.
This explains the references to PCIe below.

I use both FDT and ACPI style booting of various Rev 1.4 "B0T"
8 GiByte RPi4B's without using a 3 GiByte mode. ("B0T" is from
the end of an ID printed on top of the SOC. "C0T" ones no
longer have the bad wrapper logic around the PCIe block. But
FDT based FreeBSD support does not treat "C0T" parts any
differently. "C0T" work just as well that way.)

For FDT based booting, I've had no problems testing/using
official build FreeBSD materials for releng/13.* , stable/13 ,
or main [so: 14]. (But I also sometimes run with a patch that
assigns a different highest DMA address to use with the PCIe.
Both ranges work for what I've been doing. NetBSD vs. OpenBSD
varies the address range used as well, last I knew.)

For ACPI, FreeBSD does not have the handling of limited address
range for PCIe bus mastering in the "B0T" parts. This can be
tested via duplicating huge files in 8 GiByte mode (such
as, significantly bigger than RAM) --and if that completes
comparing the files. The fairly recent UFS valdiation code added
tends to catch problems during the copy. Previously it was
silently corrupting some data. I have a patch to the sources
that I use to deal with making ACPI respect the "B0T"
limitation: ACPI does provide the information. So my ACPI use
is with 8 GiBytes --but via my self support for the issue.

WARNING: the huge file testing can corrupt the file system
beyond repair when FreeBSD is not using a correctly limited
address range. Test only media that it is okay to reinitialize
to see if a combination of materials is working!

(It turns out that, like FreeBSD's kernel, the ACPI
implementation always indicates a configuration valid for the
"B0T" DMA addressing limitation, even on "C0T" parts. Again,
"C0T" works fine that way.)

Note: the emmc2bus in the "B0T" parts also have a addressing
limitation that is not in the "C0T" parts. I've not yet done
any testing for this.

> I didn't expect this limitation after reading the
> wiki. The xhci dma bug has been corrected in netbsd and openbsd.
> Could someone share the state of this issue in freebsd? Also with
> acpi the ethernet interface is not detected, I'm using RTL8152/3
> usb cards.

FreeBSD has no ACPI drivers that cover the built-in Ethernet.
To my knowledge, the FreeBSD folks that used to work on the
RPi* support never claimed any ACPI support: only the
port U-Boot's FDT --and only with the versions of RPi*
firmware that have in the ports tree a the time.

The same sort of thing applies to trying to use microsd cards
in the built-in slot from FreeBSD after ACPI booting: no ACPI
drivers that cover the context.

The normal U-Boot FDT configuration has both of these working.

Use of ACPI is historically: strictly self-support.


> I'm impressed with the performance (without overclocking the cpu),
> really impressed. And the usb subsystem looks more stable. I had
> problems in the past (and in the present with other bsds), like the
> system crashing when attaching or detaching some devices.
> 
> Apart from the loss of ram and the inconvenience of not be able to
> use the ethernet interface, I'm feeling very comfortable right
> know.

Glad it is working okay for your context.

===
Mark Millard
marklmi at yahoo.com