From mboxrd@z Thu Jan  1 00:00:00 1970
From: Chen Baozi <baozich@gmail.com>
Subject: Re: Domain 0 crashed when booting OMAP5 uEVM
Date: Thu, 15 Aug 2013 18:59:19 +0800
Message-ID: <9D2BAA06-8A4A-455F-85AE-36C11AFCA65E@gmail.com>
References: <20130812122452.GA21443@cbz-workstation>
	<5208D969.6090708@linaro.org>
	<20130813091007.GA16513@cbz-workstation>
	<CAGQvs6jX1geF5vMi-KjiPZt4riRqtY_n1WZxkVCadKwtaNS0dQ@mail.gmail.com>
	<CAPnVf8y=AkAkmRdUBwSGFM0TJ4pdq3T-yRDC4mFDE9yQyEURYg@mail.gmail.com>
	<E8556B21-D916-49A3-8F0F-EF6264E71533@gmail.com>
	<CAPnVf8y3r9wbY3zrBAsrZohjLpUaQ-LUWKz15_NrYdX79bCzMg@mail.gmail.com>
	<1EA3C0D2-F1BB-4EC9-B154-DEA746D9F2BC@gmail.com>
	<CAPnVf8zjsRyuEzR1zmwmnCq88Jria_KK0hHQWf_GxZ=T-nad_A@mail.gmail.com>
	<20130815094724.GA8286@cbz-workstation>
	<CAPnVf8wTfxiOJiOoEF55OenSSseD7CZX--E7QPscCGH9xEDNiA@mail.gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAPnVf8wTfxiOJiOoEF55OenSSseD7CZX--E7QPscCGH9xEDNiA@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Julien Grall <julien.grall@linaro.org>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Andrii Anisov <andrii.anisov@globallogic.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org


On Aug 15, 2013, at 6:07 PM, Julien Grall <julien.grall@linaro.org> wrote:

> On 15 August 2013 10:47, Chen Baozi <baozich@gmail.com> wrote:
>> On Thu, Aug 15, 2013 at 10:13:15AM +0100, Julien Grall wrote:
>>> On 14 August 2013 13:38, Chen Baozi <baozich@gmail.com> wrote:
>>>> 
>>>> On Aug 14, 2013, at 5:55 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>> 
>>>>> On 14 August 2013 10:46, Chen Baozi <baozich@gmail.com> wrote:
>>>>>> 
>>>>>> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>>>> 
>>>>>>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>>>>>>>> disable printings from LK decompressor (it writes directly to omap debug
>>>>>>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>>>>>>>> abort)
>>>>>>> 
>>>>>>> With Chen's patch series and the latest Xen, you don't need to disable
>>>>>>> LK decompressor.
>>>>>>> Xen has a basic emulation for "stolen" UART.
>>>>>> 
>>>>>> BTW, does it mean that we don't need to set the UART status "disabled" in DTS?
>>>>> 
>>>>> Unfortunately, no. The UART emulation is too simple to handle the real driver.
>>>>> I'm currently preparing a patch series which will remove this hack in the DTS.
>>>> 
>>>> Another question.
>>>> 
>>>> Before I saw Linux booting message, there is a line of message:
>>>> 
>>>> (XEN) vgic.c:435:d0 vGICD: GICD_SGIR write r=fe0000 vcpu_mask=fe, wrong CPUTargetList
>>>> 
>>>> Is it a big issue for booting dom0?
>>> 
>>> I don't think so. Linux is trying to send an SGI to a non-running VCPU.
>>> 
>>> I'm curious to know why Linux is trying to do this. Can you try to
>>> apply the patch below and paste dom0 output log?
>>> 
>> 
>> FYI,
>> 
>> [    1.139260] CPU: Testing write buffer coherency: ok
>> [    1.140167] /cpus/cpu@0 missing clock-frequency property
>> [    1.140181] /cpus/cpu@1 missing clock-frequency property
>> [    1.140214] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> [    1.140245] Setting up static identity map for 0xc0511478 - 0xc05114d0
>> [    1.143730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3+ #19
>> [    1.143766] [<c001b5ec>] (unwind_backtrace+0x0/0xf8) from [<c0017b90>] (show_stack+0x1)
>> [    1.143786] [<c0017b90>] (show_stack+0x10/0x14) from [<c0506940>] (dump_stack+0x70/0x8)
>> [    1.143806] [<c0506940>] (dump_stack+0x70/0x8c) from [<c02bca50>] (gic_raise_softirq+0)
>> [    1.143823] [<c02bca50>] (gic_raise_softirq+0x64/0x70) from [<c00192f8>] (arch_send_wa)
>> [    1.143844] [<c00192f8>] (arch_send_wakeup_ipi_mask+0x18/0x1c) from [<c002e6ec>] (omap)
>> [    1.143860] [<c002e6ec>] (omap4_boot_secondary+0xf4/0x174) from [<c0018f78>] (__cpu_up)
>> [    1.143877] [<c0018f78>] (__cpu_up+0x84/0x130) from [<c004408c>] (_cpu_up+0xd4/0x154)
>> [    1.143894] [<c004408c>] (_cpu_up+0xd4/0x154) from [<c0044184>] (cpu_up+0x5c/0x84)
>> [    1.143916] [<c0044184>] (cpu_up+0x5c/0x84) from [<c0740ba4>] (smp_init+0x9c/0xd4)
>> [    1.143935] [<c0740ba4>] (smp_init+0x9c/0xd4) from [<c072789c>] (kernel_init_freeable+)
>> [    1.143954] [<c072789c>] (kernel_init_freeable+0x70/0x1c4) from [<c0501d2c>] (kernel_i)
>> [    1.143972] [<c0501d2c>] (kernel_init+0x8/0xe4) from [<c0013f48>] (ret_from_fork+0x14/)
>> [    2.152167] CPU1: failed to come online
>> [    2.152516] Brought up 1 CPUs
>> [    2.152527] SMP: Total of 1 processors activated (12.28 BogoMIPS).
>> [    2.152535] CPU: All CPU(s) started in SVC mode.
> 
> Xen uses PSCI to bring up secondary VCPU. It seems Linux is trying to
> bring up the CPU with omap callbacks which is wrong.
> 
> Did you add a PSCI node in your device tree?
> psci {
>      compatible      = "arm,psci";
>      method          = "hvc";
>      cpu_on          = <2>;
> };

Oops, that is the point. I didn't add it. And it would be OK after adding.

Thanks.

Baozi