[PATCH 4/4] rockchip: rock5b-rk3588: Add support for ROCK 5B+

[Sebastian Reichel]

Hi,

On Tue, Jul 15, 2025 at 08:26:27PM +0200, Jonas Karlman wrote:
> On 7/15/2025 6:48 PM, Sebastian Reichel wrote:
> > On Mon, Jul 14, 2025 at 10:34:01PM +0000, Jonas Karlman wrote:
> >> Include FDTs for both ROCK 5B and 5B+ in the FIT and add board
> >> selection code to load the 5B+ FDT when the ADC channel 5 value is
> >> close to 4095.
> > 
> > The Rock 5B uses the same channel and starts with 0V for revision A
> > and jumps in 0.3V steps for newer revisions. So technically a Rock
> > 5B revision H would be detected as Rock 5B+ with this code. IDK if
> > Radxa will ever release such a board. But I have an alternative
> > implementation, which does the board detection via the DDR memory
> > type (Rock 5B = LPDDR4, Rock 5B+ = LPDDR5):
> 
> Radxa's U-Boot has following table of SARADC values, something that seem
> to match for the board model and revisions I have access to.
> 
> static struct variant_def variants[] = {
> 	{"rockchip,rk3588", 300, 380, "rockchip/rk3588s-radxa-e54c.dtb"},
> 	{"rockchip,rk3588", 980, 1060, "rockchip/rk3588-rock-5t.dtb"},
> 	{"rockchip,rk3588", 1650, 1730, "rockchip/rk3588s-radxa-e52c.dtb"},
> 	{"rockchip,rk3588", 2360, 2440, "rockchip/rk3588s-rock-5c.dtb"},
> 	{"rockchip,rk3588", 3370, 3450, "rockchip/rk3588s-rock-5d.dtb"},
> 	{"rockchip,rk3588", 4050, 4130, "rockchip/rk3588-rock-5b-plus.dtb"},
> };

Interesting. When I checked they still had a standalone config for
each board :) I guess if Radxa started relying on this there is a
lower chance of collisions. On the other hand the Rock 5T looks
quite close to your Rock 5B values.

> My Radxa rk358x boards report following for SARADC ch5:
> - ROCK 5B+ (no emmc): 4073, 1790329 uV
> - ROCK 5B+ (with emmc): 4075, 1791208 uV
> - ROCK 5B v1.42:  854, 375384 uV
> - ROCK 5B v1.42: 1100, 483516 uV
> - ROCK 5B v1.45: 1211, 532307 uV
> - ROCK 5B v1.46: 2109, 927032 uV
> - ROCK 5A v1.1: 682, 299780 uV
> - ROCK 5A v1.2: 685, 301098 uV
> - ROCK 5C v1.1: 2402, 1055824 uV
> - ROCK 5C Lite v1.1: 2402, 1055824 uV 
> - E52C v1.2: 1692, 743736 uV
> - E54C v1.2: 340, 149450 uV
> 
> So Radxa's table seem to match values reported by my boards/models.
> 
> Maybe the ROCK 5B is a little bit more flaky in reading out the ADC
> value and matching using some different way could improve board accuracy.

I was looking at the table on page 15 of the Rock 5B schematics:

https://dl.radxa.com/rock5/5b/docs/hw/radxa_rock_5b_v1423_sch.pdf

> > https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/commit/9803234dbb014a8fa4b495aa8f95bdc710d88380
> 
> rockchip_sdram_size() and asm/arch-rockchip/sdram.h already contains
> code and defines for these regs, so should probably be re-used instead
> of re-inventing how the DRAM type is read from OS reg if we go with DRAM
> type matching ;-)

Right.

> > Considering that the different memory is something Radxa explicitly
> > promotes as board difference between 5B and 5B+ it seems like a
> > better approach to me.
> 
> My main concern with using DRAM type matching is that it may limit
> what models can be supported by a single defconfig.

Fully agreed.

> > Note I only haven't send this yet, since I
> > was waiting for the Rock 5B+ DT to land in the upstream kernel. But
> 
> Sorry, I have not looked at your downstream tree for some time ;-)

No worries, I do not expect anyone doing so :)

> Btw, you can probably drop my "HACK: mkimage: fit: Keep data that should
> be loaded into SRAM embedded" from your tree, it should not be needed
> since long time now that PIO mode typically is used instead of DMA for
> TF-A loading.

Ack.

> > I'm totally happy for you to take care of this :)
> 
> I can probably extend the check to include DRAM type testing for a v2,
> should probably make board model matching as safe as it can be.

Combining both methods sounds good to me. The DRAM type check is
quite cheap.

Greetings,

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250715/e4fc04a1/attachment.sig>