[OpenBIOS] Booting SunOS from OpenBIOS

[Mark Cave-Ayland]

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 at 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 at 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?

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)


ATB,

Mark.