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

Martin Herren <[email protected]> Tue, 23 Jun 2026 12:16:42 +0000
Newsgroups	org.yoctoproject.lists.yocto-patches
Message-ID	<Pq9-9AjU_eNySwkfd928TgfA7sjgmLxhBfF5DyJsQvov-HfOOIUirWuTCsRJND4WsDiLRfuUvqQK-4Q86-ugykRbeT0qcfWW50gJhuKzA4A=@on-the-web.ch>
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.

> > 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.

> > +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.

> > +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.

> > +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.

> >   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 ?).

> 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.
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).

> 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.

> Cheers,
> Quentin

Cheers,

Martin
signature.asc (application/pgp-signature, 343 B)