[U-Boot] [RFC] sandbox: Enable 1:1 map
Simon Glass
sjg at chromium.org
Wed Jun 20 17:51:54 UTC 2018
Hi Alex,
On 14 June 2018 at 17:13, Alexander Graf <agraf at suse.de> wrote:
> So far we've always had a split address space situation with
> "U-Boot addresses" (a number space starting from 0) and "host
> virtual addresses" (128MB mapped randomly in address space).
>
> This meant that we had to make sure all code is properly aware that
> addresses and pointers are not the same thing, so they must not cast
> between the two.
>
> However, most real boards do actually have a 1:1 map. So it's
> much easier to just expose the same in sandbox.
>
> So this patch maps sandbox RAM from 0x8000000-0x10000000. This
> address range fits just fine on both 32bit and 64bit systems.
>
> ---
>
> The patch is on top of my "efi-sandbox-v3" tree. But I'm sure
> it easily applies on vanilla too.
>
> I also don't know if this really is the best path forward, but
> at least it's one that gets rid of the one awkward target that
> does not have a 1:1 map ;)
> ---
> arch/sandbox/cpu/cpu.c | 18 ++----------------
> arch/sandbox/cpu/state.c | 4 ++--
> arch/sandbox/cpu/u-boot.lds | 3 +++
> arch/sandbox/include/asm/io.h | 17 +++++------------
> common/board_f.c | 4 +++-
> configs/sandbox64_defconfig | 6 +++---
> configs/sandbox_defconfig | 6 +++---
> configs/sandbox_flattree_defconfig | 4 ++--
> configs/sandbox_noblk_defconfig | 4 ++--
> configs/sandbox_spl_defconfig | 4 ++--
> include/configs/sandbox.h | 22 +++++++++++-----------
> 11 files changed, 38 insertions(+), 54 deletions(-)
NAK, as discussed.
Just to repeat myself, I do not want to change how sandbox works at
this stage. We will always have some need for mapping, even if only to
make PCI work.
Once we have EFI working and have more test coverage in U-Boot itself
we can revisit this. But this change is not necessary to make EFI
work.
Regards,
Simon
More information about the U-Boot
mailing list