All of lore.kernel.org
 help / color / mirror / Atom feed
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 13:48:21 +0300	[thread overview]
Message-ID: <20060621104820.GA23461@inaccessnetworks.com> (raw)
In-Reply-To: <20060614143104.145D9353C1B@atlas.denx.de>

On Wed, Jun 14, 2006 at 04:31:04PM +0200, Wolfgang Denk wrote:
> > Currently the defines for the environment expect raw numerical values. 
> 
> What makes you think so?
> 
> I didn't try it, but I see no reason why something like
> 
> 	#define CFG_ENV_ADDR		my_env_params(1)
> 	#define CFG_ENV_SIZE		my_env_params(2)
> 	#define CFG_ENV_SECT_SIZE	my_env_params(3)
> 
> would be impossible. But this probably does not solve your problem  -
> see below.

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

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

> > And all sizes are detected correctly. I want to use these values to 
> > calculate the location of the environment dynamically at runtime. This 
> > way I can have a single u-boot image for all flash configurations!
> 
> There is one problem which you probably did not realize  yet:  U-Boot
> will  access  the  environment  (for  example,  to  read  the console
> baudrate) *long* before the flash detection code  is  running  (which
> actually  happens very late in the init sequence, after relocation to
> RAM). So you cannot rely on values filled in the flash_info[]  array,
> as  such data does not exist yet when you need it. You will need some
> other way (like configuration registers of jumpers on the  board)  to
> figure out which configuration to use.
> 
> Or you simply chose a definition that works on all  boards,  even  if
> this  means  that  you  will waste some flashmemory on 2 of the board
> configurations.

This is the solution I will follow, although I was trying to avoid it.
The second block, right after the u-boot will hold the environment. I
have an issue though with the environment sector size. I have three
configurations, two of which have a sector size 0x40000 and one has
0x20000. The problem I mentioned above with the static declarations
appears here. If I declare the env size to be the smaller sector, An
error occurs during the environment saving : "flash sector size is not
equal to the environment size" or something like that.

Another note not related to the ones above. A couple of days ago I sent
some patches for the arm architecture, but I did not received any
replies. Have you seen them (it was on the 6th of June)?

Regards, 

Angelos Manousaridis

  reply	other threads:[~2006-06-21 10:48 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 [this message]
2006-06-21 14:11     ` Wolfgang Denk
2006-06-21 17:16       ` Angelos Manousarides
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=20060621104820.GA23461@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.