On 28/03/13 13:52, Artyom Tarasenko wrote:
Can you put together a quick patch for obp_child() and obp_nextnode() so that if CONFIG_DEBUG_OBP is enabled, they also output the package name in the debug string as well as the phandle? Take a look at how obp_proplen uses get-package-property in order to get hold of the "name" property from the package.
(Or in fact, for an even quicker hack, the (void) POP() in obp_proplen() is dropping a pointer to a string itself. So if you display that instead then for your output above you should see the package name displayed)
Ok. Did the later, and now it looks even stranger:
obp_proplen(0xffd35ba8, name) = 6 (iommu) obp_nextnode(0xffd35ba8) = 0xffd36360 obp_proplen(0xffd36360, name) = 5 (obio) obp_nextnode(0xffd36360) = 0xffd39724 obp_proplen(0xffd39724, name) = 12 (FMI,MB86904) obp_nextnode(0xffd39724) = 0x0 Unhandled Exception 0x00000007
But: 0> show-devs ffd2e31c / [...] ffd35ba8 /iommu [...] ffd36360 /obio (hierarchical) [...] ffd3972c /FMI,MB86904 (cpu)
Why does obp_nextnode(0xffd36360) return 0xffd39724 ? According to show-devs it must be 0xffd3972c !
Yeah... that doesn't like quite right at all :/
obp_nextnode() is actually very simple in that it just calls the Forth "peer" word. Do you see the same phandles if you cycle through the device tree using "peer" directly from the OpenBIOS prompt?
0 peer dup u. peer dup u. peer dup u. peer ..etc..
ATB,
Mark.