Werner

Looks like stuff got lost due to force-push. Check this how it looked before: https://github.com/rvdr/build/activity?ref=spi-nvme-patches

standard baud rate for rockchip socs is 1500000. And for the other your cp2102 is no good for this high speed since it cannot handle it. And instead of failing it will output garbage. get ft232r, cp2104 or pl2303 based adapter.

https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first/#comment-199170

Good morning

@Werner  Thanks for the patch. I'll probably wait for the new kernel and test it. The project is long-term. For the first answer "to address myself" :). I think I understand what you're saying. Thanks :).
If I find a solution to this, I'll share it with the community, as I've been doing so far  
@usual user Thanks for the answer.
Today is the 31st and I'm thinking of not working on servers, happy new year and may the next one be fruitful for all of us.

Best regards,
A.H.

Are you sure you don't mean BSP which stands for Board Support Package??

Didn't warn ffmpeg from a guts feel years ago that they will issue a takedown if no action is taken? So I'm not surprised. Kind of.

@JuanEsf sunxi-edge is now on 6.18. You can add your patches for t527 there.

You're in luck. Major work has been done. https://github.com/armbian/build/pull/9049 Still needs testing
Once this is merged 4A and other more recent Allwinner Soc related work can be rebased on top of that.

picture seems broken/corrupted

There is something to start with. Untested, not even put much thought into it. Try'n'error: https://github.com/armbian/build/compare/main...EvilOlaf:build:rock2f
Ignore the rpi4b stuff, accidentially mixed branches.

@JuanEsf sunxi-edge is now on 6.18. You can add your patches for t527 there.

moved

But it is that extra money that is paying for the better support after the sale that you see in the RaspPi ecosystem.  All the other SBC vendors compete on low price and can't afford to provide any support after the sale and rely on open source volunteers to provide their long term support.

From https://github.com/armbian/build/pull/5056#issuecomment-1529793978
 

https://lore.kernel.org/linux-amlogic/20251127170908.14850-1-18255117159@163.com/T/#t
https://lore.kernel.org/linux-amlogic/176397825606.3590190.10935817124468233062.b4-ty@linaro.org/T/#t
 

When support for Raspberry Pis has been added there was no model 5 yet. With the intention to only support the flagship the board configuration was added as rpi4b.conf. Since then support was extended across all models from 3 and up. However renaming a board config file is an issue. I already had the idea to address that but gave up on it: https://github.com/armbian/build/pull/7881
 
tl;dr: rpi4b image will work on all models from 3 to 5. https://www.armbian.com/rpi4b/

No. This fork uses the name Armbian without permission and they do not contribute to the core development process. Instead they trick you into thinking that you'd get any sort of support here at our place whatsoever. 

not recommended for rockchip socs since it cannot handle the rather high baud rate of 1.5Mbaud. Use FT232, CH340 or CP2104 instead.

Armbian does not have a config for this board nor is it supported in some way.

The rk3588 soc has a fixed boot order which is spi, emmc, microsd, other I think. So if there is a boot loader found on spi it will ignore other options and try to boot from that. 
While Armbian uboot binaries on spi are instructed to check if there is a microsd card inserted and boot from that, vendors can (ab)use this circumstance to make it harder for other operation systems being used because tools like rkdevtool are necessary to get rid of it. If the spi is pre-flashed with crap, I guess that's why the step is necessary.

The rk3588 soc has a fixed boot order which is spi, emmc, microsd, other I think. So if there is a boot loader found on spi it will ignore other options and try to boot from that. 
While Armbian uboot binaries on spi are instructed to check if there is a microsd card inserted and boot from that, vendors can (ab)use this circumstance to make it harder for other operation systems being used because tools like rkdevtool are necessary to get rid of it. If the spi is pre-flashed with crap, I guess that's why the step is necessary.

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

merged. forum tag added.

I think this is wrong. The overlay needs to enabled if there is an m2 sata ssd connected. However in this case we connect a pcie device which connects to a chip that multiplexes the sata devices. tl;dr: try disabling this overlay

Yes
 
That's on us