ag123

ok just an update, I managed to get past that '1.5GB' issue the hack is done in u-boot, but the bad news is that that alone won't fix things: U-Boot SPL 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) sunxi_board_init DRAM:sunxi_dram_initdetected memsize 2048 M 1536 MiB spl_board_init_r Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0b4330, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 U-Boot 2024.04-00757-FixOPiZero3_1.5G (Apr 19 2024 - 23:25:32 +0800) Allwinner Technology CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 1.5 GiB Core: 58 devices, 25 uclasses, devicetree: separate WDT: Not starting watchdog@30090a0 MMC: mmc@4020000: 0 Loading Environment from FAT... Unable to use mmc 0:1... In: serial@5000000 Out: serial@5000000 Err: serial@5000000 Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@5020000using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in MAC de:ad:be:ef:00:01 HOST MAC de:ad:be:ef:00:00 RNDIS ready , eth1: usb_ether starting USB... Bus usb@5200000: USB EHCI 1.00 Bus usb@5200400: USB OHCI 1.0 scanning bus usb@5200000 for devices... 1 USB Device(s) found scanning bus usb@5200400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3259 bytes read in 4 ms (794.9 KiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 205 bytes read in 4 ms (49.8 KiB/s) 32823 bytes read in 8 ms (3.9 MiB/s) Working FDT set to 4fa00000 4203 bytes read in 7 ms (585.9 KiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 10936176 bytes read in 457 ms (22.8 MiB/s) 23570440 bytes read in 982 ms (22.9 MiB/s) Moving Image from 0x40080000 to 0x40200000, end=41910000 ## Loading init Ramdisk from Legacy Image at 4ff00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 10936112 Bytes = 10.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 Working FDT set to 4fa00000 Loading Ramdisk to 49592000, end 49ffff30 ... OK Loading Device Tree to 0000000049521000, end 0000000049591fff ... OK Working FDT set to 49521000 Starting kernel ... [ 2.144698] thermal thermal_zone0: gpu-thermal: critical temperature reached, shutting down [ 2.153147] reboot: HARDWARE PROTECTION shutdown (Temperature too high) [ 2.192185] reboot: Power down This gpu over temperature is nonsense, the chip is hardly warm and this same image boots just fine on a 2GB device with the 'standard' u-boot. It'd seem that some other things is at play here, e.g. that the registers for 1.5GB model are after all different and may need a different DTS configuration. I don't have a solution to go forward for now for 1.5GB devices, configuring DTS takes much more than this little hack, in the sense that we'd not know if this gpu thermal thing is the only odd thing or that there are other things that needs to be fixed as well. -- for those who insist if you would like to test this solution, the attached file is the modified u-boot compiled from https://source.denx.de/u-boot/u-boot https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-sunxi/dram_sun50i_h616.c?ref_type=heads#L1353 the function arch / arm /mach-sunxi /dram_sun50i_h616.c function mctl_calc_size() is modified as: static unsigned long mctl_calc_size(const struct dram_config *config) { u8 width = config->bus_full_width ? 4 : 2; /* 8 banks */ unsigned long long memsz = (1ULL << (config->cols + config->rows + 3)) * width * config->ranks; log_info("detected memsize %d M\n", (int)(memsz >> 20)); /* 1.5 GB hardcoded */ memsz = 2048UL * 1024UL * 1024UL * 3 / 4; return memsz; } i.e. that 1.5GB is *hardcoded*, obviously this won't be appropriate for most boards except in particular case of 1.5GB. Initially, i placed an if statement that says if the detected ram is 2GB say that it is 1.5GB, that is bad as well as then 2GB boards will simply read 1.5GB. however, during tests, I noted that the detected dram size varies between 2 GB and 4 GB. my guess is there are timing issues associated with the 1.5GB dram chip, hence I resorted to hard coding which does not bother how much dram is really detected. if you prefer to build u-boot from sources, follow instructions from here: https://docs.u-boot.org/en/latest/board/allwinner/sunxi.html To use this modified u-boot, the best practice is to start with / use an image that is known to work on 1GB / 2GB / 4GB Orange Pi Zero 3 boards. assuming that your image SD card is mounted at /dev/sdX, you can backup your existing u-boot e.g. sudo dd if=/dev/sdX of=u-boot-backup.bin bs=1024 skip=8 count=1024 that should backup the u-boot in your device to u-boot-backup.bin then to write the modified u-boot into the SD card it is (be sure that you are writing to the correct device ! mistakes here can corrupt your existing hard disks / storage) sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdX bs=1024 seek=8 it may be possible to write that to an existing image file (do backup your image file beforehand) dd if=u-boot-sunxi-with-spl.bin of=file.img bs=1024 seek=8 conv=notrunc but that I've not tried this. and note this is caveat emptor (let the user beware, use at your own risk), there is no assurance if after all it fixes anything or break other things. u-boot-sunxi-with-spl.bin

