Search the Community

Hello! First of all. Sry if this was already menationed ins some thread. I tried to find the solution here I am using a ROCKPI E. I switchted my OS from Ubutnu to ARMBIAN 23.8 Bookworm. I am still confused, if this was a good idea. I read that ARMBIAN should be the “better” OS for the KERNEL. Is there a rule of thumb what to use? On my Ubuntu i made some settings to route my IPS, since i am controling a pump on ETH0 and using my LAN on ETH1. On UBUNTU i made this changes on dhcpcd.conf: interface eth0 static ip_address=192.168.1.50/24 static router=192.168.1.2 static domain_name_server=8.8.8.8 Since this file does not exist on ARMBIAN, where do i make the changes for this on ARMBIAN? thank you

Thank you. like in this thread, that come through my research (thats why i have 2 threads, sorry) I somehow cant activate end0 (eth0) almost like it doesnt exist. Strange

This is interesting one. Kind of like how sd card names are different between different version of RPi. You haven't mentioned the image you are using. But from the post I am deducing it was working fine for you until you installed an update? I am not 100% sure as this is not a device I work with. But generally the root device is set in a file called armbianEnv.txt. Here is something for you to try mount your root partition mount /dev/mmcblk0p1 /mnt check if /mnt/boot/armbianEnv.txt exists ls /mnt/boot/armbianEnv.txt if it doesn't exists, create it. Replace <Your UUID> with UUID shown in output of blkid command echo "rootdev=UUID="<Your UUID>" > /mnt/boot/armbianEnv.txt unmount your root partition umount /mnt and reboot

@rm_ We have found the reason for the issue. It seems to be cause by sun8i-a33-mbus kernel module which provides dynamic frequency scaling for ram i.e if the system is not under too much load, the driver will lower ram frequency to save some power. I tried modifying the driver to see if a higher value for minimum frequency can solve the issue, but even though that works when testing on a running system, it doesn't work on boot. So as a workaround, I am going to disable this driver in the kernel config and raise a PR. Until the fix is merged, as a workaround follow these steps to mitigate the issue on your system Edit the /etc/modprobe.d/blacklist.conf file. Feel free to create it if it doesn't exist. Add the following line to it blacklist sun8i-a33-mbus You might also have to run the following command to make sure driver is not loaded from initramfs sudo update-initramfs -c -k all Your device should work fine after reboot

I'm trying to include pin definitions for SPI but I don't see a good example of how this is done. I tried this approach based on another DTS, but it does not work. Any advice on how to clean up this DTS and make it work would be appreciated. If I omit the pin mappings, the overlay works and the SPI devices exist (SPI0.0 & SPI0.1) and appear to work on my scope. /dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; fragment@0 { target = < 0xffffffff >; __overlay__ { spi0_cs1 { pins = "PC3"; function = "gpio_out"; output-high; phandle = < 0x01 >; }; spi1_cs1 { pins = "PA21"; function = "gpio_out"; output-high; phandle = < 0x02 >; }; }; }; fragment@1 { target = < 0xffffffff >; __overlay__ { pinctrl-names = "default\0default"; pinctrl-1 = < 0x01 >; cs-gpios = < 0x00 0xffffffff 0x02 0x03 0x00 >; }; }; fragment@2 { target = < 0xffffffff >; __overlay__ { pinctrl-names = "default\0default"; pinctrl-1 = < 0x02 >; cs-gpios = < 0x00 0xffffffff 0x00 0x15 0x00 >; }; }; fragment@3 { target = <&spi0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; spidev@0 { reg = < 0x00 >; /* Chip Select 0 */ compatible = "spidev"; spi-max-frequency = <1000000>; status = "okay"; }; spidev@1 { reg = < 0x01 >; /* Chip Select 1 */ compatible = "spidev"; spi-max-frequency = <1000000>; status = "okay"; }; }; }; };

Hi there, I have a rockpi 4b running armbian bionic desktop legacy kernel 4.4y on a 128 GB emmc module, I’d like to use this machine as a server. I was just tinkering around with Plex, .bashrc and crontab while all of a sudden the keyboard mapping over RDP changed (e.g. > became ;, ~ became @ etc) (indication of the problem?). I tried to fix this by changing the system keyboard layout and running dpkg-reconfigure keyboard-configuration, this all didnt work. I decided to reboot the machine to see if that would work. After the reboot I could not connect to either RDP or SSH so I decided to connect the machine to a HDMI monitor. This resulted in the following output: Can anyone help me understand what I am seeing here and how this could have happened ? Is this even Ubuntu ? Or is this GRUB ? Where in the boot process is this ? My guess is that the whole EMMC is disconnected but this seems very weird since I did not touch the board in any way. (I have no SD installed) I’m now thinking of solving this problem by attaching the emmc to a sd reader and backing up the etc,home,opt,root,srv,usr and var folder, reflashing the image and putting the folders back. This is however a very destructive process so I hope something less destructive is possible. I also even don’t know if this is going to work since I have no idea how this problem was caused. Can anyone help me please ? Thanx in advance! Thank you in advance

https://docs.armbian.com/#what-is-the-difference-between-armbian-and-debianubuntu If you are good with Debian or Ubuntu, you will be good with Armbian too. If you are seeking for Ubuntu specific and there is no ready made Ubuntu based image, you can make one in no time. https://github.com/armbian/build If service you need is not installed, and DHCPD almost certainly is not preinstalled, configuration file can not exist. Armbian comes without any preinstalled bloatware. If you want to change it to file server or whatever, you install that. Shipping everything that is possible for everyone would be very stupid. Perhaps this (didn't read the text by I assume this is what you need - google search) https://www.tecmint.com/install-dhcp-server-in-ubuntu-debian/

I booted my OPi5B from SD card with Armbian dd'ed to it and with the 5b DTB enabled. I logged in via ssh and ran armbian-config as root. System - Hardware I enabled rock-5b-hdmi1-8k and rock-5b-hdmi2-8k overlays. I rebooted and HDMI output started working. So `armbianEnv.txt` reads now: ``` verbosity=1 bootlogo=true overlay_prefix=rockchip-rk3588 fdtfile=rockchip/rk3588s-orangepi-5b.dtb rootdev=UUID=329a3cf7-a8ce-4ea6-a3ef-c2128bda1678 rootfstype=ext4 overlays=opp-oc-24ghz rock-5b-hdmi1-8k rock-5b-hdmi2-8k usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u ``` HTH!

Hello. I have tried to boot from both sd and nvme with the latest version for rock5. The first problem I had is that it doesn't recognize the screen resolution. I am writing from sd card with original armbian image. This version recognizes the size of the screen without problems, but the version of Balbes I get only part of the screen. I see everything magnified. Excuse my technological language, it lacks words to determine things correctly. But you know what I'm talking about. Even so, with the huge screen, I managed to log in with the minimal image of armbian balbes. From there, I managed to update spi to the latest version with armbian-config and run armbian-install to install to nvme. And here it gets more complicated, because from sd I can log in, but from nvme (it boots without sd), I don't get to the login screen. The last screen I get is one where it tells me that the UUID does not exist. And that's where it all ends.

