Hi Sascha,
On Mon, 15 Jul 2013 11:23:54 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
Albert ARIBAUD albert.u.boot@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,