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

[Mark Cave-Ayland]

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?


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs