On Mon, May 24, 2010 at 9:02 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Andreas Färber wrote:
I've dropped the above patch in favor of a more readable ppc-only one:
diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c index 7631a1c..2a5eca2 100644 --- a/arch/ppc/qemu/ofmem.c +++ b/arch/ppc/qemu/ofmem.c @@ -431,4 +431,5 @@ ofmem_init( void )
ofmem_map( 0, 0, get_ram_bottom(), 0 ); ofmem_map( get_ram_top(), get_ram_top(), ofmem->ramsize - get_ram_top(), 0);
- ofmem_claim(get_ram_top(), ofmem->ramsize - get_ram_top(), 0);
}
ofmem_common.c:is_free considers 0x07f00000 free because it only sees one range in ofmem->phys_range, 0x80000000 size 962560. Thus, I simply claim the reserved part of RAM - no idea what side effects this may have...
On sparc64, instead of ofmem_map, opmem_map_page_range is called, but no ofmem_claim either.
On SPARC64 I think ofmem_walk_boot_map/ofmem_map_page_range are used to set up the translations to cover the regions of memory used to hold OpenBIOS and beyond. According to the spec, a standard claim should NOT automatically generate a mapping IIRC as I had to fix this to get SPARC64 to boot further under OpenSolaris.
Right. For sparc64 we copy mappings from hardware tables set up by asm bootstrap code using a walk over hardware translations. Most of bootstrap mappings are locked into tlb so we do not really need to handle translations for them. Instead we use bootstrap mappings to keep client from allocating memory in those spaces. For other architectures I think we can do the same in arch-specific way (probably walk code can be reused?)
BTW I checked the code using ppc gentoo installation and have not seen a regression when ofmem changes went in.
Either way Haiku then hangs while trying to set the first segment register (mtsrin):
http://dev.haiku-os.org/browser/haiku/trunk/src/system/boot/platform/openfir...
Interesting. It's great to see you making progress with this :)