Dear Haavard Skinnemoen,
In message 20090901152305.68e8d339@hskinnemoen-d830 you wrote:
On a 32 bit system with 36 bit physical addresses you cannot use a physical address when running the "md" command, for example.
Yes you can, if you teach the "md" command to map it at a virtual address first. Again, map_physmem() makes this possible without changing the external interface in any way.
Well, that was the part of me saying before: "as long as it doesn't hurt others". We don't want to add that complexity to U-Boot as noone needs it.
The only few systems that seem to have problems are yours with their exotic memory mappping.
As far as I understand, the only difference for such systems is that keeping 64-bit physical addresses around are a bit more costly than passing around 32-bit virtual pointers. But presumably those systems have enough memory to make it a non-issue...
That's not true. There are 32 bit systems with bigger physical address spaces.
Which part of what I said isn't true? The part about some systems might require 64-bit variables to store a physical address or that such variables take more storage than a 32-bit virtual address?
Well, that the have enough memory not to case about size, for example. [Keep in mind that this also effects the U-Boot image size in NOR flash.]
We do not want to implement a full-fledged OS with virtual memory and on-demand paging and all that stuff in U-Boot.
Then why are you forcing me to implement it for AVR32?!?
I'm not. I'm suggesting to implement a plain stupid 1:1 mapping and a function to turn on and off data cache (at least on the flash area).
The advantage is that other drivers with similar needs can use it as well.
But they can use map_physmem() today! It allows you to specify exactly what caching properties you need. The fact that it _may_ return a virtual address which is different from the physical one just allows more flexibility in how the architecture chooses to implement it!
You make assumptions on how other architectures work that may or may not be true.
On other architectures it is not possible to map the same memory area multiple times with different attributes.
So what? They can just return the physical address unchanged. It's not _mandatory_ to remap anything...
So how would these benefit from using data cache when reading from flash? This works for you only because you are then reading from a different address range.
It would be a good idea to clean up this board support, remove the proprietary flash driver and use the CFI driver instead. Patches are welcome.
You must be joking. Replacing a working driver with a broken one? Why the hell would anyone do that?
Fix the issues on the way?
Best regards,
Wolfgang Denk