[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] Problem booting qemu-system-ppc with cpu e500XX and machi

From: Alexander Graf
Subject: Re: [Qemu-ppc] Problem booting qemu-system-ppc with cpu e500XX and machine mpc8544ds
Date: Wed, 4 Jul 2012 14:22:44 +0200

On 04.07.2012, at 14:17, Badrinath Sriman wrote:

>> Does it mean that the lbz instruction is not emulated? I saw in the qemu 
>> code base that it was emulated.
> No, it means that your guest is trying to access memory that is out of its 
> initial TLB mapping, but it didn't set up IVPR+IVOR vectors to handle page 
> faults yet.
> Either try and see if it works with current git from 
> git://git.qemu.org/qemu.git or check out mmubooke_create_initial_mapping in 
> hw/ppce500_mpc8544ds.c and increase the map size.
> I tried from the git, but still the problem continues. I went through the 
> function mmubooke_create_initial_mapping to try and increase the map size. So 
> far, I have only been a qemu user and hence I do not have a reasonable 
> understanding of qemu code base/flow. 
> To increase the TLB map size, I tried changing the following line inside this 
> function:
> ps = booke206_page_size_to_tlb(dt_end) + 1;
> I tried different increments like 2 and 4, instead of 1 like
> ps = booke206_page_size_to_tlb(dt_end) + 2;
> ps = booke206_page_size_to_tlb(dt_end) + 4;
> The "info tlb" inside qemu monitor which initially showed TLB size as 64M, 
> now show 512M (when I changed it to 4).
> But the hang problem still continues. Hence, the problem may be that I am not 
> doing the proper change for increasing the TLB map size. 
> I also saw that recently you have committed a patch related to TLB sizing, as 
> given in 
> http://lists.gnu.org/archive/html/qemu-ppc/2012-06/msg00255.html.
> The head version that i am trying also has this fix. 
> So, please advise on what variable/line to modify to increase the TLB map 
> size.

Please add "cpu" to your -d parameters and try to find out what the contents of 
r9 are at that point, so we can see what it tries to access.
It might also help to call gdb on your binary and check which line you're in 
there. That might give hints to the semantics of things.

I'd assume given the function name "e500_cnputc" that something is trying to 
write to the serial port, which is mapped very high up.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]