[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
Re: [Qemu-ppc] [SLOF] [PATCH v4] board-qemu: add private hcall to inform host on "phandle" update
Thu, 5 Oct 2017 10:39:49 +1100
On Wed, Oct 04, 2017 at 08:17:12AM -0500, Segher Boessenkool wrote:
> On Tue, Oct 03, 2017 at 11:21:34AM +1100, David Gibson wrote:
> > > All cells (and all phandles) are 64 bits on a 64-bit OF. This is what
> > > a 64-bit OF _is_, fundamentally: it uses 64-bit cells. Cells are the
> > > fundamental data type: for example stack entries are cells.
> > >
> > > The things in the device tree are 32 bits. A few places in the Open
> > > Firmware specification unfortunately call those "cells" as well.
> > Right. Unfortunate as it may be, that's the main sense in which
> > "cell" is now being used.
> Not in the OF world (or Forth world, even). Culture clash :-)
Sorry. My world's bigger than your world :-p.
> > > With the status quo (32-bit phandles in the device tree, so the client
> > > uses 32-bit phandles as well) we can still use phandles with a non-zero
> > > upper 32 bits in OF, using one of various translation schemes. I was
> > > worried that the translation via FDT would prevent that, force OF to
> > > always use only memory in the low 4GB. I now think that not much changes,
> > > and in practice we will always use low 4GB addresses for OF's memory
> > > anyway. The recommendation in 1275.6 (the 64-bit extension) is similar.
> > So, I'm still a bit unclear on this. Ok, so in a 64-bit OF phandles
> > are 64-bit internally. What happens when they get encoded out into
> > the device tree though (e.g. in 'interrupt-parent' or whatever)?
> > 2) Do they get (somehow) translated down into 32-bit quantities?
Ok, so this is always an issue with a 64-bit OF, and has nothing to do
> And translating 32-bit ihandles and phandles back into "real"
> ones can get complex. But it looks like we won't have to go there :-)
Right. It won't be a problem if you constrain OF's allocations to be
within a 4G region. If not, you're probably going to have to treat
them as indirect labels, and have some sort of lookup table to
translate them to actual pointers. Which makes them pretty much
equivalent to the way FDT treats phandles - an arbitrary, unique,
32-bit label on a node.
Though, TBH, if you really need > 4G for your boot time firmware, what
the _hell_ are you doing.
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_!
Description: PGP signature