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

[Blue Swirl]

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 >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Sparc64-fix-mmu_map.patch
Type: application/mbox
Size: 640 bytes
Desc: not available
URL: <http://lists.openbios.org/pipermail/openbios/attachments/20091204/c54fa5bd/attachment.bin>