All Activity

This is the hint I got from AI 🙂 I changed the repositories from beta to stable and installed: sudo sed -i 's|beta.armbian.com|apt.armbian.com|g' /etc/apt/sources.list.d/armbian.list and sudo apt download armbian-bsp-cli-orangepi3-lts-current sudo dpkg --install --ignore-depends=base-files armbian-bsp-cli-orangepi3-lts-current_25.8.2_arm64.deb Now it's OK....but is this the right approach?

How did you determine this without holding the board in your hands? Without connecting the uart? The chips are located on both sides of the board. Assuming that h5anag8najr-wmc is a fake label and that the chip is 1Gbx8, the u-boot output on the uart should be Row=17 CS=2, not ROW=16 CS=1. Or am I wrong? If the board allows you to work with two ranks and the CS-1, A14, and A16 are present (on the board), then u-boot should display ROW=17, CS=2 Size=4096MB. BUT, the bootloader does not recognize the 2nd memory rank. https://github.com/hqnicolas/Rockchip-Library/tree/main/RK356x/rkbin - It is not possible to build rk356x_spl_loader_v1.xxx.bin, also known as the miniloader, using this link. There is no tools directory in this section. I managed to figure out how to assemble rk356x_spl_loader_v1.xxx.bin using different (rk3566_ddr_528MHz_ultra_v1.10, rk3566_ddr_780MHz_ultra_v1.10, rk3566_ddr_920MHz_ultra_v1.10, rk3566_ddr_1056MHz_ultra_v1.20, as well as rk3566_ddr_920MHz_v1.23, rk3566_ddr_1056MHz_v1.23.) I also managed to build u-boot - I'll have time to test it all. It's a pity that few people share information. P.S. If you look at https://github.com/hqnicolas/Rockchip-Library/blob/main/RK356x/u-boot/socfpga/rk3568_common.h, you'll see #define SDRAM_MAX_SIZE 0xf0000000, which limits the size to 4GB. Therefore, it is possible that u-boot is built with a 4GB SDRAM limit. However, I also assume that the memory could have been tampered with. I would benefit from obtaining U-boot's UART output from those with NT5AD1024M8A3 memory. Currently, I am considering three options. 1. U-boot is built with SDRAM_MAX_SIZE 0xf0000000 limitation 2. rk3566_ddr_xxxMHz_v1.xxx.bin - does not recognize the 2nd rank (2R) of Hynix h5anag8najr-wmc memory 3. Memory labeling is still fake

@erebus041 @Nick AOne small detail: I've used etchdroid and drofus to burn my sd card.

Well, the source code is still on github so you could try building it. I can't find that tag in `armbian/build`, but did find `v24.11.0-trunk.303` It does build [I guessed at jammy, maybe it should be noble] time ./compile.sh build BOARD=jetson-nano BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes RELEASE=jammy KERNEL_CONFIGURE=no KERNEL_GIT=full ARTIFACT_IGNORE_CACHE=yes [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img (4.07GiB) ] [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img.sha (202.00B) ] [🐳|🌱] Fast-moving file to output/images [ -> Armbian-unofficial_24.11.0-trunk_Jetson-nano_jammy_current_6.6.116_minimal.img.txt (19.29KiB) ]

@erebus041can you please provide the link of Yuzuki Chameleon images?

Ok. Also I think these are wrong for the PI5: dtoverlay=disable-wifi dtoverlay=disable-bt I believe it's: dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 My notes on this: # Pi3 / ZERO2W dtoverlay=pi3-disable-wifi dtoverlay=pi3-disable-bt # PI5 dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 # Everything else dtoverlay=disable-wifi dtoverlay=disable-bt Back in the day, I read somewhere that Bluetooth can inhibit serial from functioning correctly on the Pi's. I've never seen it happen, but maybe using the wrong overlay is hindering it in some way? Worth looking into.

I just noticed from your screenshot that you aren't using Armbian. You need to ask support questions for non-armbian software from where you got your software. Ophub is a fork of Armbian that used the Armbian name without permission. They do not contribute to Armbian development nor do they contribute the these forums.

yes!

@erebus041Thanks for the details.I'll try and i hope it works.

So you are saying that when you copy the working SD card install (by working I mean that it has the correct memory amount) to emmc that the problem occurs?

