On Tue, Jul 29, 2025 at 08:22:11AM -0600, Tom Rini wrote: > On Tue, Jul 29, 2025 at 02:27:49PM +0200, Philip Oberfichtner wrote: > > Hi Tom, > > > > On Mon, Jul 28, 2025 at 04:25:31PM -0600, Tom Rini wrote: > > > On Tue, Jul 08, 2025 at 12:39:57PM +0200, Philip Oberfichtner wrote: > > > > > > > Like other images, u-boot-with-spl.bin may be subject to size > > > > restrictions. Extend CONFIG_SPL_SIZE_LIMIT to handle this case. > > > > > > > > Signed-off-by: Philip Oberfichtner <p...@denx.de> > > > > --- > > > > > > > > Notes: > > > > Changes in v4: none > > > > > > > > Changes in v3: > > > > Reuse existing SPL_SIZE_LIMIT instead of implementing a new > > > > option > > > > > > > > Changes in v2: none > > > > > > > > Makefile | 1 + > > > > common/spl/Kconfig | 2 +- > > > > 2 files changed, 2 insertions(+), 1 deletion(-) > > > > > > This is not quite right enough, sorry. This causes a number of boards > > > (evb-ast2600 ibm-sbp1 stm32746g-eval_spl stm32f746-disco_spl > > > stm32f769-disco_spl) which have size checks and are fine to now fail > > > their size checks, presumably because they're checking the "wrong" file > > > now or similar. > > > > Thanks for pointing that out. To sum it up: If those boards use > > SPL_SIZE_LIMIT to restrict the size of an SPL-only image, then > > u-boot-with-spl.bin, of course, can be too large and the build fails. > > > > Plus in our previous discussion, we figured out why using > > BOARD_SIZE_LIMIT also isn't suitable: > > https://lore.kernel.org/u-boot/aD2EflR9DRYG-MY5@antares/ > > > > So from here I really don't see any better way than introducing yet > > another CONFIG_*SIZE_LIMIT option. > > > > > > But maybe we can however simplify and deduplicate some of the code. What > > do you think about something like that (I have not yet tested it, just > > a rough idea so far): > > That sounds like a good idea, so long as it works :) Thanks! >
So I've tested it for multiple board/image combinations. Should be fine now. v5 is on the way. Best regards, Philip > -- > Tom -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Johanna Denk, Tabea Lutz HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany =====================================================================
