Re: [yocto-patches] [rockchip][PATCH 1/2] rk3576: add initial support

Hi Martin,

On 6/23/26 2:16 PM, Martin Herren wrote:
> Hej Quentin,
> 
> On Monday, June 22nd, 2026 at 6:58 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]>
>>>
>>> Add basic SoC support for the Rockchip RK3576 using the mainline Linux
>>> kernel and Rockchip's binary TPL (DDR init), BL31 (TF-A) and BL32
>>> (OP-TEE) blobs from rkbin.
>>>
>>
> 
>> Did you actually boot a U-Boot with OP-TEE OS from rkbin? As far as I
>> know, this isn't supported by upstream U-Boot but maybe something's
>> changed /me shrugs. How did you test?
> 
> True, while I use rkbin's BL32 to build the image, it doesn't work, no OP-TEE support yet. Will clarify that.
> 

In Yocto? I don't think it's supported at the moment, c.f. 
https://lore.kernel.org/yocto-patches/[email protected]/ 
where I added support for building and packaging OP-TEE OS in U-Boot 
binary on Rockchip. I have yet to come back to it, but I'm not finding 
time to do it at the moment :(

>>> The RK3576 is an octa-core SoC (4x Cortex-A72 + 4x Cortex-A53) with a
>>> Mali-G52 MC3 GPU and a 6 TOPS NPU. It is the only currently supported
>>> rk3xxx SoC with a different RAM base address, and therefore uses a
>>> different UBOOT_ENTRYPOINT of 0x4a000000.
>>>
>>> NOTE: a bootable rk3576 currently requires a U-Boot fork. Upstream
>>> U-Boot has the rk3576 SoC support and board defconfigs, but is missing a
>>> critical fix for a BootROM issue that prevents loading boot images from
>>> SD card; see the WIP commit "rockchip: mkimage: Add rk3576 align and
>>> sd-card workaround" on Kwiboo's rk3576 branch.
>>>> Signed-off-by: Martin Herren <[email protected]>
>>> ---
>>>    conf/machine/include/rk3576.inc               | 24 +++++++++++++++++++
>>>    recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb   |  4 ++++
>>>    ...
>>> /rkbin/rockchip-rkbin-optee-os_git.bb      |  4 ++++
>>>    recipes-bsp/rkbin/rockchip-rkbin-tf-a_git.bb  |  3 +++
>>>    recipes-bsp/rkbin/rockchip-rkbin.inc          |  2 ++
>>>    .../trusted-firmware-a_%.bbappend             |  5 ++++
>>>    recipes-bsp/u-boot/u-boot_%.bbappend          |  5 ++++
>>>    7 files changed, 47 insertions(+)
>>>    create mode 100644 conf/machine/include/rk3576.inc
>>>
>>> diff --git a/conf/machine/include/rk3576.inc b/conf/machine/include/rk3576.inc
>>> new file mode 100644
>>> index 0000000..acb4249
>>> --- /dev/null
>>> +++ b/conf/machine/include/rk3576.inc
>>> @@ -0,0 +1,24 @@
>>> +SOC_FAMILY ?= "rk3576"
>>
> 
>> Please use =, there's no reason to override the SOC_FAMILY for any board
>> based on rk3576. If you took inspiration from RK3588S, it's because it's
>> a mess with RK3588S and RK3588 being covered by the same override for
>> convenience.
> 
> Yes, used rk3588(S) as a template as I believed it to be the most mature on the rk35xx serie. Will fix.

Possibly, but due to the RK3588S/RK3588 reuse, it may be more complex 
than needed. (Let's not talk about RK3582 and RK3583 until someone tries 
to add support for it :) ).

> 
>>> +MACHINEOVERRIDES =. "rk3576:"
>>
> 
>> I don't think you need this MACHINEOVERRIDES with the SOC_FAMILY above.
> 
> Same, inherited from 3588, will remove and retest.
> 
>>> +DEFAULTTUNE ?= "cortexa72-cortexa53-crypto"
>>> +
>>> +ROCKCHIP_CLOSED_TPL ?= "1"
>>> +
>>> +require conf/machine/include/rockchip-defaults.inc
>>> +require conf/machine/include/arm/armv8a/tune-cortexa72-cortexa53.inc
>>> +require conf/machine/include/rockchip-wic.inc
>>> +
>>> +SERIAL_CONSOLES = "1500000;ttyS0"
>>> +
>>
> 
>> Please keep this in the machine conf file, the debug output is not
>> specific to the SoC and thus shouldn't be defined in the SoC include file.
> 
> Used the other SoC's includes where it is overriden at SoC level as a reference. Can move it to machine conf.
> 

