qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform


From: David Gibson
Subject: Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update
Date: Sat, 30 Sep 2017 13:17:55 +1000
User-agent: Mutt/1.9.0 (2017-09-02)

On Fri, Sep 29, 2017 at 03:18:41AM -0500, 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).

Um.  Wat.

Maybe this was theoretically possible at some point.  Maybe there's
just never been a 64-bit OF in this sense.  But in practice phandles
(and all cells) have been always 32-bit for a very, very long time.

Linux has certainly never had any facility to handle 64-bit phandles.
You can tell because there aren't (is OF 64-bit)? conditionals
practically everywhere in the device tree code.

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

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]