ag123

cross posting this thread, as this seemed to be a related 'bleeding edge' thread one can probably ignore the 'don't use' remarks as apparently, efforts are underway to make the recent kernel work (on zero3, zero2w)

if you want to play with the NPU, you would likely need to resort to the reversed engineered open source NPU driver https://www.hackster.io/news/tomeu-vizoso-s-open-source-npu-driver-project-does-away-with-the-rockchip-rk3588-s-binary-blob-0153cf723d44 https://www.cnx-software.com/2024/04/21/rockchip-rk3588-npu-open-source-driver-object-detection30-fps/ https://blog.tomeuvizoso.net/search/label/rk3588 this is not from rockchip nor orange pi, probably no documentation and you would need to find your way around yourself, you are on your own. but that the open source driver is absolutely bleeding edge, i.e. it is in mainline linux and the one and only one. as for wifi I didn't seem to see explicit support for the chip AP6611 in the wild, may be I didn't find it in the 'right' places. did anyone chanced upon a driver for ap6611 on github, etc?

@Dual Stack I think it has to do with DRAM timings and detection and that possibly Orange Pi used different dram chips even though the board is sold as Orange Pi Zero 3 DRAM initialization is in the embedded boot loader u-boot and the problem mainly occurs during a cold startup reboot. https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-sunxi/dram_helpers.c#L28-L64 There used to be a '1.5 GB' problem and other associated problem detecting memory sizes, those has been resolved to some extent. Among the solutions, without resorting to fixing codes: make sure your Wifi antenna is not lying on the board near any of the chips (cpu, dram etc), bring the antenna outside the board so that it don't lie over any electronic components. There has been reports that the Wifi interference has caused some problems with memory / cpu etc. as for myself, after booting successfully, I practically simply leave the board on, that is ok as I used it as a WiFi AP. Otherwise the 'solution' is to simply reboot taking note of the Wifi antenna issue above. That said, Armbian on Orange Pi Zero 3 should be running pretty well except for some of these hiccups https://www.armbian.com/orange-pi-zero-3/ it is one of the distributions/images that has considerable volunteered effort to make Armbian run on Orange Pi Zero 3. you can review this long thread for the history. The difference between Armbian vs the vendors images is that the vendor's images is to some extent proprietary. While Armbian is literally / actually build from source and you can rebuilt an image if you are willing to go the distance. https://docs.armbian.com/Developer-Guide_Build-Preparation/ It is also different in this sense in that Armbian can be updated to a recent kernel and supporting codes (e.g. u-boot) (which indeed it is) and often the kernel in the vendors images tend to be 'left behind' with an old kernel version, which may not get updated. It'd be good to support the Armbian project via donations etc as this is probably about the only way to keep the project sustainable and supported. Strictly speaking, those donations are subscriptions as would be for commercial os and distributions. --- There is an old *unsupported* image that I rebuilt from source based on 6.7 kernel back then. I won't be providing any support for this image, and it may not necessarily fix this problem and may have other issues e.g. the 1.5GB issue. But if you'd like to try it it is here: ----- It is quite possible to hard code memory configuration in u-boot, but that it requires re-building an armbian image from source. It is probably not recommended currently, but that if you are curious to look at an early fix back then about the 1.5 GB issue a similar tactic can be used to hardcode say 4GB for your board, but requires re-building the at least u-boot and patching it into the image, or rebuilding armbian image from source. That can 'work around' those memory detection issues since all that configurations is hard coded.

I think rotation is managed by some LCD commands, see MADCTL in the datasheet. https://www.hpinfotech.ro/ILI9488.pdf so the driver probably needs to implement it to have rotation

well, the SOC is the same, 'in theory', that image e.g. for pi5-plus should work. The trouble is the dram and all + on board emmc, and i'm not sure what else (ethernet/wifi ?) etc may be different. I think i'd go with a Rpi 5 firsthand as I've yet to get a board and maybe add a rk3588 (perhaps much) later. and well in mainline there seemed to be a dts already there for opi 5 plus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts?h=v6.13 but it'd seem there is no 'specifics' for opi 5 ultra https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip?h=v6.13 if it is true, one'd need to go on the notion of 'may work' e.g. to use the opi 5+ image for a start. and of course the other 'hidden' (and very important) thing is uboot https://www.denx.de/project/u-boot/

hdmirx aside, Would Armbian run on Orange Pi 5 ultra? a closer image I'd guess is this? https://www.armbian.com/orange-pi-5-plus/ there is also some 'rumors' about rk3588 mainlining efforts, I'd guess it could be 'lost in translation' / misintepreted I've weighed between a Rpi 5 vs rk3588, rk3588 seemed to be higher performing and has a built-in NPU. But that for sure Rpi 5 have more 'popular' support, at least from Rpi itself. A thing about Armbian and/'or mainline based linux running on these boards is, they tend to be 'beyond rpi', hacks like HDMI RX is feasible. Rpi is more for 'lazy' tinkerers who wants boards that 'just works', but that sometimes that helps.

oh and get a usb-uart cable and work from the 'debug' (3 pin serial) port, that is an absolute necessity to mess with network configs https://www.aliexpress.com/w/wholesale-usb-uart-3.3v.html https://www.aliexpress.com/w/wholesale-usb%25252duart.html https://www.aliexpress.com/w/wholesale-usb-uart-ch340.html get those that is 3.3v or with a switch or jumper that you can toggle to 3.3v outputs, 5v is probably unsafe to put on the allwinner chip. I configured my that way from the serial console so that WiFi and ethernet sits on a bridge practically as my little desktop WiFi AP. --- but that HDMI patch is truly valuable

