On Aug 28, 2009, at 7:14 AM, Haavard Skinnemoen wrote: > Wolfgang Denk <w...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
