[OpenBIOS] Solaris 8 - fun with CPUs :)

Artyom Tarasenko atar4qemu at gmail.com
Tue Apr 19 08:59:57 CEST 2011


On Tue, Apr 19, 2011 at 12:15 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> On 18/04/11 17:00, Mark Cave-Ayland wrote:
>
>> A quick watchpoint later showed that this is in fact controlled by the
>> presence of a zero-length attribute called "aligned-allocator" under
>> /openprom. Since this property appears in the sample prtconf output,
>> then it suggests that this code path is triggered by OBP. Rather
>> bizarrely, if I add this property to OpenBIOS then kadb crashes further
>> down the line - BUT if I simply use gdb to make kadb think the property
>> is present by changing the relevant register within gdb then I am able
>> to load kadb?!
>>
>> I think I'm probably about 90% there when it comes to getting kadb up
>> and running under OpenBIOS, but I still need to figure out why just
>> adding the missing property isn't enough here.
>
> Okay - so it looks like I win the prize for discovering a new romvec entry
> point :)  When the /openprom/aligned-allocator property exists with zero
> length, kadb somehow manages to get ufsboot to jump to a different offset
> within the romvec parameter block. Tracing the offset through gdb shows that
> it is trying to jump to the function pointer at this location in openprom.h:
>
> int filler[15];
>
> Hmmm. Since this was set to NULL, it was causing kadb to trap when trying to
> allocate memory from OpenBIOS. Anyhow the parameters look pretty much like
> obp_dumb_memalloc() except with an extra parameter probably giving the
> alignment. So with a quick patch I can now fire up kadb like this:

Great Job!

> 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 Apr 18 2011 21:08
>  Type 'help' for detailed information
>
> 0 > boot cdrom:d kadb -kvd Not a bootable ELF image
> Loading a.out image...
> Loaded 7680 bytes
> entry point is 0x4000
> bootpath: /iommu/sbus/espdma/esp/sd at 2,0:d
>
> Jumping to entry point 00004000 for type 00000005...
> switching to new context:
> Size: 119204+222573+28987 Bytes
> kadb:
> kadb: kernel/unix
> Size: 259040+54154+47486 Bytes
> /platform/SUNW,SPARCstation-5/kernel/unix loaded - 0x95000 bytes used
> kadb[0]: :c
> stopped at:
> scb:            sethi   %hi(0xf0041000), %l3
> kadb[0]: :c
> SunOS Release 5.8 Version Generic_108528-09 32-bit
> Copyright 1983-2001 Sun Microsystems, Inc.  All rights reserved.
> \
>
>
> Alas unfortunately I have no idea what this new mystery function is called,
> so if anyone can come up with a more suitable name please let me know.

Have you looked how the calling function is named? Maybe this could give a hint.

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/



More information about the OpenBIOS mailing list