I got past that DRAM: 0 Bytes it is my own goof when I'm editing the u-boot codes U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 19 2024 - 18:04:53 +0800) sunxi_board_init DRAM:sunxi_dram_initmemsize 2048 M 1536 MiB spl_board_init_r Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 ... the hack seemed to work next I'd need to learn u-boot,

@usual user I think this is what happens, within the microprocessor soc, there is sram likely small 10s-100s of K bytes is likely, so the on board rom loads u-boot as a SPL (secondary program loader) also into s-ram. Then that u-boot needs to *clock the dram* (i.e. setup the dram so that it is actually working), determine dram size, configure dram to be up and running e.g. the 'rows and columns', setup memory mapping. All these in *sram* it did not even touch dram. Then that once everything is up, u-boot loads the *linux kernel* into dram, pass over the DTS and pass over the dram memory size and jumps into the kernel code, then linux boots up from there on. The trouble is that u-boot did not detect the DRAM and the codes is directly from the stem (mainline) https://source.denx.de/u-boot/u-boot I added a lot of debug() statements to trace execution flow and it seemed apparently that it did not even go into the dram initialization parts of the code. So I actually need help with the u-boot codes. I can't figure out why it is not working. All that BL31 etc is mainly for power management (e.g. shutdown / suspend etc), didn't seem to deal with DRAM https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/allwinner/sun50i_h616

@voapilro, @bjorn, @electricworry I'm attempting to fix (at least a hack) the 1.5GB problem by attempting to build a custom u-boot to attempt to resolve the issue. The thing is the codes are pretty complex. https://docs.u-boot.org/en/latest/ https://source.denx.de/u-boot but that actually I succeeded in building u-boot The trouble is I'm getting this: U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) DRAM: 0 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 ion U-Boot 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) Allwinner Technology size=30, ptr=590, limit=2000: 26370 CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 0 Bytes So I literally need help with the codes, I'm doing pretty tedious debug etc with a 1.5G OPi Z3 board I bought for this purpose. if you run the 'original' images, that has a 'working' u-boot, it reads DRAM 2GB https://www.armbian.com/orange-pi-zero-3/ still 'incorrect' but that accordingly there'd be fixes for it (in u-boot) https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/42 https://gist.github.com/iuncuim The trouble as i try to trace where the calls are going is that it is not even going into the dram initialization codes in u-boot meant for H616/H618 to initialize and size up the lpddr4 dram. the codes are complex and I'd hope to get some leads there to attempt a solution. if a 'custom u-boot' can fix that, it'd at least help those who still only have 1.5GB boards to get Armbian running on it. By *replacing* the u-boot (practically the boot loader (and BIOS)) in the image or sd card. The image (and on the SD card) looks like this 0-7 KB (unused/reserved) 8 KB - 1 MB u-boot 1 MB - the rest of your sd card (this is your linux partition and Armbian proper (Debian or Ubuntu) lives here) u-boot does the bulk of the 'black magic' dealing with memory initialization and sizing, and then passing that across to linux during boot up. and linux uses the device tree (DTB, DTS) to configure the various devices uart, usb, sd card, leds, etc etc and subsequently present various of them in /dev. a 'custom u-boot' apparently seem to be a most feasible 'solution' (hack) to at least get past the 1.5GB problem. it is quite easy to simply take the original image, and substitute one u-boot made to say the memory is 1.5GB.