@c0rnelius I will try that too, along with some other ideas that I came across. I won't have time to work on this during the weekend, but I will get back to you early next week. Appreciate your patience!

Hi. I installed Armbian Server on my TV box (Ugoos X3 Pro 4/64 x905x3) to the NAND, and I have some trouble with the RAM size in the system. I use meson-sm1-ugoos-x3.dtb. It turns out that only 1.8GB of 4GB RAM is available in the system. On the Russian forum 4PDA, I found some information on how to fix this. I repacked the DTB file and changed memory@ from 0x40000000 to 0xFF000000. After that, 3.8GB RAM appeared in the system, but it turned out the system was unstable and randomly froze. However, when I installed Armbian from an SD card, all 3.8GB RAM was available in the system, and the system worked fine and stable. I also used meson-sm1-ugoos-x3.dtb. Is it possible to fix this and use all available RAM?

Does it work when you remove that HAT?

Well, that's strange, and thus I am a bit confused. I retried a few times: flashed Armbian_25.8.1_Rpi4b_noble_current_6.12.41_xfce_desktop.img.xz onto a micro-SD card in a UGREEN SD-card reader. I tried both rpi-imager and plain old dd. I am using a WCH340-based USB-serial adapter (came from the Pine64 webshop) wired up apparently correctly (see the attached photo). (I believe that my initial problem may have been caused by the rpi-imager custiomization settings, that I thought were supported with the Armbian image too.) Since then I stopped using those customization settings. The system now boots OK, the GUI comes up, but I'm still not seeing anything in the minicom screen. My config.txt settings are still: usb_max_current_enable=1 enable_uart=1 dtoverlay=uart0 dtparam=pciex1 dtparam=pciex1_gen=3 max_current_enable=1 dtoverlay=disable-wifi dtoverlay=disable-bt I now have both ttyAMA0 and ttyAMA10 devices: root@rpi5b:~# ls -l /dev/ttyAMA* crw-rw---- 1 root dialout 204, 64 nov 7 12:16 /dev/ttyAMA0 crw--w---- 1 root tty 204, 74 nov 7 12:57 /dev/ttyAMA10 root@rpi5b:~# systemctl status serial-getty@ttyAMA10.service ● serial-getty@ttyAMA10.service - Serial Getty on ttyAMA10 Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled-runtime; preset: enabled) Drop-In: /usr/lib/systemd/system/serial-getty@.service.d └─10-term.conf Active: active (running) since Fri 2025-11-07 12:57:12 CET; 1h 49min ago Docs: man:agetty(8) man:systemd-getty-generator(8) https://0pointer.de/blog/projects/serial-console.html Main PID: 2714 (agetty) Tasks: 1 (limit: 9411) Memory: 200.0K (peak: 1.7M) CPU: 12ms CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyAMA10.service └─2714 /sbin/agetty -o "-p -- \\u" --keep-baud 115200,57600,38400,9600 - linux nov 07 12:57:12 rpi5b systemd[1]: serial-getty@ttyAMA10.service: Scheduled restart job, restart counter is at 1. nov 07 12:57:12 rpi5b systemd[1]: Started serial-getty@ttyAMA10.service - Serial Getty on ttyAMA10. root@rpi5b:/usr/lib/systemd/system# systemctl enable --now serial-getty@ttyAMA0 Created symlink /etc/systemd/system/getty.target.wants/serial-getty@ttyAMA0.service → /usr/lib/systemd/system/serial-getty@.service. root@rpi5b:/usr/lib/systemd/system# systemctl restart serial-getty@ttyAMA0 root@rpi5b:/usr/lib/systemd/system# fuser -c /dev/ttyAMA0 /dev/ttyAMA0: 42rc 3040m 4999 root@rpi5b:/usr/lib/systemd/system# ps auxfw | fgrep 4999 root 5013 0.0 0.0 9040 2108 pts/4 S+ 14:50 0:00 \_ grep -F --color=auto 4999 root 4999 0.0 0.0 8192 1956 ttyAMA0 Ss+ 14:49 0:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 - linux root@rpi5b:/usr/lib/systemd/system# systemctl restart serial-getty@ttyAMA10 root@rpi5b:/usr/lib/systemd/system# And in the end, nothing seems to be happening when I start the new getty on AMA0 or restart the old one on AMA10. I am puzzled.

