Dear Yuli,
in message 17061.20898.318765.498613@astp0002.localdomain you wrote:
But we're discussing only "environment in flash" case. All the rest is
Yes. I see no reason for a "but" in this sentence, though.
unchanged. The CFG_ENV_SECT_SIZE is relevant for flash only, isn't it?
Yes. And the memory footprint for U-Boot on the boot device is essential.
So look at the saveenv code (in common/env_flash.c). The following definition:
...
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
Right. Normally U-Boot is used to boot an OS which requires several megabytes of RAM so we don't have to worry about allocating even bigger temporary buffers in U-Boot.
develop it. Also, I see no reason why U-Boot should be less convenient or less flexible than, say, PlanetCore.
I agree, if it can be avoided. But we have clear priorities. Small memory footprint is much hicher on the list than comparing U-Boot against 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?
It was needed once, and I guess nobody ever spent the effort to actually test all related platforms if it can be savely removed.
Best regards,
Wolfgang Denk