Re: state of beaglebone black

On September 23, 2025 2:56:48 AM GMT+03:00, Warner Losh <imp@bsdimp.com> wrote:
>On Mon, Sep 22, 2025 at 10:04 AM Zach Metzinger <zmetzing@pobox.com> 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