[PATCH v3 11/11] configs: j722s_evm_r5_hsmboot: Add new defconfig to show HSM boot

[Tom Rini]

On Tue, Jan 06, 2026 at 04:07:44PM +0530, Beleswar Prasad Padhi wrote:
> Hi Bryan, Andrew
> 
> On 05/01/26 22:49, Andrew Davis wrote:
> > On 1/5/26 8:11 AM, Bryan Brattlof wrote:
> >> On December 31, 2025 thus sayeth Beleswar Padhi:
> >>> Up until now, the R5 SPL in J722S platform was configured to start out
> >>> of the SMS0_HSM_SRAM0_0 (0x0043C00000, 512KB) memory region. However,
> >>> with the requirement of loading HSM M4F core with its own secure
> >>> firmware, R5 SPL can no longer utilize that memory to execute itself.
> >>>
> >>> Therefore, utilize the MSRAM8KX256E0_RAM (0x0043C40000, 256KB) memory
> >>> region for loading and executing R5 SPL. Naturally, the SPL size has now
> >>> to be trimmed to be fit inside the smaller 256KB region.
> >>>
> >>> As an example, create a new defconfig (j722s_evm_r5_hsmboot_defconfig)
> >>> which removes the SPI related configs to trim down the SPL size to
> >>> ~175KB. The above defconfig demonstrates loading HSM core with SD, eMMC
> >>> and UART bootmodes.
> >>
> >> I am worried we will need to find a better way to handle the defconfigs
> >> which are mainly here for testing things. I agree we should have a way
> >> to test this driver but if we go this route we will have too many
> >> defconfigs and build instructions for each evaluation board to get our
> >> code coverage to the levels we want.
> >>
> >> And it really only confuses people who are getting started.
> >>
> >
> 
> Agreed, not a fan of creating multiple defconfigs too, But...
> 
> > +1
> >
> > Using the SMS_HSM_SRAM for the R5 SPL was always a bit hacky, might be
> > better to move the default defconfig over to using MSRAM for R5 SPL. 
> 
> 
> ...won't that effect backward compat if we disable some configs?
> 
> > This
> > would of course mean we have to shrink it down a bit, but the Sitara
> > platforms get by with as much SRAM without much issue already.
> >
> > How far is the current R5 SPL on J722S from fitting in MSRAM currently?
> 
> 
> It's not just R5 SPL but also it's required stack, heap, BSS, global data
> and Scratchpad area. Adding all those we get ~270KB bin. Whereas
> our MSRAM is 256KB.
> 
> So a bloat of ~14KB.

Taking a quick peek, CONFIG_SPL_EFI_PARTITION=y can be dropped I bet and
maybe CONFIG_SPL_YMODEM_SUPPORT=y doesn't need to be in every build? It
might be worth sitting down and working out which boot use cases need to
be supported in the basic build for the platform and which ones it's OK
to have the user build, or build in your SDK or what-have-you. I'd
really hope we can still make something both useful and functional in
256KiB of memory.

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