From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 22 May 2007 16:53:57 -0400 Subject: [U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT In-Reply-To: <46535464.6090206@freescale.com> References: <464B624D.2050102@freescale.com> <46535464.6090206@freescale.com> Message-ID: <46535865.6060400@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Timur Tabi wrote: > Doesn't anyone have an answer to this question? > > Timur Tabi wrote: >> On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled: >> >> #define CFG_ENV_ADDR (CFG_MONITOR_BASE - 0x1000) >> #define CFG_ENV_SIZE 0x2000 >> >> This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. >> Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will >> overwrite the beginning of u-boot.bin whenever someone does a saveenv? Looks like it to me. Looks like somebody increased the size without fixing the address offset to match. Looks to me like it would be better defined: #define CFG_ENV_SIZE 0x2000 #define CFG_ENV_ADDR (CFG_MONITOR_BASE - CFG_ENV_SIZE) 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. * 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. * 4K is fairly large for an env, so people probably don't run into the problem. Best regards, gvb