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

Blue Swirl blauwirbel at gmail.com
Sat Dec 5 09:22:46 CET 2009 

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?

Anyway I don't see any benefit compared to r639 and we lose the milaX progress.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Revert-r639-fix-mem_claim-Igor-Kovalenko-and-mem_.patch
Type: application/mbox
Size: 1073 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20091205/e0f76d18/attachment-0001.bin>

More information about the OpenBIOS mailing list