[U-Boot-Users] Dynamic location of the environment sector

[U-Boot-Users] Dynamic location of the environment sector

[Angelos Manousarides]

I have a board that comes in three flash confirurations:
- 32MB
- 64MB
- 128MB

The cfi code can safely detect the flash sizes, banks and widths at boot 
time. I have however the problem that the flash chips are "top" type and 
the small sectors are at the end of the address space. So I want to make 
the last sector (a small sector) to contain the environment. The last 
sector though is in a different address (and has a different size) 
depending on the flash configuration.

Currently the defines for the environment expect raw numerical values. 
Is there an infrastructure somewhere to define the flash size at 
runtime? I tried to print the flash sizes in the board specific codes, 
for instance:

extern flash_info_t flash_info[];

printf("flash 0 : %d %x\n", flash_info[0].size, 
flash_info[0].start[flash_info[0].sector_count-1]);
...

prints:

Flash: 64 MB
In:    serial
Out:   serial
Err:   serial
flash 0 : 67108864 3ff0000

(the second number is the address of the last sector)

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!

--
Angelos Manousaridis

[U-Boot-Users] Dynamic location of the environment sector

[Wolfgang Denk]

In message <448FF915.5060306@inaccessnetworks.com> you wrote:
> I have a board that comes in three flash confirurations:
...
> the last sector (a small sector) to contain the environment. The last 
> sector though is in a different address (and has a different size) 
> depending on the flash configuration.

OK.

> 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.

> Is there an infrastructure somewhere to define the flash size at 
> runtime? I tried to print the flash sizes in the board specific codes, 
> for instance:

You have all the powers of the C preprocessor and  compiler  at  your
hands. Just use them.

> 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.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our business is run on trust.  We trust you will pay in advance.

[U-Boot-Users] Dynamic location of the environment sector

[Angelos Manousarides]

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

[U-Boot-Users] Dynamic location of the environment sector

[Wolfgang Denk]

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 :-)

> 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.

So don'ty do it, then. Make the size 0x40000.

> 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)?

Did you see them on the list? If so, OK. 
What sort of replies did you expect anyway? 

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
That's the thing about people who think  they  hate  computers.  What
they really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"

[U-Boot-Users] Dynamic location of the environment sector

[Angelos Manousarides]

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

[U-Boot-Users] Dynamic location of the environment sector

[Angelos Manousarides]

Angelos Manousarides wrote:

> 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?
> 

Ooops, sorry I forgot to mention that with the above line changed to:

static env_t *flash_addr = (env_t *)(CFG_ENV_ADDR + sizeof(unsigned long));

the saveenv command produced the desired result. I am not so sure if 
this is the appropriate solution, it is a bit hard-coded, but I thought 
I should mention it. It would be more desirable to infer the address of 
the environment directly, but I am not sure how this can be done for the 
PXA architecture (or in a unified way for all architectures for that 
matter).

Regards,
Angelos Manousaridis

[U-Boot-Users] Dynamic location of the environment sector

[Wolfgang Denk]

In message <44997F0A.8010303@inaccessnetworks.com> you wrote:
> 
> 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?

You must be doing something wrong.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"355/113 -- Not the famous irrational number PI,  but  an  incredible
simulation!"

[U-Boot-Users] Dynamic location of the environment sector

[Wolfgang Denk]

In message <44998029.9020708@inaccessnetworks.com> you wrote:
> 
> Ooops, sorry I forgot to mention that with the above line changed to:
> 
> static env_t *flash_addr = (env_t *)(CFG_ENV_ADDR + sizeof(unsigned long));

This cannot be correct.

> I should mention it. It would be more desirable to infer the address of 
> the environment directly, but I am not sure how this can be done for the 
> PXA architecture (or in a unified way for all architectures for that 
> matter).

See the existing code examples / linker scripts.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
CONSUMER NOTICE:  Because  of  the  "Uncertainty  Principle,"  It  Is
Impossible  for  the  Consumer  to  Find  Out  at  the Same Time Both
Precisely Where This Product Is and How Fast It Is Moving.

[U-Boot-Users] Dynamic location of the environment sector

