ag123

@bjorn there are things I'm myself learning as well, hence won't be able to give an appropriate answer. btw, avoid using a source repository outside the armbian and mainline source tree. the main armbian build framework is here https://github.com/armbian/build and https://git.kernel.org for the 'real' mainline, I liked to ref Linus's git repository https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ Orange Pi Zero 3 and Zero 2W literally is directly supported out of mainline https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts?h=v6.8 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero2w.dts?h=v6.8 but that over here in Armbian, various contributors made further changes, go back pages in this thread and you would see them. But that the memory detection problem is not in the kernel. it is in u-boot and this is the original source the 'main stem' https://source.denx.de/u-boot/u-boot the 'black magic' for all that memory probing is in there https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads // SPDX-License-Identifier: GPL-2.0+ /* * sun50i H616 platform dram controller driver * * While controller is very similar to that in H6, PHY is completely * unknown. That's why this driver has plenty of magic numbers. Some * meaning was nevertheless deduced from strings found in boot0 and * known meaning of some dram parameters. * This driver supports DDR3, LPDDR3 and LPDDR4 memory. There is no * DDR4 support yet. * * (C) Copyright 2020 Jernej Skrabec <jernej.skrabec@siol.net> * */ https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_timings/h616_lpddr4_2133.c?ref_type=heads now here is the big story https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/38?u=ag1233 accordingly, the memory probing logic (is pretty much a hack), does by writing values to memory and reading it back. But that for 1.5GB dram chips, the address *wraps around* to some *unknown address*. so that 1.5GB is *incorrectly* detected as 2GB, so as soon as thing boot, it crash/hang. But that the dram controller is *undocumented* hence we can't simply access registers in the dram chip and simply read the memory size from the dram chip (that is the normal way to get the dram size these days, but that allwinner h616/h618 choose to *hide* the documentation for the dram controller, so there is *no way* to get at it. Then by reasoning, the only way left is: to find some ways to pass the memory size to *u-boot* so that u-boot would take that value and initialize the *whole* system. this is a / the solution to 'fix' this '1.5GB problem' as once that procedure is known and documented, then one can use this image with practically *any arbitrary dram size* , you can boot any H616/H618 board by passing the correct memory size e.g. by means of a 'config' file (e.g. a DTS overlay) u-boot is the bootloader and practically the *BIOS* e.g. it does things that the kernel 'don't know' about. this is the extreme of the *state of the art*, armbian (along with u-boot) is completely *bare metal*, you control the metal (e.g. transistors, silicion) *directly*, nothing, no software blobs is sitting in between you and the metal. --- one 'other' way that is practically a *hack* https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1348 static unsigned long mctl_calc_size(const struct dram_config *config) { u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ return (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; } it may be possible to compile a *custom u-boot*, and you change this code to return a memory size that you want, risky but I'd guess that may be what is floating out there in those binary blobs. The DTS (device tree source) file probably has other changes which is needed as well. imho, not quite a 'solution', but for things 'in the wild' you may instead be getting this hack in a binary blob. the *solution*, probably needs to be found in u-boot itself, that that may mean understanding the codes, and eventually a fix in u-boot itself to read the memory size say from a 'config' file (DTS?) all these ideas are for now just 'theory', it would take working this and testing it to see if e.g. simply return 1.5 GB in this function and writing the custom u-boot into the image literally gets the *whole system* up and running.

@bjorn it actually isn't necessary to make a new image from scratch, but that we'd need to figure out how to pass that 1.5GB memory size to u-boot, e.g. possibly a DTS overlay. then this means the procedure may possibly be: write the existing published image to sd card make a DTS overlay with the 1.5GB configured (a text file) - may need to be compiled into a DTB file update armbianEnv.txt to use the edited overlay and save them on the image sd card appropriately on booting up, the os should then boot normally as do any other boards. Unfortunately, no one yet has probed this and document the steps to do this successfully.

