[U-Boot] [PATCH RFC] sandbox: Add 64-bit sandbox

Mario Six mario.six at gdsys.cc
Fri Jan 19 07:16:51 UTC 2018


Hi Simon,

On Thu, Jan 18, 2018 at 10:44 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Mario,
>
> On 15 January 2018 at 20:28, Simon Glass <sjg at chromium.org> wrote:
>> Hi Mario,
>>
>> On 14 January 2018 at 23:23, Mario Six <mario.six at gdsys.cc> wrote:
>>> Hi Simon,
>>>
>>> On Fri, Dec 29, 2017 at 4:13 AM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Mario,
>>>>
>>>> On 20 December 2017 at 07:31, Mario Six <mario.six at gdsys.cc> wrote:
>>>>> From: Mario Six <six at 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.six at 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 <sjg at 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
>


More information about the U-Boot mailing list