[Angelos Manousarides]

Wolfgang Denk wrote:
> In message <44997F0A.8010303@inaccessnetworks.com> you wrote:
> 
>>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?
> 
> 
> You must be doing something wrong.
> 

Ok. I found what the problem was. I was looking at the TRAB board which 
is a PXA board with the environment embedded and did exactly the same 
thing. What i did NOT notice is that it is mentioned explicitely in the 
common/environment.c file, and that is why it works and mine did not:

#if (defined(CONFIG_CMI)        || \
      defined(CONFIG_FADS)       || \
      defined(CONFIG_HYMOD)      || \
      defined(CONFIG_ICU862)     || \
      defined(CONFIG_R360MPI)    || \
      defined(CONFIG_TQM8xxL)    || \
      defined(CONFIG_RRVISION)   || \
      defined(CONFIG_TRAB)       || \
      defined(CONFIG_MRG110_6)   || \
      defined(CONFIG_PPCHAMELEONEVB) )   && \
      defined(ENV_CRC) /* Environment embedded in U-Boot .ppcenv section */
/* XXX - This only works with GNU C */
#  define __PPCENV__ __attribute__ ((section(".ppcenv")))
#  define __PPCTEXT__ __attribute__ ((section(".text")))

#elif defined(USE_HOSTCC) /* Native for 'tools/envcrc' */
#  define __PPCENV__ /*XXX DO_NOT_DEL_THIS_COMMENT*/
#  define __PPCTEXT__ /*XXX DO_NOT_DEL_THIS_COMMENT*/

#else /* Environment is embedded in U-Boot's .text section */
/* XXX - This only works with GNU C */
#  define __PPCENV__ __attribute__ ((section(".text")))
#  define __PPCTEXT__ __attribute__ ((section(".text")))
#endif


My board is not on the first #if, so it felt back to the last #else, 
thus placing the env_size and environment in the wrong order.

Regards,
Angelos Manousaridis

[U-Boot-Users] Dynamic location of the environment sector

[Wolfgang Denk]

In message <449A6F42.9090509@inaccessnetworks.com> you wrote:
>
> Ok. I found what the problem was. I was looking at the TRAB board which 
> is a PXA board with the environment embedded and did exactly the same 

No, TRAB is not a PXA system. It's a s3c2400 board.

> thing. What i did NOT notice is that it is mentioned explicitely in the 
> common/environment.c file, and that is why it works and mine did not:

No, this is not correct.

> #if (defined(CONFIG_CMI)        || \
>       defined(CONFIG_FADS)       || \
>       defined(CONFIG_HYMOD)      || \
>       defined(CONFIG_ICU862)     || \
>       defined(CONFIG_R360MPI)    || \
>       defined(CONFIG_TQM8xxL)    || \
>       defined(CONFIG_RRVISION)   || \
>       defined(CONFIG_TRAB)       || \
>       defined(CONFIG_MRG110_6)   || \
>       defined(CONFIG_PPCHAMELEONEVB) )   && \
>       defined(ENV_CRC) /* Environment embedded in U-Boot .ppcenv section */

The only effect of this is to put the  environment  into  a  separate
linker  section. You can do this, but you don't have to. You can make
this work without this setting es well. Just  configure  your  linker
script correctly.

> My board is not on the first #if, so it felt back to the last #else, 
> thus placing the env_size and environment in the wrong order.

This is an error in your linker script then.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Virtual" means never knowing where your next byte is coming from.

[U-Boot-Users] Dynamic location of the environment sector

[Angelos Manousarides]

Wolfgang Denk wrote:
> In message <449A6F42.9090509@inaccessnetworks.com> you wrote:
> 

> The only effect of this is to put the  environment  into  a  separate
> linker  section. You can do this, but you don't have to. You can make
> this work without this setting es well. Just  configure  your  linker
> script correctly.
> 
> 
>>My board is not on the first #if, so it felt back to the last #else, 
>>thus placing the env_size and environment in the wrong order.
> 
> 
> This is an error in your linker script then.

