Re: state of beaglebone black

On Tue, Sep 23, 2025 at 2:50 AM Sulev-Madis Silber
<[email protected]> wrote:
> On September 23, 2025 2:56:48 AM GMT+03:00, Warner Losh <[email protected]> wrote:
> >On Mon, Sep 22, 2025 at 10:04 AM Zach Metzinger <[email protected]> wrote:
> >
> >> On 9/22/25 05:27, Hellmuth Michaelis wrote:
> >> > On the beaglebones here i (think i) run 13.2 without any problems and i
> >> > have failed to get 14.something up and running. Is 13.2 the last version
> >> >   for the bbb ? Is someone still working on it ?
> >>
> >> I have -13.5 built for my BBGs (which are just BBB without the HDMI
> >> framer, etc.). Seems to work fine for my use cases.
> >>
> >> I am interested in keeping armv7 (32-bit) going for my devices in the
> >> field. As I've recently posted, they seem far more robust than the RPi
> >> boards. However, I've also been looking at the "PocketBeagle 2" boards,
> >> which are 64-bit, to replace them.
> >>
> >
> >The DTS format changed in upstream Linux. In theory, DTS is supposed to be
> >OS agnostic, but some systems, like TI's boards, that evolve the DTS
> >quickly. Oskar has been working to update all the drivers to the latest DTS
> >we have in the tree. I'm not sure what the status of that work is, so I've
> >cc'd him.
> >
> >Warner
>
> i find if weird that for compatibility reasons fbsd has imported a necessary component from linux and thanks to that part, it has massive issues of supporting hw now. some might say it imported non-executable "backdoor". have to rely on someone else. a new boss who could do whatever (s)he wants and everyone just says baaa and complies
>
> about as wtf as switching to one unified boot method, again for compat reasons, which means adding efi support to non-efi hw via uboot just so it can "efi" boot. resulting in rube goldberg boot system but at least fully industry standard. or maybe was it solely amd64. last time i heard even bios-booting hw need to be starting efi booting or just die off if it can't. this feels like awful path really
>
> that is all true for even for embedded platforms, where system is very likely customized to a point where one fdt file doesn't add much to the complexity of supporting it
>
> unsure which is more or less hell tho. the fdt and kernel or even userland fragmentation is also widespread in linux embedded world. i'm not sure how many embedded systems are installed like servers or desktops. like, slap system on it, poof, done
>
> or i don't know, to me those are artificial hurdles or self-inflicted wounds. i was wtf when i saw bbb disconnected from build due can't boot on new fdt from linux!
>
> of course i'm thankful for someone updating drivers so i can get bbb updated again after 10 years and getting it working but i don't like the permanent (voluntary) job position in fbsd to keep fdf compat up to linux
>
> seems like politics (or should i say policies) creep in again

the source of problem is usually SoC vendor that does not provide full
SoC documentation, sometimes not even basic documentation, but instead
they provide some binary blobs for radio, etc, or just specific linux
version drivers and the whole world needs to adapt to that crap. very
often even world wide popular board vendors does not have
documentation themselves. i just dont get it why people even want to
use this crap no to mention hype it as something wonderful. this is
clearly working for free and bumping sales to companies that dont give
a f. while companies that cared probably are already gone.

yes this sux a lot. for years. maybe a solution here is to return the
favor to the vendors that despise open source.

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info