From mboxrd@z Thu Jan 1 00:00:00 1970 From: Angelos Manousarides Date: Wed, 21 Jun 2006 20:16:58 +0300 Subject: [U-Boot-Users] Dynamic location of the environment sector In-Reply-To: <20060621141141.822AF353A9B@atlas.denx.de> References: <20060621141141.822AF353A9B@atlas.denx.de> Message-ID: <44997F0A.8010303@inaccessnetworks.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk wrote: > In message <20060621104820.GA23461@inaccessnetworks.com> you wrote: > >>Indeed it does not. The problem however, just for the record is code >>like the following segment: >> >># if (CFG_ENV_ADDR >= CFG_MONITOR_BASE) && \ >> (CFG_ENV_ADDR+CFG_ENV_SIZE) <= (CFG_MONITOR_BASE + CFG_MONITOR_LEN) >># define ENV_IS_EMBEDDED 1 >># endif > > > This is not a real problem, me thinks. > > >>The preprocessor cannot obviously perform checks and do arithmetic with >>C variables and constructs: >> >>include/environment.h:64:20: token "[" is not validin preprocessor expressions > > > Well, don't use '[' in your definitions, then :-) Ok I finally decided to switch to an embedded environment in the text segment of u-boot. The documentation says it is tricky business, but I prefer to take that risk and have a single image for all the platforms, without wasting 512K of flash space. The placement of the environment is a bit of a tricky business though in the ARM platform. Initially I tried to place it on the end of the sector but realised that after the text segment is the data segment of which the size I don't know. The other solution is to place it at the beginning right after the reset code, but this also does not have a fixed size (cpu/pxa/start.o). I decided to use the latter approach and place the environment at the 16K boundary, hoping that the object start.o will never reach this size. Another problem I encountered has to do with the manipulation of the environment with the "saveenv" command. The image I produced was ok, I booted and the default environment was recognized. I saw that the file common/environment.c defines before the environment the env_size variable, therefore placing the environment at 0x4004 than 0x4000 that is my hard coded offset. This causes a problem with the saveenv command, since here (common/env_flash.c): #ifdef CMD_SAVEENV /* static env_t *flash_addr = (env_t *)(&environment[0]);-broken on ARM-wd-*/ static env_t *flash_addr = (env_t *)(CFG_ENV_ADDR + sizeof(unsigned long)); #endif the address the command uses is the initial offset (0x4000) and not the actual offset after the env_size variable. Is this a bug introduced by the workaround for the flash_addr? Or am I doing something wrong and the env_size variable should never have appeared in my code? Regargs, Angelos Manousaridis