Kinda a long one ... but it's been like 1 week trying to get u-boot and all this stuff correct on my own not specific to armbian. But, been searching all over for all sorts of things, made comments on the uboot/uboot github etc.. I'm learning this whole linux uboot etc... maybe this might be useful, any input or corrections etc let me know.
The uboot/uboot github you got to pay attention to the branches...
The orangepi_zero3 is almost identical to the orangepi_zero2w. but in no way is the orangepi_zero2 and zero2w compatible don't even bother looking at that, except for maybe the the eth phy , but since the 2w doesn't have that, I don't see a chip in docs, or on the board (maybe on the expansion board but I don't have one, those docs, same don't really show anything unless its built into the rj45 board connector or just uses the SoC). The zero3 does have a `motorcomm=y` the chip (10/100/1000) that is in the defconfig from uboot/uboot.. the zero2 has some `rtl8211f=y` in the defconfig, that might be the only thing (maybe) that the zero2 and zero2w might have in common.
So the DDR4 if you look at the schematics side by side orangepi_zero3 and 2w they are the same (not just ddr4 but everything - the eth ic). the PMIC are the same and the busses and voltages are all the same ( one of them the schematic shows extra capacitors but the voltage / "bus" address all the same)
The WiFi chip is the same power / pins etc, I saw someone mentioned the WiFi no working but on the official (beta build 6.1 debian) I've had no issues with it (haven't benched marked it or anything), on the older debian it gave me issues, like on first boot I could get my apt updates, after that restart it wouldn't connect, but it would after a second reboot... ( not sure I remember some of those helium miners I messed around with had issues like that, and a lot of the time it was the 2.4ghz and 5ghz home routers, would have the same SSID name and for whatever reason some of those drivers / chips would get stumped on that).
As I was looking around I finally stumbled on the "next" branch in the the `1.`orangepi-build github directory, and that things been getting updates like every week and is like a year ahead of the master branch. There are no instructions there... But for the past 10 hours I been going threw it and banging out the headaches of figuring it out... but its kind of different and I'm just learning what all this different parts of uboot / linux build are structured.
ref `1.` : https://github.com/orangepi-xunlong/orangepi-build/tree/next
This seems to be the files you might need to compare here with what you got ( just referencing the wifi area since I noticed that was an issue a lot of people were having)
zero2w
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero2w-u-boot-current.dts#L2707
zero3 - should be same note the difference in line number...
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/dts/orangepizero3-u-boot-current.dts#L2688
Some other files here that have settings, other board in the parent folder...
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/pack-uboot/sun50iw9/bin/sys_config/sys_config_orangepizero2w.fex
But also in the above files notice the HDMI ( someone was saying something about that)
I had an issue with an armbian I downloaded 2-3 of the community versions for the 2w and it kinda worked... but I had issues with the HDMI with a DVI converter, I could see stuff it was just all glitching out, and would stall out on me. I tried it with just plugging it in HDMI to the TV HDMI (no dvi adapter + 1080) and it wasn't glitching out, I think the GNOME and the video drivers crash it im guessing, I did try to install GNOME on the official working xfce debian "beta" 6.1 and it was lagging hard, I tried to figure out wayland but leaving that for after I build this kernel to have "full control" of my debuging etc.. The orange pi beta 6.1 debian worked fine with the HDMI to DVI at any res, and the 6.1 mainline kernel I think already has the support for the Mali gpu, ( I still had to build it, with mesa etc for getting gstreamer ffmpeg codecs etc... I built that like 3 different ways... via the debian-mali method, with the ARM docs method, and random stuff I first found. As I've been going through the orangepi-build files / build I'm pretty sure there was a setting / option already set for PanfrostLima ...
debian-mali
https://wiki.debian.org/PanfrostLima#Hardware_support
Mesa-mali
https://docs.mesa3d.org/drivers/panfrost.html
ARM-mali
https://developer.arm.com/downloads/-/mali-drivers/bifrost-kernel
But if you go into the orangepi-build/external/ you'll find all the things I mentioned above, and how I have been confirming all my random configs I been hacking together over the week. That repo is actually very well organized vs the other things I been going through, just files seem to have different names, and/or are structured more for whiptail style config / build system (actually really nice once you figure out how to get it to run (I even made / currently debuging a windows 11 Dockerfile that lets me use build on windows using linux docker, with the whole 'docker in docker' method).
So you might not find like a defconfig (I'm not sure how armbian does this), but all the settings are there, even if they are mixed into a file that just builds those files out... but its actually convenient because you see the orangepi_zero3 and zero2w on the same page or directory without 10000 files in it, separated by whatever if statement / setting that is different. for example
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/sources/families/include/sunxi64_common.inc#L69
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/sources/families/sun50iw9.conf#L118
Like it all works, I'm just in that stage of trying to update it to newer mainline kernels, fixing w.e errors pop up on my windows docker build attempt... but if your happy with what they got already there 6.1 and 5.4... and the ./build.sh just runs a menu config, that lets you build each part separate , uboot / kernel / fs .. and it has option for updating the kernel through the standard menuconfig.
Preset configs that auto load into the menuconfig for orangepi_zero2w /zero3 and be completely adjusted from the whiptail menu...
ref: - check parent folder for the other models
https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/config/kernel/linux-6.1-sun50iw9-next.config
So there are no instructions for that thing but this is what I was able to do, but then ran into, and still debugging some stuff (just for my windows docker container)
1. `git clone https://github.com/orangepi-xunlong/orangepi-build.git`
2. `cd ./orangepi-build`
3. `sudo chmod +x build.sh` (if necessary)
4. `./build.sh`
- Note the build process makes a docker image and downloads all the build dependencies, so you shouldn't need to. But if you are building on x86_64 linux it has some function in there that will throw an error `You are running on an unsupported system [ bookworm<distro> ]` , the function that causes this has a note 'Ubuntu 21.04.x (Hirsute) x86_64 is the only fully supported host OS release', but you can use this ENV / VAR in the console or maybe the ./build <arg> `export NO_HOST_RELEASE_CHECK=yes`, which will bypass that, but with no gaurentee if it will work.
5. from the whiptail menu pick what you want to build uboot, kernel, fs, etc..
- Note that once you go into that option, its going to build the option at the end, it does not go back to the main menu for you to pick the next build option, it builds 1 at a time, then at the end theres another option to put it together, ( this is where you can either switch to armbian or w.e @least you hopefully* got a working u-boot)
- Note when you are going through each step of the build option you made it will give you a list, to pick which board -> the ram -> what branch you want to use "master" or "next", next is like 1 year ahead of master, especially for orangepi_zero2w / orangepi_zero3
Thats pretty much it you just repeat step 5 untill you build everything you want, then combine it with armbian, or w.e ( havent ever built a U-boot before), but it spits each step out to some output folder in that orangepi-build directory, if it works then just go copy the settings and update the armbian repo or w.e
I know it was alot, but I got alot of info from this forum, and others so I figure I post where I'm at , where I Noticed an active thread dealing with this. Again I've never built U-boot before but I'm sure alot of us haven't so to save someone from 1-2 weeks of reading 5 year old post and what not thats what I've gathered.
Happy Newyears eve ... dunno if im going to finish this build for a day or 2
Ive been trying to figure something out with the orangepi zero2w, specifically for video decoding. Ive gotten the 3d engine working and benching fine with opengl, and I installed this when you first posted it for the hardware video acceleration, but what I been trying to figure out in general for the GPU and or the video, is the CMA memory... I think this might be the limiting factor in all this, and is a big oversight on alot of this video stuff. Im not running armbian at the moment but on the orangepi os running 6.1 debian I run this cat /proc/meminfo | grep -i cma CmaTotal: 131072 kB CmaFree: 117696 kB (128 mB) so depending on the different kernel / SoC builds debian, armbian, custom stuff... everyone probably has something different. And from what I have read in other posts here and within the Raspberry Pi community, the CMA allocation seems to be the most important part for video and 3d hardware acceleration, since its not in the "user space" it technically not have access to the whole RAM only the CMA (128mB in my case). I think 128 is enough but if your running some thing crazy it could need more as in other post in this forums that people have pushed 1GB ram board to a max of 512mB~ Ive read that the CMA can be in the device tree which seems not to be the case for the orangepi zero2w debian 6.1, so im trying to figure out where else I can change that, I figure I post this here, maybe someone has more insight or has tried changing the CMA for this driver and has verified results?