Hi Sascha, On Mon, 15 Jul 2013 11:23:54 +0200, Sascha Silbe <t-ub...@infra-silbe.de> wrote:
> Albert ARIBAUD <albert.u.b...@aribaud.net> writes: > > >> The situation has gotten better recently and U-Boot fits into the > >> previous partition size of 384KiB again. So it isn't broken on OpenRD > >> anymore and the above would seem like a good approach. > > How well does it fit again, and do you have any idea what caused the > > increase in size, and what caused the decrease? > > I had the same questions and tried a few buildman runs, but didn't get a > clear picture. The size was going up and down for various slices of > commits. > > With v2013.07-rc3, we are now at 376344B (≈ 96% of 384KiB) for > openrd_ultimate when built on Debian Wheezy using > gcc-4.7-arm-linux-gnueabi from Emdebian. Thanks for the info. > Is there an equivalent to CONFIG_SPL_MAX_SIZE for the "regular" U-Boot? > Detecting the overlap at build time would prevent bricking the device > using saveenv at run time. As an additional benefit, commits that push > the size beyond the limit would also show up in buildman reports as > build failures. I don't know of a feature like CONFIG_SPL_MAX_SIZE for regular U-Boot. You could 'port it over' as something like CONFIG_MAX_IMAGE_SIZE for U-Boot. Somehow I gather that an approach like the one I sketched out in http://article.gmane.org/gmane.comp.boot-loaders.u-boot/165510 could bring benefits like making CONFIG_SPL_MAX_SIZE a feature of a "constraints" component which could be built as well in U-Boot as in SPL; but that's at the very early RFC stage anyway -- actually, it drew no reaction at all so far, leading me to think it's not that useful. > Sascha Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
