[U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR
Kumar Gala
galak at kernel.crashing.org
Fri Aug 28 15:42:26 CEST 2009
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
More information about the U-Boot
mailing list