I *guess* it could be acceptable if if we losely set it (with ?=; and 
for this to work it needs to be set before the require 
rockchip-defaults.inc) such that the actually machine configuration can 
set it anywhere with an = sign and be done with it.

Considering the RK3568 hardware design guide says UART2 is the default 
UART for RK3568, I guess that is fine. See 
https://dl.xkwy2018.com/downloads/RK3568/RK356X/Hardware/Rockchip_RK3568_Hardware_Design_Guide_V1.2_EN.pdf

>>> +KBUILD_DEFCONFIG ?= "defconfig"
>>> +
>>> +PREFERRED_PROVIDER_trusted-firmware-a
>>> = "rockchip-rkbin-tf-a"
>>
> 
>> Can you use ?= here? Upstream TF-A supports RK3576 since version 2.13
>> which is available in meta-arm already.
> 
> Will fix, also the next one.
> 
>>> +PREFERRED_PROVIDER_optee-os = "rockchip-rkbin-optee-os"
>>> +
>>
> 
>> Same here. OP-TEE OS just gained support for RK3576, see commit
>> bddd9f2ea837 ("plat-rockchip: add support for RK3576"). No release yet
>> though so that's fine I guess.
>>
> 
>>> +UBOOT_SUFFIX ?= "itb"
>>> +UBOOT_ENTRYPOINT ?= "0x4a000000"
>>> +
>>
> 
>> Why this address specifically? We use 0x06000000 for all other SoCs and
>> the DRAM address start at 0 for them. Considering the RK3576 starts DRAM
>> at 0x40000000, why not use the same offset and have it at
>>
> 
>> 0x46000000
>>
> 
>> ?
>>
> 
>> At the same time, we default to 0x40800000 for RK3576 in upstream U-Boot
>> for the load/entry properties (c.f. CONFIG_TEXT_BASE in
>> arch/arm/rockchip-u-boot.dts).
> 
> Used the value of kernel_comp_addr_r taken from u-boot's include/configs/rk3576_common.h as a reference.
> As for other boards it is also defined as 0x0a000000 in u-boot and 0x06000000 is used in Yocto, i will update to 0x46000000 to have a coherent offset and retest.
> 

Yeah, maybe something I can have a look at when I have some spare time :)

>>> +TFA_PLATFORM = "rk3576"
>>> +TFA_BUILD_TARGET = "bl31"
>>> +
>>> +ENABLE_STATELESS_VPU_GST ?= "1"
>>> diff --git a/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb b/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
>>> index 7f1e820..7427f57 100644
>>> --- a/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
>>> +++ b/recipes-bsp/rkbin/rockchip-rkbin-ddr_git.bb
>>> @@ -14,6 +14,10 @@ RKBIN_BINVERS:rk3568 ?= "v1.23"
>>>    RKBIN_BINFILE:rk3568 ?= "rk3568_ddr_1560MHz_${RKBIN_BINVERS}.bin"
>>>    RKBIN_DEPLOY_FILENAME:rk3568 ?= "ddr-rk3568.bin"
>>>
>>> +RKBIN_BINVERS:rk3576 ?= "v1.09"
>>> +RKBIN_BINFILE:rk3576 ?= "rk3576_ddr_lp4_2112MHz_lp5_2736MHz_${RKBIN_BINVERS}.bin"
>>> +RKBIN_DEPLOY_FILENAME:rk3576 ?= "ddr-rk3576.bin"
>>> +
>>>    RKBIN_BINVERS:rk3588s ?= "v1.18"
>>>    RKBIN_BINFILE:rk3588s ?= "rk3588_ddr_lp4_2112MHz_lp5_2400MHz_${RKBIN_BINVERS}.bin"
>>>    RKBIN_DEPLOY_FILENAME:rk3588s ?= "ddr-rk3588.bin"
>>> diff -
>>> -git a/recipes-bsp/rkbin/rockchip-rkbin-optee-os_git.bb b/recipes-bsp/rkbin/rockchip-rkbin-optee-os_git.bb
>>> index 0f3c927..35a102e 100644
>>> --- a/recipes-bsp/rkbin/rockchip-rkbin-optee-os_git.bb
>>> +++ b/recipes-bsp/rkbin/rockchip-rkbin-optee-os_git.bb
>>> @@ -19,6 +19,10 @@ RKBIN_BINVERS:rk3568 ?= "${RKBIN_BINVERS_RK356x}"
>>>    RKBIN_BINFILE:rk3568 ?= "rk3568_bl32_${RKBIN_BINVERS}.bin"
>>>    RKBIN_DEPLOY_FILENAME:rk3568 ?= "tee-rk3568.bin"
>>>
>>> +RKBIN_BINVERS:rk3576 ?= "v1.05"
>>> +RKBIN_BINFILE:rk3576 ?= "rk3576_bl32_${RKBIN_BINVERS}.bin"
>>> +RKBIN_DEPLOY_FILENAME:rk3576 ?= "tee-rk3576.bin"
>>> +
>>>    RKBIN_BINVERS:rk3588s ?= "v1.19"
>>>    RKBIN_BINFILE:rk3588s ?= "rk3588_bl32_${RKBIN_BINVERS}.bin"
>>>    RKBIN_DEPLOY_FILENAME:rk3588s ?= "tee-rk3588.bin"
>>> diff --git a/recipes-bsp/rkbin/rockchip-rkbin-tf-a_git.bb b/recipes-bsp/rkbin/rockchip-rkbin-tf-a_git.bb
>>> index ece5faa..39cc7ee 100644
>>> --- a/recipes-bsp/rkbin/rockchip-rkbin-tf-a_git.bb
>>> +++ b/recipes-bsp/rkbin/rockchip-rkbin-tf-a_git.bb
>>> @@ -21,5 +21,8 @@ RKBIN_B
>>> INFILE:rk3566 ?= "rk3568_bl31_${RKBIN_BINVERS}.elf"
>>>    RKBIN_BINVERS:rk3568 ?= "${RKBIN_BINVERS_RK356x}"
>>>    RKBIN_BINFILE:rk3568 ?= "rk3568_bl31_${RKBIN_BINVERS}.elf"
>>>
>>> +RKBIN_BINVERS:rk3576 ?= "v1.15"
>>> +RKBIN_BINFILE:rk3576 ?= "rk3576_bl31_${RKBIN_BINVERS}.elf"
>>> +
>>
> 
>> We have much newer ddrbin, bl31 and bl32 in current master of rkbin,
>> should we consider updating? I haven't looked at the various changelogs
>> but maybe it's fixing important stuff.
> 
> Didn't look yet. Tried to be the least invasive possible so used the ones at the same commit as the other SoCs. Can try to override the SRC_REV for this SoC to get the latest and try.
> 

