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

[Alexander Graf]

On 05.07.2012, at 20:31, Scott Wood <address@hidden> wrote:

> On 07/05/2012 07:07 AM, Alexander Graf wrote:
>> On 07/05/2012 01:54 PM, Badrinath Sriman wrote:
>>>> 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.
>>> 
>>> You are correct. The instruction at 0x00297620 (e500_cnputc) is trying
>>> to write onto the address 0xe0004505, which is the fifth byte of the
>>> serial0 register space, as seen from "info mtree" and also in the
>>> #defines inside ppce500_mpc8544ds.c. The value of register R9 is also
>>> 0xe0004505, as given by the following sample output, extracted from -d
>>> cpu,int, when the first exception occurs:
>>> 
>>> NIP 00297620   LR 0028db6c CTR 000249f0 XER 00000000
>>> MSR 00000000 HID0 00000000  HF 00000000 idx 1
>>> TB 00000000 07108696 DECR 00000000
>>> GPR00 000000000020c438 0000000002d6ddb0 00000000deadbeef 0000000000000000
>>> GPR04 0000000000000020 0000000000000000 0000000000000000 0000000002d6de88
>>> GPR08 0000000000000000 00000000e0004505 00000000022f0000 00000000000249f0
>>> GPR12 0000000020080004 00000000deadbeef 00000000deadbeef 00000000deadbeef
>>> GPR16 0000000002d6de88 00000000deadbeef 00000000deadbeef 00000000deadbeef
>>> GPR20 0000000000000000 0000000000000001 00000000deadbeef 0000000000000005
>>> GPR24 0000000000100040 0000000000a352d9 0000000000000000 0000000000db0000
>>> GPR28 0000000000000000 0000000000000020 00000000022f0000 0000000000000020
>>> CR 40084044  [ G  -  -  L  G  -  G  G  ]             RES ffffffff
>>> FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>> FPSCR 00000000
>>>  SRR0 00000000  SRR1 00000000    PVR 80210022 VRSAVE 00000000
>>> SPRG0 00db5c68 SPRG1 00000000  SPRG2 deadbeef  SPRG3 00db5dbc
>>> SPRG4 00000000 SPRG5 00000000  SPRG6 00000000  SPRG7 00000000
>>> CSRR0 00000000 CSRR1 00000000 MCSRR0 00000000 MCSRR1 00000000
>>>   TCR e0100000   TSR 04000000    ESR 00000000   DEAR 00000000
>>>   PIR 00000000 DECAR 00000000   IVPR 00000000   EPCR 00000000
>>>  MCSR 00000000 SPRG8 00000000    EPR 00000000
>>>  MCAR 00000000  PID1 00000000   PID2 00000000    SVR 00000000
>>>  MAS0 00000000  MAS1 00000000   MAS2 00000000   MAS3 00000000
>>>  MAS4 00000000  MAS6 00000000   MAS7 00000000    PID 00000000
>>> MMUCFG 00000000 TLB0CFG 04110200 TLB1CFG 101cc010
>>> Raise exception at 00297620 =>  0000000d (00)
>>> NIP 00000000   LR 0028db6c CTR 000249f0 XER 00000000
>>> MSR 00000000 HID0 00000000  HF 00000000 idx 1
>>> TB 00000000 07181135 DECR 00000000
>>> GPR00 000000000020c438 0000000002d6ddb0 00000000deadbeef 0000000000000000
>>> GPR04 0000000000000020 0000000000000000 0000000000000000 0000000002d6de88
>>> GPR08 0000000000000000 00000000e0004505 00000000022f0000 00000000000249f0
>>> 
>>> 
>>> In our code base also, the uart console's address space is mapped to
>>> the address 0xe0004500 and the code is trying to write to 0xe0004505,
>>> as seen from gdb output. Looks like the e500_cnputc function is the
>>> e500 equivalent of the C putc function and as writing to the serial 0
>>> register is creating problem, this would explain the blank output
>>> after the qemu-system-ppc command is executed.
>>> 
>>> Does this trigger any known problem or is it an issue with qemu
>>> mpc8544 emulation or with our netbsd implementation?
>> 
>> It means that NetBSD expects a different initial TLB setup from Linux.
>> Please try to give NetBSD a full linear map of all 4GB and it should be
>> happy.
> 
> Not if it's expecting to be able to talk to the serial port...

Why? Do we map it somewhere else?

Alex

> 
> -Scott
>