summaryrefslogtreecommitdiffstats
path: root/.checkpatch.conf
diff options
context:
space:
mode:
authorSimon Glass <sjg@chromium.org>2013-02-24 17:33:14 +0000
committerSimon Glass <sjg@chromium.org>2013-02-28 19:09:22 -0800
commit4213fc2913722045eb2c327a64b99e3e3178aa5c (patch)
treeaf5c64aebc9d51c61a2990db7b5b3d66afcb42a8 /.checkpatch.conf
parente101550a9a8b956434cf2a73f66afbb42f4654bd (diff)
downloadtalos-obmc-uboot-4213fc2913722045eb2c327a64b99e3e3178aa5c.tar.gz
talos-obmc-uboot-4213fc2913722045eb2c327a64b99e3e3178aa5c.zip
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>
Diffstat (limited to '.checkpatch.conf')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud