Hi Tom,
On Fri, 21 Jun 2024 at 13:19, Tom Rini trini@konsulko.com wrote:
On Fri, Jun 21, 2024 at 11:55:42AM -0600, Simon Glass wrote:
Hi Tom,
On Fri, 21 Jun 2024 at 10:05, Tom Rini trini@konsulko.com wrote:
[snip]
Yes, I very much do not like guessing about 3 numbers instead of guessing about 1 number and using the standard mechanism we already have. Please use BOARD_SIZE_LIMIT as this is the standard mechanism to enforce size limits on U-Boot itself.
If it were that easy I would have sent a patch :-)
Here is the map for this board:
ImagePos Offset Size Name 00000000 00000000 00800000 rom ff800000 ff800000 00001000 intel-descriptor ff801000 ff801000 001ff000 intel-me ffef0000 ffef0000 000999f0 u-boot-with-ucode-ptr fff899f0 fff899f0 00005554 u-boot-dtb-with-ucode fff8ef50 fff8ef50 00000000 u-boot-ucode fff8ef50 fff8ef50 00000571 fdtmap fff90000 fff90000 00010000 intel-vga fffa0000 fffa0000 0002fc94 intel-mrc fffcfc94 fffcfc94 00000000 private-files fffff800 fffff800 00000070 x86-start16 fffffff0 fffffff0 00000005 x86-reset16 fffffff8 fffffff8 00000008 image-header
What limit should I set on what?
Is this a trick question? $ printf %d\n $(( 0xfff90000 - 0xffef0000)) 655360
Of course since we're less than that today, you can reduce it by whatever other magic numbers I'm not seeing but are part of your assumed sizes.
That limit is on u-boot-nodtb.bin. Even with a size (for that file) of 634816 it doesn't fit. I need to calculate a size based on the size of the dtb and the microcode...which of course can change.
- the U-Boot is the thing you are wanting to limit
- the dtb has microcode added
- the ucode is empty in this case
- the fdtmap is variable in size
So this all seems a bit backwards. The actual limit is that (u-boot-with-ucode-ptr + u-boot-dtb-with-ucode + u-boot-ucode + fdtmap) fits in the space available. Note that some boards don't have intel-vga or intel-mrc.
With the other patch I sent I can have a sensible limit for all x86 boards.
Did you miss the comments above?
And you can set the same sensible limit with the existing mechanism with the bonus of it not making x86 different from the rest?
I understand that it is possible to set a limit for u-boot-nodtb.bin but that is not accurate nor sufficient in the presence of blobs. The solution belongs in Binman.
Regards, Simon