Re: Beaglebone Black/Green/Blue support (volunteering)

On Sep 17, 2024, at 23:44, Sulev-Madis Silber <freebsd-arm-freebsd-org097@ketas.si.pri.ee> wrote:

> i'm looking forward to replace current from 2014 in my one singular bbb with newer one
> 
> is it only because fdt? i proposed to just use own fdt like earlier but people told sorry can't do that. to that i was like how about i supply my own fdt then?
> 
> then, why is fdt such a shitshow anyway? or it works in linux as is, or? or it changes often? to my still limited knowledge that just defines a hw, why would it change, as hw doesn't?

My understanding of the operating principles here:

The FDT provides a mapping between the Linux kernel's way
of working and the hardware. When Linux changes how the
kernel works the Linux FDT tracks the redesign. The two
are not independent. In essence, the FDT is a form of
kernel data structure. Multiple distinct FDT's can
describe the exact same hardware: the hardware of itself
does not uniquely determine the FDT for that hardware.

Some contexts have fairly stable Linux kernel designs and,
so, fairly stable FDTs; others do not.

So, one can get evidence about some of what is being
significantly reworked over time in the Linux kernel via
the seeing the repeated FDT restructuring over the time
frame. This contrasts with other context's FDTs being
stable because there is a lack of such Linux kernel
driven changes to that FDT.

So, when FreeBSD sees the linux FDT has changed and has to
adjust for such, it is actually tracking some consequences
of the Linux kernel rework activity that changed both the
Linux kernel and the FDT.

At least, that is my understanding.

FreeBSD does not have the resources to develop and use its
own FDT's overall and simply chooses to track an upstream
source of a context's FDT(s) instead. In the case of RPi*'s,
it is not mainline Linux FDT's that are tracked --but the
FDT's are from a Linux kernel context. (I'm not sure if
RPi*'s have the only non-main-line FDT's used.)

> so am i correct, we throw that thing out just because it's super hard to use fdt from linux?
. . .

How difficult or messy or frequently FDT tracking is
involved varies widely across the various contexts.
It is not a uniform global property for all Linux FDTs.

. . .
> while there, how do all the people dev for armv7?

Many aarch64 systems can execute armv7 code and so
serve as a means of building armv7 code with armv7
tools (armv7 jail's, armv7 chroot's, possibly even
lib32). Such is generally more reliable and less time
consuming than use of qemu for "cross-activity" many
context that try to use qemu.

The official FreeBSD armv7 packages are built on
aarch64 systems that can execute armv7 code. This
uses armv7 poudriere jails. It works a lot better
than the historical qemu use on amd64 before these
ampere[123] aarch64 machines were available (or
were not yet used this way).

Some folks use the likes of Windows Dev Kit 2023's
or RPi4B's or RPi5B's for such activities of their
own. (Apple M1/M2/M3/M4 do not support armv7 code
and so are not example contexts for doing these
sorts of things without qemu involved.)

===
Mark Millard
marklmi at yahoo.com