Re: state of beaglebone black
Sulev-Madis Silber <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On September 23, 2025 4:16:50 AM GMT+03:00, Tomek CEDRO <[email protected]> wrote: >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. > oh i can understand the business decisions they do. but it just makes hardware user life harder. yada yada yaaada, ip, corporate espionage etc. perfect. to biz. not to me sometimes you have to bite the bullet. i mean yeah qualcomm engineers get their paychecks from *SOMEWHERE*. but as a user and even tiny bit of a hw dev i see giant middle finger being waved to me. like some bully who goes like nanananaa where are you going to from us? there are no competitors in mobile radio interface market that's how i feel when seeing this. i want to use rockchip. but why they have that ram blob. others are gone now thankfully. why do i need to just "suck it up"