[U-Boot] [PATCH] OpenRD: relocate environment to 640kB

[Albert ARIBAUD]

Hi Sascha,

On Mon, 15 Jul 2013 11:23:54 +0200, Sascha Silbe
<t-uboot at infra-silbe.de> wrote:

> Albert ARIBAUD <albert.u.boot at 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.