On 25.05.18 04:42, Simon Glass wrote: > Hi Alex, > > On 24 May 2018 at 06:24, Alexander Graf <ag...@suse.de> wrote: >> >> >> On 16.05.18 17:42, Simon Glass wrote: >>> At present this code casts addresses to pointers so cannot be used with >>> sandbox. Update it to use mapmem instead. >>> >>> Signed-off-by: Simon Glass <s...@chromium.org> >> >> I really dislike the whole fact that you have to call map_sysmem() at >> all. I don't quite understand the whole point of it either - it just >> seems to clutter the code and make it harder to follow. > > The purpose is to map U-Boot addresses (e.g. 0x1234) to actual > user-space addresses in sandbox (gd->arch.ram_buf + 0x1234). > > Otherwise we cannot write tests which use particular addresses, and > people have to worry about the host memory layout when using sandbox.
Not if we write a smart enough linker script. I can try to see when I get around to give you an example. But basically all we need to do is reserve a section for guest ram at a constant virtual address. >> Can't we just simply make sandbox behave like any other target instead? > > Actually that's the goal of the sandbox support. Memory is modelled as > a contiguous chunk starting at 0x0, regardless of what the OS actually > gives U-Boot in terms of addresses. Most platforms don't have RAM start at 0x0 (and making sure nobody assumes it does start at 0 is a good thing). The only bit we need to make sure is that it always starts at *the same* address on every invocation. But if that address is 256MB, things should still be fine. Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
