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

Blue Swirl blauwirbel at gmail.com
Sat Dec 5 11:21:48 CET 2009


On Sat, Dec 5, 2009 at 11:45 AM, Igor Kovalenko
<igor.v.kovalenko at gmail.com> wrote:
> On Sat, Dec 5, 2009 at 11:22 AM, Blue Swirl <blauwirbel at gmail.com> wrote:
>> On Sat, Dec 5, 2009 at 2:00 AM, Igor Kovalenko
>> <igor.v.kovalenko at gmail.com> wrote:
>>> On Sat, Dec 5, 2009 at 1:37 AM, Nick Couchman <Nick.Couchman at seakr.com> wrote:
>>>>>>> On 2009/12/04 at 14:43, Igor Kovalenko <igor.v.kovalenko at gmail.com> wrote:
>>>>> 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);
>>>>>  }
>>>>
>>>> This still yields the following unhandled exception:
>>>>
>>>> entry point is 0x4000
>>>> Evaluating FCode...
>>>> Unhandled Exception 0x0000000008000000
>>>> PC = 0x00000000ffd10e4c NPC = 0x00000000ffd10e50
>>>> Stopping execution
>>>>
>>>> (gdb) l *0x00000000ffd10e4c
>>>> 0xffd10e4c is in cfetch (../include/openbios/stack.h:34).
>>>> 29      typedef ucell phandle_t;
>>>> 30
>>>> 31
>>>> 32
>>>> 33
>>>> 34      static inline void PUSH(ucell value) {
>>>> 35              dstack[++dstackcnt] = (value);
>>>> 36      }
>>>> 37      static inline void PUSH_xt( xt_t xt ) { PUSH( (ucell)xt ); }
>>>> 38      static inline void PUSH_ih( ihandle_t ih ) { PUSH( (ucell)ih ); }
>>>>
>>>
>>> Right, exception is there still.
>>> Though I found the real issue, return value of mem_claim has reversed
>>> lo/hi cells of physical address.
>>> The following patch fixes that, but r639 must be reverted. With this
>>> change my HelenOS disk boots as before r639 (it does not use mem_claim
>>> obviously, and mmu_map appears to be OK indeed.)
>>>
>>> Signed-off-by: igor.v.kovalenko at gmail.com
>>>
>>> Index: openbios-devel/arch/sparc64/lib.c
>>> ===================================================================
>>> --- openbios-devel.orig/arch/sparc64/lib.c
>>> +++ openbios-devel/arch/sparc64/lib.c
>>> @@ -376,8 +376,8 @@ mem_claim( void )
>>>
>>>     ofmem_map(phys, phys, size, -1);
>>>
>>> -    PUSH(phys >> 32);
>>>     PUSH(phys & 0xffffffffUL);
>>> +    PUSH(phys >> 32);
>>>  }
>>>
>>>  /* ( phys size --- ) */
>>>
>>
>> Shouldn't we then have something like the attached patch for consistency?
>
> ACK. I missed mem_release physical address decoding.
>
>>
>> Anyway I don't see any benefit compared to r639 and we lose the milaX progress.
>>
> We get out of loop compared to r638 I believe so there is still a progress.

OK, I applied the patch then.



More information about the OpenBIOS mailing list