Re: [yocto-patches] [rockchip][PATCH 2/2] rock-4d: add initial support

Hi Martin,

On 6/24/26 12:20 AM, Martin Herren wrote:
> Hi Quentin,
> 
> On Monday, June 22nd, 2026 at 7:19 PM, Quentin Schulz via lists.yoctoproject.org <[email protected]> wrote:
> 
>> Hi Martin,
>>
> 
>> On 6/21/26 11:19 PM, Martin Herren via lists.yoctoproject.org wrote:
>>> From: Martin Herren <[email protected]>
>>>
>>> The Radxa ROCK 4D is a compact single-board computer (SBC) featuring
>>> numerous top-tier functions, features, and expansion options.
>>>
>>> Equipped with the Rockchip RK3576 SoC, the ROCK 4D boasts an octa-core
>>> CPU (4x Cortex-A72 + 4x Cortex-A53), Mali-G52 MC3 GPU, and a 6 TOPS NPU,
>>> making it ideal for AI and multimedia tasks.
>>>
>>> 	http://radxa.com/products/rock4/4d
>>>
>>> tech specs:
>>> - Rockchip RK3576 (4x Arm Cortex-A72 + 4x Cortex-A53)
>>> - Arm Mali-G52 MC3 GPU
>>> - DDR5 RAM (2/4/8/16 GB)
>>> - uSD, eMMC/UFS module connector
>>> - GbE
>>> - 1x USB-C (power delivery only)
>>> - USB 3.0: 1x Type-A HOST, 1x Type-A OTG/HOST
>>> - USB 2.0: 2x Type-A HOST
>>> - 1x HDMI 2.1
>>> - 1x MIPI CSI camera port
>>> - 40-pin GPIO (uart, spi, i2c, pcm/i2s, pwm, gpio)
>>>
>>> The ROCK 4D is the only board of the Rock 4 series using the new RK3576
>>> SoC instead of the RK3399 used in the rest of the Rock 4x serie.
>>>
>>> NOTES:
>>> Due to the RK3576 boot ROM limitations, the bootloader cannot be
>>> loaded
>>> from the SD card; it must be extracted from the wic image and
>>> flashed to the SPI flash. The kernel and rootfs then boot from the SD
>>> card. See the "rk3576 booting" note in the README for details.
>>>
>>
> 
>> I'm confused, if it doesn't work, what is the purpose of using Jonas's
>> U-Boot fork?
> 
> With Jonas' fork it works when flashed to the SPI. With upstream it won't work, neither on SD nor SPI.
> 

Jonas explicitly stated he tested SPI booting in the introducing commit: 
https://lore.kernel.org/u-boot/[email protected]/ 
so either it got broken since (not impossible), there's a hardware issue 
or misconfiguring/misflashing U-Boot. Can you tell us which binary (how 
you're building it) you're flashing and how (commands, offsets, etc...)? 
At some point you may be able to get better help from the U-Boot 
community directly where we currently have at least two people 
interested in RK3576, either from IRC on #u-boot at libera.chat or on 
the mailing list (rather the latter).

>>> Ethernet is only partially working, mostly in degraded 100 or even 10
>>> Mbps mode or sometimes not at all. Investigations are still ongoing and
>>> if found a fix will be submitted in a future patch.
>>>
>>> Wifi is not yet working, requires an out-of-tree kernel driver. Work on
>>> this will be done on a separate future patch.
>>>
>>> Signed-off-by: Martin Herren <[email protected]>
>>> ---
>>>    README                                  | 17 +++++++++++++++++
>>>    conf/machine/rock-4d.conf               | 11 +++++++++++
>>>    recipes-kernel/linux/linux-rockchip.inc |  1 +
>>>    3 files changed, 29 insertions(+)
>>>    create mode 100644 conf/machine/rock-4d.conf
>>>
>>> diff --git a/README b/README
>>> index c2697d1..8192284 100644
>>> --- a/README
>>> +++ b/README
>>> @@ -39,6 +39,7 @@ Status of supported boards:
>>>    			roc-rk3328-cc
>>>    			roc
>>> k-3a
>>>    			rock-4c-plus
>>> +			rock-4d
>>>    			rock-5a
>>>    			rock-5b
>>>    			rock-pi-4a
>>> @@ -122,6 +123,22 @@ Notes:
>>>
>>>    	in the configuration (e.g. conf/local.conf).
>>>
>>> +  rk3576 booting:
>>> +	The RK3576 boot ROM cannot load the bootloader from the SD card.
>>
> 
>> The datasheet claims otherwise.
>>
> 
>> It could simply be that the board doesn't allow you to select booting
>> from SD card first. On RK35xx family, the SARADC channel 0 is used by
>> the BootROM to select which devices to try loading the bootloader from.
>> I'm thinking either you already have something valid on SPI and/or
>> eMMC/UFS and the board starts from there, or the board is configured in
>> such a way that the ADC selects a configuration for which the BootROM
>> will not attempt to load from SD card. I don't have a reference design
>> for the RK3576 and Radxa's schematics for the Rock4D don't provide this
>> table so your guess is as good as mine as to which values select which
>> devices. There's some weird circuitry on Rock4D schematics though on
>> that channel, c.f. page 11.
> 
> Yes it is strange. The board ships with with the vendor's bootloader already flashed in the SPI.
> This is different from like the Rock 5B with a rk3588 where the board comes with empty SPI. Flashing the bootloader is only needed when booting from NVMe for example on the 5B.
> 

I'm assuming you meant booting the Linux kernel here as I don't think 
the RK3588 BootROM supports booting from an NVMe.

> With the 4D the preinstalled vendor bootloader already crashes when parsing the GPT from the Yocto image.

Yeah, Rockchip U-Boot is an absolute joke.

> Erasing the SPI won't boot, neither with the vendor bootloader nor upstream nor Jonas' on the SD card.
> So it seems it can only boot from SPI.
> 

Seems like Jonas agrees with you: 
https://lore.kernel.org/u-boot/[email protected]/

"""
ROCK 4D boards with SPI Flash is configured to boot from 
FSPI0->UFS->USB, or directly from USB when the MASKROM button is 
pressed, booting directly from SD-card is not possible on these boards.
"""

Can you please add a small word about this in the README? We should 
probably document this in U-Boot as well.

> Didn't try with an UFS, don't have any. eMMC seems mutualy exclusive with the SPI according to Radxa on their support forum.
> 

Yes, looking at the schematics, the SPI and eMMC signals are routed to 
the same pins on the SoC.

>>> +	For rk3576-based boards (e.g. the rock-4d) the bootloader must be
>>> +	extracted from the wic image and flashed to the SPI flash; the
>>> +	kernel and rootfs then boot from the SD card.
>>> +
>>> +	To extract the SPI bootloader region (first 16 MiB) from a wic
>>> +	image:
>>> +
>>> +		dd if=<image>.wic of=spi.bin bs=1M count=16
>>> +
>>
> 
>> Please just make sure idbloader.img and u-boot.itb are in the deploy
>> directory (or even better, u-boot-rockchip-spi.bin which contains both
>> with u-boot.itb at the right offset already) and tell the user to flash
>> those binaries on SPI at a specific offset. I believe you're also
>> copying the partition table, which doesn't make sense on the SPI flash
>> (at least not that partition table since there's for sure not enough
>> room for the full system on it).
> 
> That's sounds much cleaner, will need to look how to do it. Having a clean u-boot-rockchip-spi.bin would be useful for some other boards like the Rock 5B as wel.
> 

Note that I don't know if the plumbing exists to do such a thing as I 
haven't looked into it yet.

Cheers,
Quentin