Do you have any files or directories listed in /sys/kernel/debug/pinctrl/ directory or does that not exist as well?

Hello community! Orange pi 4 LTS with Armbian 22.11 Jammy CLI, there is a problem with launching the screen with resolutions: 1024x600 - there is no image 1024x768 - the image is there, there are ripples 1920x1080 - everything is fine Tell me how to solve this problem. uname -a Linux orangepi4-lts 5.15.80-rockchip64 #22.11.1 SMP PREEMPT Wed Nov 30 11:12:47 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux /boot/armbianEnv.txt verbosity=1 bootlogo=false overlay_prefix=rockchip fdtfile=rockchip/rk3399-orangepi-4-lts.dtb rootdev=UUID=72cc3f82-2e76-4495-99fd-8cc46a4a21db rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Link: armbianmonitor 1024x600 Link: armbianmonitor 1024x768

Hi! I try to use GPIO on BananaPi M5 board. But interface doesn't work. Armbian 23.05.1 Jammy with Linux 6.1.30-meson64. /boot/armbianEnv.txt: verbosity=1 console=both overlay_prefix=meson fdtfile=amlogic/meson-sm1-bananapi-m5.dtb rootdev=UUID=d099eb25-cf52-43fb-b826-535b9109637f rootfstype=ext4 overlays=w1-gpio usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u m5@bananapim5:~$ dmesg | grep w1 [ 7.568386] w1-gpio onewire@0: gpio_request (pin) failed [ 7.607814] w1-gpio onewire@0: gpio_request (pin) failed [ 7.620109] w1-gpio onewire@0: gpio_request (pin) failed [ 7.662444] w1-gpio onewire@0: gpio_request (pin) failed [ 7.671512] w1-gpio onewire@0: gpio_request (pin) failed [ 7.677156] w1-gpio onewire@0: gpio_request (pin) failed [ 7.689428] w1-gpio onewire@0: gpio_request (pin) failed [ 7.693341] w1-gpio onewire@0: gpio_request (pin) failed [ 7.711606] w1-gpio onewire@0: gpio_request (pin) failed [ 7.714019] w1-gpio onewire@0: gpio_request (pin) failed [ 7.784669] w1-gpio onewire@0: gpio_request (pin) failed [ 7.836363] w1-gpio onewire@0: gpio_request (pin) failed [ 7.877654] w1-gpio onewire@0: gpio_request (pin) failed [ 7.915447] w1-gpio onewire@0: gpio_request (pin) failed [ 7.975862] w1-gpio onewire@0: gpio_request (pin) failed [ 7.983126] w1-gpio onewire@0: gpio_request (pin) failed [ 18.143361] w1-gpio onewire@0: gpio_request (pin) failed Have any ideas?

I replied to an older thread from last year regarding this same problem after I stumbled across this problem with the 23.02.2 Jammy XFCE image. I did some experimentation with various parameters and responded to that old post. In any case, I got it working using a different SD card. If you are interested in what I did, check out the post titled [Odroid-C4] Alert! Root UUID does not exist. Dropping to a shell!