My linker script is :

         .text      :
         {
           cpu/pxa/start.o       (.text)
           . = env_offset ;
           common/environment.o  (.text)
           *(.text)
           /**(EXCLUDE_FILE (common/environment.o) .text)*/
         }


env_offset is defined at common/environment.c, and this is the defined 
used by other boards as well.
BUT:

$ arm-linux-objdump -d common/environment.o

common/environment.o:     file format elf32-littlearm

Disassembly of section .text:

00000000 <env_size>:
        0:       00 80 00 00                                         ....

00000004 <environment>:
        4:       85 6f 43 92 62 6f 6f 74 64 65 6c 61 79 3d 35 00 
.oC.bootdelay=5.
       14:       62 61 75 64 72 61 74 65 3d 31 31 35 32 30 30 00 
baudrate=115200.
         ...

How can this be correct? All the defines are for offset 0 of this file, 
but at 0 is the env_size. I also did a hexedit of the u-boot.bin and the 
environment indeed starts at 0x4004 :

00004000   00 80 00 00  85 6F 43 92  62 6F 6F 74  64 65 6C 61



Regards,
Angelos Manousaridis

[U-Boot-Users] Dynamic location of the environment sector

[Angelos Manousarides]

Angelos Manousarides wrote:
> env_offset is defined at common/environment.c, and this is the defined 
> used by other boards as well.
> BUT:
> 
> $ arm-linux-objdump -d common/environment.o
> 
> common/environment.o:     file format elf32-littlearm
> 
> Disassembly of section .text:
> 
> 00000000 <env_size>:
>         0:       00 80 00 00                                         ....
> 
> 00000004 <environment>:
>         4:       85 6f 43 92 62 6f 6f 74 64 65 6c 61 79 3d 35 00 
> .oC.bootdelay=5.
>        14:       62 61 75 64 72 61 74 65 3d 31 31 35 32 30 30 00 
> baudrate=115200.
>          ...
> 

Well, I decided to change the linker script to :

           cpu/pxa/start.o       (.text)
           . = 16 * 1024 - 4;
           common/environment.o  (.text)
           *(.text)

This way the environment will be alligned at the right address and I 
don't have to change the u-boot code.

What is the story of the env_size variable? The tools tin tools/env/* do 
not use this variable, the environment size is retrieved from the 
configuration files.


The only reference I found was in tools/envcrc.c:

#ifdef  ENV_IS_EMBEDDED
extern unsigned int env_size;
extern unsigned char environment;
#endif  /* ENV_IS_EMBEDDED */

These declarations though are not used anywhere on the code that follows!

In the actual u-boot code (not the tools) there is no usage. Is it some 
kind of a legacy mechanism, leftover from older versions of u-boot?

--
Angelos Manousaridis

[U-Boot-Users] Dynamic location of the environment sector

[Wolfgang Denk]

In message <449FF5D4.8050007@inaccessnetworks.com> you wrote:
>
> What is the story of the env_size variable? The tools tin tools/env/* do 
> not use this variable, the environment size is retrieved from the 
> configuration files.

I have no idea what's happening in your configuration. Especially,  a
variable  like  env_size  should not be part of the .text segment ion
the first place.

> In the actual u-boot code (not the tools) there is no usage. Is it some 
> kind of a legacy mechanism, leftover from older versions of u-boot?

I don't even remember that...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I paid too much for it, but its worth it.

[U-Boot-Users] Dynamic location of the environment sector

[Angelos Manousarides]

On Mon, Jun 26, 2006 at 11:10:51PM +0200, Wolfgang Denk wrote:
> In message <449FF5D4.8050007@inaccessnetworks.com> you wrote:
> >
> > What is the story of the env_size variable? The tools tin tools/env/* do 
> > not use this variable, the environment size is retrieved from the 
> > configuration files.
> 
> I have no idea what's happening in your configuration. Especially,  a
> variable  like  env_size  should not be part of the .text segment ion
> the first place.

Could it be that I am the first to try an embedded environment in u-boot
for the PXA architecture? The PXA platforms are very few, I wouldn't be
suprised if that was the case.

Regards,
Angelos Manousaridis