it may be in one/some of the patches, there is a huge thread about it where development originally started. probably to look in there to see if the patch can be found and applied to edge, at least locally the search box on top of forum probably could help

I'd think WSL is Microsoft's version of Virtualbox, so if you have Ubuntu or Debian running in it, it is Linux, which is a reason it is surprising it didn't work 😛 When I tried building Armbian in a systemd-nspawn container running Ubuntu Jammy. it has issues with loop devices and I worked around them as discussed in this thread. Missing the loop devices will cause writing the image to fail and abort at the last stage. I don't think the loop devices problem is identical, but that the problems may be similar. Fixing the loop devices issue may require editing the build scripts in particular the image creation parts, I did that once and managed a successful build. However, in a subsequent update, a git merge 'messed up' my changes and I'd need to figure out how I did it again which I had forgotten.

it seemed strange for it to need qemu-arm, but a google search for binfmts qemu-arm return this as one of the results https://wiki.debian.org/QemuUserEmulation

you can probably run it directly in the shell that wsl presents, which has to be in Ubuntu itself. But that PREFER_DOCKER=no runs the build directly in that shell without spawning another docker instance. root (via sudo called internally) is needed to run it, but that it mostly stays within the build folder. root is needed due to the use of loop devices which is used to create the image. it can be run as root without much fanfare and it should complete a build and leave your image in output/images. flashing that image is the same as how you would when you downloaded it say from Armbian https://www.armbian.com/orange-pi-zero-3/ building from source opens up all the knobs and switches that you can tweak, I think it is even possible to change the kernel version. standard selections offers current and 'edge'. 'edge' is what I mostly choose as that would be a more recent kernel than stock. you may need to explicitly 'enable', rather select your board (i.e. orange pi zero 3) from the menu presented during the build

well, it isn't necessary to build in another virtual machine like docker etc if you are using linux running in wsl you can build it directly in your shell using compile.sh PREFER_DOCKER=no https://gist.github.com/ag88/05245121cce37cb8f029424a20752e35#-building-armbian-in-systemd-nspawn-container

my guess is if you build it from source, look in the same directory trees for the drivers you should find the patched kernel sources and may be there could be the drivers specific to st7796 the kernel sources I'd guess is normally found under cache/sources/linux-kernel-worktree/ after a build you could try looking in the further sub trees for panel drivers e.g. root/drivers/gpu/drm/panel I'm not too sure if it isn't there that if you could patch your files there for the build, I'd think there are other related matters e.g. how to integrate that in the makefiles, config etc and there is likely armbian specifics on how to appropriately create the patch a thing would be to check if st7789 driver works for st7796, st7789 is in the kernel but nothing specific to st7796 at least from the origin source tree. you could perhaps try the compatible string from the st7789 driver fbtft may no longer work in the recent kernels e.g. 6.x (i'm not sure about this one) however, you may nevertheless want to try it out just in case it works after all https://github.com/armbian/build/blob/bab9b3fbe383a2a2b1224d2bd4ca4d26142ed020/patch/kernel/archive/sunxi-6.6/patches.armbian/Add-FB_TFT-ST7796S-driver.patch#L142 ^ note that this is for st7796s and the relevant github repo is fbtft wiki itself https://github.com/notro/fbtft/wiki if you build from source, you could find that under drivers/staging/fbtft in cache/sources/linux-kernel-worktree/ do check if you may need to enable that during config for the kernel build itself

I know zero about display panels and near zero about device tree and its interactions. But that i went googling around and found out where the source codes for some of the lcd panel drivers are found in the kernel source codes apparently the 'new' drivers for the various LCD panels may be found under root/drivers/gpu/drm/panel https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel some of the 'older' drivers could be under fbtft https://github.com/notro/fbtft/wiki implemented under fbdev root/drivers/video/fbdev https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev apparently fbtft may no longer be in more recent kernels from 5.4 https://github.com/notro/fbtft/wiki a 'compatible' statement match in the driver is found for ILI9341 lcd e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-ilitek-ili9341.c#n563 I did not find a driver name that has 7796, some of them found has sitronix-st* file names e.g. for st7789 a 'compatible' statement is found here https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-sitronix-st7789v.c#n672 take note that ST7796 may be using SPI rather than MIPI http://www.lcdwiki.com/4.0inch_SPI_Module_ST7796 I've yet to try interfacing with ILI9341 which I've and I do not know how to configure SPI and in turn its driver with SPI things found from random google searches https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/refs/heads/akpm-base/Documentation/devicetree/bindings/display/ilitek%2Cili9341.txt https://lore.kernel.org/lkml/20220618123035.563070-2-mail@conchuod.ie/ this is what is found so far but there is still a lot more questions than there are answers, e.g. how to test if the spi is after all responding, how to test if the lcd is after all responding, some hints can probably be found by reading the driver source codes, e.g. those embedded messages would likely show up in dmesg if after all the appropriate driver is loaded

/boot/armbianEnv.txt is not a feature of Cannonical rather it is a feature of das u-boot and Armbian https://source.denx.de/u-boot/u-boot you can find some of those documentation here https://docs.armbian.com/User-Guide_Armbian_overlays/#armbianenvtxt-entries-reference it doesn't do 'everything' it mainly provides variables for u-boot scripts, and you would need to review the installed scripts to understand it. its functionality is possibly different between boards, as u-boot is compiled and built and works differently for every different soc and board the catch is that u-boot can be customized and built and work differently for the same soc and board, e.g. that used for Armbian is different from that say in the vendor's images (e.g. from Orange Pi etc) if you do not understand u-boot, you would need to start here https://docs.u-boot.org/en/latest/