Search the Community

Ok, everything is as expected. So attached is the overlay source as promised and here is how to use it: To avoid path information in the commands, I use cd /boot/dtb/allwinner/ as the working directory. To compile the overlay, execute: dtc --in-format dts sun50i-h618-orangepi-zero3-con1.dtso --out sun50i-h618-orangepi-zero3-con1.dtbo This is an one-off action that has only to be repeated when the overlay source changes. To apply the overlay statically, execute: mv sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-native.dtb fdtoverlay --input sun50i-h618-orangepi-zero3-native.dtb --output sun50i-h618-orangepi-zero3-con1.dtb sun50i-h618-orangepi-zero3-con1.dtbo ln -s sun50i-h618-orangepi-zero3-con1.dtb sun50i-h618-orangepi-zero3.dtb By modifying the symlink, you can now easily switch between both or possibly multiple pre-build variants of DTBs, regardless of which overlay application method your system provides or not. If you don't want pre-built variant support, an in-place application is also possible with: fdtoverlay --input sun50i-h618-orangepi-zero3.dtb --output sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-con1.dtbo The application of the overlay must always be repeated if the base DTB changes (update). I've attached this feature to my kernel build process so I don't have to worry about it. The kernel install process is also an option to apply local overlays permanently. Of course, you can also use your OS's overlay application system. If you want to modify the label names, use my *.dtso as a template and choose a new overlay filename. In this way, both variants can exist at the same time and you can choose as you wish. Since this overlay only modifies one property value, it can even be applied repeatedly. I.e. with: fdtoverlay --input sun50i-h618-orangepi-zero3.dtb --output sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-my-labels.dtbo you can simply rewrite the property without any further necessary actions. I'm sorry that my method doesn't require patches or even rebuilding the entire OS and works in every system from userspace that has the DTC software package installed and the firmware get the DTB provided from the userspace (filesystem) for loading. Any system administrator should be able to execute the commands (either symlink adjustment or overlay application) from a running system and activate the changes by rebooting. sun50i-h618-orangepi-zero3-con1.dtso

I have a NanoPi Neo V1.4 running Armbian 23.8.1 bullseye with kernel nanopineo 6.1.63-current-sunxi. Now, that I got my micro-USB port working for a SD card holder, I want to programmatically backup my boot SD on a regular base to another SD. Yes, it works by a full dd-copy. but this is quite time consuming and I want to skip some directories while backup, which does not work with dd. The idea: Take a new SD (same model as source SD) Create a new partition table and a primary partition 1 with fully equal parameters as my source SD Format partition 1 with ext4 and mount to /mnt rsync all files (exclude some directories as e.g. /var/log) from source / to target / (which is /mnt/) Use this SD in case of a problem with the source SD as new boot SD In /boot/armbianEnv.txt i have rootdev=/dev/mmcblk0p1. No UUID used. But, it just does not boot. The LED's of my NanoPi stay on with no blinking at all. Nothing is written to /var/log. Unfortunately I cannot connect a console to the NanoPi to see the boot messages. Only SSH at this time. What is missing on the new SD? I assume something with the U-Boot bootloader? Can anybody help me? What is missing and needs to be copied to the SD? I assume to the bytes 512-8192 just in front of partition 1 and after the partition table. Even that a full dd works, I'd like to know how to do that manually. Thanks a lot for help 🙂

Hi, I downloaded the jammy xfce image for ODROID C2 today: MD5SUM 033fbc0babb56db5388b4c707a2fc0ce Armbian_23.11.1_Odroidc2_jammy_current_6.1.63_xfce_desktop.img.xz After flashing it onto my SD card with xzcat and dd, I tried to boot with my Odroid C2 ending up with this error message: ALERT! UUID=75e23441-f5ee-4479-a484-7060ccd898ae does not exist. So I put the SD back into my PC and checked with gparted: the UUID of the partition that I have on my SD card seems to have exactly the UUID that was not found. In fact the boot until that error message lastet quite long, so I expect that the timeout is not too small. Does anyone have an idea? Thanks!

