From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@linaro.org>
Subject: Re: [ARM:PATCH v2 1/1] Pass the timer clock-frequency
 to DOM0
Date: Fri, 11 Apr 2014 17:32:31 +0100
Message-ID: <5348191F.9030209@linaro.org>
References: <1395892451-14191-1-git-send-email-suriyan.r@gmail.com>
	<53349C97.2010204@linaro.org>
	<CANoR_OC19JSkxhRc7T41dyq5KJ4XNnvGBh6xxZPhtif7Nh72oA@mail.gmail.com>
	<5335815A.2040901@linaro.org>
	<1396350736.8667.105.camel@kazak.uk.xensource.com>
	<CANoR_ODP4z0nsp41xgB4JAaSpZapBqkpOMOn6sKjAh5QnAat5A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CANoR_ODP4z0nsp41xgB4JAaSpZapBqkpOMOn6sKjAh5QnAat5A@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: Suriyan Ramasami <suriyan.r@gmail.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Tim Deegan <tim@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

Hello,

On 04/11/2014 05:05 PM, Suriyan Ramasami wrote:
> On Tue, Apr 1, 2014 at 4:12 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Fri, 2014-03-28 at 14:04 +0000, Julien Grall wrote:
>>> That made me think that this is the only board with this issue. I would
>>> definitely prefer to fix the clock frequency in U-boot. The bootloader
>>> should respect the ARM ARM (see B.8.1.1):
>>>
>>> "The CNTFRQ register is UNKNOWN at reset, and therefore the counter
>>> frequency must written to CNTFRQ as part
>>> of the system boot process."
>>
>> Yes, Suriyan, please exhaust this avenue of attack (fixing u-boot on the
>> platform) first.
>>
> Thank you gentlemen for your comments.
> The problem with this board is that the uboot is not entered in secure
> mode, and hence the mcr indstruction to set the ARCH timer frequency
> cannot be executed in u-boot.

If so, what is the state of the CPU when it jumps to U-boot?
The CPU has to be either in secure mode or hyp mode.
AFAIK, if it's NS you won't be able to go in hyp mode, unless crash the
CPU...

Regards,

-- 
Julien Grall