Ok,I got a little excited, [ddf] vs [dff].
Sometimes I’m easily confused.
On May 7, 2018, at 10:54 AM, Joe van Tunen
On 5/7/18, 4:56 AM, "Segher Boessenkool" <segher(a)kernel.crashing.org>
On Mon, May 07, 2018 at 07:33:04AM -0400, Jd Lyons wrote:
Ok, I think the reason for the exception with
[dff] is I don’t have an active device tree node. So, “ /pci/@x” open-dev to my-self works
on Apple’s implementation of OF, but Openbios and SLOF deal with things a little
s” /pci/@x” select-dev
That works in SLOF, otherwise SLOF throws an exception with [dff] and tells us there is
no active device tree node.
You should use begin-package and new-device or the like. See the Open
Firmware specification glossary entries for those words and byte-load .
Doesn’t anyone know how I can view the active
device tree node?
my-self ihandle>phandle ( -- phandle) and do some stuff with that,
or just use pwd .
Is there a reason this thread isn't going to the openbios mailing list?
Do you mean [dff] or [ddf]? Wasn't the evidence pointing to [ddf]?
[ddf] calls the parent's map-in function a few times. The "PCI Bus Binding to
Open Firmware" document mentions a bug with map-in which existed in Apple's
original Open Firmware implementation. Do QEMU and the Quicksilver G4 both have a
correctly implemented map-in function?
What is the maximum dictionary space allowed by QEMU's OpenBIOS? If the maximum is
reached, does it grow or does an exception occur? It's probably not likely that the
nvidia fcode is exceeding this limit, but it would be good to have a method to confirm