Hi Alex, On 14 June 2018 at 17:13, Alexander Graf <ag...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
