I’m trying to get DietPi flashed to my Radxa RK3566 based Zero 3W but have a hard time following the instructions. I’m on Linux.
According to rkdeveloptool | Radxa Docs I should use rkdeveloptool and the mentioned images for SPI U-Boot and Loader, so what I do is:
$ sudo rkdeveloptool db rk356x_spl_loader_ddr1056_v1.12.109_no_check_todly.bin
[sudo] password for ***:
Downloading bootloader succeeded.
(rk356x_spl_loader_ddr1056_v1.12.109_no_check_todly.bin is “recommended”)
Then
$ sudo rkdeveloptool wl 0 DietPi_RadxaZERO3-ARMv8-Bookworm.img
Write LBA from file (100%)
If I then restart the SBC using sudo rkdeveloptool rd, the Zero reboots and starts flashing two short. I haven’t hooked up the Zero to a monitor yet, but it doesn’t look like it’s booting?
Also, when I ask rkdeveloptool list-partitions in Maskrom mode, it says
$ sudo rkdeveloptool list-partitions
Read GPT failed!
Read parameter failed!
Not found any partition table!
Which looks like a failure to flash any filesystem?
I’ve been reading up on Image | Radxa ZERO 3 · Issue #7024 · MichaIng/DietPi · GitHub and I was expecting the current DietPi Zero image dowload to be up-to-date with the latest findings on that issue?
What am I doing wrong here?
To be true, I never managed to get something working with rkdeveloptool either. I was trying it with a NanoPi R5S IIRC, with theirs as well as Radxa’s version of rkdeveloptool. The Windows GUI (in both cases) has and requires to fill some parts which just do not make any sense. Most likely in FriendlyELEC board case it is expecting the image to have 8 partitions like their images do, with each bootloader segment, boot environment, kernel image etc each on an own partition without filesystem. For the kernel this meant no regular way to access and upgrade. Maybe officially Radxa images are similarly complex partitioned?
Possibly this has something to do with it, though weird is that our image does have a GPT partiton table as well, so even that it has a single partiton only, at enough offset to leave room for the bootloader, no idea how reading that one can fail: the GPT headers are (must be) located always at the exact same point at the start of the drive. I cannot test it, as I have a Radxa ZERO 3E only, which has no onboard eMMC. Will retry with another Rockchip SBC with onboard eMMC when I find time.
For now, even that it is somewhat annoying double work: flash and boot an SD card with DietPi or something else, then flash the DietPi image from there to onboard eMMC.
Btw in the GitHub issue you linked using rkdeveloptool was never discussed. There was an issue with our dietpi-imager tool when dealing with images with enforced partition alignment, but it is unrelated and has been solved last year.
Is dd’ing the dietPie image to eMMC after booting from SD enough or do I still need to flash a bootloader at some point?
For future reference: Moving a running DietPi system to a USB stick/disk or an onboard eMMC – DietPi Blog
usually should be fine to dd the image and check if it is booting well.
Right, the bootloader is part of the image, so this is generally never required. Incase of rkdeveloptool I am also not sure why fulling that DDR blob is needed, probably the tool itself somehow needs it to initiate the board enough to make the eMMC available. But it has nothing to do with whether a flashed image can boot or not.
1 Like