[U-Boot-Users] Compile-time flash dependencies (was: PATCH: RPXlite configuration fixes)

[Yuli Barcohen]

>>>>> Wolfgang Denk writes:

    Yuli> It's what I'm trying to do. I'd like to clarify "increasing
    Yuli> the code size" concern which appears from time to time on the
    Yuli> list. As we all know, U-Boot occupies entire flash sector (or
    Yuli> several sectors). So, IMHO, if the increase does not require
    Yuli> additional sector, the increase

    Wolfgang> You assume that there is flash on a board. There are
    Wolfgang> boards which use a 128 kB ROM, and still are able to use a
    Wolfgang> decent set of features.  Of course this requires
    Wolfgang> optimization, and omitting some stuff. It's not a matter
    Wolfgang> of using an additional sector or not, it's as simple as
    Wolfgang> works or does not work.

But we're discussing only "environment in flash" case. All the rest is
unchanged. The CFG_ENV_SECT_SIZE is relevant for flash only, isn't it?
Also, if CFG_ENV_SECT_SIZE is defined, the existing mechanism will
work. I'd suggest any changes only for the case when CFG_ENV_SECT_SIZE
is undefined so the programmer always can chose between compile-time and
run-time approaches.

    Yuli> should not be a problem. Even if you're concerned about RAM
    Yuli> size, I'm not sure U-Boot size can be an issue. In most cases,
    Yuli> there is at least 8MB of RAM, so if U-Boot is 170K or 200K
    Yuli> should not make any difference. I personally never had such an
    Yuli> issue with our customers. In

    Wolfgang> I do, and I will strictly look at the code size. The rules
    Wolfgang> are well known.

    Yuli> cases when such a difference is critical, current method
    Yuli> (compile-time CFG_ENV_SECT_SIZE) can be used. In any case, I
    Yuli> believe that run-time vs compile-time code size difference can
    Yuli> be 2-3K in the worst case.

    Wolfgang> Maybe. Then it's 2-3k which can be saved, and shall be
    Wolfgang> saved.

So look at the saveenv code (in common/env_flash.c). The following
definition:

#if defined(CFG_ENV_SECT_SIZE) && (CFG_ENV_SECT_SIZE > CFG_ENV_SIZE)
	ulong	flash_offset;
	uchar	env_buffer[CFG_ENV_SECT_SIZE];
#else

allocates CFG_ENV_SECT_SIZE bytes on stack, in many cases this is
256KB. So we don't care for RAM data size but fight for every byte of
code size? Anyway, nobody is forced to use new mechanism if and when I
develop it. Also, I see no reason why U-Boot should be less convenient
or less flexible than, say, PlanetCore.

Unrelated question, also regarding the environment. It looks like
CFG_ENV_IS_EMBEDDED is unnecessary because ENV_IS_EMBEDDED is calculated
and used. What do you think?

-- 
========================================================================
 Yuli Barcohen       | Phone +972-9-765-1788 |  Software Project Leader
 yuli at arabellasw.com | Fax   +972-9-765-7494 | Arabella Software, Israel
========================================================================