All Activity

I have a question. After making the modifications as described above and executing the `compile.sh` script, the file `arch/arm64/boot/dts/allwinner/sun50i-h618-x98h.dts` reverts to its original state. Is this normal? How can I determine if my changes have been compiled into the image? @Nick A

Yesterday I did start to install armbian trixie iot on my Pinebook. Second part in debian - after the u-boot) starts, but then the Pinebook shuts off, because of a low battery(?) I did charge the whole day and powered off in the evening. Today the Pinebook stand on my table with a swollen battery. I removed it and happily it doesnt crash anything else than the battery holder. But now it doenst boot up complete like with a low battery. After the u-boot debian trixie does boot , but at the middle of the messages it does shutdown Can it run completly without battery? I have normally a 5V/2Ah power-supply connected and that did work the last years. Now I can only try to use a 5V/60W quick-charge Power-Supply. Anyone has experiences with that? Thanks for info in advance...

Continuing the story. Or 4pda (Russian).

If you have patience, CEC may work at some point with mainline kernel. There is not fast solution.

See There is an issue with the build framework that prevents base-files from being built for the arm64 target. At present time the issue is unresolved, and the root cause might be still unknown.

I ran into the same problem when setting up a retroarch based gaming system with Armbian Debian Trixie. I wanted to use my Dualsense 4 controller with it but couldn't get it to work on Vendor or Current. I later realized that you need to enable `LEDS_CLASS_MULTICOLOR` and `HID_PLAYSTATION` for it to work with the controller. This was only present from the kernel 6.2 and involved compiling the kernel after enabling those flags. I got that working in current and edge but I lost HDMI-CEC. The edge kernel at the time is 6.18.0 for rock 5b. Is there any way forward to get both functionalities working? I see that HDMI-CEC is listed as `n/a` under rock 5b here: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md.

didn't even realize you were on beta repo. Well when you use bleeding edge, you have to be prepared for breakage since it is expected ;).

https://github.com/armbian/os/commits/25.11.0-trunk.367/git_sources.json This file determine state (hash) of sources. It's not a straightforward process, but one can recreate exact image (except userspace packages, which versions are not stored) This file has to be here https://github.com/armbian/build/commit/31e82512cc60a74f56b710aa2971d7dc2beec9b9 One day, this will be done better Sadly there is too much of such e-waste and way way too little people willing to maintain them in their limited private time. I am sure you can find a working image somewhere in our archives so you don't need to throw it away, but we cannot fool you & ourselves to be able to keep this board maintained.

I came from 4pda to armbian and I came from there already being a prejudiced person. this is just another normal day in the TV box section. Many other users have already encountered similar problems with Chinese boxes. you can solder a better module like @Deoptim

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