Re: [OpenBIOS] Booting SunOS from OpenBIOS

[Mark Cave-Ayland]

On 06/04/13 20:34, Artyom Tarasenko wrote:
> Unfortunately not:
>
> OFMEM: ofmem_map_page_range ffdd3000 ->  050800000 000c0000 mode 0000003c
> OFMEM: mapping altered virt=ffdd3000)
> 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=ffc80000 size=00080000 align=00000000
>
> ^^^^ this one
>
> 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 13: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 fefff000 ->  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 feffe000 ->  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 feffd000 ->  006f7d000 00001000 mode 000000bc
> OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000
> OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00002000
> OFMEM: ofmem_map_page_range fefe8000 ->  006f60000 00014000 mode 000000bc
> 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 feffc000 ->  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 fefe7000 ->  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 fefe6000 ->  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: ofmem_map_page_range ffc5f000 ->  006f5c000 00002000 mode 000000bc
> .....OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc61000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc61000 ->  006f3e000 00002000 mode 000000bc
> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc63000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc63000 ->  006f3c000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc65000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc65000 ->  006efe000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc67000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc67000 ->  006efc000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc69000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc69000 ->  006efa000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc6b000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc6b000 ->  006ef8000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc6d000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc6d000 ->  006ef6000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc6f000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc6f000 ->  006ef4000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc71000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc71000 ->  006ef2000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc73000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc73000 ->  006ef0000 00002000 mode 000000bc
> ....OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000
> OFMEM: ofmem_claim_virt virt=ffc75000 size=00003000 align=00000000
> OFMEM: ofmem_map_page_range ffc75000 ->  006eec000 00003000 mode 000000bc
> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc78000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc78000 ->  006eea000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00003000 align=00004000
> OFMEM: ofmem_claim_virt virt=ffc7a000 size=00003000 align=00000000
> OFMEM: ofmem_map_page_range ffc7a000 ->  006ee4000 00003000 mode 000000bc
> ....OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc7d000 size=00002000 align=00000000
> OFMEM: ofmem_map_page_range ffc7d000 ->  006ee8000 00002000 mode 000000bc
> ..OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc7f000 size=00002000 align=00000000
> OFMEM: Non-free virtual memory claimed!
>
> ^^^^^ overlaps with this one.

Hmmm so a quick look at the Linux source code (and some dumps from 
QEMU's "info tlb") showed me what has happening here. The problem is 
that Linux doesn't read the value of the "translations" property from 
OpenBIOS when taking over the MMU page table - instead it performs a 
manual scan of the existing page table between a range of addresses.

It looks as if the range is from 0xfe400000 to 0xfff00000, however the 
lower ends of these ranges seem to be repurposed for debuggers and I/O 
memory - so it means that if we keep anything too far outside of the 
PROM range 0xffd00000 to 0xfff00000 then we're going to be in trouble.

Unfortunately because we map the entire framebuffer directly then we 
don't have much memory to play with :(  I think the only solution is to 
reduce the amount of memory for the Forth machine for SPARC32 by 
changing MEMORY_SIZE in arch/sparc32/openbios.c, and then tucking it 
underneath 0xffd00000 as per my last patchset.

So far I can get away with reducing it to 128K, and Bob's original test 
case for increasing the Forth machine memory (because of lack of memory 
for the Fcode table) still runs, e.g.

fd000000 1000 l!
00000020 1004 l!
12095145 1008 l!
4d552c74 100c l!
65737401 1010 l!
1412046e 1014 l!
616d6501 1018 l!
10000000 101c l!
cd /iommu/sbus
" /iommu/sbus" select-dev
new-device
1000 1 byte-load

Artyom - can you confirm whether reducing MEMORY_SIZE to 128K is enough 
for kadb to work in your SunOS image? If that works, I'll create another 
patch series for you to test.

ATB,

Mark.

Booting SunOS from OpenBIOS

[Artyom Tarasenko]

On Sun, Apr 7, 2013 at 8:30 PM, Mark Cave-Ayland
 wrote:
> On 06/04/13 20:34, Artyom Tarasenko wrote:
> > Unfortunately not:
>
> Hmmm so a quick look at the Linux source code (and some dumps from QEMU's
> "info tlb") showed me what has happening here. The problem is that Linux
> doesn't read the value of the "translations" property from OpenBIOS when
> taking over the MMU page table - instead it performs a manual scan of the
> existing page table between a range of addresses.
>
> It looks as if the range is from 0xfe400000 to 0xfff00000, however the lower
> ends of these ranges seem to be repurposed for debuggers and I/O memory - so
> it means that if we keep anything too far outside of the PROM range
> 0xffd00000 to 0xfff00000 then we're going to be in trouble.
>
> Unfortunately because we map the entire framebuffer directly then we don't
> have much memory to play with :(  I think the only solution is to reduce the
> amount of memory for the Forth machine for SPARC32 by changing MEMORY_SIZE
> in arch/sparc32/openbios.c, and then tucking it underneath 0xffd00000 as per
> my last patchset.
>
> So far I can get away with reducing it to 128K, and Bob's original test case
> for increasing the Forth machine memory (because of lack of memory for the
> Fcode table) still runs, e.g.
>
> fd000000 1000 l!
> 00000020 1004 l!
> 12095145 1008 l!
> 4d552c74 100c l!
> 65737401 1010 l!
> 1412046e 1014 l!
> 616d6501 1018 l!
> 10000000 101c l!
> cd /iommu/sbus
> " /iommu/sbus" select-dev
> new-device
> 1000 1 byte-load
>
> Artyom - can you confirm whether reducing MEMORY_SIZE to 128K is enough for
> kadb to work in your SunOS image? If that works, I'll create another patch
> series for you to test.

You mean, instead of modifying ofmem_arch_get_virt_top, right?
Yes, this seems to be enough, kadb starts.

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