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

[Segher Boessenkool]

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!)

We cannot translate between the two types of phandles, because we do not
(and CANNOT) know what parts of properties are phandles (for example
when using FCode on a plugin board).

Or maybe phandles on flat device trees just are cell size and the spec
(I looked at devicetree.org) is horribly wrong?  That would be good
(here and everywhere else).


Segher