Hi Stephen,
On Wed, 10 Apr 2013 17:09:45 -0600, Stephen Warren swarren@wwwdotorg.org wrote:
On 04/10/2013 04:50 PM, Albert ARIBAUD wrote:
On Wed, 10 Apr 2013 16:21:54 -0600, Stephen Warren wrote:
On 04/09/2013 05:14 PM, Albert ARIBAUD wrote:
...
This still seems to have separate defines for SPL text/data/rodata size and BSS size. If I want instead to limit the total text/data/rodata/bss size, but place no specific limit on the bss size individually, can I not do that?
This would defeat the purpose of giving CONFIG_SPL_MAX_SIZE a constant meaning -- one of the issues which prompted this patch series is that in ARM sometime CONFIG_SPL_MAX_SIZE meant BSS included, and sometime excluded, and this inconsistency had to be resolved. As in the rest of U-boot, CONFIG_SPL_MAX_SIZE was meant BSS excluded, this is the semantics that was decided.
What we could do, though, is subdivide testing based on the existence or non-existence of CONFIG_SPL_BSS_START_ADDR:
if CONFIG_SPL_BSS_START_ADDR exists, then we assume SPL image and BSS are disjoint and we test each one against its max size, as this patch series does;
if CONFIG_SPL_BSS_START_ADDR does not exist, then we assume SPL image and BSS are contiguous and we test the whole of SPL against the sum of CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE.
Why not either:
a) define CONFIG_SPL_MAX_SIZE to include the BSS size if CONFIG_SPL_BSS_START_ADDR is not set, but exclude it if it is.
or:
b) use 3 defines instead of 2, so that CONFIG_SPL_MAX_SIZE (if defined) always limits text+rodata+data, CONFIG_SPL_MAX_FOOTPRINT (if defined) always limits text+rodata+data+bss, and CONFIG_SPL_BSS_MAX_SIZE (if defined) always limits bss size.
Tegra would define only CONFIG_SPL_MAX_FOOTPRINT in this scheme. Other boards would presumably define other combinations of those.
Tom R on IRC showed preference for CONFIG_SPL_MAX_FOOTPRINT -- I'll send out a V3 with this solution.
Amicalement,