That's fine with me (if the SD card issue isn't also fixed in newer 
revisions of rkbin git repo). We would need a separate (from RK3576 
support) patch for bumping everything so that we can revert it if we 
need to.

>>>    RKBIN_BINVERS:rk3588s ?= "v1.48"
>>>    RKBIN_BINFILE:rk3588s ?= "rk3588_bl31_${RKBIN_BINVERS}.elf"
>>> diff --git a/recipes-bsp/rkbin/rockchip-rkbin.inc b/recipes-bsp/rkbin/rockchip-rkbin.inc
>>> index 9ddd54f..a276aa6 100644
>>> --- a/recipes-bsp/rkbin/rockchip-rkbin.inc
>>> +++ b/recipes-bsp/rkbin/rockchip-rkbin.inc
>>> @@ -11,6 +11,7 @@ COMPATIBLE_MACHINE = "^$"
>>>    COMPATIBLE_MACHINE:rk3308 = "rk3308"
>>>    COMPATIBLE_MACHINE:rk3566 = "rk3566"
>>>    COMPATIBLE_MACHINE:rk3568 = "rk3568"
>>> +COMPATIBLE_MACHINE:rk3576 = "rk3576"
>>>    COMPATIBLE_MACHINE:rk3588s = "rk3588s"
>>>
>>>    PACKAGE_ARCH = "${MACHINE_ARCH}"
>>> @@ -26,6 +27,7 @@ ALLOW_EMPTY:${PN} = "1"
>>>    RKBIN_BINDIR:rk3308 ?= "bin/rk33/"
>>>    RKBIN_BINDIR:rk3566 ?= "bin/rk35/"
>>>    RKBIN_BINDIR:rk3568 ?= "bin/r
>>> k35/"
>>> +RKBIN_BINDIR:rk3576 ?= "bin/rk35/"
>>>    RKBIN_BINDIR:rk3588s ?= "bin/rk35/"
>>>
>>>    do_deploy() {
>>> diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
>>> index 4c7fc3c..4e7265b 100644
>>> --- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
>>> +++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
>>> @@ -7,6 +7,7 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"
>>>    COMPATIBLE_MACHINE:append:px30 = "|px30"
>>>    COMPATIBLE_MACHINE:append:rk3566 = "|rk3566"
>>>    COMPATIBLE_MACHINE:append:rk3568 = "|rk3568"
>>> +COMPATIBLE_MACHINE:append:rk3576 = "|rk3576"
>>>    COMPATIBLE_MACHINE:append:rk3588s = "|rk3588s"
>>>
>>>    # code bloats with clang and results in error below now
>>> @@ -35,6 +36,10 @@ fixup_baudrate:rk3568() {
>>>    	sed -i "s/#define FPGA_BAUDRATE\s\+.*/#define FPGA_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3568/rk3568_def.h
>>>    }
>>>
>>> +fixup_baudrate:rk3576() {
>>> +	sed -i "s/#define RK_DBG_UART_BA
>>> UDRATE\s\+.*/#define RK_DBG_UART_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3576/rk3576_def.h
>>> +}
>>> +
>>>    fixup_baudrate:rk3588s() {
>>>    	sed -i "s/#define RK_DBG_UART_BAUDRATE\s\+.*/#define RK_DBG_UART_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3588/rk3588_def.h
>>>    }
>>> diff --git a/recipes-bsp/u-boot/u-boot_%.bbappend b/recipes-bsp/u-boot/u-boot_%.bbappend
>>> index 08e1730..ddb6fd2 100644
>>> --- a/recipes-bsp/u-boot/u-boot_%.bbappend
>>> +++ b/recipes-bsp/u-boot/u-boot_%.bbappend
>>> @@ -4,6 +4,11 @@ FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
>>>
>>>    SRC_URI:append:rk-u-boot-env = " file://rockchip-enable-environment-mmc.cfg"
>>>
>>> +SRC_URI:rk3576 = " \
>>> +    git://source.denx.de/u-boot/contributors/kwiboo/u-boot.git;protocol=https;branch=rk3576 \
>>> +"
>>> +SRCREV:rk3576 = "04e6417226f50e4e3cb04272280922eb425c18ab"
>>> +
>>
> 
>> This is a no, sorry.
>>
> 
>> We do not accept non-upstream fork in meta-rockchip.
>>
> 
>> And even if we did, it should be its own recipe and not piggy-backing on
>> the upstream U-Boot recipe which reports a different version than the
>> one in Jonas (Kwiboo)'s current branch.
>>
> 
>> Jonas may rebase at his liking and we wouldn't be able to build this
>> anymore. It happened in the past and likely would again.
> 
> Was afraid this won't pass, even the same seems to have been done in the past for other boards (rock 3 ?).
> 

Yes, and it's been an issue a few times already :) Hence why we're 
trying to learn from our mistakes.

1cdcb4960374 ("u-boot: use upstream for radxa-zero-3{e|w}")

Removed it in master, and you can see that someone sent a patch (for 
another branch I'm assuming where this commit isn't present) to fix the 
build issue.

We also used to use some linux-next tag and the tag and/or commit 
disappeared a few times.

b2470c03340c ("linux-torvalds-next: SRCREV with nobranch")
ce1ce3465a53 ("linux-torvalds-next: use tag")

>> It seems you have found the commit that fixes the issue for you, so
>> maybe we should include this patch on top of upstream U-Boot here as a
>> ".patch" in SRC_URI. This would be acceptable to me.
> 
> I started trying only to backport the last commit, unfortunately it depends on a bunch of previous ones. Thus my switching completely to this fork.

Ah yes, likely the mkimage patches at the very least.

> Now that it boots will try to cleanup my patch to use the upstream u-boot at 2026.04 with a minimal patch set. If too much, maybe worth to postpone this patch and wait u-boot 2026.07 and until yocto switches officially to it.
> 
> A quick analysis shows it might require 9 patches. The WiP patch, 6 patches submitted without being merged yet and 2 already merged in upstream (not in v2026.04).
> 

Would appreciate if you have the links so I can have a look and maybe 
help push this in U-Boot.

>> I vaguely recall this was somehow related to boost DDR blob... Jonas
>> hasn't sent the patch yet to the mailing list so I'm assuming he's still
>> unhappy with it (or is lacking time like most of us :) ).
> 
> Yes, the main issue is this boost.bin plus the prerequisites to bundle it into the image.
> 
>> Wondering if
>> an update of the DDR blob from rkbin would make this work? Would this be
>> something you could try? Change SRC_URI to ecb4fcbe954e ("README:
>> Update" and update the version numbers for rk3576 to point at the right one.
> 
> Yes, this is something i can try. Although as with the latest ddr bins there is still a boost available, it is probably still required.
> 

Rockchip isn't known for cleaning up their repos so it could be a 
leftover. Also, they mention in the introducing commit log that boost is 
for accelerating UFS boot speed, so doesn't seem so much related to SD 
card (but eh, could be).
I unfortunately do not have an RK3576 device so cannot test.

Please note that I'm not a maintainer of meta-rockchip, only Trevor is.

Cheers,
Quentin