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

[Scott Wood]

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.

-Scott