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

On Wed, Sep 18, 2024 at 9:31 AM Mark Millard <marklmi@yahoo.com> wrote:

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

The theory is that DTS is a stable, OS independent description of the
hardware. Some hardware vendors and their maintainers really believe this.
The practice, though, is that some just have it be whatever is convenient
for their drivers, which they change around a lot to get better
performance, or when new hardware comes out.


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

Close. In reality, the TI DTS are the most unstable. The rest are fairly
stable and generally easy enough for us to use.


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

RPi do have a bit of churn, but the problems with getting base
documentation more than FDT.


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

Yea, the Apple M3 I have is where I run much of the armv7 code in a FreeBSD
VM...

Warner