On Sat, 29 Aug 2009 13:39:02 +0200 Stefan Roese <s...@denx.de> wrote: > I think too, that revering the patch in question is not the right > "solution" for this problem in the current stage. But I have to admit > that I don't have enough insight into your platform to come up with > another good idea quickly.
Yeah, I only meant to suggest it as one possible solution, with this patch being one other, less intrusive but also less complete, solution. And I'm not really even opposed to the patch in question, I just need to know how I should configure my systems from now on since all of a sudden, some addresses are supposed to be virtual while others are physical, and it doesn't seem to be documented anywhere what should be used where. > > > So...which config symbols are supposed to be virtual now, and how > > > are you supposed to know how the virtual-to-physical mappings are > > > set up in > > > advance? > > > > Everything is treated as virtual unless it's being used for hardware > > setup. If you use something to do memory accesses, it's virtual. A > > lot of code had been just using the PA as a VA, because things were > > always mapped 1-1. > > Correct. All those addresses to configure the CFI driver should be > virtual addresses. That cannot possibly be true, as the start address of the flash is passed to physmem_map(). It is also an absolutely idiotic thing to do since on any CPU with a MMU, the virtual address can be anything, so locking all the configuration symbols to specific virtual addresses would effectively lock down the MMU configuration forever (and I imagine that would be a particularly nasty problem on hardware with more physical address bits than virtual.) > > Can you point me at an example in your scenario of code that > > interacts with the flash? > > Yes, please give us an example of your memory mapping (physical and > virtual) on your failing platform. CFI-compatible flash at physical address 0. By default, all virtual addresses up to 2GB are mapped 1:1 with caching enabled (when paging is enabled, which it isn't in u-boot, this area is translated through the MMU.) Then, virtual address 0x80000000..0x9fffffff is mapped to 0x0..0x1fffffff with caching enabled (supervisor-only and not translated even with paging enabled; this is where the Linux kernel is mapped). Then, virtual address 0xa0000000..0xbfffffff is mapped to 0x0..0x1fffffff with caching disabled -- this is where we want to access the flash and other external hardware. Then there's another paged region and finally a 512MB uncached, direct-mapped region for accessing internal peripherals. So the problem is that even though we may read from the flash using the physical address as virtual address, we cannot initialize, erase or write it using those addresses. Hence the need for map_physmem(). Haavard _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