@bjorn the "1.5G issue" is a known issue, few of us has time to work on that for now. if you scroll a little back, you would find this comment The problem is in *u-boot*, the 'solution' is to pass a parameter to u-boot to tell u-boot the memory size of the board. None of us has tried it in the meantime, and among the options is to make a DTS overlay that has the memory size (not tested) and perhaps update armbianEnv.txt to load that overlay https://docs.armbian.com/User-Guide_Armbian_overlays/ this has to be manually done for every board that u-boot cannot detect the memory size (because the dram controller is *undocumented*, the current memory probe is at best a hack, and it works for 'whole numbers' dram sizes 1G, 2G, 4G) You could give that a shot by exploring that solution, just that none (of us, including yourself) has worked it yet.

@mc510 , Guests, et. al. yup this board is 'community maintained', i.e. by 'all (various) of us' including yourself here. There are some images linked at the board page (scroll to the bottom), currently 6.6.26 as seen (they could be new versions as things progress) https://www.armbian.com/orange-pi-zero-3/ if you prefer a more recent 'bleeding edge' versions, try building the image yourselves: https://docs.armbian.com/Developer-Guide_Build-Preparation/ That makes it really good as you can configure every kernel build parameter and change codes for the build as you deem fit yourselves. Jumping this hoop which is quite a high bar is also a necessary step to learn to maintain Armbian. None of us truly 'own' nor is committed to the (long term) maintenance, but that all (various) of us who owns the board (including yourselves) participate to test and work the board (e.g. use it) and chip in to fix issues as they get discovered (ourselves). I'd nevertheless give credits to @Igor, staff, contributors and friends, and various other contributors, moderators, you could find them if you browse this thread. For the relentless work as Linux versions progresses. This is one of the distributions that attempts to go up to the very recent mainline kernel releases (e.g. 6.8 recently), and not least for hosting this forum and the web site. Do consider sponsoring Armbian https://forum.armbian.com/subscriptions/ as that makes this project a co-operative, e.g. the users of Armbian are also its contributors and that this become more sustainable.

@thuvasooriya wrote hi if you review this thread, the earlier comments, you would notice that there are quite varous discussions about DTS overlays for the gpio headers. noticably discussions from / between @Gunjan Gupta @pixdrift @Stephen Graf. Unfortunately, it seemed for now not all the changes have made it into the trunk. there are also various discussions about libgpiod and gpiod, hope those may help with access to the pins.

@thuvasooriya wrote rather than to use HDMI and a monitor, I used a usb-uart (usb-serial) dongle that lets me connect over the serial console with the debug pins and I'm literally able to boot up in a serial console and (even) configure networking, i.e. I didn't even need network and can change the network interface configurations. That would also be a way to troubleshoot boot up problems if there is. I used the serial debug pins/console to configure networking as more than often, the default setup of network isn't what I want, and playing with the network interfaces will lock me out of ssh. After I've network configured over usb-uart, I can then ssh remotely into the device over the network. And that if you use dynamic IP, it may help to install and use avahi-daemon and avahi-tools (i.e. multicast DNS), I installed avahi-daemon on the OPi Z3 Armbian board so that I can find it from my main linux box using avahi-browse -a , and that ssh into there could be simply ssh orangepizero3.local that's a way to practically use it headless , in fact, after I've setup things, it is now my WiFi AP on the desk.

Among the things to try, get and set up a usb-serial (usb-uart) dongle to the debug UART pins, and you should be able to see the boot up in a serial console. The boot messages may provide a clue to what went wrong.

@electricworry I can't remember where I saw comments about the HDMI sound issues, but that it is more than likely that HDMI and even graphics could be *undocumented* and *reverse engineered* (possibly by the talented people on the linux sunxi https://linux-sunxi.org/Main_Page and such efforts), it could be an up hill task to reverse engineer HDMI sound in particular considering the complexity of such interfaces. there is apparently some related work, thread and thanks to @Nick A for researching and sharing various info, there may be some hints as to what needs to be done. it seemed quite possible to patch dts files to get hdmi sound support, but it is just wild guesses, you would need to review the info.

@thuvasooriya while I do not have an OrangePi Zero 2W (I only have Zero 3), it would seem to me that Zero 2W is basically Zero 3 less the onboard Ethernet. I'm not sure what else is different where 'compatibility' goes. Ethernet for Zero 2W is on the expansion board that Orange Pi sells, hence if you want ethernet, you may want to purchase the expansion board to experiment. No promises if it'd works though. It'd seem to me that OrangePi is basically selling on the 'form factor' difference, and 2W being smaller won't fit the bulky ethernet RJ45 connector and the phy chip. But that if you actually try that, it'd be good to report in a comment if it (expansion board and ethernet) works or otherwise. As well if you used the Zero 3 images, e.g. from 'original' image https://www.armbian.com/orange-pi-zero-3/ , if you scroll down to the bottom you woul see the links to the images and torrents. It would be good to feedback in a comment about what works or not etc. I went straight with Zero 3 initially as I wanted both ethernet and wifi, those are built on board for Zero 3 and hence that.

@boorch wrote Hi thanks for trying it out, I feel somewhat embarrassed that I've not tried it out myself. In terms of the release the vendor Orange Pi (Xun Long) actually first released the Zero 3 then subsequently Zero 2W they are both based on H618 do post a comment to say what works or not. If your are trying my image, that is based on a minimal Debian Bookworm build, I did that mainly to save up on the image size/footprint. And also that I'm using that mainly as a wifi hotspot, and a desktop environment bring along too much baggage add gigabytes of storage use, consume a lot of memory and possibly slow down my intended use. To go from minimal to a desktop environment, I googled and found this page: https://wiki.debian.org/DesktopEnvironment as documented you can try > apt show task-desktop Package: task-desktop Version: 3.73 Priority: optional Section: tasks Source: tasksel Maintainer: Debian Install System Team <debian-boot@lists.debian.org> Installed-Size: 6,144 B Depends: tasksel (= 3.73), xorg, xserver-xorg-video-all, xserver-xorg-input-all, desktop-base Recommends: task-gnome-desktop | task-xfce-desktop | task-kde-desktop | task-lxde-desktop | task-gnome-flashback-desktop | task-cinnamon-desktop | task-mate-desktop | task-lxqt-desktop, xdg-utils, fonts-symbola, avahi-daemon, libnss-mdns, anacron, eject, iw, alsa-utils, sudo, firefox | firefox-esr, cups Download-Size: 1,036 B APT-Sources: http://mirror.sg.gs/debian bookworm/main arm64 Packages Description: Debian desktop environment > apt show task-gnome-desktop Package: task-gnome-desktop Version: 3.73 Priority: optional Section: tasks Source: tasksel Maintainer: Debian Install System Team <debian-boot@lists.debian.org> Installed-Size: 9,216 B Depends: tasksel (= 3.73), task-desktop, gnome-core Recommends: gnome, synaptic, libreoffice-gnome, libreoffice-writer, libreoffice-calc, libreoffice-impress, libreoffice-help-en-us, mythes-en-us, hunspell-en-us, hyphen-en-us, network-manager-gnome Download-Size: 1,184 B APT-Sources: http://mirror.sg.gs/debian bookworm/main arm64 Packages Description: GNOME ^ I think that is the package to install the desktop environment for instance to install gnome desktop it could be > sudo apt install task-gnome-desktop Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: accountsservice acl adwaita-icon-theme apache2-bin apg appstream apt-config-icons at-spi2-common at-spi2-core baobab bluez-obexd bubblewrap colord colord-data dconf-cli dconf-gsettings-backend dconf-service desktop-base desktop-file-utils dictionaries-common emacsen-common eog evince evince-common evolution-data-server evolution-data-server-common folks-common fonts-quicksand fonts-urw-base35 gcr gdisk gdm3 geocode-glib-common gir1.2-accountsservice-1.0 gir1.2-adw-1 gir1.2-atk-1.0 gir1.2-atspi-2.0 gir1.2-evince-3.0 gir1.2-freedesktop gir1.2-gck-1 gir1.2-gcr-3 gir1.2-gdesktopenums-3.0 gir1.2-gdkpixbuf-2.0 gir1.2-gdm-1.0 gir1.2-geoclue-2.0 gir1.2-gmenu-3.0 gir1.2-gnomebluetooth-3.0 gir1.2-gnomedesktop-3.0 gir1.2-gnomedesktop-4.0 gir1.2-goa-1.0 gir1.2-graphene-1.0 gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gir1.2-gtk-3.0 gir1.2-gtk-4.0 gir1.2-gtksource-4 gir1.2-gweather-4.0 gir1.2-handy-1 gir1.2-harfbuzz-0.0 gir1.2-ibus-1.0 gir1.2-javascriptcoregtk-4.1 gir1.2-json-1.0 gir1.2-mutter-11 gir1.2-nm-1.0 gir1.2-nma-1.0 gir1.2-notify-0.7 gir1.2-pango-1.0 gir1.2-peas-1.0 gir1.2-polkit-1.0 gir1.2-rsvg-2.0 gir1.2-soup-3.0 gir1.2-upowerglib-1.0 gir1.2-webkit2-4.1 gjs gkbd-capplet glib-networking glib-networking-common glib-networking-services gnome-backgrounds gnome-bluetooth-3-common gnome-bluetooth-sendto gnome-calculator gnome-characters gnome-contacts gnome-control-center gnome-control-center-data gnome-core gnome-desktop3-data gnome-disk-utility gnome-font-viewer gnome-keyring gnome-logs gnome-menus gnome-online-accounts gnome-session gnome-session-bin gnome-session-common gnome-settings-daemon gnome-settings-daemon-common gnome-shell gnome-shell-common gnome-shell-extensions gnome-software gnome-software-common gnome-sushi gnome-system-monitor gnome-terminal gnome-terminal-data gnome-text-editor gnome-themes-extra gnome-themes-extra-data gnome-user-docs gnome-user-share grilo-plugins-0.3 gsettings-desktop-schemas gstreamer1.0-gl gstreamer1.0-gtk3 gstreamer1.0-packagekit gstreamer1.0-pipewire gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-x gtk-update-icon-cache gtk2-engines-pixbuf gvfs gvfs-backends ... Suggested packages: apache2-doc apache2-suexec-pristine | apache2-suexec-custom www-browser colord-sensor-argyll gnome | kde-standard | xfce4 | wmaker ispell | aspell | hunspell wordlist eog-plugins nautilus-sendto unrar evolution fonts-freefont-otf | fonts-freefont-ttf fonts-texgyre orca libpam-fprintd libpam-sss libpam-pkcs11 gstreamer1.0-pulseaudio pkexec gnome usbguard gir1.2-malcontent-0 gir1.2-telepathyglib-0.12 gir1.2-telepathylogger-0.2 ... Recommended packages: xserver-xephyr fonts-noto-color-emoji cups-pk-helper gnome-remote-desktop power-profiles-daemon rygel | rygel-tracker malcontent-gui network-manager-gnome realmd firefox-esr | firefox | chromium | chromium-browser | epiphany-browser | gnome-www-browser libproxy1-plugin-networkmanager low-memory-monitor gnome-keyring-pkcs11 iio-sensor-proxy pkexec bolt chrome-gnome-shell ibus switcheroo-control gnome-shell-extension-prefs fwupd nautilus-extension-gnome-terminal gnome-accessibility-themes aspell-en | aspell-dictionary | aspell6a-dictionary libaacs0 libcanberra-gtk3-module enchant-2 libgdk-pixbuf2.0-bin libgphoto2-l10n fonts-droid-fallback libgtk-3-bin libgtk-4-bin usbmuxd libmtp-runtime ... 0 upgraded, 584 newly installed, 0 to remove and 32 not upgraded. Need to get 301 MB of archives. After this operation, 1,218 MB of additional disk space will be used. Do you want to continue? [Y/n] I stopped and answered 'n' at the prompt, if you have the space, you could try that out to see if that works to install and setup a full desktop environment note that I've not tried the above, and there are also other selections / desktop environment that you can choose Recommends: task-gnome-desktop | task-xfce-desktop | task-kde-desktop | task-lxde-desktop | task-gnome-flashback-desktop | task-cinnamon-desktop | task-mate-desktop | task-lxqt-desktop, xdg-utils, fonts-symbola, avahi-daemon, libnss-mdns, anacron, eject, iw, alsa-utils, sudo, firefox | firefox-esr, cups e.g. there are the above of task-xxx-desktop which I'd think installs the respective desktop environment. After installing sudo systemctl set-default graphical.target to make sure that the desktop environment starts up on reboot if you do try that out, do leave a comment on your experiences with it and how it works. That may help others wanting to do the same. post a screenshot another page found from a google search for a reference https://www.layerstack.com/resources/tutorials/How-to-install-Graphical-User-Interface-GUI-for-Debian-11-Cloud-Servers ^ there are other stuff there e.g. enable root login etc