Can't say for sure, but I guess you used armbian-install to install root to emmc. Then while still running from sdcard, you tried to check the UUID, which will give the uuid present in sdcard's /boot/armbianEnv.txt file and hence you got the UUID of sdcard. So my guess is when you updated the UUID, you actually ended up changing that on your sdcard too. When sdcard will be removed, the emmc never would have bootloader installed and hence will fail to boot. But with sdcard inserted you will be able to use emmc as root device. Again this is all speculation. Best option to tell will be if you can share screenshot of armbian-install's first screen highlighting which option you choose to install to emmc.

It sounds to me as if you may have used armbian-config to copy the root filesystem to emmc, but didn't copy the boot environment over. So you may have had a working environment with boot from SD, but everything else on emmc. Then when you forced the change of the boot uuid, you now have a broken system as there may not be a boot environment installed on emmc. But since I don't know the exact options you used in armbian-config this is only a guess.

@Gunjan Gupta I only used the Armbian-Config to see what the Boot Environment was set to and to see if the correct boot device was set by Armbina-Install. It turned out that Armbian-Install had set the UUID of the SD-Card as the boot device. I will try to add a UART Serial port to the board and see what I can come up with.

Sorry but I am confused about this part. Why did you had to modify the UUID yourself? Armbian install has the option to install bootloader to emmc. Not sure if you used it, but if not try using the same. It generally helps to see the serial console logs when troubleshooting boot issues, so if you can share them that will make it easier for people to help you out.

Hey guys, I have been fiddling with this for days now. I think I have to give up. I am able to boot from an sd-card that has the built on it that @pixdrift whipped up the other day. It boot flawlessly. In the terminal is was able to start armbian-install and move the content of the sd over to the internal emmc. That finished without errors. i then went ahead and opened the armbian-config from the emmc and modified the boot environment to make sure it has the correct boot drive UUID. Everything look good but I will still not boot from EMMC. Any help with this would be appreciated. BTW everything in this built seems to be working as long as I boot from SD-Card. Ethernet, Wifi all the USB port ... everything works great except the part with moving it to emmc.

