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

David Gibson david at gibson.dropbear.id.au
Sat Sep 30 13:18:41 AEST 2017

On Fri, Sep 29, 2017 at 06:04:56PM -0500, Segher Boessenkool wrote:
> On Fri, Sep 29, 2017 at 08:08:56PM +0200, Thomas Huth wrote:
> > On 29.09.2017 10:18, Segher Boessenkool wrote:
> > > 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.
> Yep, and SLOF encodes (at least some) ihandles as just 32 bit (and actually
> reads them from the device tree again constantly, bad plan -- see other
> thread).
> I guess we can live with the restriction, certainly if we only do this
> create-FDT-from-the-real-device-tree thing when running under QEMU.

64-bit phandles would break much, much more than just this proposal.

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_!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/slof/attachments/20170930/349cb8d9/attachment.sig>

More information about the SLOF mailing list