Hi Mark,
On Thu, Mar 28, 2013 at 12:59 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 28/03/13 08:38, Artyom Tarasenko wrote:
Back to the original topic:
Here is the boot log with romvec debug:
Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Mar 26 2013 13:29 Type 'help' for detailed information Trying disk... Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@0,0
Jumping to entry point 00004000 for type 00000005... switching to new context: obp_nextnode(0x0) = 0xffd4531c obp_child(0xffd4531c) = 0xffd45438 obp_proplen(0xffd45438, name) = 8 obp_nextnode(0xffd45438) = 0xffd454dc obp_proplen(0xffd454dc, name) = 9 obp_nextnode(0xffd454dc) = 0xffd45684 obp_proplen(0xffd45684, name) = 8 obp_nextnode(0xffd45684) = 0xffd456fc obp_proplen(0xffd456fc, name) = 7 obp_nextnode(0xffd456fc) = 0xffd457e0 obp_proplen(0xffd457e0, name) = 8 obp_nextnode(0xffd457e0) = 0xffd4b084 obp_proplen(0xffd4b084, name) = 9 obp_nextnode(0xffd4b084) = 0xffd4ca8c obp_proplen(0xffd4ca8c, name) = 7 obp_nextnode(0xffd4ca8c) = 0xffd4cb30 obp_proplen(0xffd4cb30, name) = 15 obp_nextnode(0xffd4cb30) = 0xffd4cbdc obp_proplen(0xffd4cbdc, name) = 6 obp_nextnode(0xffd4cbdc) = 0xffd4d394 obp_proplen(0xffd4d394, name) = 5 obp_nextnode(0xffd4d394) = 0xffd50758 obp_proplen(0xffd50758, name) = 12 obp_nextnode(0xffd50758) = 0x0 obp_devopen(/iommu/sbus/espdma/esp/sd@0,0) = 0xffc831f8 obp_devseek(fd 0xffc831f8, hi 0, lo 3637248) = 0 obp_devread(fd 0xffc831f8, buf 0x4000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3645440) = 0 obp_devread(fd 0xffc831f8, buf 0x6000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3653632) = 0 obp_devread(fd 0xffc831f8, buf 0x8000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3661824) = 0 obp_devread(fd 0xffc831f8, buf 0xa000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3670016) = 0 obp_devread(fd 0xffc831f8, buf 0xc000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3678208) = 0 obp_devread(fd 0xffc831f8, buf 0xe000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3686400) = 0 obp_devread(fd 0xffc831f8, buf 0x10000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3694592) = 0 obp_devread(fd 0xffc831f8, buf 0x12000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3702784) = 0 obp_devread(fd 0xffc831f8, buf 0x14000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3710976) = 0 obp_devread(fd 0xffc831f8, buf 0x16000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3719168) = 0 obp_devread(fd 0xffc831f8, buf 0x18000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3727360) = 0 obp_devread(fd 0xffc831f8, buf 0x1a000, nbytes 8192) = 8192 obp_devseek(fd 0xffc831f8, hi 0, lo 3743744) = 0 obp_devread(fd 0xffc831f8, buf 0x1c000, nbytes 8192) = 8192 obp_devclose(0xffc831f8) = 1 obp_nextnode(0x0) = 0xffd4531c obp_child(0xffd4531c) = 0xffd45438 obp_proplen(0xffd45438, name) = 8 obp_nextnode(0xffd45438) = 0xffd454dc obp_proplen(0xffd454dc, name) = 9 obp_nextnode(0xffd454dc) = 0xffd45684 obp_proplen(0xffd45684, name) = 8 obp_nextnode(0xffd45684) = 0xffd456fc obp_proplen(0xffd456fc, name) = 7 obp_nextnode(0xffd456fc) = 0xffd457e0 obp_proplen(0xffd457e0, name) = 8 obp_nextnode(0xffd457e0) = 0xffd4b084 obp_proplen(0xffd4b084, name) = 9 obp_nextnode(0xffd4b084) = 0xffd4ca8c obp_proplen(0xffd4ca8c, name) = 7 obp_nextnode(0xffd4ca8c) = 0xffd4cb30 obp_proplen(0xffd4cb30, name) = 15 obp_nextnode(0xffd4cb30) = 0xffd4cbdc obp_proplen(0xffd4cbdc, name) = 6 obp_nextnode(0xffd4cbdc) = 0xffd4d394 obp_proplen(0xffd4d394, name) = 5 obp_nextnode(0xffd4d394) = 0xffd50758
^^^^ is that correct?
obp_proplen(0xffd50758, name) = 12 obp_nextnode(0xffd50758) = 0x0 Unhandled Exception 0x00000007 PC = 0x00401a04 NPC = 0x00401a08 Stopping execution
Now, the last obp_nextnode looks suspicious. It looks like the boot process is iterating over the devices in / without descending, but I don't see the node 0xffd50758. The last two known ones are /iommu (0xffd4cbdc) and /obio (0xffd4d394)
Interesting. Perhaps it could be being added by something earlier in the bootcode?
To me it looks like a pure OpenBIOS issue: it's exactly the value obp_nextnode(0xffd4cbdc) returns.
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 !