From: Angelos Manousarides <amanous@inaccessnetworks.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Dynamic location of the environment sector
Date: Wed, 21 Jun 2006 20:16:58 +0300 [thread overview]
Message-ID: <44997F0A.8010303@inaccessnetworks.com> (raw)
In-Reply-To: <20060621141141.822AF353A9B@atlas.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
next prev parent reply other threads:[~2006-06-21 17:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-14 11:55 [U-Boot-Users] Dynamic location of the environment sector Angelos Manousarides
2006-06-14 14:31 ` Wolfgang Denk
2006-06-21 10:48 ` Angelos Manousarides
2006-06-21 14:11 ` Wolfgang Denk
2006-06-21 17:16 ` Angelos Manousarides [this message]
2006-06-21 17:21 ` Angelos Manousarides
2006-06-21 20:47 ` Wolfgang Denk
2006-06-21 20:46 ` Wolfgang Denk
2006-06-22 10:21 ` Angelos Manousarides
2006-06-22 10:44 ` Wolfgang Denk
2006-06-22 11:02 ` Angelos Manousarides
2006-06-26 14:57 ` Angelos Manousarides
2006-06-26 21:10 ` Wolfgang Denk
2006-06-27 9:20 ` Angelos Manousarides
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44997F0A.8010303@inaccessnetworks.com \
--to=amanous@inaccessnetworks.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.