SBC and embedded world is an absolute jungle, take for instance Orange Pi Zero 3 (just as an example) , it has an on board flash chip which can store a boot rom. the kernel bootloader u boot https://en.wikipedia.org/wiki/Das_U-Boot can either: boot from a normal sd card (and this depends on the vendor's boot rom, which loads the first few sectors on the sd card (which is u-boot itself) and jumps to u-boot which in turns boots linux (no uefi) u-boot can be installed in that boot rom become the BIOS ! itself, and u-boot can boot linux *directly* u-boot can practically emulate any kind of booting scheme (including the vendor's original, uefi etc) but that requires u boot to replace the vendor's boot rom (deemed a risky activity, it may brick the board) and that every different board can have different hardware configuration (a LED on a different pin or configuration (e.g. pull up or pull down) make a different board (with everything else being the same) !) the above already constitute M different boot configurations and N different boards, with just 8 pins for LEDs you can make a combination of 8! 8x7x6x5x4x3x2x1 permutations x 2 configurations (pull up or pull down) ~ 80640 different boards for the same board. so for sanity and practicality, a device tree overlay is made for a *fixed* board. e.g. Orange Pi Zero 3 and that this project is practically supporting M socs x N boards x X configurations x Y distributions (debian / ubuntu to name just 2, wrong not just 2 within that 2 there are different *releases* ) x Z kernels (legacy / stable / bleeding edge) and that is not just 3 versions, oh and just UEFI alone has another N different versions https://uefi.org/specifications 😛 btw u-boot practically achieved the *holy grail* (look ma no BIOS) http://www.haifux.org/hebrew/lectures/111/img0.html it is as hard core and bare metal as one can be. it isn't about OS being 'portable' per se, than it is about what you see in each figment (i.e. a particular board with a particular config) is just one single very narrow endpoint in the sea of infinite permutations.

