Hi Simon, On Thu, Jan 18, 2018 at 10:44 PM, Simon Glass <s...@chromium.org> wrote: > Hi Mario, > > On 15 January 2018 at 20:28, Simon Glass <s...@chromium.org> wrote: >> Hi Mario, >> >> On 14 January 2018 at 23:23, Mario Six <mario....@gdsys.cc> wrote: >>> Hi Simon, >>> >>> On Fri, Dec 29, 2017 at 4:13 AM, Simon Glass <s...@chromium.org> wrote: >>>> Hi Mario, >>>> >>>> On 20 December 2017 at 07:31, Mario Six <mario....@gdsys.cc> wrote: >>>>> From: Mario Six <s...@gdsys.cc> >>>>> >>>>> To debug device tree issues involving 32- and 64-bit platforms, it is >>>>> useful to >>>>> have a generic 64-bit platform available. >>>>> >>>>> Add a version of the sandbox that uses 64-bit integers for its physical >>>>> addresses as well as a modified device tree. >>>>> >>>>> Signed-off-by: Mario Six <mario....@gdsys.cc> >>>>> >>>>> --- >>>>> arch/sandbox/Kconfig | 6 + >>>>> arch/sandbox/cpu/cpu.c | 2 +- >>>>> arch/sandbox/dts/Makefile | 4 + >>>>> arch/sandbox/dts/sandbox64.dts | 317 >>>>> +++++++++++++++++++++++++++++++++++++++ >>>>> arch/sandbox/include/asm/io.h | 6 + >>>>> arch/sandbox/include/asm/types.h | 14 +- >>>>> cmd/demo.c | 6 +- >>>>> configs/sandbox64_defconfig | 200 ++++++++++++++++++++++++ >>>>> drivers/demo/demo-simple.c | 2 +- >>>>> 9 files changed, 550 insertions(+), 7 deletions(-) >>>>> create mode 100644 arch/sandbox/dts/sandbox64.dts >>>>> create mode 100644 configs/sandbox64_defconfig >>>> >>>> Reviewed-by: Simon Glass <s...@chromium.org> >>>> >>>> Can you please update the sandbox README? >>>> >>> >>> Sure, I'll extend the README. >>> >>>> Also, how does this play with CONFIG_SANDBOX_64BIT and CONFIG_PHYS_64BIT ? >>>> >>> >>> Yeah, the names of the config options are all a bit confusing (hence why I >>> added the RFC to see if someone may have a better idea). Setting the >>> CONFIG_PHYS_64BIT is not strictly necessary for the 64-bit sandbox, but some >>> architectures use the option to decide whether they run on a 32- or 64-bit >>> system, so I thought it was consistent to also set it, just in case. The >>> CONFIG_SANDBOX_64BIT option causes a 64-bit sandbox *binary* to be built. >>> This >>> binary still uses 32-bit-wide types in the device tree (phys_addr_t and >>> phys_size_t, mostly, so the width of the physical addresses are still >>> 32-bit), >>> so that's not what we want in this case. I decided to override the type >>> definitions in arch/sandbox/include/asm/types.h based on CONFIG_SANDBOX64 >>> directly, since I didn't want to introduce yet another option that has the >>> words sandbox and 64 in its name. But it's pretty confusing still, I admit. >>> >>> Maybe we could rename CONFIG_SANDBOX_64BIT to CONFIG_HOST_64BIT, and use >>> CONFIG_PHYS_64BIT to control the width of the physical addresses in types.h >>> (which is what it is used for in arch/arm/include/asm/types.h now that I'm >>> taking a closer look); that would at least make the names congruent with >>> their >>> actual semantics. We would then have the options CONFIG_HOST_64BIT, >>> CONFIG_PHYS_64BIT, and CONFIG_SANDBOX64 as the "board option". >>> >>> Maybe that's a cleaner solution? >> >> Yes I think that is a good idea. > > Do you have a new version in the works? >
Yes, sorry, v2 is about to land. > Regards, > Simon > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
