Re: nanobsd [was Re: Cross compiling user applications for armv7]

On September 20, 2025 7:35:05 PM GMT+03:00, Zach Metzinger <zmetzing@pobox.com> wrote:
>On 9/19/25 22:55, Sulev-Madis Silber wrote:
>> so what do you run on them now? how did you get 16-current up? some bits are removed now. and there are fdt issues supposedly. 
>
>I have booted a compile of -13.5 on them, as well as a -current (as of perhaps 6 months ago -- not so "current").

oh i should look into that then!

but parts of ti code ended up being removed from kernconf & build (that too iirc). perhaps even code, i have to look

whole reason somehow being that upstream fdt has issues. upstream is linux. and one supposedly can't add own fdt's as that's supposedly unmaintainable locally in fbsd project?

it wasn't support issue at all. or perhaps not *that* support issue

i highly doubt that anyone running bbb now or then was running it with defaults. it's not general hw, nor does it have general use. likely very specific and for those, own changes aren't difficult

if the changes go too far, i just end up running old fbsd on it, despite insecure etc. i have like old ports too and even local distfiles so i could compile things for it

apparently there's huge push for whole 64bit onlyness even !i386, despite new hw being sold still. the actual i386 perhaps deserves museums, tho, in a pinch, you can still use it. funnily, you have to search new os or bear holes

>
>I've used SPI-interfaced peripherals (accelerometer/gyro), I2C (pressure/temperature sensors), and serial ports (BT-LE chips) on these rugged little beasties.
>
>Most of my use cases do not require anything with a beefy CPU, as they're mostly data collection units with nice onboard tools and ssh access.
>
>They seem to last a lot longer than the RPi Zero 2W's that I've tried using. The Broadcom chip, or the RPi system design, seems very sensitive to the least little bit of ESD or having an I/O pin shorted to ground. Those chips really were meant for the inside of a cell phone and not to have unprotected I/O brought out to a user header. Also, I don't have to add an external dongle for wired Ethernet.

good to know. tho, i would not count on internals for shorts or actual esd. either human or lightning / switching. need external diode / tvs circuits or optical / magnetic isolation

>
>(Also, what less-than-stellar engineer thought up putting the 5V and 3.3V rails right next to each other on the expansion header without putting GND in-between them? One slip of a probe tip and poof, there goes your RPi.)

oh don't worry, nanopi neo core, allwinner h3 i have, has same thing. i was wtf. in my custom extension ports i tried to get 5v as far as possible from 3.3v and additonally made it so when you accidentally reverse your, also 40pin, connector, you end up with things not quite working right, as opposed to blowing things up

but rpi had own reasons for that i guess. now it stuck. now we're crapped

>
>--- Zach
>