@Igor, @Gunjan Gupta thanks for all that effort, I'm sure many would patiently, and eagerly wait for that and an ad for Armbian, for/to new users who have stumbled into this thread https://www.armbian.com/donate/ those who are using Armbian e.g. on Orange Pi Zero 3, do consider 'sponsoring' Armbian (e.g. with a subscription etc). 'donate' is actually an incorrect term for that, but there is no equivalent. open sourced projects like such takes a lot of effort, but that unlike commercial SASS (software as a service) etc, there is practically no feasibility to put a *paywall* as do most other commercial providers / software. Some providers resorted to *close source*. And most will *detest* this as imagine that you need to fix a bug that *blink a led* on your pin header, that'd means *no access*, *cannot be done*. embedded *intrusive* ads would be a next wors(e,t) thing --- on another topic, about technicals: i look at some 'solutions' for patches, i've not found practically anything that 'works' the problem of patch sets against multiple targets (different patch set applies) and version, and between multiple different *contexts*, between 'release' upgrades and that the patch sets in themselves has their own dependencies on the core source codes (sometimes even modules in the source codes become recursive patch-on-patch dependencies) and between patches. something like gerrit code review, *does not address the issue* https://www.gerritcodereview.com/about.html https://gerrit-documentation.storage.googleapis.com/Documentation/3.9.2/intro-rockstar.html that would instead cause stalls in development workflow as we have n different boards with different distribution targets with different *boot loaders* and hardware and configuration (e.g. a led on a different pin makes a *different board* even if every thing else being the same) this conundrum has never been fully addressed even today with the device tree. We need 'dynamic device tree' that can literally *change on the fly* after things booted up, because you can hot plug anything on the pin headers. the whole development would practically *stop* as the different *boards* would have *no (or very few) reviewers* then I looked at stackedgit https://stacked-git.github.io/guides/usage-example/ https://stacked-git.github.io/guides/tutorial/ https://github.com/stacked-git/stgit/ looks promising but again that would take time and effort to explore and it is likely not adequate to address this same issue.

