[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <46535865.6060400 at smiths-aerospace.com> you wrote:
>> Looks to me like it would be better defined:
>> #define CFG_ENV_SIZE		0x2000
>> #define CFG_ENV_ADDR		(CFG_MONITOR_BASE - CFG_ENV_SIZE)
> 
> No, this is broken as CFG_ENV_SIZE may be (and often actually is)
> smaller than CFG_ENV_SECT_SIZE

In the case of RAMBOOT where the env is stored in RAM, the flash sector 
size is immaterial.  "But such discussion is void, as ramboot itself it 
not supported officially."

>> The saving grace here is probably:
>> * For a RAMBOOT image, there isn't any incentive to save lots of stuff 
>> in the env since it (generally) disappears on a reboot and definitely 
>> disappears on a power cycle.
> 
> One could argue that a correctly  configured  ramboot  version  would
> access  the  original  copy  of  the  environment  in flash. But such
> discussion is void, as ramboot itself it not supported officially.

Yup, but arguing minutia keeps geeks entertained.  ;-)

>> * On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and 
>> vectors which aren't used by a RAMBOOT image so overwriting them is a 
>> non-fatal error.
> 
> Wrong. You may have timer and other interrupts,  so  overwriting  the
> exception vectors is a Bad Thing (TM).

Beg to differ (granted, I was pretty loose in my description above).  If 
the env is being stored _before_ u-boot.bin, it means u-boot.bin is not 
being stored at location 0x00000000 thus _those_ vectors cannot be the 
ones actively being used by the processor.  They are the _source_ of the 
active vectors (copied to location 0 on relocation) but that is before 
they are *hypothetically* corrupted by the user creating 4K++ of env and 
then saving the env.

Obviously, the RAMBOOT u-boot.bin image cannot have more than 4K (+/-) 
of env variables built in or Very Bad Things would have happened during 
the link and/or execution.  "But such discussion is void, as ramboot 
itself it not supported officially."

> Best regards,
> 
> Wolfgang Denk

Best regards,
gvb