ag123

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/

@av4625 there is one experiment that I did not try which is to play with wpa_supplicant with its own /etc/wpa_supplicant.conf if it works, it'd likely point to a problem in network manager itself, possibly that network manager is sending the 'wrong' commands. However, as I couldn't figure out how to work that with network manager, possibly conflicts since network manager is intended to control it via the unix socket? redoing the 'whole' thing by having network manager unmanage the wifi interface is another test, but I did not try that due to the effort involved.

@av4625 I tried setting up WiFI AP using Network Manager which in turns uses wpa_supplicant. The configuration is actually 'much' easier than this current manual method using hostapd. 1st install dnsmasq (without this I found errors in journalctl -u NetworkManager logs saying that dnsmasq is not accessible) apt install dnsmasq then the following needs to be done using the usb uart serial debug dongle on the 3 serial pins. to configure the upstream *ethernet* interface it is nmcli c add "Wired connection 1" ifname end0 type ethernet That creates the network manager connection for the ethernet interface and it obtains its address via dhcp Hang / no response while half way working with usb uart serial debug dongle Some troubles while working in the usb uart serial debug dongle, it occasionally (quite frequently) hangs for uncertain reasons, no response in terminal. The terminal app I used is putty https://www.putty.org/ There is actually 'no solution' to the serial debug hang issue. I'm halfway suspecting that it may be due to loose connections, but I can't prove it. I used cheap usb-uart dongles like these https://www.aliexpress.com/w/wholesale-usb-uart.html solution to serial debug hang What I actually did to 'overcome' this is that I first configure the ethernet to work correctly in network manager (as above using nmcli). after that useful tip, install avahi (mDNS https://en.wikipedia.org/wiki/Multicast_DNS ) apt install avahi-daemon apt install avahi-utils then in /etc/avahi/avahi-daemon.conf [server] publish-workstation=yes then I look for that over the network using avahi-browse -a to search for the board in the lan. it is then simple to ssh into that e.g. ssh user@orangepizero3.local The ethernet connection proved to be more stable than the 'usb uart serial debug' monitor route. ------ configuring the WiFi AP. nmcli d wifi hotspot ifname wlan0 ssid testspot password 12345678 The good thing about NetworkManager with this is that it configures and setup the WiFi hotspot, configures all that necessary routing, setup ip masquadering through the other interface ( i.e. ipv4.method = shared ), configures dnsmasq. Everything with this 'simple looking' command line. devices are unable to connect with / without password I'm able to reproduce the various troubles that you are encountering. e.g. it is not possible to connect after playing with the various wpa / wpa 2 settings including things like key-mgmt, pairwise, group etc. I tried specifying 'tkip, ccmp' for both pairwise and group, didn't work. I run wpa_ctl status like what you see the key-mgmt is 'unknown'. I set "log_level debug" < yup just this statement in the prompt, then run journalctl -fu wpa_supplicant. The trouble is I've troubles connecting, but that nothing shows in the log during my connection attempts. I googled around next, apparently wpa_supplicant has its own large set of knobs (parameters) to play with https://web.mit.edu/freebsd/head/contrib/wpa/wpa_supplicant/wpa_supplicant.conf ^ what is quite interesting in this example is that key-mgmt do have the various options in network manager, but that in wpa_ctl , and running "status" command shows that to be 'unknown'. solution to 'NetworkManager' AP Actually, I 'don't have a solution'. Rather, I'm not sure where and what to tweak to try to make wpa_supplicant work with Network Manager. I tried creating a /etc/wpa_supplicant.conf play with some values, more occasional hangs etc, but did not solve the problem, i.e. journalctl -fu wpa_supplicant don't show any entries and I can't connect from my android phone. Then I switched back to my hostapd based setup in prior comment. it 'just works', practically 'no nonsense' The trouble with hostapd based setup is that you have more work to do (unlike that nmcli one liner to create an AP) if you want to run a routed setup as discussed in the prior comment. I'd guess that you could adapt that 'bridged' setup, e.g. doing that and running dhcp (e.g. dnsmasq or isc-dhcp-server, you would need to configure it separately) https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 could be a possible setup. The catch is that when you connect through ethernet, that dhcp is running on the bridge and if you have another dhcp server in the lan, things can be somewhat messy. the other ways would be to do a truly routed setup as discussed in prior comments. Configuring the WiFI interface as 'ethernet' in Network manager I'm not too sure if it is quite possible to setup the 'wifi' interface as 'ethernet' in network manager (e.g. nmcli). e.g. nmcli c add "WiFI connection" ifname wlan0 type ethernet ipv4.method manual ipv4.address <IP>/<prefix> ipv4.gateway <GW-address> ^ I'd guess ipv4.method = shared and without those ipv4.address, ipv4.gateway params may be possible with this which would do ip masquadering through the other (ethernet) interface use ip -4 add and/or ip route, to check what addresses and subnet gets assigned to wifi interface (wlan0) if you used ipv4.method = shared That is needed for the dhcp server below. Note check also if network manager 'automatically' configures dnsmasq as dhcp server by using ipv4.method = shared, which would make that extra step to configure dnsnmasq below redundant, unnecessary. 'everything' can be configured in network manager if this works. I've not tried this, but that if this is feasible, it would save some effort trying to set an ip address and routing for the wifi interface. I'd guess hostapd should still be able to run on top of that as hostapd doesn't bother about the ip and routing stuff. The bridge (bridge=br0) is not needed in hostapd.conf in this case. and with this it is not necessary to 'unmanage' the wifi interface in network manager i.e. that /etc/NetworkManager/conf.d/99-unmanaged-devices.conf is not required And in addition, you would still need to install and configure dhcp (dnsmasq or isc-dhcp-server) to provide the connecting devices with ip address and dns address. note: see that ipv4.method = shared above. This step may not be needed. oh and systemctl disable wpa_supplicant, I'm not too sure if hostapd would conflict with wpa_supplicant (I'd guess quite possible, they do pretty much similar and contradictory system calls. Hostapd runs an AP, wpa_supplicant mainly tries to setup a wifi client) do report on if this is feasible / successful / issues etc if you try this