@voapilro orange pi's suffer from a few things, in particular poor software support and if you have an issue and goto their forums http://www.orangepi.org/orangepibbsen/ you can see a lot of no responses, spams etc. and that for the 'official' images you have obtained, those are the relevant support forums as they are different from Armbian today. The images released from Orange Pi are linux kernel versions 6.1 which has yet been updated, nothing 'wrong' about it, but that linux version progress is relentless. in fact Orange Pi Zero 3 (and a little later Zero 2W) is supported out of mainline linux from kernel release 6.6, i.e. the DTS (device tree configuration) is released open sourced. And that the implementation from mainline is completely developed open sourced (by various talented individuals outside here in linux-sunxi i think, and subsequently the few of us here siezed on the opportunity and tried to make Armbian run on it, browse the earlier part of this thread and you see @Gunjan Gupta, @pixdrift, @Stephen Graf et.al working this, we also found that a lot of things are undocumented and it is a *miracle* that it is after all running (well) today. try getting a 1G / 2G / 4G board and run Armbian on it. https://www.armbian.com/orange-pi-zero-3/ And I'd like to add that Armbian itself @Igor and team contributes in no small measure that makes this project possible (just consider catching up with the linux versions with so many platforms to carry), considering that there is no 'big company' (e.g. Intel, Rpi etc) behind this. it is all little contributors whom you see here. In this sense, the users of Armbian are the contributors and maintainers as well, a co-operative, practically the spirit of open source, if after all that economic model works. A good thing is that you can literally build ths whole thing (the images for your board from *source*) https://github.com/armbian/build you can configure all the kernel parameters for all you want for the build, edit the source codes, fix bugs, add features etc, there are many 'upstream' projects which include the linux kernel itself, u-boot, the distributions Debian / Ubuntu that contributes into the assembly, probably others as well, and the armbian build framework at this day is huge and complex considering the platforms (boards) that is supported. This probably also matter to 'security conscious' people who want to know every nut that is in there. But that it is up to you to make the effort to inspect that there are no 'holes' (e.g. trojans, backdoors, connecting to 'unauthorized' C2 (command and control) sites that you don't want etc). e.g. you can inspect and tweak all you want and afterwards run the build. And not least being open sourced means that it is nearly / practically *bare metal*, the codes work the metal (transistors / silicion / registers) directly, no blobs in-between. The trouble with blobs is your app is release to you as a binary, the driver is a binary (blob), then a new os (e.g. linux version, you can even consider windows) is released, now your binary app and or driver no longer works in the new os version (linux or windows), and you can use your device (e.g. mouse) as your new door stop. buy a new one and again more binaries , more device driver blobs.

@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/

it is there in 'community releases' https://www.armbian.com/orange-pi-zero-3/ scroll to the bottom of that page get a 'whole number' (1GB, 2GB, 4GB) dram size board, for 1.5GB there it is still under 'research', you + (community) need to find a way to tell u-boot (the bios and boot loader) that the board is 1.5GB once that is figured out, it is possible to practically use any board with any amount of memory.

@jvro wrote: Try the 'server' / minimal image? it used to be called 'run levels' in sysv init. Now it is systemd https://opensource.com/article/20/5/systemd-startup#targets https://www.cyberciti.biz/faq/switch-boot-target-to-text-gui-in-systemd-linux/ There may be some features if you review the user guide https://docs.armbian.com/User-Guide_Getting-Started/ and maybe check in the tutorials forum section https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/ but that for anything more complicated, what I did instead is to get a usb-uart dongle connect to the 3 pins for 'debug' console, check the documentation for Orange Pi Zero 3 from the vendor. Then that you can literally boot up in a console / terminal app, login on the console / terminal app etc even for the first time. For now I keep the steps as a set of manual command line commands I run, including changing the passwords etc. And basically 'copy and paste' the commands say from a pre maintained file with the steps and commands. edit: I think for that matter, it is quite possible to *script* that say using python https://pyserial.readthedocs.io/en/latest/ and have the 'auto setup and config' all done over serial usb-uart over that debug port. and for those who are 'ancient' enough, there is tcl/tk https://www.tcl.tk/ and expect https://wiki.tcl-lang.org/page/Expect https://wiki.tcl-lang.org/page/BOOK+Exploring+Expect https://gist.github.com/fstab/6d39fae3a436d9bd6cecb1d9fde9a667 ---- I think it is possible to directly customize the image though. That would take mounting the image as a loop device in Linux (prefably make a copy of it). And perhaps for the config files (e.g. in /etc) on your running SD card, copy them out and replace the same in the image.

