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 joevt@shaw.ca wrote:
On 5/7/18, 4:56 AM, "Segher Boessenkool" segher@kernel.crashing.org wrote:
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 different.
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 .
Segher
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 this.