2010/4/9 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Artyom Tarasenko wrote:
Yes, it's a bunch of reads. The first 9 reads (f00890ec-f00a10ec) don't do any visible harm, but f00a30ec is lethal. Under OBP there is more than 30 reads after this point. Didn't count them after this point.
Well given that the same disk code for SPARC64 is reading in several megs at a time without any problems now, I think if there was an issue then it could be in one of the hardware drivers or possibly the MMU.
Wait a minute. I've just noticed that arch/sparc32 hasn't been updated to use the new libopenbios/ofmem_common.c API which will handle the physical memory allocation, virtual memory allocation and mappings for you. And this would explain why CONFIG_DEBUG_OFMEM wouldn't have actually output anything :(
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?
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.