So if this works for you and you apparently know how to change bootloader, I can not really say or conclude more in addition to what is already said. I do not use images nor Imager and also do not own the ITX, I only tried to see if this issues is maybe something RK3588 generic.

Hi all, I know this is a bit of a long shot given the age of the hardware, but I’m wondering if anyone here has ever experimented with running Armbian on an EVPad 2S (the old Android TV box). I’ve been tinkering with some older devices and thought it might be interesting to see if this one can be repurposed. I’ve attached a screenshot of the system info - unfortunately, it’s pretty sparse. The box is running Android 4.4.2 with kernel version 3.4.39, but the processor type is listed as “UNKNOWN,” and I haven’t found much documentation on the chipset or board layout. so before I dive deeper I wanted to ask: Has anyone managed to get Armbian (or any Linux distro) running on it? Are there known limitations with the chipset or bootloader that make it a dead end? Any tips, resources, or even “don’t bother” experiences would be appreciated. Thanks in advance for any insights - sometimes these older boxes surprise us, but I realize support may be very limited.

Hello @brunorro. That "current.txt" from above: the UART output shows you are booting an older KY-Uboot from NOR flash. Probably SD card not fully inserted. "edge.txt" shows a correct SD card boot sequence. Best // Sven-Ola

@JuanEsf Is possible fist acces via SSH?

Hi @ff255, It's been a while, I'm assuming you are still getting the same error as mentioned below: Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... The output you shared helps, but can you share a little bit more? Would need to know the following for your case: Filesize of your kernel image file Filesize of your initrd file If possible, filesize of the DT file being loaded. With those three values, we should be able to calculate the correct load addresses and try booting. (All this also presuming that your issue is that the load addresses used by U-Boot/the bootscript do not leave enough room for either a kernel or initrd file, causing one of those to overlap the start of the other.) Groetjes,