Orange PI Zero2 and FreeBSD 13.2

what does work now? back in day i bought bbb for getting it's fbsd support better and because i wanted my first sbc. still works decade later but fbsd support went to sorry state now. now i have somehow 13 nanopi neo cores (no headers soldered, at that time it was about the only sbc in stock too) but want something that fbsd could support for longer period. like opiz3 is 64bit and everything. maybe it's inevitable to lose support but the problem is, embedded devices don't get replaced. as seen on insecure android phones that work until they die. i stepped up from hobby level now and realize it's hard since fbsd is still my favorite after 21 years but since mips/arm/riscv/etc is so fragmented, freebsd support for such hardware is like it's marching in from front door and straight out via back door. and i even get the problem. i read the thread of deprecating 32bit entirely. arm too. little of user interest, little of dev interest. upstream issues. and then you get users moaning how they put bbb's into some high security env machines and can't get them replaced anymore. so can't decide here. yes, i can make own lts freebsd dist like many others but. there's also option to switch to [no]bsd or linux. so i'm out of ideas here. i mean, what to select for a hw that's beyond the level of home cpe/stb you can easily install one year and throw away next
 
on zero2 and zero3 i have uart, sd/mmc, usb, wired lan, i2c, gpio, enough clocks, spi, pwm, cpufreq, voltage regulator ic, thermal sensors working
spi nor flash tested on zero3 work readonly (did not try to write to it)
what does not work is video/hdmi, built in wifi, sound
i probably can do sound via line out
video may be doable via drm-subtree by evadot
sdio wifi only if someone makes linuxkpi available to sdio devices
 
that's already a lot of stuff working

apparently you do a lot of fancy hw, are there anything else that could fit in place of zero3, like thinclients or so. like having some case around board would help. or stb's if they can be reflashed

basically something with long term fbsd support and ability to connect one 1-wire sensor to gpio is the current idea. and cheap? apparently cots hw like this doesn't really exist. having any amd64 here would be huge sledgehammer for this simple task

so unsure. allwinners seem best bet on arm. on fbsd. common. usb otg support. hmm...
 
refurbished thin clients are best supported and cheapest and usually well built and 64bit arch
unlike most other mini pc's most thin clients are fan-less and have long term manufacturer support
the most expensive part is the powerbrick (they use laptop type adapters) and they seem huge compared with arm sbcs
you need some usb to gpio device which i see are usually controlled via libusb so no kernel driver is necessary and they need more power than your typical devboard sbc


android set top boxes with allwinner h6/h3/h616 and various versions of rockchip will probably work with freebsd but they
have shitty build, you are never sure what hardware you will get (emmc or raw nand, eth phy type) but they are (used to be?) cheaper thand dev boards for the
"specs". also they do not have pin headers but you get a case, a power supply, remote control
they can be reflashed, i have one running armbian from emmc, probably ill install freebsd on the h616 one

development boards are best suited for controlling stuff via i2c, gpio, spi because they already have the pins exposed
seems like the prices are getting better the zero3 and 3b are getting competitive with android boxes
3b with 4Gb/64Gb emmc, cortex a55 is about 50 euros shipped (rk3566) and has nvme slot
so they are getting price competitive with android stbs.
but you have to buy them from aliexpress or support a hefty reseller markup if you buy them in eu
zero3 is the cheapest, 3b is probably the cheapest with active development
also rockpi-s which is cortex a35 but it has only 512Mb ram, no mainline kernel support ( i can provide patches) and has no gpu and only 100tx ethernet
 
