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

[Alexander Graf]

On 05.07.2012, at 21:26, Scott Wood <address@hidden> wrote:

> On 07/05/2012 01:56 PM, Alexander Graf wrote:
>> 
>> 
>> 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?
> 
> Never mind, I guess it'll work under QEMU.  You wouldn't be able to get
> away with it on real hardware due to WIMG, so I doubt NetBSD is really
> expecting this.

Yeah, I am surprised it doesn't set up any TLBs and/or interrupt vector 
registers. Maybe we're just hitting the panic handler here, which never got 
tested in early boot code?

Doing a bt in gdb is probably the easiest way to find out.

Alex

> 
> -Scott
>