[OpenBIOS] Booting SunOS from OpenBIOS

Artyom Tarasenko atar4qemu at gmail.com
Thu Mar 28 14:52:39 CET 2013


Hi Mark,

On Thu, Mar 28, 2013 at 12:59 PM, Mark Cave-Ayland
<mark.cave-ayland at 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 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?

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 !

-- 
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu



More information about the OpenBIOS mailing list