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

[Kumar Gala]

On Aug 28, 2009, at 7:14 AM, Haavard Skinnemoen wrote:

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

Such a revert would break other boards that now expect the new  
behavior (like all the 36-bit physical cfg for FSL boards)

- k