Hi, After running armbian-install on S905x device it stopped booting. USB Burning Tool doesn't recognize the device, nothing. After connecting to UART it looks like install script has overwritten the original u-boot. That's the boot log from UART connection without sd card: GXL:BL1:9ac50e:a1974b;FEAT:ADFC318C;POC:3;RCY:0;EMMC:0;READ:0;0.0;CHK:0; TE: 104174 BL2 Built : 11:58:42, May 27 2017. gxl gc3c9a84 - xiaobo.gu@droid05 set vcck to 1120 mv set vddee to 1000 mv Board ID = 1 CPU clk: 1200MHz DQS-corr enabled DDR scramble enabled DDR3 chl: Rank0+1 @ 912MHz - PASS Rank0: 1024MB(auto)-2T-13 Rank1: 1024MB(auto)-2T-13 DataBus test pass! AddrBus test pass! -s Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x00004000 New fip structure! Load bl30 from eMMC, src: 0x00010200, des: 0x01100000, size: 0x0000d600 Load bl31 from eMMC, src: 0x00020200, des: 0x05100000, size: 0x00018400 Load bl33 from eMMC, src: 0x0003c200, des: 0x01000000, size: 0x000af000 NOTICE: BL3-1: v1.0(release):3348978 NOTICE: BL3-1: Built : 15:44:01, May 12 2017 [BL31]: GXL CPU setup! mpu_config_enable:ok [Image: gxl_v1.1.3221-2cfba69 2017-05-27 16:03:58 qiufang.dai@droid07] OPS=0x82 8f bb f0 da ba 22 d2 cf 1 b0 31 f4 [0.359461 Inits done] secure task start! high task start! low task start! ERROR: Error initializing runtime service opteed_fast <debug_uart> U-Boot 2022.07-armbian (Nov 25 2023 - 12:50:42 +0000) libretech-cc Model: Libre Computer AML-S905X-CC SoC: Amlogic Meson GXL (S905X) Revision 21:b (82:2) DRAM: 2 GiB Core: 169 devices, 27 uclasses, devicetree: separate MMC: mmc@72000: 0, mmc@74000: 1 Loading Environment from nowhere... OK In: serial Out: serial Err: serial [BL31]: tee size: 0 [BL31]: tee size: 0 Net: eth0: ethernet@c9410000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 1: Armbian Retrieving file: /uInitrd ** File not found /uInitrd ** Skipping Armbian for failure retrieving initrd SCRIPT FAILED: continuing... Found U-Boot script /boot/boot.scr 8147 bytes read in 1 ms (7.8 MiB/s) ## Executing script at 08000000 U-boot default fdtfile: amlogic/meson-gxl-s905x-libretech-cc.dtb Current variant: Current fdtfile after armbianEnv: amlogic/meson-gxl-s905x-libretech-cc.dtb Mainline bootargs: root=/dev/mmcblk1p1 rootwait rootfstype=ext4 splash=verbose c onsole=ttyAML0,115200 console=tty1 consoleblank=0 coherent_pool=2M loglevel=1 ub ootpart=d27dbd06-01 libata.force=noncq usb-storage.quirks= cgroup_enable=memo ry swapaccount=1 22783841 bytes read in 500 ms (43.5 MiB/s) 27433472 bytes read in 601 ms (43.5 MiB/s) 40228 bytes read in 4 ms (9.6 MiB/s) Failed to load '/boot/dtb/amlogic/overlay/-fixup.scr' ## Loading init Ramdisk from Legacy Image at 13000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 22783777 Bytes = 21.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 04080000 Booting using the fdt blob at 0x4080000 Loading Ramdisk to 7a982000, end 7bf3c721 ... OK Loading Device Tree to 000000007a90f000, end 000000007a981fff ... OK "Synchronous Abort" handler, esr 0x96000004 elr: 00000000010656ec lr : 0000000001055038 (reloc) elr: 000000007dfb46ec lr : 000000007dfa4038 x0 : e14b4287a666c25d x1 : 000000007dfbc290 x2 : 0000000000000010 x3 : 000000007bf54e10 x4 : 0000000000000000 x5 : e14b4287a666c25d x6 : 0000000001000000 x7 : 0000000000000000 x8 : 0000000000000007 x9 : 0000000000000000 x10: 0000000000000178 x11: 000000007bf40eec x12: 00000000000000a4 x13: 000000007bf40ea8 x14: 000000007a90f000 x15: 0000000000000020 x16: 000000007df5946c x17: 0000000000000000 x18: 000000007bf4cdb0 x19: 000000007af41040 x20: 000000007df4fb18 x21: 000000007dfbc290 x22: 0000000000001000 x23: 000000007bf54d60 x24: 000000007dfdacb8 x25: 0000000001000000 x26: 0000000000000000 x27: 0000000001000000 x28: 0000000000001000 x29: 000000007bf40ea0 Code: eb04005f 54000061 52800000 14000006 (386468a3) Resetting CPU ... resetting ... bl31 reboot reason: 0xd bl31 reboot reason: 0x0 system cmd 1. And with sd card GXL:BL1:9ac50e:a1974b;FEAT:ADFC318C;POC:3;RCY:0;EMMC:0;READ:0;0.0;CHK:0; TE: 103545 BL2 Built : 11:58:42, May 27 2017. gxl gc3c9a84 - xiaobo.gu@droid05 set vcck to 1120 mv set vddee to 1000 mv Board ID = 1 CPU clk: 1200MHz DQS-corr enabled DDR scramble enabled DDR3 chl: Rank0+1 @ 912MHz - PASS Rank0: 1024MB(auto)-2T-13 Rank1: 1024MB(auto)-2T-13 DataBus test pass! AddrBus test pass! -s Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x00004000 New fip structure! Load bl30 from eMMC, src: 0x00010200, des: 0x01100000, size: 0x0000d600 Load bl31 from eMMC, src: 0x00020200, des: 0x05100000, size: 0x00018400 Load bl33 from eMMC, src: 0x0003c200, des: 0x01000000, size: 0x000af000 NOTICE: BL3-1: v1.0(release):3348978 NOTICE: BL3-1: Built : 15:44:01, May 12 2017 [BL31]: GXL CPU setup! mpu_config_enable:ok [Image: gxl_v1.1.3221-2cfba69 2017-05-27 16:03:58 qiufang.dai@droid07] OPS=0x82 8f bb f0 da ba 22 d2 cf 1 b0 31 f4 [0.358822 Inits done] secure task start! high task start! low task start! ERROR: Error initializing runtime service opteed_fast <debug_uart> U-Boot 2022.07-armbian (Nov 25 2023 - 12:50:42 +0000) libretech-cc Model: Libre Computer AML-S905X-CC SoC: Amlogic Meson GXL (S905X) Revision 21:b (82:2) DRAM: 2 GiB Core: 169 devices, 27 uclasses, devicetree: separate MMC: mmc@72000: 0, mmc@74000: 1 Loading Environment from nowhere... OK In: serial Out: serial Err: serial [BL31]: tee size: 0 [BL31]: tee size: 0 Net: eth0: ethernet@c9410000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 1: Armbian Retrieving file: /uInitrd Retrieving file: /Image append: root=UUID=a6cf29bd-49ae-4d3b-bf22-800408ae1fba rootflags=data=writeback console=ttyAML0,115200n8 console=tty0 rw no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 splash plymouth.ignore-serial-consoles Retrieving file: /dtb/amlogic/meson-gxl-s905x-p212.dtb Moving Image from 0x8080000 to 0x8200000, end=9cd0000 ## Loading init Ramdisk from Legacy Image at 13000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 22783777 Bytes = 21.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 08008000 Booting using the fdt blob at 0x8008000 Loading Ramdisk to 7a982000, end 7bf3c721 ... OK Loading Device Tree to 000000007a975000, end 000000007a98169c ... OK "Synchronous Abort" handler, esr 0x96000004 elr: 00000000010656ec lr : 0000000001055038 (reloc) elr: 000000007dfb46ec lr : 000000007dfa4038 x0 : e14b4287a666c25d x1 : 000000007dfbc290 x2 : 0000000000000010 x3 : 000000007bf54e10 x4 : 0000000000000000 x5 : e14b4287a666c25d x6 : 0000000001000000 x7 : 0000000000000000 x8 : 0000000000000007 x9 : 0000000000000000 x10: 0000000000000188 x11: 000000007bf409ec x12: 00000000000000b4 x13: 000000007bf409a8 x14: 000000007a975000 x15: 0000000000000020 x16: 000000007df7a768 x17: 0000000000000000 x18: 000000007bf4cdb0 x19: 000000007af41040 x20: 000000007df4fb18 x21: 000000007dfbc290 x22: 0000000000001000 x23: 000000007bf54d60 x24: 000000007dfdacb8 x25: 0000000001000000 x26: 0000000000000000 x27: 0000000001000000 x28: 0000000000001000 x29: 000000007bf409a0 Code: eb04005f 54000061 52800000 14000006 (386468a3) Resetting CPU ... resetting ... bl31 reboot reason: 0xd bl31 reboot reason: 0x0 system cmd 1. Is there any way to restore original firmware?

