qemu-ppc
[Top][All Lists]
Advanced

[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: Scott Wood
Subject: Re: [Qemu-ppc] Problem booting qemu-system-ppc with cpu e500XX and machine mpc8544ds
Date: Thu, 5 Jul 2012 13:31:09 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

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...

-Scott




reply via email to

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