On Aug 28, 2009, at 7:14 AM, Haavard Skinnemoen wrote:
Wolfgang Denk wd@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