Hello,
Am 31.12.2009 um 17:32 schrieb Andreas Färber:
Am 26.12.2009 um 23:24 schrieb Andreas Färber:
Am 22.12.2009 um 22:48 schrieb Andreas Färber:
checking for memory... 0: base = 0x00000000, size = 134217728 1: empty region total physical memory = 128 MB suggested page table size = 1048576 need new page table, size = 1048576! new table at: 0x07f00000
This hang here can be reproduced by the following 1-byte memset (given -m 128). The commented-out memset does not trigger it.
I've dug some more and noticed that the data parsed from /chosen/mmu/ translations seems wrong:
0: map: 0x00000000, length 16384 -> physical: 0x00000000, mode 132972544 1: map: 0x00030000, length 0 -> physical: 0x07f00000, mode 1048576 2: map: 0x00000002, length -2147483648 -> physical: 0x000eb000, mode 106
Note the weird mode and subsequent values. It looks as if Haiku expects (and gets on real OpenFirmware): void *virtual_address int length void *physical_address int mode whereas OpenBIOS writes in libopenbios/ ofmem_common.c:ofmem_update_mmu_translations: props[ncells++] = t->virt props[ncells++] = t->size props[ncells++] = t->mode
Should this be changed as follows, or is this platform-dependent?
diff --git a/libopenbios/ofmem_common.c b/libopenbios/ofmem_common.c index 8a577b6..71afbc0 100644 --- a/libopenbios/ofmem_common.c +++ b/libopenbios/ofmem_common.c @@ -182,7 +182,7 @@ static void ofmem_update_mmu_translations( void ) for( t = ofmem->trans, ncells = 0; t ; t=t->next, ncells++ ) { }
- props = malloc(ncells * sizeof(ucell) * 3); + props = malloc(ncells * sizeof(ucell) * 4);
if (props == NULL) return; @@ -190,6 +190,7 @@ static void ofmem_update_mmu_translations( void ) for( t = ofmem->trans, ncells = 0 ; t ; t=t->next ) { props[ncells++] = t->virt; props[ncells++] = t->size; + props[ncells++] = t->phys; props[ncells++] = t->mode; }
Thanks, Andreas