[PATCH v4 6/8] arm: dts: meson-gx-u-boot: add binman configuration for U-Boot SPL

[Ferass El Hafidi]

Hi Quentin,

On Thu Oct 16, 2025 at 9:21 AM UTC, Quentin Schulz wrote:
> <...>
>
> Yesterday me was convinced binman is generating the SPL binaries but it 
> isn't the case :) Sorry for the noise.
>

No worries!

>>> Typically it is generated with:
>>>
>>> u-boot-spl {
>>> };
>>>
>> 
>> ...but I think this is much cleaner, so I'll go with that.
>> 
>
> And this is essentially
>
> blob {
>      filename = "spl/u-boot-spl.bin";
> };
>
> Because tools/binman/etype/u_boot_spl.py is inheriting Entry_blob whose 
> default "filename" property is "spl/u-boot-spl.bin".
>
> TIL :)
>

Yep, but I think maybe `u-boot-spl {};` might be cleaner than just
`blob`..

>>> ?
>>>
>>> If you're trying to enforce a max size, then we have Kconfig symbols for
>>> those, probably SPL_MAX_SIZE and then I believe binman enforces those
>>> one way or another. If it doesn't, then many boards and architecture
>>> have a problem and we should fix that so you can rely on it.
>>>
>> 
>> I did know of SPL_MAX_SIZE... Might have just overlooked it though.
>> I think this should be the proper way to do this, yeah.
>> 
>
> If I were you I'd triple check though, because I'm not entirely sure it 
> does what you want. I quickly checked on Rockchip and I think this is 
> rather enforced at the mkimage level in tools/rkcommon.c where we store 
> the max size of the xPL (size of available SRAM to U-Boot (third member 
> of spl_info struct)) and compare the size of the xPL (TPL if there's 
> one, SPL otherwise). See rkcommon_check_params().
>
> Though that tool predates our use of binman for generating the images on 
> Rockchip, so maybe Binman checks properly. I vaguely remember having 
> binman shout at me that my xPL was too big (likely because it detected 
> an overlap with the offset at which U-Boot proper is expected). One way 
> to be sure is to artificially increase the size of the binary and check 
> if it fails when expected to.
>
> FYI, on Rockchip we went for a unique binary (u-boot-rockchip.bin) which 
> contains both the xPL and U-Boot proper at the expected offset. Then you 
> just need to tell users to flash the binary at the offset the BootROM is 
> expecting to find the xPL header. It's rather convenient (but is a bit 

This is also how Amlogic works here. There's a single
u-boot-meson-with-spl.bin binary which contains the @AML bootROM header,
raw SPL binary, and the rest are fit images. The issue mainly lies in
the bootROM only reading up to 0xc000 bytes, and with the header taking
0x1000 bytes (there's padding, so that SPL gets loaded to 0xd9001000),
this means we only have 0xb000 for the entire SPL image.

> "bloated" by zeroes if U-Boot proper is much later in the storage medium 
> compared to the end of the xPL, e.g. by default on Rockchip proper is 
> almost ~8MiB after the start of xPL) because regardless of the device or 
> configuration, the flashing instructions are the same. We still expose 
> the xPL and proper files individually if you want to flash them by hand 
> (which comes in handy when you want to use those 8MiB for storing e.g. 
> the U-Boot environment(s) and not erase it whenever you flash U-Boot). 
> Food for thoughts :)
>
> [...]
>
>>>> +				};
>>>> +
>>>> +				atf {
>>>> +					description = "ARM Trusted Firmware";
>>>> +					type = "firmware";
>>>> +					os = "arm-trusted-firmware";
>>>> +					arch = "arm64";
>>>> +					compression = "none";
>>>> +					load = <BL31_ADDR>;
>>>> +					entry = <BL31_ADDR>;
>>>> +
>>>> +					atf-bl31 {
>>>> +						filename = "bl31.bin";
>>>
>>> I believe this is already the case if you set BL31 environment variable
>>> to bl31.bin. I would simply remove it and let the user decide what's
>>> best for them. For binman this comes from the -a atf-bl31-path=${BL31}
>>> argument.
>>>
>>> The benefit is that you can now point to a BL31 outside of U-Boot's
>>> tree, which is super convenient for debugging TF-A, or with build
>>> systems like Yocto or Buildroot.
>>>
>> 
>> You can already point to a BL31 outside U-Boot's tree, and this is what
>> I've been always doing when testing.
>> 
>
> Reading tools/binman/etype/atf_bl31.py and 
> tools/binman/etype/blob_named_by_arg.py, it seems if BL31 env variable 
> is set (and thus passed via -a atf-bl31-path to binman) then the 
> filename property of atf-bl31 node is replaced with BL31. So you're right :)
>
>> But I think having it check for a bl31.bin inside the tree when $BL31 is
>> not set is a sane default IMO .. but correct me if I'm wrong and it's
>> considered poor practise.
>> 
>
> No opinion on this.
>
> [...]
>
>>>> +				};
>>>> +
>>>> +				scp {
>>>> +					description = "SCP firmware";
>>>> +					type = "scp";
>>>> +					arch = "arm"; /* The Cortex-M core is used as SCP */
>>>> +					compression = "none";
>>>> +					load = <SCP_ADDR>;
>>>> +
>>>> +					scp {
>>>> +						filename = "scp.bin";
>>>> +					};
>>>
>>> I would recommend to attempt mimicking what's been done for atf-bl31
>>> (then you need to add a new argument to the lists of arguments for
>>> binman in the root Makefile). See above for benefits.
>>>
>> 
>> One can already `export SCP=../path/to/scp/firmware` and have binman use
>> that.
>> 
>
> Indeed, it is passed via -a scp-path to Binman. And this mimics what's 
> been done earlier in this patch for atf-bl31, so I guess this checks out 
> :) Sorry for the noise.
>
> Cheers,
> Quentin

Thanks,
Ferass