opi0 used to be fucking 5 eur in larger quantity! entire board. can't forget it. sadly now it's not. rk* iirc has really inconvient boot procedure where you have to use something closed, and rps had little of support in fbsd too? i guess devboard is the best way to, yeah. until i could design own hw. but devboard is pretty much barebone soc and ram. and i don't think 512m ram is stopping point, or 100m eth. it just seems like 1g + 1g is cheaper. joys of modern hw dev. in real life, in 2023, there's enough headroom in 512m ram that on my h3 nanopi, like ~350mb ram is free, even though i run everything i need. and i could fetch new firmware image directly into ram if if i wish, and do it 5 times in a row. and 100m eth where your expected average throughput is 1kb/minute? i wish i could trade something off here and get cheaper item but sadly i can't. as for prices, 32bit arm full set is 44 eur at https://botland.store/nanopi-module...-kit-with-nanopi-neo-512mb-5904422313432.html compare it to poor stb hacks. i know a ton of cheap hw there is. barely binary manuf linux kernel support. i don't like this life but this is how it is. maybe i should accept that devboard or similar is best and well support is something that can go away. and i could either continue or give up, or give it away to another trusted party. now, if i sell open hw, any future hackers will thank me, as they could be easily repurposed beyond their life. unlike products i have in my home that can't. to be honest, i'm new in this field. not fbsd or electronics. but other. i think we came to same conclusion that currently opiz3 is something to look at. eg, generic hw that's just pcb, soc, ram, eth phy, pins, pmic, sockets. and maybe 10 years of fbsd official support is enough. unsure. sorry, i can't pay for hw research yet : ) maybe i could in future. or might as well support fbsd itself. so yeah good info here from you. lot of stuff to think about
 
ketas said:
maybe i should accept that devboard or similar is best and well support is something that can go away. and i could either continue or give up, or give it away to another trusted party.
Click to expand...
I sense your frustration here. As a embedded design house you need to buy a bunch of boards at intro (usually the best availability) to develop a product and hope OS support catches up by the time your product is ready.

With the batch of boards you bought at intro (for product security and prototyping) you now hope no groundbreaking revisions have happened and the board is still in production....
 
at least i'm not really tied to any particular hw. but i see nightmare coming from trying to support all that different hw for decades. that was the give up or away part

i'm honest here that i don't know anything except other people's mistakes on embedded hw/sw production

i don't even know where majority of opiz3's go. but i guess answer is everywhere the i386/amd64 also goes. i know it's not really a hardened hw

so maybe it's not too bad that i choose cots hw for a start. i didn't write os either. noone else did either. i think that's not needed even

so far i've learned that, while people like me can sometimes frown if they see hw being sold at highly inflated prices of like ~3.5x the price, that easy money could just vanish into this huge task of providing actually working product for years. because that's what they buy. i think maximum i've seen is 56x the hw price

so yeah, seems too much. certainly for one guy who hasn't had a dayjob due being unable stand people close by nor communicate with people. but electronics and fbsd doesn't really them so in those i have decades of experience. that's what this is all about. but i was encouraged by others luckily that this could make a nice startup anyway
 
did not try to write to it yet but i will. it contains some linux mini os so its bootable but it switches to hdmi so i see just loading linux and some u-boot messages before that. did not have a hdmi cable hooked when i tried. it will be kind of hard to fit a usable freebsd image in 16mb but not impossible. fitting loader or loader and kernel is probably easier but you still need a sd card or usb stick to run the os. or riun root or nfs. there is no uboot support for the ethernet phy so u-boot pxe is not possible as of now.
also the xunlong provided sources for uboot dont seem to support the spi flash but i may have to dig better for them

also xunlong launched opi zero2w in a rpi zero form factor and optional hat io board. with various ram configs
also cheaper than competition
 
i did write the entire flash with the original content and dump it again.
the contents seem to match the original data so it either works or it did nothing
the writing dd took 15min. i will try to write zeros and come back

LE: wrote zeros in first 128k and worked, wrote back the original 128k and worked
 
i'm not expecting to run fbsd off of it, i just wondered if i could put uboot there. like emergency uboot or maybe some config or loader. you know so you can flash uboot and loader and not worry about power failure making your board ubootless. i know some allwinners have two locations on one sd for uboot. i hope this boots same way. or how does this boot, what's your sd layout? also that's your own uboot and fdt here? or just wipe it clean so it won't interfere with my stuff. i guess i could buy one, which is like 25 eur from ali. now that i know it can boot up. sad that the wifi/bt is such a hassle. i guess noone uses sdio, because why else would that be basically missing. but does it even have good chipset? it would be bad to need to add equally strange usb wifi to the system in places where wifi is needed. running fbsd wifi aps would be awesome! but this is not major hassle, at least for me. while there, ethernet works, right?
 