I believe this question goes to @rpardini as maintainer of patches for Rockchip series in the `build` repo: I'm trying connect camera to Orange Pi 3B (yes, it boots from community support on edge kernels), but spent 2h digging to find no drivers for CSI2 from Rockchip's fork are ported to patches for recent kernels (for example: https://github.com/armbian/linux-rockchip/blob/rk-5.10-rkr6/drivers/phy/rockchip/phy-rockchip-csi2-dphy.c and corresponding device trees to instantiate these drivers). This is a little chicken egg problem as I need recent kernels to have access to open source GPU drivers - they're not present on 5.10 based original system images for OrangePi 3B. I created a DT overlay for imx219 camera, but it cannot work as right references don't exist on Armbian yet. I could help with porting these, but I need to know the procedure - that's some amount of drivers I can figure out based on `compatible = ` entries from Rockchip's device trees. I probably need to get them built with 6.6 and 6.7, then generate patches with these and PR changes. Any more hints appreciated. I'm interested in having both MIPI CSI2 and GPU working on these boards for now: OrangePi 3B (that one I have on my desk) Radxa Zero 3E Radxa Zero 3W Thank you. How you can live with forum not supporting humanly Markdown?

I tried the latest 6.8 kernel edge on my Rock 5A and noticed the CSI camera interface doesnt exist. Is there any plan or time schedule to fix that? I saw it's marked "TODO" on https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md . So in 6.9 perhaps? (A LOT of other stuff works remarkably well though, great work!)

AFAIK rk3128 is not supported in the mainline armbian code, perhaps some forks may exist but I doubt a lot they do.

Unfortunately when I put my pendrive and boot from pendrive with the desktop version I get Uuid=xxxx does not exist. Dropping to a shell But I can boot fine with the minimal image

Hi, Using the image Armbian_23.5.0-trunk.181_Rock-5b_lunar_edge_6.3.1.img I get this error at boot: Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done. done. 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=6a70cc68-5120-4343-887c-ca90fd2188f9 does not exist. Dropping to a shell! The SD card is working fine when using the Armbian_23.02.2_Rock-5b_jammy_legacy_5.10.110 image.

Yes, you can obviously reinstall the boot completely instead of backing up what you have on your system. This is great info in the thread! I opted for a backup rather than a reinstall. Not only may, I have learned it is more of a rule than an exception. This an example with the opi5 img: Model: Loopback device (loopback) Disk /dev/loop0: 7315MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 16,8MB 285MB 268MB fat16 bootfs bls_boot 2 285MB 7315MB 7030MB ext4 rootfs Witch is the reason I do a dd of the entire boot sector (including any existing boot partitions if they exist) in the initial backup, sup-sequential backups, I just mount both partitions (if there is a boot partition) on the img and backs up the entire file system.

prepare-host: check_host_has_enough_disk_space(): don't check if dir does not exist; fixes #5246 prepare-host: check_host_has_enough_disk_space(): don't check if dir does not exist; fixes #5246 View the full article

I got this on a nano pi and have WordPress on it and use it as a backup and I back it up with WP Synchro. MariaDB Database Server MariaDB version 10.5.21 But it gets all sort of errors like this: 1 Error(s) during migration: Migration aborted, due to a SQL query failing. See WP Synchro log (found in menu "Logs") for specific information about the query that failed. The specific error from database server was: "Unknown collation: 'utf8mb4_0900_ai_ci'". That means that the charset/collation used is not supported by the target database engine. The table charset/collations needs to be changed into a supported charset/collation for the target database or excluded from migration. See documentation on wpsynchro.com for further help. 1 Error(s) during migration: Table 'wordpress.wpsyntmp_65b643f7cbd44' doesn't exist 1 Error(s) during migration: Table 'wordpress.wpsyntmp_65b643f7cc1c2' doesn't exist 3 Error(s) during migration: Table 'wordpress.wpsyntmp_65b643f7cc396' doesn't exist Table 'wordpress.wpsyntmp_65b643f7cc396' doesn't exist Table 'wordpress.wpsyntmp_65b643f7cc396' doesn't exist I can click on RESUME MIGRATION and that's how I got the errors here but it can keep going and I did that one time before took me over a hour to click on the RESUME MIGRATION over and over. Then at the end WordPress said error in database. Have another Debian on a old i386 and I got MySQL install on it. by putting this one line in /etc/apt/sources.list: deb http://ftp.de.debian.org/debian bookworm main contrib non-free non-free-firmware Then could do a apt update and apt install mysql-server. That worked but it don't on this arm armbian for the nano pi. I know with MySQL I don't get any error with the WP Synchro. Looked and I guess no way to install the MySQL on it. Or can't they update the MariaDB to be 100% computable with MySQL? root@nanopi-dock:~# apt install mysql-server Reading package lists... Done Building dependency tree... Done Reading state information... Done Package mysql-server is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'mysql-server' has no installation candidate root@nanopi-dock:~# -Raymond Day

I checked my image. In the minicom console (BPI-M3 -UART -> FTD232 -> USB - Host Linux), in the SSH session, and on the monitor screen connected via HDMI, I see the same greeting pictures: ____ ____ _ __ __ _____ | __ )| _ \(_) | \/ |___ / | _ \| |_) | | | |\/| | |_ \ | |_) | __/| | | | | |___) | |____/|_| |_| |_| |_|____/ Welcome to Armbian 23.10 Bookworm with Linux 6.4.10 No end-user support: built from trunk & unsupported (bookworm) userspace! System load: 1% Up time: 4 min Memory usage: 6% of 1.96G IP: 192.168.100.101 CPU temp: 46�°C Usage of /: 6% of 15G leo@bananapim3:~$ dmesg | grep -i hdmi [ 0.000000] Kernel command line: root=UUID=41970142-87ec-4b91-8231-1b55ee68d69f rootwait rootfstype=ext4 splash=verbose console=ttyS0,115200 console=1 [ 0.084376] platform 1ee0000.hdmi: Fixed dependency cycle(s) with /soc/lcd-controller@1c0d000/ports/port@1/endpoint@1 [ 0.086788] platform connector: Fixed dependency cycle(s) with /soc/hdmi@1ee0000/ports/port@1/endpoint [ 2.327031] sun8i-dw-hdmi 1ee0000.hdmi: supply hvcc not found, using dummy regulator [ 2.327713] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller v1.32a with HDCP (sun8i_dw_hdmi_phy) [ 2.328344] sun8i-dw-hdmi 1ee0000.hdmi: EVENT=plugin [ 2.328730] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI I2C bus driver [ 2.329389] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc0baecbc) [ 2.330594] sun8i-dw-hdmi 1ee0000.hdmi: read_hpd result: 1 [ 43.228319] sun8i-dw-hdmi 1ee0000.hdmi: EVENT=plugin [ 44.121951] sun8i-dw-hdmi 1ee0000.hdmi: EVENT=plugin Observation: My monitor is very smart. He thinks he has correctly identified the entrance from the three possible ones. But he was wrong. I had to press the button with my hand to switch the mode and see the command prompt for entering the password.

