Re: Beaglebone Black/Green/Blue support (volunteering)
- Reply: Mark Millard : "Re: Beaglebone Black/Green/Blue support (volunteering)"
- Reply: Warner Losh : "Re: Beaglebone Black/Green/Blue support (volunteering)"
- Reply: void : "Re: Beaglebone Black/Green/Blue support (volunteering)"
- In reply to: Warner Losh : "Re: Beaglebone Black/Green/Blue support (volunteering)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 18 Sep 2024 06:44:06 UTC
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? so am i correct, we throw that thing out just because it's super hard to use fdt 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 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 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 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