Re: [OpenBIOS] Booting SunOS from OpenBIOS

[Mark Cave-Ayland]

On 05/04/13 08:35, Artyom Tarasenko wrote:
> > Actually there is another option - does the previous allocation before this
> > one that returns 0xffc67000 as the virtual address? In that case it could
> > indicate that va=0x0 doesn't have a special meaning after all.
> >
> > Is it possible for you to post the complete log output from an unpatched
> > OpenBIOS for us to look at so we can see the complete pattern of
> > allocations?
>
> The with the unpatched one it dies pretty early, right after claiming va=0x0.
> See the the attachment.

Got it. Hmmm definitely a special behaviour when va == NULL seems to be 
the more likely explanation for the moment. Let me know if anything 
changes with my latest patch.

Otherwise I think you'd have to disassemble the boot loader a bit to see 
where the va = NULL is coming from. If it's a constant 0x0 then that 
would definitely confirm that the value has a special behaviour.

ATB,

Mark.

Booting SunOS from OpenBIOS

[Artyom Tarasenko]

On Fri, Apr 5, 2013 at 11:25 AM, Mark Cave-Ayland
 wrote:
> On 05/04/13 08:35, Artyom Tarasenko wrote:
> > > Actually there is another option - does the previous allocation before
> > > this
> > > one that returns 0xffc67000 as the virtual address? In that case it could
> > > indicate that va=0x0 doesn't have a special meaning after all.
> > >
> > > Is it possible for you to post the complete log output from an unpatched
> > > OpenBIOS for us to look at so we can see the complete pattern of
> > > allocations?
> >
> > The with the unpatched one it dies pretty early, right after claiming
> > va=0x0.
> > See the the attachment.
>
> Got it. Hmmm definitely a special behaviour when va == NULL seems to be the
> more likely explanation for the moment. Let me know if anything changes with
> my latest patch.
>
> Otherwise I think you'd have to disassemble the boot loader a bit to see
> where the va = NULL is coming from. If it's a constant 0x0 then that would
> definitely confirm that the value has a special behaviour.

With your last patch it looks the same as with the va=0x0 patch,
except for the "bad alignment" error.
The addresses are different, but still not aligned to 0x2000.

OFMEM: ofmem_map_page_range ffdd3000 -> 050800000 000c0000 mode 0000003c
OFMEM: ofmem_map_page_range ffe93000 -> 050200000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe94000 -> 071000000 00001000 mode 0000003c

OFMEM: ofmem_claim phys=ffffffffffffffff size=00080000 align=00001000
OFMEM: ofmem_claim_virt virt=ffffffff size=00080000 align=00001000
OFMEM: ofmem_map_page_range ffc80000 -> 006f80000 00080000 mode 000000bc
OFMEM: ofmem_map_page_range ffe95000 -> d00000000 00001000 mode 0000003c
Configuration device id QEMU version 1 machine id 32
OFMEM: ofmem_map_page_range ffe96000 -> 010000000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe97000 -> 071100000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe98000 -> 071000000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe99000 -> 071200000 00002000 mode 0000003c
OFMEM: ofmem_map_page_range ffe9b000 -> 071400000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe9c000 -> 071900000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe9d000 -> 071910000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe9e000 -> 071f00000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffe9f000 -> 071d00000 00011000 mode 0000003c
OFMEM: ofmem_map_page_range ffeb0000 -> 071e00000 00011000 mode 0000003c
OFMEM: ofmem_map_page_range ffec1000 -> 007fff000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffec2000 -> 010001000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffec3000 -> 078400000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffec4000 -> 078800000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffec5000 -> 078400000 00001000 mode 0000003c
OFMEM: ofmem_map_page_range ffec6000 -> 078c00000 00001000 mode 0000003c
CPUs: 1 x FMI,MB86904
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.0 built on Mar 28 2013 23:34
  Type 'help' for detailed information

0 > boot disk kadb -kdvs 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:
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
OFMEM: ofmem_map_page_range ffc7f000 -> 006f7f000 00001000 mode 000000bc
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
OFMEM: ofmem_map_page_range ffc7e000 -> 006f7e000 00001000 mode 000000bc
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc
OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000
OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000
OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc

^^^^ this one

Boot Release 4.1.4 (sun4m) #2: Fri Oct 14 11:07:52 PDT 1994
Copyright (c) 1983-1990, Sun Microsystems, Inc.
Boot: Romvec version 3.
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
OFMEM: ofmem_map_page_range ffc7c000 -> 006f7c000 00001000 mode 000000bc
root on /iommu/sbus/espdma/esp/sd@0,0 fstype 4.2
Boot: kadb
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
OFMEM: ofmem_map_page_range ffc7b000 -> 006f7b000 00001000 mode 000000bc
.Size: 121296............................+103120+14200 bytes
Statistics:
OFMEM: ofmem_claim phys=ffffffffffffffff size=0003c000 align=00040000
OFMEM: ofmem_claim_virt virt=ffc00000 size=0003c000 align=00000000
OFMEM: ofmem_map_page_range ffc00000 -> 006f00000 0003c000 mode 000000bc
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
OFMEM: ofmem_map_page_range ffc7a000 -> 006f7a000 00001000 mode 000000bc
kadb:
kadb: vmunix
.Size: 1548288......................................................................................................................................................................................................................................................+463688+225704
bytes
OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000
OFMEM: ofmem_claim_virt virt=ffc3c000 size=00003000 align=00000000
OFMEM: ofmem_map_page_range ffc3c000 -> 006f74000 00003000 mode 000000bc
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=ffc3f000 size=00001000 align=00000000
OFMEM: ofmem_map_page_range ffc3f000 -> 006f79000 00001000 mode 000000bc
.OFMEM: ofmem_claim phys=ffffffffffffffff size=0001c000 align=00020000
OFMEM: ofmem_claim_virt virt=ffc40000 size=0001c000 align=00000000
OFMEM: ofmem_map_page_range ffc40000 -> 006f40000 0001c000 mode 000000bc
................OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000
align=00001000
OFMEM: ofmem_claim_virt virt=ffc5c000 size=00001000 align=00000000
OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc
OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000
OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc
...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000
OFMEM: Non-free virtual memory claimed!

^^^^ overlaps with this one.

OFMEM: ofmem_map: Bad parameters (006f5c000 FFFFFFFF 00002000)
OFMEM: ofmem_map_page_range fffff000 -> 006f5c000 00002000 mode 000000bc
ran out of memory for symbol table.
halt, power off

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