Re: Compiling device tree overlays

On Jan 31, 2023, at 19:15, John Rushford <jjrushford@gmail.com> wrote:

> The additional uarts on raspberry pi 4 do not function in FreeBSD 13.1.  I’ve built the rpi-firmware port but it seems to extract pre-built dtb’s for Linux,

The RPi* firmware dtb's are ones from the RPi* folks, which
are the ones used by FreeBSD. They are an old version. The
*.dtb's match the other firmware contained. Arbitrary mixing 
nd matching of .dtb versions vs. firmware versions is not
supported by anyone as far as I know.

The FreeBSD kernel crashes on any rpi* firmware version that is
fairly modern last I knew. The crash is tied to mishandling the
*.dtb content in the wrong order, causing a use before
initialization. I've:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268835

with a patch to fix the crash issue by causing the correct ordering.
That could allow experiments with more recent versions without
having to deal with the crashes (at least).

Note: I do not expect that updated RPi* firwmare(+ *.dtb 's) would
make any difference for what you are doing. But, right now, any
direct exploration of such is blocked by the crashes for the kernel
as it is.

> at least that’s my understanding.
> I install these pre-built dtb’s into the boot/msdos/overlays directory

*.dtb files and *.dtbo files are different by purpose, despite
a common format.

*.dtbo 's go in overlays/
*.dtb 's do not.

FYI: The RPi* firmware reads in the appropriate *.dtb and modifies
parts of the live Devicie Tree to match various hardware details,
such as for "B0T" vs. "C0T" BCM2711's. Some of the detail from the
*.dtb can not be depended on.

Loading *.dtbo's makes more modifications to the live Device Tree.

> and I then try to enable uart3 with ‘dtoverlay=uart3’ in config.txt.  I can see after boot that there is an additional ttyu1 and cuau1 but,
> Neither of these functions.  Using vmstat -I I see no interrupts generated for uart3 when I open the ttyu1 or cuau1 with “cu -l”.  Also, when I write data to the device file, the write blocks.  
> Using ‘watch’ on /dev/ttyu1, I see no data read ever.  I have a GPS card wired up to uart3 and I do not see the NMEA data there but when I change out the SD card and boot into Debian, uart3 works fine.
> 
> So, I’m thinking there may be an issue with the pre-built dtb’s and am trying to make changes to ./sys/contrib/device-tree/src/arm/bcm2711.dtsi

sys/contrib/device-tree/src/arm/ materials for RPI*'s are from
the Linux mainline kernel and need not match the ones from the
RPi* folks. (Last I knew they did not.) FreeBSD does not build
these nor did it intend to use these. That is part of why there
is a separate port for bringing the RPi* firmware into the
FreeBSD environment.

> to troubleshoot uart3.  I’m a newbie to raspberry pi and device tree overlays.
> I do not know how to compile my changes and build a new uart3.dtbo

To my knowledge, bcm2711.dtsi is not involved in building
uart3.dtbo at all, just building the *.dtb . (But, I'm no
expert.)

> and am unable to find any documentation on this.  I was wondering if someone could help me out with this task?

FreeBSD may need changes for it to work for the extra UARTs in
RPi4B's. To my knowledge, no kernel work was done to support
such new things explicitly: the UART support is the same as
it was for the prior RPi*'s as far as I know: 2 UARTs, both
for the same serial connection, other other UART possibly used
internally for Bluetooth (or otherwise ignored). Prior to the
RPi4B's that is all there was for serial connections.

While FreeBSD may need changes, I doubt that FreeBSD would ever
provide changes to the RPi* firmware materials that would make
them any different than those gotten from upstream.

In other words, I expect you are working at the wrong end of
the chain of software involved.

A problem here is that, to my knowledge, no one actively works
on any significant RPi* related FreeBSD support any more, and
has not for a significant time. For example, the lack of
documentation has been a large problem even for the folks that
are knowledgable in the general subject areas --and it has been
just too painful to deal with. Anyone that tried has
eventually stopped. (FreeBSD committers still support committing
work by others that appears to make sense to them. That is not
the same as the kind of activity I'm referencing.)

(I'm not generally knowledgable in most of the relevant
background material. It took me months to discover the tiny
changes that are in the patch that I referenced earlier
--including discovering their appropriateness to dealing with
Device Tree handling.)

===
Mark Millard
marklmi at yahoo.com