On 11/02/14 00:44, Olivier Danet wrote:
I knew you would not like that ...
Allocation :
- In the current code, 'arch/sparc32/lib.c:obp_memalloc(va,size,align)'
always calls ofmem_claim_virt(va,size,align) with align=0. So allocating with va=0 does not work.
IIRC, there was also a problem ensuring that the physical and virtual areas had the same size and alignment.
Deallocation :
Here is a log of NextStep booting the ISO, with these crazy patches and this option in OpenBIOS :
<option name="CONFIG_DEBUG_OFMEM" type="boolean" value="true"/> and "#define CONFIG_DEBUG_MEM" in arch/sparc32/lib.c ... and a few manual linefeeds
(big cut)
The big problem is in : obp_dumb_memfree: virta 0xf0180000, sz 4120576 (=0x3EE000)
No memory starting at 0xf0180000 was ever allocated! There is instead something at 0xf016e000, sz 4194304 (0x400000)
There is certainly a relation, as the end match : f016e000+400000 = F056E000 f0180000+3EE000 = F056E000
I tried a bit to trace Sun's OFW with gdb, but with no luck. I don't know whether it is a bug in OpenBIOS, QEMU or NextSTEP. It certainly does not look reasonable...
Thanks for the traces - these are really helpful! :) First thing to check is, are these traces from an unpatched SVN trunk? For example your output looks like this:
obp_memalloc: virta 0xf016e000, sz 4194304, align 4 OFMEM: ofmem_claim phys=ffffffffffffffff size=00400000 align=00000004 OFMEM: ofmem_claim_virt virt=f016e000 size=00400000 align=00000004 OFMEM: ofmem_claim_virt virt=f016e000 size=00400000 align=00000000 OFMEM: ofmem_map_page_range f016e000 -> 0069c0000 00400000 mode 000000bc
According to obp_memalloc(), ofmem_claim_virt() should only be called once whereas in these traces it is being called twice?
ATB,
Mark.