Hi Alex,
On 26 August 2018 at 19:11, Alexander Graf agraf@suse.de wrote:
On 08.08.18 11:54, Simon Glass wrote:
At present map_sysmem() maps an address into the sandbox RAM buffer, return a pointer, while map_to_sysmem() goes the other way.
The mapping is currently just 1:1 since a case was not found where a more flexible mapping was needed. PCI does have a separate and more complex mapping, but uses its own mechanism.
However this arrange cannot handle one important case, which is where a test declares a stack variable and passes a pointer to it into a U-Boot function which uses map_to_sysmem() to turn it into a address. Since the pointer is not inside emulated DRAM, this will fail.
Add a mapping feature which can handle any such pointer, mapping it to a simple tag value which can be passed around in U-Boot as an address.
Signed-off-by: Simon Glass sjg@chromium.org
I think you are aware that this logic will fall apart spectacularly if any arithmetic operation happens on the virtual (U-Boot) address, right? So simple code like
readl(vaddr + 1);
will just fail (hopefully) or (more likely) return a completely incorrect value.
I assume this is intentional, but shouldn't the tag increment be something slightly larger then?
What do you expect readl() to do on sandbox? At present it is just a no-op. I suppose we could support memory-mapped I/O but it has not been attempted yet.
Regards, Simon