From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754939AbbCFMSk (ORCPT ); Fri, 6 Mar 2015 07:18:40 -0500 Received: from mailout2.samsung.com ([203.254.224.25]:64125 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753997AbbCFMSh (ORCPT ); Fri, 6 Mar 2015 07:18:37 -0500 X-AuditID: cbfee68f-f791c6d000004834-4a-54f99b1a9f77 Message-id: <54F99B1A.3080600@samsung.com> Date: Fri, 06 Mar 2015 21:18:34 +0900 From: Chanwoo Choi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-version: 1.0 To: Mark Rutland Cc: Chanwoo Choi , "kgene@kernel.org" , Marc Zyngier , "arnd@arndb.de" , "olof@lixom.net" , Catalin Marinas , Will Deacon , "inki.dae@samsung.com" , "chanho61.park@samsung.com" , "sw0312.kim@samsung.com" , "jh80.chung@samsung.com" , "ideal.song@samsung.com" , "a.kesavan@samsung.com" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-samsung-soc@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC References: <1425533911-14800-1-git-send-email-cw00.choi@samsung.com> <1425533911-14800-2-git-send-email-cw00.choi@samsung.com> <20150305122459.GC14093@leverpostej> <20150305170450.GG14093@leverpostej> <20150305185407.GK14093@leverpostej> <54F9140B.3060109@samsung.com> <20150306114021.GF8700@leverpostej> In-reply-to: <20150306114021.GF8700@leverpostej> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsWyRsSkUFdq9s8Qg0MbDC0er1nMZPF30jF2 i/fLehgtLu/Xtnh2VNti/pFzrBa7/t5ntJh0fwKLxY1fbawW/Y9fM1tsenyN1eLyrjlsFjPO 7wPqvPOPzWLp9YtMFqeufwaKTX7JZvHy4wkWByGPNfPWMHr8/jWJ0WPnrLvsHptWdbJ5bF5S 73HlRBOrR9+WVYwenzfJBXBEcdmkpOZklqUW6dslcGW0z4orOCRc8W/VJpYGxoX8XYycHBIC JhIP+ucxQ9hiEhfurWfrYuTiEBJYyigxY1MTG0zRyXunWCAS0xklbu46wwSSEBJ4zShxfwY3 iM0roCUxYetusEksAqoSDWuesIPYbEDx/S9ugA0SFQiTWDn9CgtEvaDEj8n3wGwRAXWJnl1f wBYwCzxkk5jyZR9YQlggUuJUTx8TxOaTzBI7Dm8H28ApYCCxfFMbI4jNLKAjsb91GhuELS+x ec1bqH/Wckgcf64NcZGAxLfJh4CGcgDFZSU2HYAqkZQ4uOIGywRGsVlIbpqFZOosJFMXMDKv YhRNLUguKE5KLzLWK07MLS7NS9dLzs/dxAiM/tP/nvXvYLx7wPoQowAHoxIPb4PwzxAh1sSy 4srcQ4ymQFdMZJYSTc4Hppi8knhDYzMjC1MTU2Mjc0szJXHehVI/g4UE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwegbFzEv88P23rKzHpPtnP8yNt/wp5iJ3XHvBt5hZD0/u71FgLpv1Kij5 5Dfrs18bH8Z6s3NXhXqK3Alm4k2xOH7sU96tFYzi8Y6CYrtme6XqfTvy3evjRLPQsHdPPnYf kHPMk9Y0j1wx++bsdY16leKlRrt/WzBM8boWlcFm/t3EfuqEFI9TSizFGYmGWsxFxYkAYd68 AvkCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIKsWRmVeSWpSXmKPExsVy+t9jQV2p2T9DDHYsV7d4vGYxk8XfScfY Ld4v62G0uLxf2+LZUW2L+UfOsVrs+nuf0WLS/QksFjd+tbFa9D9+zWyx6fE1VovLu+awWcw4 vw+o884/Noul1y8yWZy6/hkoNvklm8XLjydYHIQ81sxbw+jx+9ckRo+ds+6ye2xa1cnmsXlJ vceVE02sHn1bVjF6fN4kF8AR1cBok5GamJJapJCal5yfkpmXbqvkHRzvHG9qZmCoa2hpYa6k kJeYm2qr5OIToOuWmQP0ipJCWWJOKVAoILG4WEnfDtOE0BA3XQuYxghd35AguB4jAzSQsIYx o31WXMEh4Yp/qzaxNDAu5O9i5OSQEDCROHnvFAuELSZx4d56ti5GLg4hgemMEjd3nWECSQgJ vGaUuD+DG8TmFdCSmLB1NzOIzSKgKtGw5gk7iM0GFN//4gYbiC0qECaxcvoVFoh6QYkfk++B 2SIC6hI9u76wgCxgFnjIJjHlyz6whLBApMSpnj4miM0nmSV2HN4OtoFTwEBi+aY2RhCbWUBH Yn/rNDYIW15i85q3zBMYBWYhWTILSdksJGULGJlXMYqmFiQXFCel5xrqFSfmFpfmpesl5+du YgQnl2dSOxhXNlgcYhTgYFTi4W0Q/hkixJpYVlyZe4hRgoNZSYQ3aBpQiDclsbIqtSg/vqg0 J7X4EKMpMAwmMkuJJucDE19eSbyhsYmZkaWRuaGFkbG5kjivkn1biJBAemJJanZqakFqEUwf EwenVANj+tOkBWfOHTWv/Hbf+YZ3wvlny/f/2/2P6X/dFntm5gcOJwLfyk2ctfxmf/CPcB2X s3rJn6r/rpIQs8mLv1ZUoBVce+XmxJW8pdN5p0zPfV7HFiu+kfemSRur0dlW1T39N2dp9bQq hMhf/Hv0204G/Xu8ziGmlTMkp5m7iigv2uiZ2/JLUWWDEktxRqKhFnNRcSIAEjlkW0QDAAA= DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 03/06/2015 08:40 PM, Mark Rutland wrote: >>>>>> CPU0 (boot CPU) is only well working for CPU_OFF. >>>>>> But when I try to turn on the CPU0 after CPU_OFF, I failed it. >>>>> >>>>> That's rather worrying. Can you look into what's going on here? I'd >>>>> rather not have dts describing things which are known to be broken. >>>> >>>> The board dts don't include any node for CPU_ON/OFF. >>> >>> I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node >>> quoted above, and all the CPUs had enable-method = "psci". >> >> I mean that there are not additional dt node except for 'cpu' and 'psci' node. > > The psci node and cpu enable-method are sufficient. No other nodes > should be relevant. You're right. > >>> >>>> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen. >>>> After lockup happen, I cannot use the console. >>> >>> That sounds like a pretty major bug. >>> >>> Are you able to investigate with a hardware debugger? >> >> I can't do because there are not any jtag connector. > > That is very unfortunate. Which PSCI implementation are you using? > Surely whoever developed it has access to debug. Surely they should have > tested this? I just used the lateset Linux 4.0-rc2 for PSCI (arch/arm64/kernel/psci.c) without any modification. Unfortunately, I don't know who is the h/w developer of Exynos5433 SoC. > >>> Do other CPUs eventually log errors regarding the lockup? Or is the >>> machine completely dead from this point on? >> >> I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just show the error log without lockup. >> I gave you wrong infromation about CPU0 off. > > Ok. However that's still a major bug. > > [...] > >>>>>>> I take it CPUs boot at EL2? >>>>> >>>>> Do the CPUs boot at EL1 or EL2? >>>> >>>> Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. >>>> I think that a few SoC provider probably would know it. >>> >>> I guess I asked the wrong question. >>> >>> Do CPUs enter the kernel at EL2 or at EL1? >> >> Could you give me a tip how to check the kernel at EL2 or EL1? > > Hmm... I thought we logged this but it looks like we don't. > > You could hack in a check of is_hyp_mode_available() and > is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, > and whether all CPUs enter at the same mode (mandatory per the boot > protocol). OK, I'll try it. Thanks, Chanwoo Choi