Re: [OpenBIOS] Booting SunOS from OpenBIOS

[Mark Cave-Ayland]

On 26/03/13 08:33, Artyom Tarasenko wrote:
> Hi Mark,
>
> [adding the OpenBIOS mailing list, hoping to get some more feedback]
>
> by the way, currently Jean Michel has to use the proprietary OBP.
> There seems to be a problem with loading the SunOS 4.x under OpenBIOS:
>
> $  sparc-softmmu/qemu-system-sparc -L pc-bios -nographic -hda disk-solaris-1.1.2
>
> 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 Aug 19 2012 13:36
>    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:
> Unhandled Exception 0x00000007
> PC = 0x00401a04 NPC = 0x00401a08
> Stopping execution
>
> Is the OpenBIOS guess correct and SunOS 4.x actually does have an a.out loader?

Yes, that looks good to me. From memory the Solaris 8 bootloader is an 
a.out bootloader based at 0x4000, and the kernel loads at 0x400000 so 
you're definitely getting into the kernel image.

The quick and easy way to get a rough idea as to where the failure lies 
is to copy the kernel ELF image from your Solaris disk image and run 
objdump on it to find out the name of the function where the exception 
occurs based upon the exception address.

If you're already in the kernel panic() function, then use a 
sparc-linux-gdb attached to QEMU with a breakpoint to get a stack 
backtrace at the exception point, which again should give you an idea of 
where the issue is based upon the function names.

HTH,

Mark.

Booting SunOS from OpenBIOS

[Artyom Tarasenko]

On Tue, Mar 26, 2013 at 11:02 AM, Mark Cave-Ayland
 wrote:
> On 26/03/13 08:33, Artyom Tarasenko wrote:
> > There seems to be a problem with loading the SunOS 4.x under OpenBIOS:
> >
> > $  sparc-softmmu/qemu-system-sparc -L pc-bios -nographic -hda
> > disk-solaris-1.1.2
> >
> > 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 Aug 19 2012 13:36
> >    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:
> > Unhandled Exception 0x00000007
> > PC = 0x00401a04 NPC = 0x00401a08
> > Stopping execution
> >
> > Is the OpenBIOS guess correct and SunOS 4.x actually does have an a.out
> > loader?
>
> Yes, that looks good to me. From memory the Solaris 8 bootloader is an a.out
> bootloader based at 0x4000, and the kernel loads at 0x400000 so you're
> definitely getting into the kernel image.
>
> The quick and easy way to get a rough idea as to where the failure lies is
> to copy the kernel ELF image from your Solaris disk image and run objdump on
> it to find out the name of the function where the exception occurs based
> upon the exception address.
>
> If you're already in the kernel panic() function, then use a sparc-linux-gdb
> attached to QEMU with a breakpoint to get a stack backtrace at the exception
> point, which again should give you an idea of where the issue is based upon
> the function names.

I guess with "kernel" you mean the boot loader, since we obviously
don't get far enough for kernel loading.
It doesn't look like it has any symbols though:

$ sparc-linux-gnu-objdump -x -t -T -g  boot

boot:     file format a.out-sunos-big
boot
architecture: sparc, flags 0x00000002:
EXEC_P
start address 0x00400000

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00015158  00000000  00000000  00000020  2**3
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         000042e0  00015158  00015158  00015178  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00018950  00019438  00019438  00000000  2**3
                  ALLOC
sparc-linux-gnu-objdump: boot: not a dynamic object
SYMBOL TABLE:
no symbols

DYNAMIC SYMBOL TABLE:
no symbols

Artyom