Wolfgang Denk wrote:
In message 46535865.6060400@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