all arm boards im aware about have wifi on sdio. the wifi chip in newer zeros is unisoc but i assume is good enough. some intel low power designs have wifi on sdio like some atom base tablets and stuff.
u-boot may be at an 8k or 128k offset. i did not try the 128k variant on the opi's because i rotate the same card between zero2, zero3 and the h616 based android box. the android box wont boot with u-boot at the offset 128k. the problem with this is that gpart wont create a gpt partitition with this few entries and i had to use mbr. fortunately u-boot mbr + efi works without problems
 
only danger i see with mbr is that it has no backup in the end. with gpt you get it but lose some soc specific features. people have wanted gpart to create nonstandard gpt table but objection was to why, mbr works and who needs nonstandard features. could always patch it in i guess. only to have backup of part table. unsure why soc roms chose the 8k anyway? or 128k? easy? no waste in storage? memory limits? anyway i see you're good cat, pat-pat. when do get to see that code in tree? or how do i get your patches or tree when i eventually get board on my own. also why 13.2 and not current?
 
when i started hacking the kernel for the rockpi-s there was no diff in existing support for 13 and 14. so i decided i don't want to deal with other -current problems for no real gain
the status is the same for allwinner, there are no improvements in 14.
as for seeing the code in tree i don't know, i find it hard to go thru the review process etc, etc. also there does not seem to be much interest in "unpopular" socs so it is what it is
unpopular means anything not raspberry pi or low end cheap chinese stuff
ill post here the diff from an unmodified 13.2 kernel source. it contains some other minor patches for rtwn and some other stuff which can be ignored but the bulk of it is support for allwinner h616 and rockpi-s (rk3308)
 

Attachments

  • thediff.txt
    550 KB · Views: 78
Hi,

Please submit to reviews.freebsd.org and add manu as reviewer
If it touches different drivers etc submit separate patches not a big one.
The same goes for SoC support, do it separate batches instead everything into one giant patch.

Edit: I've also pinged some arm-people to about it

Best regards,
Daniel
 
it's a massive diff i don't get because my brain still explodes at binary operators, etc. nevermind, i have patched the kernel out of need

but hell of a work and maybe i could buy hw and test

why is this thing worse than h3? unsure about unpopular soc. i have real interest of running fbsd on low end hw. it's also cheap but i don't need more. on 4 core h3 with 512m ram, it's nearly idle with over half of ram free. and it runs full system with bunch of perl and shell in userland. sorry, h3 is just example i managed to buy during chip crisis

and i don't think anyone actively wants to scare code away from tree. it's just you need someone to maintain it. eg, you. and someone to test/use it. eg, me. end result would be fbsd running on more platforms. i think rpi gets way too much marketing and attention for no reason at all. it's not cheapest nor best hw. it's just first and popular. and perhaps subsidized

but yeah, btw. there are other socs, amlogic, etc, some of them include ram AND flash in big package. but it's like endless flow of socs. like, remember sheevaplugs, etc

funnily when i ask from people, they assume i always need to run full server or desktop on arm. or need to route 1gbe. i guess i could run those too. we have boards for that. even machines. but at least i have also need for something super tiny that would also run full fbsd but don't need 4gb ram and 100% cpu on all 8 2ghz arm cores?

so yeah, i'm happy that someone works on this hw. i thought of trying on my own, but realized it's waaaay over my head. i mean 21 years of hacking fbsd but not in that way
 
its not worse than h3 is just not as flashy as the newer rockchip stuff like rk3399/rk356x/rk3588 which are A72/A55/A76 not just A53 and support pcie
just look around the forum and see that the number of arm users is extremely small and of that probably 15% or less use allwinner

