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
signature.asc
Description: PGP signature
