@MMorales@mmie4jbcu i have the same x88 pro 20 clone like you guys, on the pcb is written "x88pro-rk3566-4d32-v1.0", which should state for 4gb ddr and 32gb rom i guess? I installed latest armbian for station m2 with image-included demo-box.dtb, everything is working so far, despite bluetooth (CDtech-208821C=RTL8821CS). installed armbian-firmware-full but bt still doesn't work. Maybe usefull for just Linux-Users (i don't have a windows pc): original loader didn't allow me to boot from sd-card, rkdeveloptool (or xrock or rdeveltool-gui) didn't work for me, so i used proprietary upgrade_tool for linux from rockchip: https://docs.radxa.com/en/zero/zero3/low-level-dev/upgrade-tool I downloaded this loader from radxa https://dl.radxa.com/rock3/images/loader/rk356x_spl_loader_ddr1056_v1.12.109_no_check_todly.bin and flashed it with: sudo ./upgrade_tool wl 0x0 rk356x_spl_loader_ddr1056_v1.12.109_no_check_todly.bin After that i put in the sdcard and it bootet straight (wait for min. 5 seconds) to armbian!

Made some progress today. For debugging, I built my own image with the Edge kernel (6.18). However, this time, the board did not even boot up and there was also no signal on HDMI. The last idea I had was to downgrade the kernel using armbian-config. But since the Ethernet is not working, I was trying to setup WiFi because armbian-config was trying to load apt cache but without internet, I cannot load anything. After multiple reboots, I slowly cached the apt. Then the armbian-config loaded. I downgraded the kernel from 6.12.60 to 6.6.63 and then the Ethernet started working fine! ☺️ Current version: $ uname -a Linux rockpi.dev.com 6.6.63-current-rockchip64 #2 SMP PREEMPT Fri Nov 22 14:38:37 UTC 2024 aarch64 GNU/Linux $ lsb_release -a Distributor ID: Debian Description: Armbian_community 26.2.0-trunk.44 trixie Release: 13 Codename: trixie I am now confident that somewhere after Kernel 6.6, the Ethernet is broken in Rockpi 4B.

That's not really possible either. The only thing that is possible is using my kernel build in Armbian environment to see how it is performing for you. With my jumpstart image, this is actually quite easy to implement. For this, both root filesystems just need to be mounted and extlinux/prepare-jump-start ${target-rootfs-mount-point} needs to be executed in the jumpstart rootfs. If the target system is now being booted with firmware that uses mainline U-Boot as the payload, nothing stands in the way of booting with my kernel. And don't worry, prepare-jump-start only adds files to the target rootfs. Nothing will be overwritten or deleted. If you want to give it a whirl, speak up and I will upload a current image. But you will be disappointed, because the stock kernel only provides the functionalities available with the officially released kernel. Both Armbian and my kernel build have already applied patches that may appear in a future official release. I doubt that you will succeed, because even the fedora organization only does a full rebuild once per release cycle. There is no advantage in rebuilding a component unmodified that leads to the same result as the package already provided. It only makes sense to do this when branching off the release version in order to create a synchronized basis for further development. Only modified packages will be replaced or upgraded. My weekly upgrade gives me several gigabytes of new packages each time because I'm on Rawhide. Somehow, I can no longer manage to stick to any official release versions.

Maybe a handful, I have most SBC's equipped with one permanently. And needed for Arduinos etc, you can even power tiny old things like RPI0/1 with it (if you connect red wire to 5V pin as well). In the meantime, you might think about some previous U-Boot and previous kernel. For quite some SBCs, there is trouble when U-Boot is new/mainline/releasecandidate and kernel vendor. I am currently also doing some tests on my NanoPi-R6C (RK3588s) because HDMI is not initialized fast enough (by U-Boot). And with 6.1.115 vendor kernel really choppy mouse updates and green tint, not complete flat green luckily, I can still see icons and mouse.

Hey @Sergey Lepeshkin, thanks for the fast reply. I will check what you mentioned. I was thinking, could i modify the recovery.zip from the recovery partition so when it reflashes it gives the box "su" rights? that would be via software and no need to connect wires. If my idea is not possible, i will keep trying with the UART. Thanks for the advice.