Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update

[Thomas Huth]

On 29.09.2017 10:18, Segher Boessenkool wrote:
> On Fri, Sep 29, 2017 at 04:19:59PM +1000, David Gibson wrote:
>> On Thu, Sep 28, 2017 at 03:49:14AM -0500, Segher Boessenkool wrote:
>>> On Thu, Sep 28, 2017 at 07:49:36AM +0100, Mark Cave-Ayland wrote:
>>>> Yeah I don't think this will be an issue. In OpenBIOS each device node
>>>> is modelled by a Forth struct with the children, peers and properties
>>>> modelled as linked lists (the phandle is actually the pointer to this
>>>> struct).
>>>>
>>>> I'm not that familiar with SLOF at source level, but if it does the same
>>>> then it's not too difficult to model the same structure but in C. Add in
>>>> some generic linked list traversal routines to iterate over the DT and
>>>> its properties and you should be good.
>>>
>>> It's about the same in SLOF.  Walking the device tree and converting
>>> it to an FDT should be pretty trivial (you need node>qname and perhaps
>>> cull some properties, for FDT peculiarities, but that's about it).
>>
>> 'name' should be the only property to cull.  You'll also need to
>> generate synthetic 'phandle' properties.  Plus some fluff to construct
>> the fdt header and memory reservation block, then split up the
>> structure and strings blocks.  The latter probably means you'll need
>> two working buffers, rather than emitting it all in one pass.
> 
> I'm a bit worried about the phandles FDT requires, which are a different
> size than what OF uses (OF uses cell size, which is 64 bit on 64-bit OF;
> the device tree specification uses 32 bit always).
> 
> Now usually everything lives low in memory, so the top 32 bits will all
> be zeroes, but do we guarantee that anywhere (and do we want to restrict
> to that!)

Currently QEMU puts the RTAS binary and the FDT just at the end of the
RMA or below 2G, whatever is lower (look for RTAS_MAX_ADDR in
hw/ppc/spapr.c). SLOF then puts itself right in front of the FDT from
QEMU (see romfs_base in board-qemu/llfw/stage2.c in the SLOF sources),
so everything related to SLOF always lives in the first 2G of RAM. Thus
we should be fine here.

 Thomas