On a Rock 5B, I installed Armbian 23.11 Bookworm CLI via a SD card and now trying to setup boot via the NVMe drive. I followed the instructions on https://www.armbian.com/rock-5b/ to create a partition on the NVMe drive, format it, then tried `armbian-install` to boot from SPI. However armbian-install does not list the option to "Boot from SPI". It shows only the following options: 1 Boot from SD - system on SATA, USB, or NVMe 5 Install/Update the bootloader on SD/eMMC I then noticed I do not have a SPI device. /dev/mtdblock0 doesn't exist as well as "cat /proc/mtd" is empty. # ls /dev/mtd* ls: cannot access '/dev/mtd*': No such file or directory # cat /proc/mtd dev: size erasesize name # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mmcblk1 179:0 0 29.7G 0 disk ├─mmcblk1p1 179:1 0 256M 0 part /boot └─mmcblk1p2 179:2 0 29.2G 0 part /var/log.hdd / zram0 251:0 0 7.7G 0 disk [SWAP] zram1 251:1 0 50M 0 disk /var/log zram2 251:2 0 0B 0 disk nvme0n1 259:0 0 3.7T 0 disk └─nvme0n1p1 259:1 0 10G 0 part # dmesg | grep -i spi [ 0.000000] GICv3: 480 SPIs implemented [ 0.000000] GICv3: 0 Extended SPIs implemented [ 0.679958] spi spi0.0: Fixed dependency cycle(s) with /spi@feb20000/pmic@0/regulators/dcdc-reg7 [ 0.679996] spi spi0.0: Fixed dependency cycle(s) with /spi@feb20000/pmic@0/dvs3-null-pins [ 0.680004] spi spi0.0: Fixed dependency cycle(s) with /spi@feb20000/pmic@0/dvs2-null-pins [ 0.680011] spi spi0.0: Fixed dependency cycle(s) with /spi@feb20000/pmic@0/dvs1-null-pins Is there something I need to do such as specifying a dtoverlay to enable SPI? Thanks in advance for your help.

