On 4/9/10, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
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
There is some information in the header file, arch/sparc32/openprom.h and how Linux uses it (arch/sparc/prom/*).
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.
Should be a good idea. There are some hacks now for Solaris/SunOS but I think this way is cleaner.