From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58089)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jcd@tribudubois.net>) id 1aapo2-0000ss-8w
	for qemu-devel@nongnu.org; Tue, 01 Mar 2016 14:18:06 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jcd@tribudubois.net>) id 1aapnw-0004bp-Eh
	for qemu-devel@nongnu.org; Tue, 01 Mar 2016 14:18:02 -0500
Received: from zose-mta03.web4all.fr ([185.49.20.44]:35115)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jcd@tribudubois.net>) id 1aapnw-0004bV-3q
	for qemu-devel@nongnu.org; Tue, 01 Mar 2016 14:17:56 -0500
References: <cover.1454967766.git.jcd@tribudubois.net>
	<4499d69ec1326c07481e9d8178e64b63f9748706.1454967766.git.jcd@tribudubois.net>
	<CAFEAcA_G1qtjiOmAKGPGdNFADEoj0Fi5vKjjqiQuX3-RVaFEXg@mail.gmail.com>
	<56C38B52.7080904@tribudubois.net>
	<CAFEAcA_ddFXYWeGdbWFc91d7PQYRFaa7922cspjfv1esyk6C7Q@mail.gmail.com>
	<56C398FA.8010204@tribudubois.net>
	<CAFEAcA8p4comWmJyh2C2Wwbb6BCiQmo0VQweeYgvY+DURQ8g4g@mail.gmail.com>
	<56C62EDA.3010307@tribudubois.net>
	<CAFEAcA-vov8o+BKNqAq-A0ecaX4j3af9R+R6uvaMqhDttR_gxw@mail.gmail.com>
	<56C6B707.8040001@tribudubois.net>
	<CAFEAcA-4hxBUtRg6zstkkSyzm3OecZe_mCHQV6rONZTmKJKrBQ@mail.gmail.com>
	<56D4AB67.6080506@tribudubois.net>
	<CAFEAcA-XVSQ=G_=nLHYFC=ORcZNcviGP9Gtbf_TjWRr_EAAK-g@mail.gmail.com>
	<56D4B8FA.4010305@tribudubois.net>
	<CAFEAcA8pRs47=AGPsgTB3ebdXoVQDR_SERZdeJ=zncS4P-7fzg@mail.gmail.com>
From: Jean-Christophe DUBOIS <jcd@tribudubois.net>
Message-ID: <56D5EAE0.9090200@tribudubois.net>
Date: Tue, 1 Mar 2016 20:17:52 +0100
MIME-Version: 1.0
In-Reply-To: <CAFEAcA8pRs47=AGPsgTB3ebdXoVQDR_SERZdeJ=zncS4P-7fzg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v2 7/9] i.MX: Add i.MX6 SOC implementation.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>, Peter Crosthwaite <crosthwaite.peter@gmail.com>

Le 01/03/2016 17:19, Peter Maydell a =C3=A9crit :
> On 29 February 2016 at 21:32, Jean-Christophe DUBOIS
> <jcd@tribudubois.net> wrote:
>> Le 29/02/2016 22:14, Peter Maydell a =C3=A9crit :
>>> Is there a datasheet available for this?
>> Well the SRC device is described in the i.MX6 reference manual.
>>
>> http://cache.nxp.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf?fpsp=3D1&=
WT_TYPE=3DReference%20Manuals&WT_VENDOR=3DFREESCALE&WT_FILE_FORMAT=3Dpdf&=
WT_ASSET=3DDocumentation&fileExt=3D.pdf
> Thanks for the link.
>
>> I believe it is hardware based. Now it might involve some of the funct=
ions
>> of the internal ROM in the process but we cannot change this behavior =
in any
>> way.
> The datasheet is pretty clear -- registers like the SRC_GPR<n> are just
> "holds some state" registers, and when the system reset controller star=
ts
> a secondary CPU it runs through some boot ROM code which reads the
> GPR controlling the start address and branches to it.
>
> This means the code you have in the SRC emulation is actually implement=
ing
> a combination of the SRC hardware and the boot ROM software. That's OK,
> but we should have a comment somewhere that makes it clear that that's
> what's going on.

OK, I'll add the comment.

JC

>
> (it is possible to implement the "jump to address as per register" as
> code that runs in the guest; highbank has a variant on this. It doesn't
> really seem necessary here though.)
>
> On the "secure vs nonsecure" question, I'm not completely sure but I
> think that the answer is that it will boot in secure. So we should
> use the patche that adds "sabrelite_binfo.secure_boot =3D true;" to the
> board code.
>
> thanks
> -- PMM
>