Unreleased open hardware board in CM4 footprint https://www.crowdsupply.com/ov-tech-gmbh/pi-mx8-module - SOC: NXP i.MX 8M Plus - NXP guarantees production of the chip for 10 years. - 4x A53 cores at up to 1.8 GHz / 1x M7 core at up to 700 MHz - 1 GB/2 GB/4 GB/8 GB LPDDR4 system memory - Vivante GC7000UL GPU - Gigabit Ethernet PHY supporting IEEE 1588v2 and SyncE - PCIe Gen3 1x1 Interface - Optional eMMC with 8 GB/16 GB/32 GB - Optional 2.4 GHz & 5 GHz Wi-Fi + Bluetooth 5.2 (Murata LBEE5PK2BC) - Optional Coral Edge TPU connected via PCIe - Two CSI-2 interfaces, one with 4-lane and one 2-lane width Some open hardware carrier boards exist such as Twisted fields CanBUS/ Robotics Piunora Camera, Qwiic, Arduino pinout Jkiv Gigabit, uSD Will cluster RobertLukan dual camera, 40 pin header Wiretrustee SATA/ NAS Mirko PC 2x HDMI, 2x Camera, M.2, uSD, 40pin tkircher camera, Qwiic, M.2, HDMI, uSD Others I plan to use this thread to document the hardware and other related efforts to support IMX8 hardware, intending to add Armbian support for this board. So far I have found: - https://github.com/Joshua-Riek/ubuntu-apalis-imx8 - https://github.com/TechNexion-customization/ubuntu-tn-imx/tree/master?tab=readme-ov-file#technexion-ubuntu-lts-image-builder

