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?