@av4625 here are some of my thoughts, as discussed prior, wpa_supplicant and / or hostapd is The 'library' that does *all* of WPA/WPA2/WPA3 https://w1.fi/wpa_supplicant/devel/ The design goal for wpa_supplicant was to use hardware, driver, and OS independent, portable C code for all WPA functionality The design goal for hostapd was to use hardware, driver, and OS independent, portable C code for all WPA functionality. That means selecting either wpa_supplicant or hostapd would provide the wifi AP functionality specifically for WPA / WPA2 and authentication. Using hostapd apparently has 'better' logging as the access attempt is logged journalctl -u hostapd there are some messages, some abstracts from my logs STA mac_addr IEEE 802.11: associated STA mac_addr RADIUS: starting accounting session 63AA93B230BE083E STA mac_addr WPA: pairwise key handshake completed (RSN) STA mac_addr WPA: group key handshake completed (RSN) STA mac_addr IEEE 802.11: disassociated this helps ascertain that the connection / WPA / WPA2 is established and authentication is successful From prior discussions, it seemed NetworkManager uses wpa_supplicant. In my case, I find the lack of logs 'opaque' and lacks info for adequate troubleshooting. I'm also unsure if I can adequately separate the concerns with Network Manager with an AP, i.e. hostapd itself (for WPA/WPA2 and authentication), then dhcp to provide (to connecting clients) ip address and dns address, ipv6 router advertisements etc and in addition to setup a bridge separate from the wifi interface itself. And in part, hostapd apparently provides significantly more detailed configuration, in particular for the various features supported by wifi itself. https://web.mit.edu/freebsd/head/contrib/wpa/hostapd/hostapd.conf Hence, I choose to use hostapd instead. However, given those documentations, https://w1.fi/wpa_supplicant/devel/, it'd seem that hostapd and wpa_supplicant are likely equivalent. just that i'm more familiar with hostapd currently. Hence, in my setup. I've Network Manager omit setting up the wifi interface. /etc/NetworkManager/conf.d/99-unmanaged-devices.conf [keyfile] unmanaged-devices=interface-name:wlan0 Network manager, however, is used to setup the bridge and manage the ethernet interface, configured using nmcli. Then hostapd is configured to patch the wifi interface into the bridge after hostapd is running. /etc/hostapd/hostapd.conf bridge=br0 Networkmanager configuration of the bridge looks like this > nmcli c NAME UUID TYPE DEVICE bridge d0fc7d8a-51ea-4c5d-a297-943e2a037cff bridge br0 lo 59201f46-2fff-4f67-9822-7019cea62cf5 loopback lo br-eth 29c02c5c-4d75-4e03-bb71-8a761e076562 ethernet end0 > sudo brctl show bridge name bridge id STP enabled interfaces br0 8000.xxyy yes end0 wlan0 Here, wlan0 is patched into the bridge by hostapd. Note the race condition issue discussed 3 comments prior. The ethernet connection should be visible in NetworkManager in the default configuration e.g. as "Wired connection 1" Then to setup the bridge I used a bunch of nmcli commands https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 nmcli con down "Wired connection 1" nmcli con del "Wired connection 1" nmcli con add connection.id bridge type bridge ifname br0 nmcli con add connection.id br-eth type bridge-slave ifname end0 master br0 #this is for dynamic (dhcp IP address) #nmcli c modify bridge ipv4.method auto #this is for fixed ip address, and assume that your gateway router is at 192.168.1.1 nmcli c modify bridge ipv4.method manual ipv4.addresses 192.168.1.10/24 ipv4.gateway 192.168.1.1 In the above I removed the default Ethernet connection and replaced that with a bridge setup. The above can only be done via a 'usb-uart serial debug' bridge/dongle on the 3 serial pins for the serial console. i.e. you can't work from ssh into the ethernet connection and change the network configs. This is for the bridged setup. For a routed setup, my thoughts are that the 'missing' things are configure ip address and routing for the wifi (wlan0) interface (this would need to be done outside NetworkManager if it isn't managing it) run a dhcp server to provide connecting clients with ip address and dns address (this can be provided by dnsmasq or a dhcp server (e.g. isc-dhcp-server). (other services to run can included ipv6 router advertisements (radvd or dnsmasq does that), avahi (multi-cast DNS) etc) configure 'upstream' routing / forwarding through the ethernet (end0) Those are covered to some extent in the prior discussions. If you managed to run a succcessful setup say with hostapd, my guess is that you could likely migrate/convert that into a completely NetworkManager setup which uses wpa_supplicant internally. It could possibly be 'less verbose' as compared to these setups which requires a lot of additional manual configuration as like above.