Armbian Trixie XFCE (Edge kernel 6.18.0-rc3-edge-rockchip64) + Stable mesa 25.0.7-2 + box64-rk3588 0.3.9+20251106.dcd3ba0-1 (https://ryanfortner.github.io/box64-debs/) + wine-10.18-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases) + dxvk-sarek v1.11.0-sarek-async-writeaccessfix-malifix-5d21d2b (https://github.com/pythonlover02/DXVK-Sarek/actions) Elin ~40fps@720p

Hip hip hooray !!! Yep, this way worked. Will provide the all steps for people who have the same issue. $ apt install linux-u-boot-rock-5b-edge $ armbian-install # Just in case I've installed to the all partitions. I mean to 5th and 7th. > 5 Install/Update the bootloader on SD card (/dev/mmcblk1) > 7 Install/Update the bootloader on MTD Flash $ reboot And now I can enter to uboot shell change to F2: 1068MHz ch0 ttot12 ch1 ttot12 ch2 ttot12 ch3 ttot12 change to F3: 1560MHz ch0 ttot14 ch1 ttot14 ch2 ttot14 ch3 ttot14 change to F0: 2112MHz ch0 ttot16 ch1 ttot16 ch2 ttot16 ch3 ttot16 out U-Boot SPL 2024.04-armbian-2024.04-S830c-P0000-Hd72c-Vdfa5-Bb703-R448a (Oct 24 2025 - 02:33:30 +0000) Trying to boot from SPI ## Checking hash(es) for config config-1 ... OK ## Checking hash(es) for Image atf-1 ... sha256+ OK ## Checking hash(es) for Image u-boot ... sha256+ OK ## Checking hash(es) for Image fdt-1 ... sha256+ OK ## Checking hash(es) for Image atf-2 ... sha256+ OK ## Checking hash(es) for Image atf-3 ... sha256+ OK INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-868-g040d2de11:derrick.huang, fwver: v1.48 NOTICE: BL31: Built : 15:02:44, Dec 19 2024 INFO: spec: 0x1 INFO: code: 0x88 INFO: ext 32k is not valid INFO: ddr: stride-en 4CH INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: valid_cpu_msk=0xff bcore0_rst = 0x0, bcore1_rst = 0x0 INFO: l3 cache partition cfg-0 INFO: system boots from cpu-hwid-0 INFO: disable memory repair INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0xa00000 INFO: SPSR = 0x3c9 ns16550_serial serial@feb50000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2024.04-armbian-2024.04-S830c-P0000-Hd72c-Vdfa5-Bb703-R448a (Oct 24 2025 - 02:33:30 +0000) Model: Radxa ROCK 5 Model B DRAM: 16 GiB Core: 353 devices, 32 uclasses, devicetree: separate MMC: mmc@fe2c0000: 1, mmc@fe2d0000: 2, mmc@fe2e0000: 0 Loading Environment from SPIFlash... SF: Detected xt25f128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial@feb50000 Out: serial@feb50000 Err: serial@feb50000 Model: Radxa ROCK 5 Model B rockchip_dnl_key_pressed: no saradc device found Net: No ethernet found. Hit any key to stop autoboot: 0 => Great Thanks a lot

What is easiest depends on the situation. If you feel comfortable enough to use dd to write bootloader, I just downloaded the -edge package from the beta apt package pool, extracted the .bin file and wrote it to correct location on SD-card, after saving the first 32k sectors also with dd to a backupfile. Then reboot and you know it. The qemu experiment was to boot directly from U-Boot to Btrfs raid1 filesystem, it took a lot of time browing through U-Boot config/compile options. Better/formal method is to install -edge package, it will remove -current package, then use armbian-config to write the bootloader explicitly.

Welcome to TV-Box section, that's the real size of your RAM: 4gb https://github.com/hqnicolas/Rockchip-Library/tree/main/RK356x/rkbin

@Farhan Ishraq well you can download the bigtreetech cb1 images or the Yuzuki Chameleon images, its running just fine!

Hi I'm looking to emulate an industrial device such as eWon or ESA router by using an sbc with dual eth and tailscale/headscale. What is the best and cheapest board? better if with a decent chassis. I'm interested in something like nanopi Rx or orangepi Rx. Any idea? thank you

Sigh ... Yeah I could see https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file but for some reason I need exactly u-boot with enabled eth interface. So, it looks like I need to check -edge version too. However, you've mentioned qemu arm64 u-boot. So, It can be the way for me to check on my side all of these distributives before deploy it on a real hardware.

@Nick A@Sadiq AhmedHey Nick,I've tried to boot BigTreetech CB1[Provided by Sadiq] and a few more.But when i put Image burned sd card in TF slot and turn on the box but my screen didn’t get any hdmi output[for 3-4 minutes] then i removed the sd card from TF slot.I Don't have that much knowledge about SoC,Bootloader blah blah blah.Can you find any mistake or suggest me a compatible os?

OK, it seems your SPI-flash is empty, so not used and skipped. I start to remember I think; ROCK5B -current is quite old and not from denx.de (or 'mainline') so I picked -edge, but I think I never wrote it to SPI, instead I have this in SPI: https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file You need grub-efi or other efi capable and configured bootloader (hide boot.scr, add ESP partition) root@rock5b:~# strings /usr/lib/linux-u-boot-edge-rock-5b/u-boot-rockchip-spi.bin | grep "U-Boot SPL" U-Boot SPL 2024.04-armbian-2024.04-S830c-P0000-H1056-Vdfa5-Bb703-R448a (Jun 08 2025 - 03:38:17 +0000) My ROCK5B is 24/7 server, I won't reboot and do checks now, up to yourself to dig deeper and see how various versions are build. I remember there is a config option w.r.t. this 1 sec timeout, that I saw when building qemu arm64 u-boot a year ago. I currently have blocked u-boot and armbian packages, but will maybe configure/build for ROCK3A 2025.10, but that is completely other topic/issue.

I see from https://github.com/nextcloud/nextcloudpi/releases that 'pi' is sort of a synonymy for 'ARM SBC' or pre-installed images. 'pi' is great but a problem as it is not generic arm64 so every SBC flavor needs a 1GByte zip image just for a different kernel and bootloader. Same as long time ago I used a 'pi' script to get Node-RED installed in an x86 Debian Bullseye Virtual Machine (so just 'Debian' actually), I would focus on generic solutions. Armbian is doing very well w.r.t. alignment and portability, so the SoC or SBC does not really matter, as long as it is compliant with Debian ARM64. For Node-RED on Opensuse-Tumbleweed ARM64 I needed to hack the script a bit to fake a compliance check, but with that, it also worked. It saved an enormous amount of effort re-installing OS etc. So bottom line is, maker sure you don't lock yourself into a certain SBC or SoC, but make sure it is standard generic ARM64 (or standard x86-64, which is already the case for years) A way to keep your current installation is to 'virtualize' it: What runs on the Odroid or RaspberryPi or other SBC from SD-card or eMMC or NVME or SSD can be made EFI bootable and then it will run as virtual machine on the same SBC or other new/faster SBC of course as well. I have done this for RPI3B functions -> RPI4B in the past (also 32-bit VM in 64-bit host, Pi-Hole for example) and this year again to replace RPi4B-8GB with ROCK5B-16GB. It is beyond the scope of this topic, but start with installing 'virt-manager' and try to boot and Armbian-UEFI image/instance. Or see: https://github.com/nextcloud/vm I haven't used 'cloud' since owncloud, but right now, if I would certainly start with a VM. Same for e.g. HAOS, runs fine in a VM on ROCK5B. You do not need proxmox, all is build-in in Linux already.

$ apt list -a --installed linux-u-boot-rock-5b* Listing... Done linux-u-boot-rock-5b-current/now 25.8.2 arm64 [installed,local] linux-u-boot-rock-5b-current/noble 25.8.1 arm64 linux-u-boot-rock-5b-current/noble 25.5.1 arm64 linux-u-boot-rock-5b-current/noble 25.2.3 arm64 linux-u-boot-rock-5b-current/noble 25.2.2 arm64 linux-u-boot-rock-5b-current/noble 24.11.3 arm64 linux-u-boot-rock-5b-current/noble 24.11.1 arm64 linux-u-boot-rock-5b-current/noble 24.8.2 arm64 $ dpkg -L linux-u-boot-rock-5b-current /. /usr /usr/lib /usr/lib/linux-u-boot-current-rock-5b /usr/lib/linux-u-boot-current-rock-5b/idbloader.img /usr/lib/linux-u-boot-current-rock-5b/rkspi_loader.img /usr/lib/linux-u-boot-current-rock-5b/u-boot-config-target-1 /usr/lib/linux-u-boot-current-rock-5b/u-boot-defconfig-target-1 /usr/lib/linux-u-boot-current-rock-5b/u-boot-metadata-target-1.sh /usr/lib/linux-u-boot-current-rock-5b/u-boot-metadata.sh /usr/lib/linux-u-boot-current-rock-5b/u-boot.itb /usr/lib/u-boot /usr/lib/u-boot/LICENSE /usr/lib/u-boot/platform_install.sh /usr/lib/u-boot/rock-5b-rk3588_defconfig /usr/share /usr/share/doc /usr/share/doc/linux-u-boot-rock-5b-current /usr/share/doc/linux-u-boot-rock-5b-current/changelog.gz $ cat /usr/lib/u-boot/platform_install.sh # Armbian u-boot install script for linux-u-boot-rock-5b-current 2017.09-Sa317-Pedb0-H5208-Vc393-Bb703-R448a # This file provides functions for deploying u-boot to a block device. DIR=/usr/lib/linux-u-boot-current-rock-5b write_uboot_platform () { local logging_prelude=""; [[ $(type -t run_host_command_logged) == function ]] && logging_prelude="run_host_command_logged"; if [ -f $1/u-boot-rockchip.bin ]; then ${logging_prelude} dd if=$1/u-boot-rockchip.bin of=$2 bs=32k seek=1 conv=notrunc status=none; else if [ -f $1/rksd_loader.img ]; then ${logging_prelude} dd if=$1/rksd_loader.img of=$2 seek=64 conv=notrunc status=none; else if [[ -f $1/u-boot.itb ]]; then ${logging_prelude} dd if=$1/idbloader.img of=$2 seek=64 conv=notrunc status=none; ${logging_prelude} dd if=$1/u-boot.itb of=$2 seek=16384 conv=notrunc status=none; else if [[ -f $1/uboot.img ]]; then ${logging_prelude} dd if=$1/idbloader.bin of=$2 seek=64 conv=notrunc status=none; ${logging_prelude} dd if=$1/uboot.img of=$2 seek=16384 conv=notrunc status=none; ${logging_prelude} dd if=$1/trust.bin of=$2 seek=24576 conv=notrunc status=none; else echo "Unsupported u-boot processing configuration!"; exit 1; fi; fi; fi; fi } write_uboot_platform_mtd () { FILES=$(find "$1" -maxdepth 1 -type f -name "rkspi_loader*.img"); if [ -z "$FILES" ]; then echo "No SPI image found."; exit 1; fi; MENU_ITEMS=(); i=1; while IFS= read -r file; do filename=$(basename "$file"); MENU_ITEMS+=("$i" "$filename" ""); ((i++)); done <<< "$FILES"; if [[ $i -eq 2 ]]; then dd if=$1/${MENU_ITEMS[1]} of=$2 conv=notrunc status=none > /dev/null 2>&1; return; fi; [[ -f /etc/armbian-release ]] && source /etc/armbian-release; backtitle="Armbian for $BOARD_NAME install script, https://www.armbian.com"; CHOICE=$(dialog --no-collapse --title "armbian-install" --backtitle "$backtitle" --radiolist "Choose SPI image:" 0 56 4 "${MENU_ITEMS[@]}" 3>&1 1 >&2 2>&3); if [ $? -eq 0 ]; then dd if=$1/${MENU_ITEMS[($CHOICE*3)-2]} of=$2 conv=notrunc status=none > /dev/null 2>&1; else echo "No SPI image chosen."; exit 1; fi } setup_write_uboot_platform () { if grep -q "ubootpart" /proc/cmdline; then local tmp part dev; tmp=$(cat /proc/cmdline); tmp="${tmp##*ubootpart=}"; tmp="${tmp%% *}"; [[ -n $tmp ]] && part=$(findfs PARTUUID=$tmp 2> /dev/null); [[ -n $part ]] && dev=$(lsblk -n -o PKNAME $part 2> /dev/null); [[ -n $dev ]] && DEVICE="/dev/$dev"; fi } $ cat /dev/mtdblock0 > /tmp/spidump $ strings /tmp/spidump | grep -i U.*Boot nothing $ du -h /tmp/spidump 16M /tmp/spidump It seems something installed and configured but for -current not for -edge I thought that -current version more stable. Am I wrong and I need to install -edge ?