Artyom Tarasenko wrote:
I'd suggest a good starting point for you would be to first switch over to the libopenbios/ofmem_common.c API in arch/sparc32/lib.c using arch/sparc64/lib.c as a reference, and then similarly update arch/sparc32/romvec.c where appropriate.
If they are so similar, why isn't the code located somewhere in sparc-common?
Probably for two reasons: firstly the ofmem_common.c memory API is quite new, and secondly it's only a few lines and so it would probably be overkill for the job in hand.
I also seem to recall that Blue had a compile time #define in Qemu that would dump the page table contents and so you can use this to verify that the OpenBIOS code is correct. With these two things in place, then you have all the debugging information you need :D
Within the next months I only have time to test, not to develop/refactor.
A quick analysis has shown that obp_dumb_memalloc is probably too dumb: it maps f00aXXXX to 0104xxxx (which seems to be already mapped to 0104xxxx).
totmap[0].num_bytes is always initialized with value 2088960. Is it the size of already mappED memory? Then why does obp_dumb_memalloc decrease this amount? If it is mappABLE, then the value 2088960 seems to be quite small.
I don't think it would be too hard a task with the necessary romvec interface documentation (anyone know where you can get this?). All you have to do is change the existing romvec functions for simple memory alloc/free/map wrapper functions that call the existing routines in ofmem_common.c instead which are already known to work with PPC/SPARC64. Then the existing code (which from your analysis seems to be broken) can just be ripped out.
HTH,
Mark.