ketas said:
and i don't think anyone actively wants to scare code away from tree.
Click to expand...
neither do I but to do that someone needs to move it to -current, fix the coding style and maybe other things like moving some bits from some part of the tree to another, etc
and I am not "prepared" to do it right now
if anyone feels like picking it up just go ahead I'll help as much as I can but really can't do it myself
 
i don't know how i can help here, except running the code maybe, for that i need to order myself, perhaps, orange pi zero 2w as it has more io brought out and could be used for other tasks than takes power and runs fbsd

with new socs always being made, unsure how it would be viable. and now i get why much of it is gone now

but yeah, i'm not really into that, i would be writing code i don't know

hah, btw:
device_printf(dev,"crappy^H^H^H^Hbad syntax #%s# -- line ignored\n",token);
 
ordered opiz2w. unsure how to help on splitting it. manu told he's not reviewing 515kb diff from forum and rightfully so. the uuencoded firmwares need to bd moved fo ports, rk and aw split up and formed into bite size chunks. and style hmm. sorry never did. i certainly don't know he enough so that would be left to others who actually have done this before
 
Interesting. I have an Orange Pi Zero 2W. Maybe I should try to get FreeBSD installed on a microSD card and see if it would boot from it.
 
the vanilla freebsd version wont get you very far
h61[68] socs are not supported in the official builds
the patch i posted above should support sd/usb/ethernet/spi flash/regulators/pwm/temp sensors/cpu freq/
sound is broken but i have a "fixed" version
it is only tested on zero3 and zero2 not zero2w but i think the only diff from zero3 is that zero2w does not have an ethernet external phy
and uses copackaged ac300 (i may be wrong about this)

the patch is against 13.2 but with some (minor) effort will work on 14
just ignore (delete) the parts for rtwn and intel est
 
the opiz2w has now arrived from ali. actually some time ago even. never powered it up yet. i (badly) hard-folded the flex and joined two boards with plant tie wire. had no standoffs for that sadly. so it's kind of ready for action

but can you somehow split the changes up so i don't need to apply entire 500kb diff and then take it apart again. and then figure out how to apply on it current

i already have issue where somehow usb template stopped working on current on h3. all of otg is suddenly off. i have good and bad commits on that

but yeah, best to actually get it to current. and if current changes, code needs to change too. it's best to have it in current to ease the dev. now, i can't get much of hw. just too much of me

but i still get how those firmwares and rk* parts don't really belong there. it needs splitting so it could be actually reviewed for inclusion. i thought i could split it or adapt to current but if i end up messing some of those hw inits there, i wouldn't know how to get it working or have i created security issues and so on

so yeah, not really the one. i could test tho. i would really want it on current

i recently helped to find strange timer issue on armv7 somehow, despite not really knowing it. apparently my system had 4 cores and each of them kept different time so clock in system ran randomly off them. each of them had 30-100s diff so it was real "fun". managed to pinpoint it to single commit and then i realized there was sysctl to change it, and eventually change was reverted

so this kind of thing i can do. much more than that is too much. i kind of didn't actually do any kernel dev in those 20 years, nor did i take any hw courses since it was boring

so there i am. kind of stupid. fuck knows what i'll do. i just feel like it should applied to current and committed fast before it gets too difficult to maintain it on 13.2 and then try to apply it on 15. i also don't know how much diff is there between them in that area

but yeah, this cheap 64bit arm soc deserves to be in recent fbsd. even if "only" for 10y. so people actually use it and dev. i could see myself using it at home/work/whatever

i think both cheap low power and expensive high power systems need to be there

so yeah, unsure what to do. i could run the sbc and report issues. but private 13.2 branch seems like dead end to me. unless you want to fork catbsd or so on? much harder than porting this to current
 
here are the "required" files, not a diff, just the changed files from 13.2-R
i removed the rockchip, rtwn and other unrelated stuff
 

Attachments

  • aw-h61x-for-13-2.zip
    178.6 KB · Views: 45
You must log in or register to reply here.
Back
Top