@Long-Johnny Rather than to say 'never solved', we (as a community) need to learn about *uboot* https://docs.u-boot.org/en/latest/ https://linux-sunxi.org/U-Boot this is practically the *BIOS* for these little boards that we use and that u-boot boots Linux - it is the boot loader. Once you / we find a way to pass that memory size to *uboot*, then it is a matter of learning to configure a file e.g. edit a DTS overlay to encode the memory size. And there you have it, a fully supported board. But that that step/procedure may have to be manually done by hand. In that sense, once one figures this out, one can manually configure these boards for any arbitrary memory size.

@Long-Johnny 1.5gb issue is a *known issue* The problem is in u-boot, rather to explain it in a simple manner, the DRAM controller in H616/H18 is *undocumented*, so developers has to probe in the dark to try to reverse engineer how it works, it is a 'miracle' that it works today where there is practically *no documentation* about the DRAM controller. The dram chips has registers which encode the size of the dram, but that there is *no way* to access the dram registers because the DRAM controller is *undocumented*. Hence, developers working on open source u-boot, Linux resort to *hacks*, the memory size is probed by writing some data at specific locations and reading it back. The trouble is that for DDR4 1.5gb dram chips, the address wraps around, so that trying to write something to 2GB for a 1.5GB chip produce *no errors*, so 1.5 GB boards are detected as 2GB boards. it gets written into an unknown location that will corrupt some other memory and uboot or kernel or any apps that use memory above 1.5GB and uboot, kernel or the app will simply *crash*. For that matter, there is no practical code fixes that can fix this, because no algorithms can generally handle arbitrary address wrap around for *different* memory sizes. e.g. there can be at some point 2.5gb, 3.5gb, 1.2gb, 1.4gb. 1.8gb, 0.9gb or any odd combination of memory, and there is no way to detect by writing and reading back memory how that wraps around if say writing memory to every 512MB locations simply wrap around to some unknown address. The only way is if Allwinner release documentations for the H618 memory controller and that the memory size be read from the dram chip registers as a formal fix to it. To find a solution to this, one would need to research a way to pass the memory size to *uboot* (and therefore the kernel), so that u-boot can read that memory size say from a config file, DTS overlay or on the uboot command prompt. In the mean time, if one don't want to try researching the 'deep end' as suggested above, use boards with 'whole numbers' memory sizes. e.g. 1GB, 2GB, 4GB.

@robertoj, all, apparently, it may be possible to name the lines in the DTS https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpiolib.c?h=v6.7.4#n456 Example: gpio-controller@00000000 { compatible = "foo"; reg = <0x00000000 0x1000>; gpio-controller; #gpio-cells = <2>; ngpios = <18>; gpio-reserved-ranges = <0 4>, <12 2>; gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R", "LED G", "LED B", "Col A", "Col B", "Col C", "Col D", "Row A", "Row B", "Row C", "Row D", "NMI button", "poweroff", "reset"; I'm not sure though if the gpio-line-names assignment can be used in pin-control devices that is currently present in the existing DTS. note also that the line/pin functions are actually defined in the source codes for the pin-control driver, just that this won't automatically appear as gpio-line-names. you may want to start experimenting, post your findings and perhaps make a PR? note that there is another source tree to commit though , which is in linux-sunxi - that would be directly mainlining / upstreaming the changes. https://linux-sunxi.org/Main_Page https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/ they have a google groups here: https://groups.google.com/g/linux-sunxi https://linux-sunxi.org/Mailing_list I'm not too sure about the procedure to commit changes in mainline though.