How to run Armbian on Odroid C4? I followed official guide (https://docs.armbian.com/User-Guide_Getting-Started), but I always ends up with following: Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! UUID=e614931e-7b37-40f0-8d34-c3ca836004e8 does not exist. Dropping to a shell! SD-Card is working fine when other OS is used (such as Ubuntu provided by Hardkernel) Am I missing something?

I ran into the same problem with Armbian_23.02.2_Odroidc4_jammy_current_6.1.11_xfce_desktop.img.xz released 27 February 2023. My equipment to write SD card images is a PC running Windows 11. In this case, I used the PNY 32GB SD Card that had just been running an official ODROID image (ubuntu-22.04-4.9-mate-odroid-c4-hc4-20220713.img.xz) This SD card has also been used with been used with other images and ARM-based SoCs. So, I was a bit surprised seeing the early error complaining that the UUID did not exist and finding myself in a busy box shell with the initramfs prompt. My process was to first "Quick format" the SD card with the official SD Card Formatter software from the sdcard.org then use Win32 Disk Imager (v 1.0) to write the image. It has been a long time since I have had a system die this early in the boot process. If my rusty memory serves me correctly, the last time I saw something like this (over a decade ago on a Sun Microsystems Ultra 45 workstation running Solaris 10), the problem was a failing disk drive. Another strange wrinkle that suggests the possibility of a bad card is that I happen to have a compatible eMMC card on which I used the same process and software (but necessarily different USB hardware) to write the image. The eMMC card works flawlessly. The next thing I did with the non-booting SD card was plug it back into the PC, start Win32 Disk Imager again, select the image file and the device, then run the 'Verify Only' function. The results shows that Win32 Disk Imager indicates a match between the image file on the PC and what is on the SD card. This suggests that the problem is not with the SD card hardware but also does not rule out the USB 3.0 adapter stick that I used to write the image. For fun, I decided to try starting over changing only one thing at a time in my process, hoping that the problem was traceable back to some minor relevant detail that I had missed or forgotten about. I started up the SD Card Formatter software, selecting the "Overwrite format" option instead of the "Quick format" option. As expected, this process took much longer. Unfortunately, I did not find any media verification / validation features in the SD Card Formatter software. When the "Overwrite format" finished (about 30 minutes after I started), it reported that it had formatted the disk as FAT32 with 32 Kbyte cluster size. At this point, I again used Win32 Disk Imager to write the image to the SD card, following the same steps and configuration selection. The Win32 Disk Imager updates the write speed about every second. Write speeds are mostly between 21 and 23 MB / sec., with the occasional short duration (1 - 2 sec.) drops to 15~16 MB / sec. write speed. Sequential read speeds during the verify operation when tested earlier were consistently in the 69 - 70 MB / sec. range. These are expected performance levels with this class 10 card. Win32 Disk Imager indicated that the write had completed successfully. I shut down the app, ejected the SD card in the Windows tray, physically removed it from the PC, then shutdown the ODROID C4 running from eMMC without problems. After removing the eMMC card, I installed the SD card and booted. Same trouble. It then occured to me that the case I had purchased with the ODROID C4 has a close fit area around the SD card slot. So, I tried again to boot the image after removing the C4 from its case, connecting the I/O cables, installing the SD card, then applying power. Saw the same failure at the same point in the boot process. So, I do not think the case was preventing the SD card from seating properly. Since this board had worked with this same SD card running a different image, I decided to go back to the image that had been functioning and use my standard process to 'build' the same SD card with the image that previously worked on it. The ODROID image booted without event and works as expected. So, experimentation suggests there is some problem with this combination of Armbian image and booting from an SD card. One other intersting thing I noticed, is how much faster the blue indicator comes on with the older ODROID image as compared to the Armbian image. Perhaps there is some relevance with uboot code that is a factor in this? Other tests I will have time for later that I would like to try include booting the Armbian image from a different SD card to ensure this specific card is not an issue, though it seems unlikely at this point. The other variable within easy reach to test would be to use a different writer application, such as the Raspberry Pi Writer tool that i have sucessfully used with other images. I would be happy to offer up what I can in the way of testing if the gurus do not have access to an ODROID C4.

FriendlyELEC sells an 11.6inch eDP FHD LCD Display with Capacitive Touch for the nanoPC-T4. I'm trying my hardest to get it working with Armbian. Unfortunately, Armbian doesn't seem to detect the display: root@nanopct4:~# xrandr --listmonitors Monitors: 0 It works in the stock lubuntu image they provide so I'm trying to gather as much configuration information as I can from lubuntu to see what I need to do to get it working. I want to try a few different experiments.. I have a kernel.img file from lubuntu that I'd like to try booting with Armbian but I don't understand uboot very well and simply copying the kernel.img file to /boot under the same name as the existing vmlinuz file seemed to only brick the install (even after I copied back the old image). Is there a way to properly get uboot to boot that image with Armbian? Here's what I've gotten so far from lubuntu configuration: Kernel command line: earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 console=ttyFIQ0 rootwait coherent_pool=1m root=/dev/mmcblk0p1 rw rootfstype=ext4 data=/dev/mmcblk0p2 consoleblank=0 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 lcd=LC116LF1L01 storagemedia=sd I did notice that lcd=LC116LF1L01 line.. I have no idea what that's for and adding that to Armbian kernel command line did nothing :/ root@FriendlyELEC:~# xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 eDP-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1920x1080 60.00* HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) root@FriendlyELEC:~# xrandr --listmonitors Monitors: 1 0: +eDP-1 1920/508x1080/286+0+0 eDP-1 Xorg.0.log: X.Org X Server 1.18.4 Release Date: 2016-07-19 [1713143.338] X Protocol Version 11, Revision 0 [1713143.338] Build Operating System: Linux 4.6.0-1-amd64 x86_64 Debian [1713143.338] Current Operating System: Linux FriendlyELEC 4.4.179 #1 SMP Thu Aug 13 12:57:41 CST 2020 aarch64 [1713143.339] Kernel command line: earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 console=ttyFIQ0 rootwait coherent_pool=1m root=/dev/mmcblk0p1 rw rootfstype=ext4 data=/dev/mmcblk0p2 consoleblank=0 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 lcd=LC116LF1L01 storagemedia=sd uboot_logo=0x02000000@0xf5c00000 loader.timestamp=2020-03-16_16:45:22 SecureBootCheckOk=0 [1713143.339] Build Date: 23 December 2016 10:24:38AM [1713143.339] xorg-server 2:1.18.4-1 (http://www.debian.org/support) [1713143.339] Current version of pixman: 0.33.6 [1713143.339] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [1713143.339] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [1713143.340] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Sep 7 01:09:37 2020 [1713143.341] (==) Using config directory: "/etc/X11/xorg.conf.d" [1713143.341] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [1713143.342] (==) No Layout section. Using the first Screen section. [1713143.342] (==) No screen section available. Using defaults. [1713143.342] (**) |-->Screen "Default Screen Section" (0) [1713143.343] (**) | |-->Monitor "<default monitor>" [1713143.343] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [1713143.343] (**) | |-->Device "Rockchip Graphics" [1713143.343] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [1713143.343] (==) Automatically adding devices [1713143.343] (==) Automatically enabling devices [1713143.343] (==) Automatically adding GPU devices [1713143.343] (==) Max clients allowed: 256, resource mask: 0x1fffff [1713143.343] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [1713143.343] Entry deleted from font path. [1713143.343] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [1713143.343] Entry deleted from font path. [1713143.344] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [1713143.344] Entry deleted from font path. [1713143.344] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, built-ins [1713143.344] (==) ModulePath set to "/usr/lib/xorg/modules" [1713143.344] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [1713143.344] (II) Loader magic: 0x16af40 [1713143.344] (II) Module ABI versions: [1713143.344] X.Org ANSI C Emulation: 0.4 [1713143.344] X.Org Video Driver: 20.0 [1713143.344] X.Org XInput driver : 22.1 [1713143.344] X.Org Server Extension : 9.0 [1713143.348] (--) using VT number 2 [1713143.348] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration [1713143.350] (II) xfree86: Adding drm device (/dev/dri/card0) [1713143.368] (II) no primary bus or device found [1713143.368] falling back to /sys/devices/platform/display-subsystem/drm/card0 [1713143.368] (II) LoadModule: "glx" [1713143.369] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [1713143.374] (II) Module glx: vendor="X.Org Foundation" [1713143.374] compiled for 1.18.4, module version = 1.0.0 [1713143.374] ABI class: X.Org Server Extension, version 9.0 [1713143.374] (==) AIGLX enabled [1713143.374] (II) LoadModule: "modesetting" [1713143.374] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [1713143.375] (II) Module modesetting: vendor="X.Org Foundation" [1713143.375] compiled for 1.18.4, module version = 1.18.4 [1713143.375] Module class: X.Org Video Driver [1713143.375] ABI class: X.Org Video Driver, version 20.0 [1713143.375] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [1713143.450] (II) modeset(0): using drv /dev/dri/card0 [1713143.451] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [1713143.451] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [1713143.451] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [1713143.451] (**) modeset(0): Option "AccelMethod" "glamor" [1713143.451] (==) modeset(0): RGB weight 888 [1713143.451] (==) modeset(0): Default visual is TrueColor [1713143.451] (II) Loading sub module "glamoregl" [1713143.451] (II) LoadModule: "glamoregl" [1713143.452] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [1713143.489] (II) Module glamoregl: vendor="X.Org Foundation" [1713143.489] compiled for 1.18.4, module version = 1.0.0 [1713143.490] ABI class: X.Org ANSI C Emulation, version 0.4 [1713143.490] (II) glamor: OpenGL accelerated X.org driver based. [1713143.494] (II) glamor: EGL version 1.4 Midgard-"r14p0-01rel0": [1713143.494] EGL_KHR_surfaceless_gles2 required. [1713143.498] (II) modeset(0): Using GLES2. [1713143.498] (WW) modeset(0): Glamor is using GLES2 but GLX needs GL. Indirect GLX may not work correctly. [1713143.498] (II) modeset(0): glamor initialized [1713143.501] (II) modeset(0): Output eDP-1 has no monitor section [1713143.501] (II) modeset(0): Output HDMI-1 has no monitor section [1713143.501] (II) modeset(0): Output DP-1 has no monitor section [1713143.502] (II) modeset(0): EDID for output eDP-1 [1713143.502] (II) modeset(0): Printing probed modes for output eDP-1 [1713143.502] (II) modeset(0): Modeline "1920x1080"x60.0 138.65 1920 1968 2000 2080 1080 1083 1088 1111 +hsync +vsync (66.7 kHz) [1713143.502] (II) modeset(0): EDID for output HDMI-1 [1713143.502] (II) modeset(0): EDID for output DP-1 [1713143.502] (II) modeset(0): Output eDP-1 connected [1713143.502] (II) modeset(0): Output HDMI-1 disconnected [1713143.502] (II) modeset(0): Output DP-1 disconnected [1713143.502] (II) modeset(0): Using sloppy heuristic for initial modes [1713143.502] (II) modeset(0): Output eDP-1 using initial mode 1920x1080 +0+0 [1713143.502] (II) modeset(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. [1713143.502] (==) modeset(0): DPI set to (96, 96) [1713143.502] (II) Loading sub module "fb" [1713143.502] (II) LoadModule: "fb" [1713143.503] (II) Loading /usr/lib/xorg/modules/libfb.so [1713143.503] (II) Module fb: vendor="X.Org Foundation" [1713143.503] compiled for 1.18.4, module version = 1.0.0 [1713143.503] ABI class: X.Org ANSI C Emulation, version 0.4 [1713143.504] (==) Depth 24 pixmap format is 32 bpp [1713143.727] (==) modeset(0): Backing store enabled [1713143.728] (==) modeset(0): Silken mouse enabled [1713143.728] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR disabled message. [1713143.728] (==) modeset(0): DPMS enabled [1713143.728] (WW) modeset(0): Option "DRI" is not used [1713143.728] (II) modeset(0): [DRI2] Setup complete [1713143.728] (II) modeset(0): [DRI2] DRI driver: rockchip [1713143.728] (II) modeset(0): [DRI2] VDPAU driver: rockchip [1713143.750] (--) RandR disabled [1713143.761] (II) SELinux: Disabled on system [1713143.762] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/rockchip_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/rockchip_dri.so: cannot open shared object file: No such file or directory) [1713143.762] (EE) AIGLX: reverting to software rendering [1713143.812] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [1713143.813] (II) AIGLX: Loaded and initialized swrast [1713143.813] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [1713143.835] (II) modeset(0): Setting screen physical size to 508 x 285 [1713143.917] (II) config/udev: Adding input device adc-keys (/dev/input/event2) [1713143.917] (**) adc-keys: Applying InputClass "evdev keyboard catchall" [1713143.917] (II) LoadModule: "evdev" [1713143.917] (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so [1713143.918] (II) Module evdev: vendor="X.Org Foundation" [1713143.918] compiled for 1.18.1, module version = 2.10.1 [1713143.918] Module class: X.Org XInput Driver [1713143.918] ABI class: X.Org XInput driver, version 22.1 [1713143.918] (II) Using input driver 'evdev' for 'adc-keys' [1713143.918] (**) adc-keys: always reports core events [1713143.919] (**) evdev: adc-keys: Device: "/dev/input/event2" [1713143.919] (--) evdev: adc-keys: Vendor 0x1 Product 0x1 [1713143.919] (--) evdev: adc-keys: Found keys [1713143.919] (II) evdev: adc-keys: Configuring as keyboard [1713143.919] (**) Option "config_info" "udev:/sys/devices/platform/adc-keys/input/input2/event2" [1713143.919] (II) XINPUT: Adding extended input device "adc-keys" (type: KEYBOARD, id 6) [1713143.919] (**) Option "xkb_rules" "evdev" [1713143.919] (**) Option "xkb_model" "pc105" [1713143.919] (**) Option "xkb_layout" "us" [1713143.921] (II) config/udev: Adding input device Typec_Headphone (/dev/input/event0) [1713143.921] (II) No input driver specified, ignoring this device. [1713143.921] (II) This device may have been added with another device file. [1713143.922] (II) config/udev: Adding input device EP0790M09 (/dev/input/event1) [1713143.922] (**) EP0790M09: Applying InputClass "evdev touchscreen catchall" [1713143.922] (II) Using input driver 'evdev' for 'EP0790M09' [1713143.922] (**) EP0790M09: always reports core events [1713143.922] (**) evdev: EP0790M09: Device: "/dev/input/event1" [1713143.922] (--) evdev: EP0790M09: Vendor 0 Product 0 [1713143.922] (--) evdev: EP0790M09: Found absolute axes [1713143.922] (--) evdev: EP0790M09: Found absolute multitouch axes [1713143.922] (II) evdev: EP0790M09: No buttons found, faking one. [1713143.922] (--) evdev: EP0790M09: Found x and y absolute axes [1713143.922] (--) evdev: EP0790M09: Found absolute touchscreen [1713143.922] (II) evdev: EP0790M09: Configuring as touchscreen [1713143.922] (**) evdev: EP0790M09: YAxisMapping: buttons 4 and 5 [1713143.922] (**) evdev: EP0790M09: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [1713143.922] (**) Option "config_info" "udev:/sys/devices/platform/ff3d0000.i2c/i2c-4/4-0038/input/input1/event1" [1713143.922] (II) XINPUT: Adding extended input device "EP0790M09" (type: TOUCHSCREEN, id 7) [1713143.922] (II) evdev: EP0790M09: initialized for absolute axes. [1713143.922] (**) EP0790M09: (accel) keeping acceleration scheme 1 [1713143.922] (**) EP0790M09: (accel) acceleration profile 0 [1713143.922] (**) EP0790M09: (accel) acceleration factor: 2.000 [1713143.922] (**) EP0790M09: (accel) acceleration threshold: 4 [1713143.923] (II) config/udev: Adding input device EP0790M09 (/dev/input/mouse0) [1713143.923] (II) No input driver specified, ignoring this device. [1713143.923] (II) This device may have been added with another device file. [1713143.924] (II) config/udev: Adding input device gpio-keys (/dev/input/event4) [1713143.924] (**) gpio-keys: Applying InputClass "evdev keyboard catchall" [1713143.924] (II) Using input driver 'evdev' for 'gpio-keys' [1713143.924] (**) gpio-keys: always reports core events [1713143.924] (**) evdev: gpio-keys: Device: "/dev/input/event4" [1713143.924] (--) evdev: gpio-keys: Vendor 0x1 Product 0x1 [1713143.924] (--) evdev: gpio-keys: Found keys [1713143.924] (II) evdev: gpio-keys: Configuring as keyboard [1713143.924] (**) Option "config_info" "udev:/sys/devices/platform/gpio-keys/input/input4/event4" [1713143.924] (II) XINPUT: Adding extended input device "gpio-keys" (type: KEYBOARD, id 8) [1713143.924] (**) Option "xkb_rules" "evdev" [1713143.924] (**) Option "xkb_model" "pc105" [1713143.924] (**) Option "xkb_layout" "us" [1713143.925] (II) config/udev: Adding input device realtek,rt5651-codec Headphones (/dev/input/event3) [1713143.925] (II) No input driver specified, ignoring this device. [1713143.925] (II) This device may have been added with another device file. [1713190.723] (II) config/udev: Adding input device Logitech K400 Plus (/dev/input/mouse1) [1713190.723] (II) No input driver specified, ignoring this device. [1713190.723] (II) This device may have been added with another device file. [1713190.735] (II) config/udev: Adding input device Logitech K400 Plus (/dev/input/event5) [1713190.735] (**) Logitech K400 Plus: Applying InputClass "evdev pointer catchall" [1713190.735] (**) Logitech K400 Plus: Applying InputClass "evdev keyboard catchall" [1713190.735] (II) Using input driver 'evdev' for 'Logitech K400 Plus' [1713190.735] (**) Logitech K400 Plus: always reports core events [1713190.735] (**) evdev: Logitech K400 Plus: Device: "/dev/input/event5" [1713190.736] (--) evdev: Logitech K400 Plus: Vendor 0x46d Product 0x404d [1713190.736] (--) evdev: Logitech K400 Plus: Found 20 mouse buttons [1713190.736] (--) evdev: Logitech K400 Plus: Found scroll wheel(s) [1713190.736] (--) evdev: Logitech K400 Plus: Found relative axes [1713190.736] (--) evdev: Logitech K400 Plus: Found x and y relative axes [1713190.736] (--) evdev: Logitech K400 Plus: Found absolute axes [1713190.736] (II) evdev: Logitech K400 Plus: Forcing absolute x/y axes to exist. [1713190.736] (--) evdev: Logitech K400 Plus: Found keys [1713190.736] (II) evdev: Logitech K400 Plus: Configuring as mouse [1713190.736] (II) evdev: Logitech K400 Plus: Configuring as keyboard [1713190.736] (II) evdev: Logitech K400 Plus: Adding scrollwheel support [1713190.736] (**) evdev: Logitech K400 Plus: YAxisMapping: buttons 4 and 5 [1713190.736] (**) evdev: Logitech K400 Plus: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [1713190.736] (**) Option "config_info" "udev:/sys/devices/platform/usb1/fe900000.dwc3/xhci-hcd.9.auto/usb5/5-1/5-1:1.2/0003:046D:C52B.0003/0003:046D:404D.0004/input/input5/event5" [1713190.736] (II) XINPUT: Adding extended input device "Logitech K400 Plus" (type: KEYBOARD, id 9) [1713190.736] (**) Option "xkb_rules" "evdev" [1713190.736] (**) Option "xkb_model" "pc105" [1713190.736] (**) Option "xkb_layout" "us" [1713190.736] (WW) Option "xkb_variant" requires a string value [1713190.736] (WW) Option "xkb_options" requires a string value [1713190.738] (II) evdev: Logitech K400 Plus: initialized for relative axes. [1713190.738] (WW) evdev: Logitech K400 Plus: ignoring absolute axes. [1713190.738] (**) Logitech K400 Plus: (accel) keeping acceleration scheme 1 [1713190.738] (**) Logitech K400 Plus: (accel) acceleration profile 0 [1713190.738] (**) Logitech K400 Plus: (accel) acceleration factor: 2.000 [1713190.738] (**) Logitech K400 Plus: (accel) acceleration threshold: 4 [1713296.783] (II) config/udev: removing device Logitech K400 Plus [1713296.789] (II) evdev: Logitech K400 Plus: Close [1713296.789] (II) UnloadModule: "evdev" [1713366.491] (II) config/udev: Adding input device Logitech K400 Plus (/dev/input/mouse1) [1713366.491] (II) No input driver specified, ignoring this device. [1713366.491] (II) This device may have been added with another device file. [1713366.520] (II) config/udev: Adding input device Logitech K400 Plus (/dev/input/event5) [1713366.520] (**) Logitech K400 Plus: Applying InputClass "evdev pointer catchall" [1713366.520] (**) Logitech K400 Plus: Applying InputClass "evdev keyboard catchall" [1713366.520] (II) Using input driver 'evdev' for 'Logitech K400 Plus' [1713366.520] (**) Logitech K400 Plus: always reports core events [1713366.520] (**) evdev: Logitech K400 Plus: Device: "/dev/input/event5" [1713366.520] (--) evdev: Logitech K400 Plus: Vendor 0x46d Product 0x404d [1713366.520] (--) evdev: Logitech K400 Plus: Found 20 mouse buttons [1713366.520] (--) evdev: Logitech K400 Plus: Found scroll wheel(s) [1713366.520] (--) evdev: Logitech K400 Plus: Found relative axes [1713366.520] (--) evdev: Logitech K400 Plus: Found x and y relative axes [1713366.520] (--) evdev: Logitech K400 Plus: Found absolute axes [1713366.520] (II) evdev: Logitech K400 Plus: Forcing absolute x/y axes to exist. [1713366.520] (--) evdev: Logitech K400 Plus: Found keys [1713366.520] (II) evdev: Logitech K400 Plus: Configuring as mouse [1713366.520] (II) evdev: Logitech K400 Plus: Configuring as keyboard [1713366.520] (II) evdev: Logitech K400 Plus: Adding scrollwheel support [1713366.520] (**) evdev: Logitech K400 Plus: YAxisMapping: buttons 4 and 5 [1713366.520] (**) evdev: Logitech K400 Plus: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [1713366.520] (**) Option "config_info" "udev:/sys/devices/platform/usb1/fe900000.dwc3/xhci-hcd.9.auto/usb5/5-1/5-1:1.2/0003:046D:C52B.0007/0003:046D:404D.0008/input/input6/event5" [1713366.520] (II) XINPUT: Adding extended input device "Logitech K400 Plus" (type: KEYBOARD, id 9) [1713366.520] (**) Option "xkb_rules" "evdev" [1713366.520] (**) Option "xkb_model" "pc105" [1713366.521] (**) Option "xkb_layout" "us" [1713366.521] (WW) Option "xkb_variant" requires a string value [1713366.521] (WW) Option "xkb_options" requires a string value [1713366.522] (II) evdev: Logitech K400 Plus: initialized for relative axes. [1713366.522] (WW) evdev: Logitech K400 Plus: ignoring absolute axes. [1713366.522] (**) Logitech K400 Plus: (accel) keeping acceleration scheme 1 [1713366.522] (**) Logitech K400 Plus: (accel) acceleration profile 0 [1713366.522] (**) Logitech K400 Plus: (accel) acceleration factor: 2.000 [1713366.522] (**) Logitech K400 Plus: (accel) acceleration threshold: 4 [1713389.710] (II) config/udev: removing device Logitech K400 Plus [1713389.718] (II) evdev: Logitech K400 Plus: Close [1713389.718] (II) UnloadModule: "evdev"

So the solution that @iamdrq and I have no longer works. I've tried armbian 22 with kernel 5.19, The device driver does not compile because of missing structure elements. I tried 6.1.30 and 6.11 kernels with Armbian 23.5. The device driver builds. All result in a hung startup. With the 6.0.0, 6.0.19 and 6.2 kernels it is impossible as the infrastructure does not exist to build the device driver. Or I have not figured out how to get it. Linux headers is not enough. I have been installing them with armbian config. Originally it worked with kernel 6.0. I am unsure of the terminal version, so I tried 0 and 19. 6.0.0 uses Linux-headers-edge-media and 6.0.19 uses current-media. Neither have a build directory in modules. Making it impossible to build the panel driver. I am travelling and do not have access to my sdcard collection or my archived downloads so I cannot pursue this line of investigation further. I did of course forget to bring my backup. So this computer is a bit of an anchor which requires an external monitor. If anyone knows how to get the modules build directory for kernels 6.x.x that would at least allow me to try them. Only the 6.1 Kernels seem to have that with the Linux headers and they hang on boot with the dtb overlay and device driver for the ts1050. Thank you for any insight.

hashed-OCI-revisioned-debs: introduce "reversioning" of .deb packages trap-logging: just discard logs dir when ANSI_COLOR=none repo-reprepro.py: set -e & pipefail prepare_host: handle PRE_PREPARED_HOST inside prepare_host_init() so WORKDIR etc is always available kernel-debs: avoid showing tree of kernel modules if they've not been built for example EXT=nomod causes no modules to be built debs: all produced debs now get a placeholder DEBIAN/changelog and a usr/share/doc .gz changelog with hash artifacts: don't keep deb-tar's .tar after uploading to OCI they won't ever be used after this, and just accumulate trash for no reason hashed-OCI-revisioned-debs: get completely rid of artifact_prefix_version hashed-OCI-revisioned-debs: build debs in PACKAGES_HASHED_STORAGE, not DEB_STORAGE (temp commit, will be rewritten by a later commit) fakeroot_dpkg_deb_build() now only takes a single argument, the unpacked package dir kernel/tmpfs: remove usage of the kernel-specific tmpfs for temporary kernel .deb's, now build directly to packages-hashed dir uboot: drop CHOSEN_UBOOT, change deployment directory, remove uboot_name as temp_dir prefix change deployment dir to not include REVISION or ARCH get rid uboot's CHOSEN_UBOOT, REVISION and ARCH in the directory name. no two u-boot debs can be installed in the same machine anyway pipeline: output-debs-to-repo-json.py: adapt to new reversioned JSON info hashed-OCI-revisioned-debs: introduce "reversioning" of .deb packages tl-dr: maximize OCI cache hit ratio across nightlies/releases/PRs/etc; publish simple Version:'s that don't include a crazy hash in repo and images introduce output/packages-hashed directory radically change the output/debs directory structure simplify artifact's prepare_version() method for deb and deb-tar artifacts: artifact_base_dir and artifact_final_file will now be auto-calculated; thus removed from each artifact (except rootfs) artifact_deb_repo ("global", "jammy", "bookworm") is now required; "global" means common across all RELEASES artifact_deb_arch is now required, "all" is arch-independent, otherwise use ${ARCH} artifact_map_debs is now auto-calculated based on the above, and shouldn't be specified manually artifact_final_version_reversioned is optional, and can force the final version of the artifact (specific for the base-files case) artifacts that need special handling for reversioning can add function names to artifact_debs_reversion_functions array (base-files and bsp-cli cases) artifacts prepare_version() should set artifact_version, but never include it in other variables; artifact_version is now changed by framework after prepare_version() returns no longer use/refer/mention ${REVISION} when building packages. All packages should be ${REVISION}-agnostic. ${REVISION} (actually, artifact_final_version_reversioned) will be automatically swapped in the control file during reversioning fakeroot_dpkg_deb_build() now takes exactly two arguments: the directory to pack, and the deb ID (key of artifact_map_packages dict); add this change in all the artifact's code for this obtain_complete_artifact(): automatically adds -Rxxxx "revisioning-hash" to artifact_version, by hashing the revisioning functions and any artifact_debs_reversion_functions set calculates more complex subdirectory paths for both the output/packages-hashed and output/debs/output/debs-beta directories with the new subdirectories we can be sure a re-version is already done correctly and can skip it (eg, for partial download-debs re-runs) in the future we can automatically clean/remove old versions that are no longer relevant based on the dir structure exports a lot more information to JSON, including the new subdirectory paths comment-out code that implemented skip_unpack_if_found_in_caches, I'm very unsure why we had this in the first place obtain_artifact_from_remote_cache() for deb type artifacts, OCI won't preserve the subdirectory structure, so move downloaded files to the correct subdirectory manually this is not needed for deb-tar, since that can preserve the dir structure itself introduce artifacts-reversion.sh and its main function artifact_reversion_for_deployment() this has the logic for reversioning .deb's, by ar-unpacking them, changing control.tar (and possibly data.tar), handling .xz compression, etc. also handles hashing those functions, for consistency. Any changes in reversioning code actually change the artifact itself so we're not caught by surprise by default, it changes control file only: replace Version: (which is the hash-version originally) with artifact_final_version_reversioned (which is mostly just ${REVISION}) add a custom field Armbian-Original-Hash: with the original hash-version artifact_reversion_for_deployment() is called by new CLI wrapper cli_obtain_complete_artifact(), used for CLI building of specific artifact, but also for download-artifact build_artifact_for_image() used during image build armbian-bsp-cli-deb.sh: move ${REVISION} related stuff from the main package build to new reversioning functions. artifact-armbian-base-files.sh: move ${REVISION} related stuff from the main package build to new reversioning functions. kernel: add some custom fields to DEBIAN/control: Armbian-Kernel-Version: / Armbian-Kernel-Version-Family: (for future use: cleanup of usage of Source: field which should be removed) declutter the Description: field, moving long description out of the first line obtain IMAGE_INSTALLED_KERNEL_VERSION from the reversioned deb (this is still a hack and has not been fixed) uboot: declutter the Description: field, moving long description out of the first line use the reversioned .deb when deploying u-boot to the image main_default_build_packages() now stores reversioned values and complete paths to reversioned .deb's list_installed_packages() now compares custom field Armbian-Original-Hash: , and not the Version: to make sure debs in the image are the ones we want install_artifact_deb_chroot() is a new wrapper around install_deb_chroot() for easy handling of reversioned debs use it everywhere install_deb_chroot() was used in distro-agnostic.sh and distro-specific.sh main-config: allow using REVISION from env or command-line param; ensure it begins with digit pipeline: force compositor to include REVISION= just like it already did for BETA= this way the prepare step's REVISION (possibly passed via CLI parameter) is always sovereign pipeline: streamline output-debs-to-repo-json to pass down info and avoid parsing paths completely artifacts: obtain: back to using flat output/debs structure, include revisioned and hashed in filename, but no subdirectories handle the global artifact_deb_repo case specially (they go in the root, not subdir) adapt obtain_complete_artifact() and friends to new reversioned scheme; introduce UPLOAD_TO_OCI_ONLY=yes for deploying to remote cache tl-dr: only deploys to remote OCI if UPLOAD_TO_OCI_ONLY=yes; stop leaving junk behind in local cache in many situations simplify CLI artifact building parameters and behaviour ARTIFACT_USE_CACHE is now deprecated, and its behaviour is the default for any uploading to OCI to occur, UPLOAD_TO_OCI_ONLY=yes must be present; in this case, reversioning is not done FORCE_ARTIFACTS_DOWNLOAD is completely removed (use download-artifact instead) cli_obtain_complete_artifact()'s and build_artifact_for_image()'s reversioning is now moved to common obtain_complete_artifact() standard_artifact_reversion_for_deployment(): check for hashed deb existence only if reversioned does not exist touch the reversioned file if it already exists; helps to clean up junk later delete hashed version after reversioning, so we don't leave trash behind unless in download-artifact mode, which touches the hashed version we can later delete old files from packages-hashed to keep junk under control refactor obtain_complete_artifact() extract function artifact_dump_json_info() since obtain is large enough already when deploying to remote, always ignore all local and remote caches introduce artifact_is_available_in_revisioned_local_cache() if not deploying to remote, and revisioned cache exists, use it directly if deploying to remote, reversioned is not checked and not created if deploying to remote, force DEB_COMPRESS=xz if deploying to remote, completely remove the local cache base dir after upload is done (no more junk leftover) store dict of artifacts actually installed in image; use it to freeze (BSPFREEZE=yes) and check hashes without spurious errors eg: linux-headers might, or might not, be installed; same with bsp-cli transitional accidentally fixes AR-1802 start-end: undo unintentional damage done to python/python2 compatibility symlinks inside the BIN_WORK_DIR kernel: fix: when KERNEL_SKIP_MAKEFILE_VERSION=yes, use 1- prefix for artifact_version (eg odroidxu4) artifact-{bsp-cli,kernel,uboot}: fix missing vars_config_hash "variables hash" in artifact_version_reason View the full article

Armbian Armbian 22.11.4 Jammy on Odroid C4 boot from SD card system on an ext4 SSD. First of all - everything I need works correctly... However, I have a question about the SD card. During the first installation on the SSD disk, the system hung on the first reboot and you could see from the console that the SD card with UUID=61748c7e-b234-40e8-b6b6-592f845c3699 was being waited for. After the timeout, the only way to fix the "error" was to log into the system via terminal. Long story - only after commenting out the SD card in the fstab on the SSD: UUID=61748c7e-b234-40e8-b6b6-592f845c3699 /media/mmcboot ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 0 /media/mmcboot/boot /boot none bind 0 0 the system booted from the SSD as requested. Since then, the SD card is not mounted and just shows up as: Disk /dev/mmcblk0: 30.61 MiB, 32096256 bytes, 62688 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes at fdisk -l. No UUID etc nothing... The SD-Card is 32G and is readable on other systems... Question now - is this normal? Can I live with that? Can it be fixed? A "curiosity" - after booting from the SSD and updating the kernel to 6.0.13, the update ended up on both the SSD and the unmounted SD card. How - is a mystery to me (;-)

Hi! Normally in a normal SBC you add an overlay with something like /boot/uEnv.txt etc... But this is not done yet. The workarround I made to work is to use Ubuntu (from oficial webpage of ubuntu, I used the Lichee version, or even the one shipped for the lichee that has the wifi driver already installedd), that is prepared also for running the mangoPi) and change group. My explanation: On the default installation of ubuntu, the only way to add overlays is with grub. The default ubuntu is configured to load the devicetree overlays with grub. So if we want to add overlays, we need to change the grub. To add a new entry on the grub we need to go to `/etc/grub.d/40_custom` and there we put the entry we want. The best way is to copy the same information that is in /boot/grub/grub.cfg regarding to the OS, like: menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-90836834-7e07-48ca-b0f9-29880429770d' { load_video insmod gzio if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root 90836834-7e07-48ca-b0f9-29880429770d echo 'Loading Linux 5.19.0-1015-allwinner ...' linux /boot/vmlinuz-5.19.0-1015-allwinner root=/dev/mmcblk0p1 ro quiet splash echo 'Loading device tree blob...' devicetree /boot/dtb } My modified version would be: menuentry 'UbuntuWithOverlays' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'ubuntu-custom-overlay'' { load_video insmod gzio if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root 90836834-7e07-48ca-b0f9-29880429770d echo 'Loading Linux 5.17.0-1003-allwinner ...' linux /boot/vmlinuz-5.17.0-1003-allwinner root=LABEL=cloudimg-rootfs ro quiet splash echo 'Loading initial ramdisk ...' initrd /boot/initrd.img-5.17.0-1003-allwinner echo 'Loading device tree blob...' devicetree /boot/overlay/my_overlay.dtb } To make that entry the default in grub you need to add `GRUB_DEFAULT="ubuntu-custom-overlay"` to `/etc/default/grub`. After some testing I realized that there can be only one command of devicetree, it is not supported the overlays, the comfiguration is cleaned in every devicetree command. But you can get the original devicetree, modify and put it in the command, that works. Dont forget to do `update-grub` after. To get the device tree blob that comes with the board, you need to run `dtc -I fs /proc/device-tree` PD: In this post I confuse Overlay with the device tree configuration. There is no overlay, is a complete device tree blob, have that in mind.

