Hi Stephen, On Wed, 10 Apr 2013 17:09:45 -0600, Stephen Warren <swar...@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. That was in my original proposals, and it was spoken against: <http://article.gmane.org/gmane.comp.boot-loaders.u-boot/158073> <http://article.gmane.org/gmane.comp.boot-loaders.u-boot/158094> > 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. That is a possibility, with the minor nitpick that we could possibly end up having conflicting values for the three symbols, whereas with the CONFIG_SPL_BSS_START_ADDR solution, there can be no value conflict. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot