Hi Jonas, On Mon, 8 Jun 2026 at 15:45, Jonas Karlman <[email protected]> wrote: > > Hi Alexey, > > On 6/8/2026 3:56 PM, Alexey Charkov wrote: > > On Mon, Jun 1, 2026 at 3:45 PM Jonas Karlman <[email protected]> wrote: > >> > >> 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]. > > > > Hi Jonas, it does indeed look like painfully slow clocks, but > > cherry-picking this patch alone doesn't seem to turn the tide for me. > > It still takes about 6 minutes from the moment `rockusb download-ddr` > > completes until there is any SPL output on the console. > > > > Is there any other change I need to apply for it to take effect? > > 6 minutes sounds very long and strange, is there some issue with rockusb? > > I did a quick test in my labgrid using close to v2026.07-rc3 + that > patch and loading usb471.bin + usb472.bin takes around 2.1 seconds, and > around 13-15 seconds from DDR init until SPL banner is printed. > > INFO StepLogger: → RKUSBMaskromDriver.load(filename=None) > INFO SSHConnection(h: Created new SSH connection to noble > INFO ManagedFile(loc: Synchronizing > /srv/u-boot/rk3576-sige5/u-boot-rockchip-usb471.bin to noble > INFO ManagedFile(loc: Synchronizing > /srv/u-boot/rk3576-sige5/u-boot-rockchip-usb472.bin to noble > INFO StepLogger: ← RKUSBMaskromDriver.load() [2.134s]
Yes, this matches what I see. > > No real change there, what took long before that commit was starting > Linux, kernel boot could take around 5-10 minutes, now just 15-30 > seconds, if I trust dmesg timestamps. > > I use labgrid PR1721 [3] to ramboot into my boards, when working on that > I noticed that use of pre-calculated crc tables helped loading speed a > lot, maybe rockusb is at fault or help slow things down for you? > > My test run above was on a ArmSoM Sige5 board. > > [3] https://github.com/labgrid-project/labgrid/pull/1721 > > Regards, > Jonas > > > > >> [2] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/ci > > > > Thanks a lot, > > Alexey > Regards, Simon
