[OpenBIOS] r638 - in trunk/openbios-devel/forth: bootstrap device

[Igor Kovalenko]

On Fri, Dec 4, 2009 at 10:28 PM, Blue Swirl <blauwirbel at gmail.com> wrote:
> On Fri, Dec 4, 2009 at 7:40 PM, Mark Cave-Ayland
> <mark.cave-ayland at siriusit.co.uk> wrote:
>> Blue Swirl wrote:
>>
>>>> Yup, that's a bug :-)
>>>
>>> Enabling DEBUG_MMU (and fixing the bugs...) confirms the MMU problem:
>>> DMMU dump:
>>> [46] VA: 8000000, PA: 0,   8k, user, RW, unlocked, ctx 0
>>> [53] VA: 8002000, PA: 0,   8k, user, RW, unlocked, ctx 0
>>> [54] VA: 8004000, PA: 0,   8k, user, RW, unlocked, ctx 0
>>>
>>> The physical address is the same (0) for all three VA entries. Why?
>>
>> Thanks for the independent confirmation (I'll look out for related MMU fixes
>> in Qemu too).
>>
>> I emailed Igor off-list for some pointers, and he suggested enabling
>> debugging in OpenBIOS by setting CONFIG_DEBUG_OFMEM and re-compiling, which
>> gives the following output for the 3 memory claims for 0x8000000, 0x8002000
>> and 0x8004000:
>>
>>
>> OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000
>> align=0000000000000001
>> OFMEM: ofmem_map_page_range 0000000000000000 -> 0000000000000000
>> 0000000000002000 mode 0000000000000032
>> OFMEM: mapping mode altered virt=0000000000000000 old mode=0000000000000036
>> new mode=0000000000000032
>> OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000
>> align=0000000000000001
>> OFMEM: ofmem_map_page_range 0000000010000000 -> 0000000000000000
>> 0000000000002000 mode 0000000000000032
>>
>> OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000
>> align=0000000000000001
>> OFMEM: ofmem_map_page_range 0000000000002000 -> 0000000000002000
>> 0000000000002000 mode 0000000000000032
>> OFMEM: mapping mode altered virt=0000000000002000 old mode=0000000000000036
>> new mode=0000000000000032
>> OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000
>> align=0000000000000001
>> OFMEM: ofmem_map_page_range 0000000008002000 -> 0000200000000000
>> 0000000000002000 mode 0000000000000032
>> OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000
>> align=0000000000000001
>>
>> OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000
>> align=0000000000000001
>> OFMEM: ofmem_map_page_range 0000000000004000 -> 0000000000004000
>> 0000000000002000 mode 0000000000000032
>> OFMEM: mapping mode altered virt=0000000000004000 old mode=0000000000000036
>> new mode=0000000000000032
>> OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000002000
>> align=0000000000000001
>> OFMEM: ofmem_map_page_range 0000000008004000 -> 0000400000000000
>> 0000000000002000 mode 0000000000000032
>> OFMEM: ofmem_claim phys=ffffffffffffffff size=0000000000002000
>> align=0000000000000001
>>
>>
>> With no memory option specified for Qemu, the default setting is 128Mb RAM
>> (which spans addresses 0 - 0x8000000). So looking at the above we can see
>> the following effects:
>>
>>
>> i) The base address for the virtual memory allocator is the top of physical
>> RAM. This doesn't seem too unreasonable.
>>
>> ii) The first request allocated at 0x8000000 is mapped to physical RAM
>> location 0x0. This looks wrong, as normally low pages contain special
>> registers for various things - perhaps we need some kind of base offset
>> here?
>>
>> iii) The second request allocated at 0x8002000 is mapped to physical RAM
>> location 0x200000000000. This is definitely wrong since the maximum physical
>> RAM location is 0x8000000.
>>
>> iv) The third request allocated at 0x8004000 is mapped to physical RAM
>> location 0x400000000000. Again, this is definitely wrong since the maximum
>> physical RAM location is 0x8000000.
>>
>>
>> So this looks to me like an OpenBIOS issue related to finding physical
>> memory slots. I wonder if anything which is attempting to access memory over
>> the physical RAM limit is simply being forced to zero?
>
> With this patch, I get a bit further:
> entry point is 0x4000
> Evaluating FCode...
> invalid access of +vd
>
> Can't mount root
>
> byte-load: exception caught!
>
> 0 >
>

It actually stops earlier, before mmapping is performed.
You should not drop high part of phys addr (because it is passed as 2 cells)
but instead reverse the order in which we assemble address from hi/lo pair.

This makes it out of loop, but still no real progress further than that:

Index: openbios-devel/arch/sparc64/lib.c
===================================================================
--- openbios-devel.orig/arch/sparc64/lib.c
+++ openbios-devel/arch/sparc64/lib.c
@@ -260,9 +260,8 @@ mmu_map(void)
     mode = POP();
     size = POP();
     virt = POP();
-    phys = POP();
-    phys <<= 32;
-    phys |= POP();
+    phys = (POP() & 0xffffffff);
+    phys |= (POP() & 0xffffffff) << 32;

     ofmem_map(phys, virt, size, mode);
 }


-- 
Kind regards,
Igor V. Kovalenko