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