[U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR

Haavard Skinnemoen haavard.skinnemoen at atmel.com
Fri Aug 28 14:14:05 CEST 2009


Wolfgang Denk <wd at denx.de> wrote:
> >  #define CONFIG_ENV_IS_IN_FLASH		1
> >  #define CONFIG_ENV_SIZE			65536
> > -#define CONFIG_ENV_ADDR			(CONFIG_SYS_FLASH_BASE + CONFIG_SYS_FLASH_SIZE - CONFIG_ENV_SIZE)
> > +#define CONFIG_ENV_ADDR			(0xa0000000 + CONFIG_SYS_FLASH_SIZE - CONFIG_ENV_SIZE)  
> 
> This is definitely a change to the worse.

Yes, I think so too.

> I feel a strong urge to NAK this. There must be a better way to fix
> the problems you are experiencing.

Yes...the idea behind the map_physmem() macro was to do any
physical-to-virtual address mapping inside the CFI flash driver and
never expose anything but physical addresses to the outside world. This
meant that the sector start addresses were expressed in terms of
physical addresses, matching how things were wired up on the board, and
the architecture was free to map those to any virtual address which is
most suitable in terms of caching properties, etc.

Now, however, the flash start addresses are mapped to virtual addresses
at initialization time, so everything that wants to interact with the
flash must known which address the architecture decided to map the
flash at, which is not necessarily even possible to know in advance if
it is being done dynamically through a hardware MMU.

Reverting 09ce9921a7d8b1ce764656b14b42217bbf4faa38 would bring things
back to the way they were, and fix both the saveenv problem and the
jffs2 problem.

Haavard


More information about the U-Boot mailing list