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

[Quentin Schulz]

Hi Ferass,

On 10/15/25 7:58 PM, Ferass El Hafidi wrote:
> Hi Quentin,
> 
> On Wed Oct 15, 2025 at 5:11 PM UTC, Quentin Schulz wrote:
[...]
>>> +
>>> +			blob {
>>> +				size = <0xb000>; /* The BootROM loads 48K max (header is 4K) */
>>> +				filename = "spl/u-boot-spl.bin";
>>> +			};
>>
>> I'm not sure this actually works? It would rely on a binary located at
>> spl/u-boot-spl.bin, which binman doesn't seem to be generating? Either
>> we;re missing something to generate it with binman, or something
>> external to binman generates it?
>>
> 
> spl/u-boot-spl.bin is generated on build-time, it's the U-Boot SPL
> binary. And that does work according to my testing...
> 

Yesterday me was convinced binman is generating the SPL binaries but it 
isn't the case :) Sorry for the noise.

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

>> ?
>>
>> 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 
"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