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. 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
HTH,
Mark.