Hi Alexey,
On 6/1/2026 11:52 AM, Alexey Charkov wrote:
> On Sun, May 31, 2026 at 10:26 PM Simon Glass <[email protected]> wrote:
>>
>> Hi Alexey,
>>
>> On Mon, 25 May 2026 at 01:57, Alexey Charkov <[email protected]> wrote:
>>>
>>> On Sat, May 23, 2026 at 4:41 AM Simon Glass <[email protected]> wrote:
>>>>
>>>> Hi Alexey,
>>>>
>>>> On Fri, 22 May 2026 at 00:24, Alexey Charkov <[email protected]> wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> On Fri, May 22, 2026 at 3:22 AM Simon Glass <[email protected]> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am trying to make Friendlyelec NanoPi M5 (RK3576) work with
>>>>>> mainline. I found the note about needing a workaround so have tried
>>>>>> kwiboo/rk3576 at
>>>>>>
>>>>>> https://github.com/Kwiboo/u-boot-rockchip.git
>>>>>>
>>>>>> I am building like this:
>>>>>>
>>>>>> $
>>>>>> ROCKCHIP_TPL=~/dev/rkbin/bin/rk35/rk3576_ddr_lp4_2112MHz_lp5_2736MHz_v1.09.bin
>>>>>> BL31=~/dev/rkbin/bin/rk35/rk3576_bl31_v1.20.elf um build
>>>>>> nanopi-m5-rk3576
>>>>>
>>>>> FWIW, upstream TF-A master branch works well as BL31 on RK3576, though
>>>>> it's most probably unrelated to the issue you're seeing
>>>>
>>>> OK, thanks.
>>>>
>>>>>
>>>>>> Image 'simple-bin' is missing optional external blobs but is still
>>>>>> functional: tee-os
>>>>>>
>>>>>> /binman/simple-bin/fit/images/@tee-SEQ/tee-os (tee-os):
>>>>>> See the documentation for your board. You may need to build Open
>>>>>> Portable
>>>>>> Trusted Execution Environment (OP-TEE) and build with
>>>>>> TEE=/path/to/tee.bin
>>>>>>
>>>>>> Image 'simple-bin-spi' is missing optional external blobs but is still
>>>>>> functional: tee-os
>>>>>>
>>>>>> /binman/simple-bin-spi/fit/images/@tee-SEQ/tee-os (tee-os):
>>>>>> See the documentation for your board. You may need to build Open
>>>>>> Portable
>>>>>> Trusted Execution Environment (OP-TEE) and build with
>>>>>> TEE=/path/to/tee.bin
>>>>>>
>>>>>> $ dd if=/tmp/b/nanopi-m5-rk3576/u-boot-rockchip.bin of=/dev/sda seek=64
>>>>>> 18579+0 records in
>>>>>> 18579+0 records out
>>>>>> 9512448 bytes (9.5 MB, 9.1 MiB) copied, 1.99658 s, 4.8 MB/s
>>>>>>
>>>>>> I get no serial output at all booting from SD card. Is there a special
>>>>>> trick I am missing? I have confirmed that the Alpine Linux image works
>>>>>> OK.
>>>>>
>>>>> Dumb question: did you flip the switch on the back side of the board
>>>>> from FSPI1 to UFS/SD?
>>>>
>>>> Yes it is set to UFS/SC.
>>>>>
>>>>> If yes, then having no serial output at all most likely means the
>>>>> boost.bin trick from Jonas' WIP patch didn't apply, because the DDR
>>>>> trainer unconditionally spits out some logs on the debug UART during
>>>>> early init.
>>>>>
>>>>> The SD card might also be finicky, so if you happen to have an SPI
>>>>> flash equipped board then you can flash U-boot there instead via
>>>>> Maskrom. Just remove all other storage, connect a USB A-A cable to the
>>>>> top USB 3.0 port, and power it up while holding the maskrom button.
>>>>
>>>> I am not sure how to power the board other than through the
>>>>>
>>>>> Then:
>>>>> rockusb download-boot rk3576_loader_fspi1_v1.13.100.bin
>>>>> # note the zero below, because u-boot-rockchip-spi.bin already has a
>>>>> 64-sector offset baked in, unlike u-boot-rockchip.bin:
>>>>> rockusb write-file 0 u-boot-rockchip-spi.bin
>>>>> rockusb reset-device
>>>>
>>>> With this I was able to get it to SPL:
>>>>
>>>> DDR 2f85f4b2d4 cym 24/11/07-19:07:28,fwver: v1.09
>>>> In
>>>> ch0 ttot6
>>>> ch1 ttot6
>>>> ch0 ttot7
>>>> LPDDR5, 2736MHz
>>>> channel[0] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=1536MB
>>>> ch1 ttot7
>>>> channel[1] BW=16 Col=10 Bk=16 CS0 Row=16 CS=1 Die BW=16 Size=1536MB
>>>> Manufacturer ID:0xff
>>>> CH0 RX Vref:24.1%, RX DQS Vref:29.6%, TX Vref:19.0%,0.0%
>>>> DQ roc:
>>>> p4 n2, p6 n7, p5 n0, p1 n0, p0 n0, p0 n4, p3 n0, p7 n0, p3 n0,
>>>> p4 n2, p5 n0, p2 n2, p0 n2, p7 n0, p2 n0, p6 n0, p7 n0, p6 n4,
>>>>
>>>> DQ rds:l0 l0 h1 l0 l0 l0 l0 l0, l0 l0 h1 l0 l0 l0 l0 l0
>>>> DQS roc: p2, n0, p1, n0
>>>>
>>>> CH1 RX Vref:25.7%, RX DQS Vref:29.2%, TX Vref:20.0%,0.0%
>>>> DQ roc:
>>>> p2 n0, p7 n0, p2 n0, p1 n0, p2 n0, p0 n1, p3 n0, p5 n0, p7 n0,
>>>> p6 n0, p3 n2, p3 n0, p2 n0, p2 n0, p6 n0, p0 n0, p0 n2, p0 n0,
>>>>
>>>> DQ rds:l0 h2 l0 l0 l0 l0 l0 h1, l0 l0 l0 l0 h1 l0 h1 l0
>>>> DQS roc: p2, n0, p2, n0
>>>>
>>>> stride=0x3, ddr_config=0x2
>>>> hash bank_mask0-3 0x0 0x2100 0x44200 0x88400, rank_mask0 0x0
>>>> change to F1: 534MHz
>>>> ch0 ttot6
>>>> ch1 ttot6
>>>> change to F2: 1320MHz
>>>> ch0 ttot8
>>>> ch1 ttot8
>>>> change to F3: 1968MHz
>>>> ch0 ttot6
>>>> ch1 ttot6
>>>> change to F0: 2736MHz
>>>> ch0 ttot7
>>>> ch1 ttot7
>>>> out
>>>>
>>>> U-Boot SPL 2026.01-00014-gf6f1066339a5 (May 22 2026 - 18:32:58 -0600)
>>>> Trying to boot from MMC1
>>>> Card did not respond to voltage select! : -110
>>>> spl: mmc init failed with error: -95
>>>> Error: -95
>>>> SPL: Unsupported Boot Device!
>>>> SPL: failed to boot from all boot devices
>>>> ### ERROR ### Please RESET the board ###
>>>>
>>>>
>>>> It seems to boot from SPI but then try to switch to MMC?
>>>
>>> Sifting through my local tree I also noticed I've got the following
>>> patch to set the pin config for SPI flash on NanoPi M5:
>>>
>>> https://github.com/flipperdevices/u-boot/commit/ffb0d6c9b4893d6a8c2fe51efc3dd5914857615e
>>>
>>> Would you mind giving it a try?
>>>
>>> The node itself and its properties are already in the upstream DTS, so
>>> it _shouldn't_ really be required, but maybe the bootph-* markers
>>> didn't propagate for me as-is and I didn't have the willpower to
>>> investigate further :)
>>>
>>>> I also found that if I 'dd if=/tmp/image of=/dev/sda count=2000' from
>>>> the good Alpine image, it ends up in the U-Boot I built (although of
>>>> course I have not built the earlier parts).
>>>
>>> Another way to get it to boot without relying on a particular storage
>>> configuration or the prebuilt image is to load an upstream binary
>>> directly to RAM over Maskrom:
>>>
>>> export BL31=[...] ROCKCHIP_TPL=[...]
>>> make nanopi-m5-rk3576_defconfig rockchip-ramboot.config
>>> make -j$(nproc)
>>> rockusb download-sram u-boot-rockchip-usb471.bin
>>> rockusb download-ddr u-boot-rockchip-usb472.bin
>>>
>>> SPI boot is supposed to work fine though. Did you use the
>>> u-boot-rockchip-spi.bin or u-boot-rockchip.bin image?
>>>
>>>>> Loader binary can be assembled from rkbin blobs, or alternatively
>>>>> taken from e.g. here:
>>>>> https://dl-linux-images.flipp.dev/u-boot/u%3D1afdc52186635bb599642064ee7c23f539b73e3c/rk%3D495eec7a93220b1269e915e684c5667250462a3d__tfa%3Dfc3691b5022abd9feba6c37330005b7437cccf9f/nanopi-m5/rk3576_loader_fspi1_v1.13.100.bin
>>>>>
>>>>> rockusb tool: cargo install rockusb --example rockusb --features=nusb
>>>>
>>>> Thanks very much for taking the time to help with this!
>>>
>>> Always welcome!
>>
>> It was booting from UFS, but since U-Boot SPL didn't have it enabled,
>> it didn't complete.
>
> Indeed, the boot-from-UFS series [1] is still pending Kever's
> attention for the Rockchip-specific part. Neil merged the common UFS
> bits a while ago, and I'm using it all the time on several RK3576
> boards.
>
> [1]
> https://lore.kernel.org/u-boot/[email protected]/
>
>> So I've erased that and am using your method of booting over USB - BTW
>> it is very slow, doesn't seem to use bulk mode.
>
> I think there was some peculiarity about the boot ROM taking a while
> to verify the checksum of the usb472 image, rather than the USB
> transfer itself taking long. It might need further investigation.
The very very slow boot time using ramboot on rk3576, around 10 min vs
30 seconds, is due to changes done in commit c6bba31dbdd4 ("rockchip:
spl-boot-order: Defer probe of boot device").
The delay of probe done in that commit correctly result in clk driver
not being probed in SPL when running ramboot, and because no clk driver
is probed, cores run at very slow rates until OS change core rates :-)
My ci branch contains a commit to fix this, and other, I just need to
find some free time before it reaches the list, see commit "WIP:
rockchip: clk: init clocks in spl for rk3576" at [2].
[2] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/ci
Regards,
Jonas
>
>> The board is now working in my lab!
>>
>> Thanks again.
>
> Sounds great! Happy to help.
>
> Best regards,
> Alexey
