Hi Alex,
On 3 June 2018 at 04:13, Alexander Graf agraf@suse.de wrote:
On 25.05.18 04:42, Simon Glass wrote:
Hi Alex,
On 24 May 2018 at 06:24, Alexander Graf agraf@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 sjg@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.
Yes, but ideally that would be 0, or something small.
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.
Yes but putting a 10000000 base address on everything is a bit of a pain.
Regards, Simon