for some reasons I didn't find related docs in the company's web site https://www.marvell.com/products/infrastructure-processors/armada-38x.html those docs links are apparently not accessible but instead stumbled into a copy elsewhere in a web search https://ulli-kroll.de/Downloads/NAS326/A38x-Functional-Spec-PU0A.pdf the interesting section is chapter 26 Real time clock pages 303 accordingly, the real time clock runs on a 32khz crystal, so check your board to see if it is there. if it isn't there, maybe it isn't using the real time clock after all. And that if it is there, find in the source codes for the real time clock implementation, apparently some details about the RTC registers are documented, so those should after all match the func spec. And perhaps you may find your way around the code to 'tweak' the register settings etc. if it is a 'pseudo RTC' i.e. didn't exist, then it is probably a 'simulated' h/w clock which may be written in s/w, it'd take reading the codes to find out that curious facts hope that helps

I changed what you suppose to change, recompile, it works. It also works for many people and many automated scenarios. Strange ... but deep hidden problems absolutely can exist. Open a ticket here: https://github.com/armbian/build/issues and provide everything that is asked in that wizard. Then we might understand why you have issues.

@ag123 can you post the full bootlog for the armbian release from GitHub (23.08)? I tried both bookworm and jammy with several micro SD cards (including name brands like Samsung) and my board (4GB model) never gets further than the following: U-Boot SPL 2021.07-armbian (Jul 12 2023 - 10:04:49 +0000) DRAM: 4096 MiB Trying to boot from MMC1 * Armbian_23.08.0-trunk_Orangepizero3_bookworm_current_6.1.31-1GB-2GB.img.xz (sha256: 6c58ad6122fd62769e1063164df3cdf004af9d498f69db3f1c86094cc749a375) * Armbian_23.08.0-trunk_Orangepizero3_jammy_current_6.1.31-1GB-2GB.img.xz (sha256: 7a794393ef8a5fedc73c4cc977cc5f29660ba106f17d0a6c2322a926f88e91fe) And yes, I did copy the 4GB dtb and u-boot as instructed. I know this forum is not the place to ask for support for unofficial Armbian forks, but I'm just curious if you encountered any such issues. If I remove the micro SD card entirely, the board boots some kind of Android from the SPI: U-Boot SPL 2021.07-orangepi (Jul 15 2023 - 15:02:23 +0800) DRAM: 4096 MiB Trying to boot from MMC1 [53]HELLO! BOOT0 is starting! [56]BOOT0 commit : 3ae35eb [59]set pll start [61]periph0 has been enabled [64]set pll end [67]unknow PMU [69]unknow PMU [73]PMU: AXP1530 [77]dram return write ok [80]board init ok [81]DRAM BOOT DRIVE INFO: V0.651 [85]the chip id is 0x2000 [87]chip id check OK [98]DRAM_VCC set to 1100 mv [101]DRAM CLK =792 MHZ [103]DRAM Type =8 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4) [114]Actual DRAM SIZE =4096 M [117]DRAM SIZE =4096 MBytes, para1 = 310a, para2 = 10001000, dram_tpr13 = 2006c61 [130]DRAM simple test OK. [133]rtc standby flag is 0x0, super standby flag is 0x0 [138]dram size =4096 [141]Use rtc to store dram tuning para [146]spinor id is: 5e 40 18, read cmd: 0b [150]Succeed in reading toc file head. [154]The size of toc is 9c000. [317]Entry_name = u-boot [322]Entry_name = monitor [326]Entry_name = dtb [330]Jump to second Boot. NOTICE: BL3-1: v1.0(debug):05d6c57 NOTICE: BL3-1: Built : 13:35:35, 2021-10-28 NOTICE: BL3-1 commit: 8 NOTICE: cpuidle init version V2.0 ERROR: Error initializing runtime service tspd_fast NOTICE: BL3-1: Preparing for EL3 exit to normal world NOTICE: BL3-1: Next image address = 0x4a000000 NOTICE: BL3-1: Next image spsr = 0x1d3<FF> U-Boot 2018.05 (Jul 10 2023 - 10:32:18 +0800) Allwinner Technology [00.408]CPU: Allwinner Family [00.411]Model: sun50iw9 I2C: ready [00.415]DRAM: 2 GiB [00.419]Relocation Offset is: 75f5d000 [00.439]secure enable bit: 0 [00.441]pmu_axp152_probe pmic_bus_read fail [00.445]PMU: AXP1530 [00.451]CPU=1008 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz MBus=400Mhz [00.457]gic: sec monitor mode [00.462]flash init start [00.464]workmode = 0,storage type = 3 SF: Detected zb25vq128as with page size 256 Bytes, erase size 64 KiB, total 16 MiB [00.481]sunxi flash init ok [00.485]Loading Environment from SUNXI_FLASH... OK [00.514]get secure storage map err [00.517]sunxi secure storage is not supported [00.521]usb burn from boot delay time 0 weak:otg_phy_config [00.535]usb prepare ok [53]HELLO! BOOT0 is starting! [56]BOOT0 commit : 3ae35eb [59]set pll start [61]periph0 has been enabled [64]set pll end [67]unknow PMU [69]unknow PMU [73]PMU: AXP1530 [77]dram return write ok [80]board init ok [81]DRAM BOOT DRIVE INFO: V0.651 [85]the chip id is 0x2000 [87]chip id check OK [98]DRAM_VCC set to 1100 mv [100]DRAM CLK =792 MHZ [103]DRAM Type =8 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4) [114]Actual DRAM SIZE =4096 M [117]DRAM SIZE =4096 MBytes, para1 = 310a, para2 = 10001000, dram_tpr13 = 2006c61 [130]DRAM simple test OK. [133]rtc standby flag is 0x0, super standby flag is 0x0 [138]dram size =4096 [141]Use rtc to store dram tuning para [146]spinor id is: 5e 40 18, read cmd: 0b [150]Succeed in reading toc file head. [154]The size of toc is 9c000. [312]Entry_name = u-boot [317]Entry_name = monitor [321]Entry_name = dtb [325]Jump to second Boot. NOTICE: BL3-1: v1.0(debug):05d6c57 NOTICE: BL3-1: Built : 13:35:35, 2021-10-28 NOTICE: BL3-1 commit: 8 NOTICE: cpuidle init version V2.0 ERROR: Error initializing runtime service tspd_fast NOTICE: BL3-1: Preparing for EL3 exit to normal world NOTICE: BL3-1: Next image address = 0x4a000000 NOTICE: BL3-1: Next image spsr = 0x1d3<FF> U-Boot 2018.05 (Jul 10 2023 - 10:32:18 +0800) Allwinner Technology [00.403]CPU: Allwinner Family [00.406]Model: sun50iw9 I2C: ready [00.410]DRAM: 2 GiB [00.413]Relocation Offset is: 75f5d000 [00.434]secure enable bit: 0 [00.436]pmu_axp152_probe pmic_bus_read fail [00.440]PMU: AXP1530 [00.445]CPU=1008 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz MBus=400Mhz [00.452]gic: sec monitor mode [00.457]flash init start [00.459]workmode = 0,storage type = 3 SF: Detected zb25vq128as with page size 256 Bytes, erase size 64 KiB, total 16 MiB [00.476]sunxi flash init ok [00.480]Loading Environment from SUNXI_FLASH... OK [00.509]get secure storage map err [00.512]sunxi secure storage is not supported [00.516]usb burn from boot delay time 0 weak:otg_phy_config [00.530]usb prepare ok [01.333]overtime [01.337]do_burn_from_boot usb : no usb exist [01.341]get secure storage map err [01.344]secure storage init fail [01.349]update dts [01.353]update part info [01.357]update bootcmd [01.359]No ethernet found. Hit any key to stop autoboot: 0 Android's image name: sun50i_arm64 [04.895]Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.9.170 (orangepi@ubuntu) (gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) ) #15 SMP PREEMPT Thu Jun 29 17:36:03 CST 2023 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] [ 0.000000] bootconsole [earlycon0] enabled On the HDMI output I have an error that it can't find initramfs, which is probably expected since there's no SD card present.

I use Orange Pi PC+ with installed Armbian 21.08.3 on eMMC. On system i can't access to mmcblk0 device. In dev directory exist only mmcblk2* files related to eMMC. How can I enable access to the SD card ?

I ask some help, but thanks to @martinayotte and @zador.blood.stained on this topic it help me a lot. but the problème is the same with the nanopi r2s board is there some dev for this 2 nanopi because i have some patch to suggest like for the MAC Address like I think that the problem is that the uboot***spl.bin don't exist may someone can compil it thanks a lot