Am 24.05.2010 um 17:21 schrieb Artyom Tarasenko:
2010/5/24 Andreas Färber andreas.faerber@web.de:
Am 24.05.2010 um 16:22 schrieb Stefan Reinauer:
On 5/24/10 4:18 PM, Andreas Färber wrote:
phys = ofmem_claim_phys_( addr, size, align, 0,get_ram_size() - 0x00100000 - (2 << 15) - (32 + 32 + 64) * 1024, 1 /* reverse */ );
virt = ofmem_claim_virt_( addr, size, align, 0,get_ram_size() - 0x00100000 - (2 << 15) - (32 + 32 + 64) * 1024, 1 /* reverse */ );
The question is, why does claim overwrite the 0x07ed0000 identity map of length 1245184, that I see no in my debug output now, with a 0x07f00000 map when using the vanilla OpenBIOS code? And do we need to supply platform-specific functions arch_get_ram_top and arch_get_ram_bottom, or is my approach just working around the problem?
Not sure if it's a platform-specific problem: on sparc32 with a similar patch Solaris boot gets a bit further.
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.
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...
Andreas