Members, I have a question, because I can't find any documentation about what is broken or not. Why does /dev/rga not exist in my armbian install? I need it for my FFmpeg rkmpp config.

Gents, installed Armbian Bullseye successfully to my Banana Pi M2 Berry. In second step i moved the OS to my attached 2,5 WD RED Sata Harddrive. This was easily possible with the command "sudo nand-sata-install". But now, i see that my /var/log is full, because its located in ZRAM. root@BananaPiM2Berry:/etc/systemd/system# df -h Filesystem Size Used Avail Use% Mounted on udev 431M 0 431M 0% /dev tmpfs 100M 11M 90M 11% /run /dev/sda1 687G 1,3G 651G 1% / tmpfs 500M 0 500M 0% /dev/shm tmpfs 5,0M 4,0K 5,0M 1% /run/lock tmpfs 500M 0 500M 0% /tmp /dev/mmcblk0p1 1,7G 1,3G 385M 77% /media/mmcboot /dev/zram1 49M 48M 0 100% /var/log tmpfs 100M 0 100M 0% /run/user/1000 As you can see i hve more than 650 GB avail in my root parttiion on /dev/sda1. But how can i setup /var/log to wirte on /dev/sda1 ? i believed to find it in /etc/fstab, but its not there. # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=7fe45d82-d362-438a-9b7a-baa3678fcab4 /media/mmcboot ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 /media/mmcboot/boot /boot none bind 0 0 UUID=614c4feb-de66-4b2c-a046-ce72aaf2e600 / ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 Right now, the device is unuseable, i cant even install system updates, since no more logs can be written. Since i have so much storage avail on my HDD, i wonder how to move /var/log there... Greatings Schlotze

