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

On Wed, Sep 18, 2024 at 7:44 AM 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?
>

Yes. It's only because of the FDT, as far as we know.


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

The problem is TI. They maintain the Linux port. Rather than having a
stable machine description in the DTS, like the theory states, they are
constantly tweaking things so that the old code won't work on the new DTS.
Since in Linux, they also update the drivers at the same time and people
know the kernel and the DTB is a matched set, it all mostly works out.


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

I wouldn't put it that way, but yes. All the other sub-ports on Linux have
a basically stable DTB, so we're able to use them w/o problems and only the
occasional tweak. Plus, the BBB has been not the primary focus of the
developers doing the actual work for a long time, so it's gotten rather far
behind. The changes usually aren't that horrible, but sometimes the whole
driver model changes and then it's hard. Keeping the old dts around is also
hard to maintain since everything else is just imported from Linux.


> whole armv7 32bit is bit weird too. looks like it's hanging on the edge of
> trash can, along with whole 32bit, just to be waiting for to be pushed in.
> yet there are armv7 hw being sold. maybe even made still, can't be all nos.
> like allwinner h3
>

There's a lot of FreeBSD use of the 32-bit arm still. But the world is
moving to 64-bit systems, and there's already features that we have in
64-bit land we don't have in 32-bit land (EFI runtime, for example).
There's also people wanting to do things that will only work on 64-bit
kernels, so there's some tension with the 32-bit world in the developer
community. Plus the 32-bit use seems to be more using it than developing
new things, so very few bug fixes or enhancements to the 32-bit code come
in (relative to the 64-bit stuff).


> i can understand the issues with 32bit but where's like good working 64bit
> alternative. out of small hw, only raspberry pi? out of big hw, only arm
> servers?
>
> i have h618 hw here, along with 13.* patches i obtained from forum,
> waiting for some tests. maybe someone else has interest in tiny recent arm
> hw on fbsd
>

You might make sure Zach has them.


> while there, how do all the people dev for armv7? i use system qemu, but
> that fails with any new current now. basically old current and old qemu
> builds ports. old qemu and new current doesn't boot. new qemu and new
> current doesn't boot. new qemu and old current doesn't build half a ports.
> to be honest, old qemu and old qemu needs multiple tries to build some too,
> funnily. i suspect mixes issues with qemu, fbsd and clang combination here.
> not to mention that qemu is over 2000 times slower than c2d machine on some
> tasks. yes, really, 2000
>

I've done two or three different things. First, for me armv7 boots with
machine type virt in qemu as recently as 9.0 when I fixed problems with
virtio-net that caused unaligned access. I do limit what I do in
qemu-system-arm since it's good for testing things, but bad at high loads.
So no network stress testing, nor package building in it.

I also build with bsd-user mode emulation, but that has some problems (I've
been slowly working through them, but could use some help). It's quite a
bit faster, and works well enough for many things. There's an issue with
rust and go, IIRC, that I think is fixed in newer versions. We need to
update the port since it's using a 6-year-old fork now (I've updated it to
the latest, and several people have contributed improvements, so fingers
crossed.

I also have a very fast arm64 machine that I run most builds on in a armv7
jail. It works almost as well as native hardware, and is very fast. I have
seen a couple of weird edge cases posted where it doesn't work, but I've
not hit them personally. I use it also for A/B testing to see if a build
hang I see in bsd-user is reproducible on real hardware.


> if embedded fbsd goes away, that would be a sad story. i'm actually
> curious about using fbsd professionally. i know some others do too, but
> can't figure out what hw should i choose where it actually stays supported?
> maybe i should wait for more standardized, less fragile arm platforms in
> the future? or maybe embedded is fragile by design? i currently look for hw
> similar in performance of h3 but there could be others too, bit more
> powerful, maybe with video out, etc
>
> sad really, and all that existing hw seems to be supported by like single
> person in fbsd. if anything happens, that hw is gone too somehow
>
> god i wish it would be as easy as with big machines. i386 is going but
> that might be less of an issue (but i'm sure it's used too). as amd64, even
> old, is everywhere
>
> so any opinions with this arm situation?
>
> or whole embedded that is. fbsd contains lot of non server things. or
> maybe they are server now. like wifi, bt, video. i wish it to stay
>
> unsure, i can't magically come up with bunch of usera and bunch of devs so
> things stay healthy and i can also take and give advantage of this
>
> it's also super hard to maintain own code locally, etc. and embedded hw
> tends to really like to stay. for over 10 years easily. i've seen many
> embedded platforms appearing in fbsd and then quickly going out. while big
> hw stays for, i mean, i've been using fbsd since v4.6, not that long, some
> hw has been in for entire this time
>
> unsure what's other option here? use nbsd, use linux? god, some hw has
> better support on obsd. sad
>
> seems like fair bit of armv7 users are still there and i bet they also
> look for 64bit extended support hw too. so how to get devs here too? i bet
> there are humans in this planet that are happy to dev for arm on fbsd
> enough for it to work well
>

One reason I've tried to encourage Zach (and others that want to
contribute) is that we do have a need to replace the 32-bit arm developers
that have retired, passed away, or moved on to other things with newer
developers. I'm hoping that even a few will make it better, and that will
spur others to contribute since it's less of a lift to get things working,
and it's psychologically easier to contribute when you know someone is
likely to pick them up.

Warner