diff mbox

[v2,7/9] i.MX: Add i.MX6 SOC implementation.

Message ID CAFEAcA-4hxBUtRg6zstkkSyzm3OecZe_mCHQV6rONZTmKJKrBQ@mail.gmail.com
State New
Headers show

Commit Message

Peter Maydell Feb. 29, 2016, 5:58 p.m. UTC 
On 19 February 2016 at 06:32, Jean-Christophe DUBOIS
<jcd@tribudubois.net> wrote:
> If I set has_el3 to false, I can boot the 4 cores without problem. With
> has_el3 set to true (default value) I am getting the above behavior (boot OK
> in uniprocessor mode, and misbehaving if -smp >= 2).

I worked out why this happens -- it's because the secondary CPUs and
the primary disagree about whether they're booting in Secure mode.
You can either:
(1) have the board code say "boot the primary in Secure mode":
 }

If you do either of these then the system will boot the kernel that
you sent the link to.

To answer the question of "which of these is the correct thing to do"
we need to look at what the real hardware does when it's running Linux:
does it run Linux in Secure or Nonsecure?

thanks
-- PMM

Comments

Jean-Christophe Dubois Feb. 29, 2016, 8:34 p.m. UTC | #1 
Le 29/02/2016 18:58, Peter Maydell a écrit :
> On 19 February 2016 at 06:32, Jean-Christophe DUBOIS
> <jcd@tribudubois.net> wrote:
>> If I set has_el3 to false, I can boot the 4 cores without problem. With
>> has_el3 set to true (default value) I am getting the above behavior (boot OK
>> in uniprocessor mode, and misbehaving if -smp >= 2).
> I worked out why this happens -- it's because the secondary CPUs and
> the primary disagree about whether they're booting in Secure mode.
> You can either:
> (1) have the board code say "boot the primary in Secure mode":
> --- a/hw/arm/sabrelite.c
> +++ b/hw/arm/sabrelite.c
> @@ -85,6 +85,7 @@ static void sabrelite_init(MachineState *machine)
>       sabrelite_binfo.kernel_cmdline = machine->kernel_cmdline;
>       sabrelite_binfo.initrd_filename = machine->initrd_filename;
>       sabrelite_binfo.nb_cpus = smp_cpus;
> +    sabrelite_binfo.secure_boot = true;
>       sabrelite_binfo.write_secondary_boot = sabrelite_write_secondary;
>       sabrelite_binfo.secondary_cpu_reset_hook = sabrelite_reset_secondary;
>
> or (2) have the code in imx6_src.c tell the secondaries that
> they should start in non-secure mode:
>
> --- a/hw/misc/imx6_src.c
> +++ b/hw/misc/imx6_src.c
> @@ -144,6 +144,7 @@ static void imx6_src_cpu_on(uint32_t cpuid,
> uint32_t entry, uint32_t context_id)
>
>       target_cpu->env.regs[0] = context_id;
>       target_cpu->env.thumb = entry & 1;
> +    target_cpu->env.cp15.scr_el3 |= SCR_NS;
>
>       target_cpu_class->set_pc(target_cpu_state, entry);
>   }
>
> If you do either of these then the system will boot the kernel that
> you sent the link to.

Thanks Peter, It does work.

>
> To answer the question of "which of these is the correct thing to do"
> we need to look at what the real hardware does when it's running Linux:
> does it run Linux in Secure or Nonsecure?

i.MX6 is definitively able to boot in secure/trustzone mode (there are 
some demo out there about it) so I guess it might be booting in secure mode.

>
> thanks
> -- PMM
>
Peter Maydell Feb. 29, 2016, 9:14 p.m. UTC | #2 
On 29 February 2016 at 20:34, Jean-Christophe DUBOIS
<jcd@tribudubois.net> wrote:
> Le 29/02/2016 18:58, Peter Maydell a écrit :
>> To answer the question of "which of these is the correct thing to do"
>> we need to look at what the real hardware does when it's running Linux:
>> does it run Linux in Secure or Nonsecure?
>
>
> i.MX6 is definitively able to boot in secure/trustzone mode (there are some
> demo out there about it) so I guess it might be booting in secure mode.


