On Sun, Apr 7, 2013 at 8:30 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 06/04/13 20:34, Artyom Tarasenko wrote:
Unfortunately not:
Hmmm so a quick look at the Linux source code (and some dumps from QEMU's "info tlb") showed me what has happening here. The problem is that Linux doesn't read the value of the "translations" property from OpenBIOS when taking over the MMU page table - instead it performs a manual scan of the existing page table between a range of addresses.
It looks as if the range is from 0xfe400000 to 0xfff00000, however the lower ends of these ranges seem to be repurposed for debuggers and I/O memory - so it means that if we keep anything too far outside of the PROM range 0xffd00000 to 0xfff00000 then we're going to be in trouble.
Unfortunately because we map the entire framebuffer directly then we don't have much memory to play with :( I think the only solution is to reduce the amount of memory for the Forth machine for SPARC32 by changing MEMORY_SIZE in arch/sparc32/openbios.c, and then tucking it underneath 0xffd00000 as per my last patchset.
So far I can get away with reducing it to 128K, and Bob's original test case for increasing the Forth machine memory (because of lack of memory for the Fcode table) still runs, e.g.
fd000000 1000 l! 00000020 1004 l! 12095145 1008 l! 4d552c74 100c l! 65737401 1010 l! 1412046e 1014 l! 616d6501 1018 l! 10000000 101c l! cd /iommu/sbus " /iommu/sbus" select-dev new-device 1000 1 byte-load
Artyom - can you confirm whether reducing MEMORY_SIZE to 128K is enough for kadb to work in your SunOS image? If that works, I'll create another patch series for you to test.
You mean, instead of modifying ofmem_arch_get_virt_top, right? Yes, this seems to be enough, kadb starts.
-- Regards, Artyom Tarasenko
linux/sparc and solaris/sparc under qemu blog: http://tyom.blogspot.com/search/label/qemu