sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf
Sandbox doesn't actually provide U-Boot access to the machine's physical
memory. Instead it provides a RAM buffer of configurable size, and all
memory accesses are within that buffer. Sandbox memory starts at 0 and
is CONFIG_DRAM_SIZE bytes in size. Allowing access outside this buffer
might produce unpredictable results in the event of an error, and would
expose the host machine's memory architecture to the sandbox U-Boot.
Most U-Boot functions assume that they can just access memory at given
address. For sandbox this is not true.
Add a map_sysmem() call which converts a U-Boot address to a system
address. In most cases this is a NOP, but for sandbox it returns a
pointer to that memory inside the RAM buffer.
To get a U-Boot feature to work correctly within sandbox, you should call
map_sysmem() to get a pointer to the address, and then use that address for
any U-Boot memory accesses.
Signed-off-by: Simon Glass <sjg@chromium.org>
diff --git a/README b/README
index 0070694..51eb71b 100644
--- a/README
+++ b/README
@@ -3811,6 +3811,15 @@
that is executed before the actual U-Boot. E.g. when
compiling a NAND SPL.
+- CONFIG_ARCH_MAP_SYSMEM
+ Generally U-Boot (and in particular the md command) uses
+ effective address. It is therefore not necessary to regard
+ U-Boot address as virtual addresses that need to be translated
+ to physical addresses. However, sandbox requires this, since
+ it maintains its own little RAM buffer which contains all
+ addressable memory. This option causes some memory accesses
+ to be mapped through map_sysmem() / unmap_sysmem().
+
- CONFIG_USE_ARCH_MEMCPY
CONFIG_USE_ARCH_MEMSET
If these options are used a optimized version of memcpy/memset will