the 'community' one is here, scroll right to the bottom https://www.armbian.com/orange-pi-zero-3/ and the kernel version is at least 6.6 and above apparently someone has seen the same , so it isn't 'new' https://www.linux.org/threads/protocol-0000-is-buggy-dev-wlan0.42774/ if one google around the web one may stumble into this https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml it could mean a device you have is sending out goofy packets that are not regular IP packets. the normal protocols used are usually TCP, UDP and ICMP.

just like to mention that I managed to run a build for Orangepizero3 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bookworm_edge_6.7.10_minimal the kernel is 6.7.10 the build managed to run to completion the image is completely untested -rw-rw-r-- 1 armbian root 1413480448 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo okworm_edge_6.7.10_minimal.img -rw-rw-r-- 1 armbian root 213 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo okworm_edge_6.7.10_minimal.img.sha -rw-rw-r-- 1 armbian root 19756 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo okworm_edge_6.7.10_minimal.img.txt And I'm not sure if it'd even work. It is not uploaded anywhere, For this build as OrangePi Zero 3 is deemed csc, you need to select the experimental unsupported builds to see the boards being listed. I ran the build just to see that the build completes after all, having no time (yet) to run tests with that. -- update it was TLDR (too late didn't read) then ok it is here, and remember *untested* (it is not known if it'd work if at all), *unofficial* *unsupported* use at your own risk https://www.mediafire.com/file/bym559l94sn8xyd/Armbian-unofficial_24.5.0-trunk_Orangepizero3_bookworm_edge_6.7.10_minimal20240320.7z/file this (file) won't be there on the permanent basis it'd seem @Igor is moving Armbian to 6.8 (hey that's just 9 days 'old' https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tag/?h=v6.8, as of this comment) that's a good thing, and thanks this linked image would be a pre-6.8, if it works. other fun stuff https://www.omgubuntu.co.uk/2024/03/linux-kernel-6-8-new-features https://www.zdnet.com/article/linux-kernel-6-8-offers-some-exciting-new-features-and-fixes-all-over/ https://www.theregister.com/2024/03/04/linux_6_8_rc_7/ https://www.phoronix.com/review/linux-68-features https://lore.kernel.org/linux-kernel/CAHk-=wiehc0DfPtL6fC2=bFuyzkTnuiuYSQrr6JTQxQao6pq1Q@mail.gmail.com/T/

i'd be kind of 'off topic' here, armbian is somewhat in the 'fast lane', 'bleeding edge' https://www.debian.org/releases/ recently when we worked on Orange Pi Zero 3 we actually jumped right into bookworm, had there been something more 'bleeding edge' that may be it and that we jumped into 6.6 kernel (as it is about the 1st kernel that has support for Orange Pi Zero 3 on allwinner H618 cpu, and that actually as development progress, it actually advanced to 6.7, 6.8 etc. Today, I just installed Ubuntu jammy from Ubuntu, only to find that that is 6.5 ! and that even orange pi's 'official' image for Orange Pi Zero 3 gets 'left behind' at 6.1 I'd suggest to try upgrading to the 'latest' debian (bookworm?) image, it may take quite a bit of 'reinstall' though. And that everything is 'brand new', 'bleeding edge' there. the python 3 version is 3.11, that in ubuntu jammy is 3.10 ! that said, there are bound to be some broken bones left around somewhere, it is 'under construction' (all the time) oh some fun stuff, 6.8 is 9 days old, who knows that might be the new Armbian kernel https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/