I booted the RC from 1/20/2024, set the ftdfile to rc3588s-orangepi-5b.dtb in armbianEnv.txt, and rebooted: no wifi or bluetooth. The hci0 and wlan0 devices are not present. They both work on the Linux 5.10 kernel. My armbianEnv.txt: -------------------------- verbosity=1 bootlogo=true overlay_prefix=rockchip-rk3588 fdtfile=rockchip/rk3588s-orangepi-5b.dtb rootdev=UUID=38eb4cb5-0503-4a0a-900f-7a5167517a20 rootfstype=ext4 overlays=sata1 sata2 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

I just want to add a few comments to this whole dtb overlay discussion. First I want to thank all of you involved in this discussion. You all have different view points and I think are tackling a very difficult problem to which there is no perfect solution. What comes out of this discussion should be applied to the other soc families as well, as they all suffer from some form of this issue as there is no standard in place that works for all use cases well. From what I have seen, good minds are thinking this through and I expect a good result to follow. The reason I am commenting at all, is because in my role as forum moderator, the basic question: "How do I enable feature x on my board" is one of, if not the most commonly asked question by end users of the forum. And when the answer is 'just write a dtb overlay', you have lost 95% of those users as they do not have the skills/knowledge to do that. The status of the dtb overlay's across Armbian supported and community maintained boards is poor. There is no standardization from family to family or board to board. And no testing of what does exist to ensure that it works. Now I'm not saying that all of this needs to be solved in what comes out of this design discussion. I'm just saying from my perspective as a moderator that this is an area that can use some attention, and in doing so, please try to make the end result usable by the typical end user of an sbc, trying to do common things. I realize also that I'm saying this when I only use these boards as servers and don't personally need any of the functionality the overlays provide. But as a forum moderator, I see the mismatch between what is being done and some common use cases that end users are looking for.

On my odroid hc2 with armbian/bullseye I found some of the logs (both in /var/log and /var/log.hdd) empty, while they should have some contens (i.e. afpd.log, kern.log, user.log, ...). The empty files all have the timestamp of a run of armbian-ramlog at a recent reboot. In armbian-ramlog.log I found this for the run that created the empty files: rsync: [receiver] write failed on "/var/log/journal/0d4b1c13b9a14b6d9c746402b7d7ef6f/user-1000@0005d37f46f9961b-23c015a66b68d086.journal~": No space left on device (28) rsync error: error in file IO (code 11) at receiver.c(378) [receiver=3.2.3] rsync: [sender] write error: Broken pipe (32) Seems that journal has become too big to fit on the log/ramdisk. That is strange, as I defined a maximum of 20MB for the journal and the ramdisk has 50MB. I guess this is what happened: When syncing to sd armbian-ramlog uses rsync without --delete. So if some older files have been already delete by journald (because of the 20 MB limit) on the ramdisk, they will still stay in the log on sd. Therefore the journal on the sd will become bigger and bigger. Which is not a problem because there is plenty of space on the sd. However, when rebooting everything is copied from the sd to the ramdisk. Including the bloated journal. Thus the ramdisk is full and additional files will not fit (see error message from rsync). I think in this case rsync just creates empty files and that is the reason for my empty logs. And on next sync the empty files are copied back to sd so both versions are empty. There is another potential problem I see in the implementation of armbian-ramlog: on reboot only recent files (so no *.gz or *.[0-9]) are copied to ramdisk. After som runtime logrotate will rotate the logs and create new *.gz or *.[0-9]. However, these might already exist on the sd. They will be overwritten when the logs are written back to sd. So you loose old logs. I think both problems are due to the fact that simple rsync is used without --delete and without copying even the old files to the ramdisk. To overcome these problems I see two ways: use rsync --delete and dont exclude *.gz and *.[0-9]. Then the ramdisk holds all logs and when copying to sd nothing is lost. But this may requier a bigger ramdisk dont use rsync but use an overlay fs instead. I found this discussion on the topic. The described solution looks superior to me than what we are using now: https://unix.stackexchange.com/questions/424341/mount-var-logs-as-tmpfs-with-help-of-overlayfs-to-save-changes-sometimes What do you think about it? Would it make sense to use an overlay fs? I am not that deep into linux hacking and therefore are not sure if I would be able to implement it in a nice way. But I would like to support this process and do some tasks. Regards, jba