Mmm. The other question I had about the system reset controller
is whether it's really purely hardware doing the "start secondary CPU",
or is it just a funny way of asking the system firmware to start
things, or is the stuff like the register for startup address
just a place to leave information that the system firmware
on the secondary CPU will read as part of its boot sequence?

Is there a datasheet available for this?

thanks
-- PMM
Jean-Christophe Dubois Feb. 29, 2016, 9:32 p.m. UTC | #3 
Le 29/02/2016 22:14, Peter Maydell a écrit :
> On 29 February 2016 at 20:34, Jean-Christophe DUBOIS
> <jcd@tribudubois.net> wrote:
>> Le 29/02/2016 18:58, Peter Maydell a écrit :
>>> To answer the question of "which of these is the correct thing to do"
>>> we need to look at what the real hardware does when it's running Linux:
>>> does it run Linux in Secure or Nonsecure?
>>
>> i.MX6 is definitively able to boot in secure/trustzone mode (there are some
>> demo out there about it) so I guess it might be booting in secure mode.
>
> Mmm. The other question I had about the system reset controller
> is whether it's really purely hardware doing the "start secondary CPU",
> or is it just a funny way of asking the system firmware to start
> things, or is the stuff like the register for startup address
> just a place to leave information that the system firmware
> on the secondary CPU will read as part of its boot sequence?
>
> 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=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf

I believe it is hardware based. Now it might involve some of the 
functions of the internal ROM in the process but we cannot change this 
behavior in any way.

>
> thanks
> -- PMM
>
Peter Maydell March 1, 2016, 4:19 p.m. UTC | #4 
On 29 February 2016 at 21:32, Jean-Christophe DUBOIS
<jcd@tribudubois.net> wrote:
> Le 29/02/2016 22:14, Peter Maydell a écrit :
>> 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=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf

Thanks for the link.

> I believe it is hardware based. Now it might involve some of the functions
> 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 starts
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 implementing
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.

(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 = true;" to the
board code.

thanks
-- PMM
Jean-Christophe Dubois March 1, 2016, 7:17 p.m. UTC | #5 
Le 01/03/2016 17:19, Peter Maydell a écrit :
> On 29 February 2016 at 21:32, Jean-Christophe DUBOIS
> <jcd@tribudubois.net> wrote:
>> Le 29/02/2016 22:14, Peter Maydell a écrit :
>>> 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=1&WT_TYPE=Reference%20Manuals&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf
> Thanks for the link.
>
>> I believe it is hardware based. Now it might involve some of the functions
>> 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 starts
> 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 implementing
> 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 = true;" to the
> board code.
>
> thanks
> -- PMM
>
diff mbox

Patch

--- a/hw/arm/sabrelite.c
+++ b/hw/arm/sabrelite.c
@@ -85,6 +85,7 @@  static void sabrelite_init(MachineState *machine)
     sabrelite_binfo.kernel_cmdline = machine->kernel_cmdline;
     sabrelite_binfo.initrd_filename = machine->initrd_filename;
     sabrelite_binfo.nb_cpus = smp_cpus;
+    sabrelite_binfo.secure_boot = true;
     sabrelite_binfo.write_secondary_boot = sabrelite_write_secondary;
     sabrelite_binfo.secondary_cpu_reset_hook = sabrelite_reset_secondary;

or (2) have the code in imx6_src.c tell the secondaries that
they should start in non-secure mode:

--- a/hw/misc/imx6_src.c
+++ b/hw/misc/imx6_src.c
@@ -144,6 +144,7 @@  static void imx6_src_cpu_on(uint32_t cpuid,
uint32_t entry, uint32_t context_id)

     target_cpu->env.regs[0] = context_id;
     target_cpu->env.thumb = entry & 1;
+    target_cpu->env.cp15.scr_el3 |= SCR_NS;

     target_cpu_class->set_pc(target_cpu_state, entry);