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.
- 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.
And you can set the same sensible limit with the existing mechanism with the bonus of it not making x86 different from the rest?