[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Vincent]

Hi,
as explained here http://community.arm.com/message/25127, it is possible to
boot the raspberry 2 in secure mode, by adding the kernel_old=1 option in
config.txt. The main effects of this option are:
- all 4 cores start executing in secure SVC mode instead of non-secure SVC
mode
- all 4 cores start at 0x0000 instead of 0x8000
- the initial boot code that setup SMP and exits secure mode is not
executed

After browsing u-boot's source code, it seems that their boot code is more
or less extracted from what u-boot is doing. However I didn't manage to
compile u-boot for the raspberry 2 supporting this secure mode.

Could anyone explain me what options I need to configure in rpi_2_defconfig
so that u-boot supports secure boot for the raspberry 2 and what the boot
sequence will be in this case ? I don't mind fixing the code if necessary
but I'm a bit lost in the order of events in the initialization.


Best,
Vincent

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Stephen Warren]

On 02/25/2015 02:30 AM, Vincent wrote:
> Hi,
> as explained here http://community.arm.com/message/25127, it is possible to
> boot the raspberry 2 in secure mode, by adding the kernel_old=1 option in
> config.txt. The main effects of this option are:
> - all 4 cores start executing in secure SVC mode instead of non-secure SVC
> mode
> - all 4 cores start at 0x0000 instead of 0x8000
> - the initial boot code that setup SMP and exits secure mode is not
> executed
>
> After browsing u-boot's source code, it seems that their boot code is more
> or less extracted from what u-boot is doing. However I didn't manage to
> compile u-boot for the raspberry 2 supporting this secure mode.
>
> Could anyone explain me what options I need to configure in rpi_2_defconfig
> so that u-boot supports secure boot for the raspberry 2 and what the boot
> sequence will be in this case ? I don't mind fixing the code if necessary
> but I'm a bit lost in the order of events in the initialization.

(Luckily I just happened to notice this message while looking at another 
one nearby. CCing the relevant board maintainer(s) explicitly would help 
your messages be noticed)

To modify U-Boot to support the alternate entry point/load address, 
you'd hopefully only need to change the definition of 
CONFIG_SYS_TEXT_BASE in include/configs/rpi*.h.

I wasn't aware of the thread/option you mention, so I have not attempted 
to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself 
will "just work" once TEXT_BASE is fixed.

To boot a kernel, you'll probably need to at least configure the ARM 
architected timers CNTFRQ register for the kernel. Perhaps there are a 
few other things like that missing?

It might be interesting to enable U-Boot's PSCI support on the RPi2, so 
that an upstream kernel could gain SMP support without the need for 
explicit BCM2836 SMP support code.

So far, I haven't attempted anything with an (upstream) kernel on RPi2, 
just U-Boot.

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Vincent]

Hi,
I finally hacked my way through U-boot and I managed to add raspberry's
boot code inside U-boot so that it can start as usual when using kernel_old
= 1. I don't think
we want this as a final solution but it made me understand a few things
about U-boot architecture (in short: I added a new section located at 0x0
which executes raspberry's code, and
then jump to the usual _start entry point). I didn't try to modify
CONFIG_SYS_TEXT_BASE yet, I'll try this morning.

From what I gathered from the source code, I think I have to activate some
options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot starts
in secure mode,
but adding them to rpi_2_defconfig doesn't seem to change anything in
.config, so I'm not sure that my current U-boot is "secure boot aware".
Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like
that ?

Thank you for your feedback !

Best,
Vincent


2015-02-25 19:38 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org>:

> On 02/25/2015 02:30 AM, Vincent wrote:
>
>> Hi,
>> as explained here http://community.arm.com/message/25127, it is possible
>> to
>> boot the raspberry 2 in secure mode, by adding the kernel_old=1 option in
>> config.txt. The main effects of this option are:
>> - all 4 cores start executing in secure SVC mode instead of non-secure SVC
>> mode
>> - all 4 cores start at 0x0000 instead of 0x8000
>> - the initial boot code that setup SMP and exits secure mode is not
>> executed
>>
>> After browsing u-boot's source code, it seems that their boot code is more
>> or less extracted from what u-boot is doing. However I didn't manage to
>> compile u-boot for the raspberry 2 supporting this secure mode.
>>
>> Could anyone explain me what options I need to configure in
>> rpi_2_defconfig
>> so that u-boot supports secure boot for the raspberry 2 and what the boot
>> sequence will be in this case ? I don't mind fixing the code if necessary
>> but I'm a bit lost in the order of events in the initialization.
>>
>
> (Luckily I just happened to notice this message while looking at another
> one nearby. CCing the relevant board maintainer(s) explicitly would help
> your messages be noticed)
>
> To modify U-Boot to support the alternate entry point/load address, you'd
> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in
> include/configs/rpi*.h.
>
> I wasn't aware of the thread/option you mention, so I have not attempted
> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself will
> "just work" once TEXT_BASE is fixed.
>
> To boot a kernel, you'll probably need to at least configure the ARM
> architected timers CNTFRQ register for the kernel. Perhaps there are a few
> other things like that missing?
>
> It might be interesting to enable U-Boot's PSCI support on the RPi2, so
> that an upstream kernel could gain SMP support without the need for
> explicit BCM2836 SMP support code.
>
> So far, I haven't attempted anything with an (upstream) kernel on RPi2,
> just U-Boot.
>

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Andre Przywara]

Hi Vincent,

On 26/02/15 08:27, Vincent wrote:
> Hi,
> I finally hacked my way through U-boot and I managed to add raspberry's
> boot code inside U-boot so that it can start as usual when using kernel_old
> = 1. I don't think
> we want this as a final solution but it made me understand a few things
> about U-boot architecture (in short: I added a new section located at 0x0
> which executes raspberry's code, and
> then jump to the usual _start entry point). I didn't try to modify
> CONFIG_SYS_TEXT_BASE yet, I'll try this morning.
> 
> From what I gathered from the source code, I think I have to activate some
> options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot starts
> in secure mode,
> but adding them to rpi_2_defconfig doesn't seem to change anything in
> .config, so I'm not sure that my current U-boot is "secure boot aware".
> Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like
> that ?

AFAIK you don't need to tell U-Boot that it runs in secure: unless it
accesses any secure/non-secure specific peripherals it should work fine
in both modes.
Setting ARMV7_BOOT_SEC_DEFAULT just prevents U-Boot to switch into
non-sec, but there is no real reason to do so - at least not for Linux.

You should do away with the original Raspi firmware snippet - not only
from a legal point of view.
Thanks to Marc U-Boot has now a much better implementation than my
original HYP-mode switcher, also this gives you PSCI support basically
for free. So just select ARMV7_VIRT and ARMV7_NONSEC.

Do you know if there is a TrustZone Controller in that SoC? That would
be needed to guard the resident U-Boot code from the OS. Some SoCs have
secure on-chip SRAM usable for that purpose, that would do it, too.
But skimming through the BCM2835 .pdf I don't spot any of those,
unfortunately.

Cheers,
Andre.

> 
> 2015-02-25 19:38 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org>:
> 
>> On 02/25/2015 02:30 AM, Vincent wrote:
>>
>>> Hi,
>>> as explained here http://community.arm.com/message/25127, it is possible
>>> to
>>> boot the raspberry 2 in secure mode, by adding the kernel_old=1 option in
>>> config.txt. The main effects of this option are:
>>> - all 4 cores start executing in secure SVC mode instead of non-secure SVC
>>> mode
>>> - all 4 cores start at 0x0000 instead of 0x8000
>>> - the initial boot code that setup SMP and exits secure mode is not
>>> executed
>>>
>>> After browsing u-boot's source code, it seems that their boot code is more
>>> or less extracted from what u-boot is doing. However I didn't manage to
>>> compile u-boot for the raspberry 2 supporting this secure mode.
>>>
>>> Could anyone explain me what options I need to configure in
>>> rpi_2_defconfig
>>> so that u-boot supports secure boot for the raspberry 2 and what the boot
>>> sequence will be in this case ? I don't mind fixing the code if necessary
>>> but I'm a bit lost in the order of events in the initialization.
>>>
>>
>> (Luckily I just happened to notice this message while looking at another
>> one nearby. CCing the relevant board maintainer(s) explicitly would help
>> your messages be noticed)
>>
>> To modify U-Boot to support the alternate entry point/load address, you'd
>> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in
>> include/configs/rpi*.h.
>>
>> I wasn't aware of the thread/option you mention, so I have not attempted
>> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself will
>> "just work" once TEXT_BASE is fixed.
>>
>> To boot a kernel, you'll probably need to at least configure the ARM
>> architected timers CNTFRQ register for the kernel. Perhaps there are a few
>> other things like that missing?
>>
>> It might be interesting to enable U-Boot's PSCI support on the RPi2, so
>> that an upstream kernel could gain SMP support without the need for
>> explicit BCM2836 SMP support code.
>>
>> So far, I haven't attempted anything with an (upstream) kernel on RPi2,
>> just U-Boot.
>>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Vincent]

I tried what Stephen suggested, and just changing CONFIG_SYS_TEXT_BASE to
0x0 (with kernel_old=1) does not work: the board display some garbage on
the uart then hangs. The content of the garbage makes me thinks that
nothing is done to handle the four cores in this setting which ends up
badly. I expected this since raspberry's "firmware" only let one core run
free. I think I need to configure U-boot so that it deals with this SMP
scenario (I just don't know how).

My goal is to use U-boot to load some small homemade baremetal kernels on
the raspberry (using serial or tftp loading), in *secure mode*, so I need
U-boot to stay in secure mode, or at least let me install my own
secure_monitor code before switching to non-secure mode.

I made a couple attempts of adding secure mode support by adding options in
configs/rpi_2_defconfig but they don't seem to be taken into account. Where
do you suggest I put ARMV7_virt and ARMV7_NONSEC ?

Best,
Vincent

2015-02-26 10:17 GMT+01:00 Andre Przywara <andre.przywara@arm.com>:

> Hi Vincent,
>
> On 26/02/15 08:27, Vincent wrote:
> > Hi,
> > I finally hacked my way through U-boot and I managed to add raspberry's
> > boot code inside U-boot so that it can start as usual when using
> kernel_old
> > = 1. I don't think
> > we want this as a final solution but it made me understand a few things
> > about U-boot architecture (in short: I added a new section located at 0x0
> > which executes raspberry's code, and
> > then jump to the usual _start entry point). I didn't try to modify
> > CONFIG_SYS_TEXT_BASE yet, I'll try this morning.
> >
> > From what I gathered from the source code, I think I have to activate
> some
> > options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot
> starts
> > in secure mode,
> > but adding them to rpi_2_defconfig doesn't seem to change anything in
> > .config, so I'm not sure that my current U-boot is "secure boot aware".
> > Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like
> > that ?
>
> AFAIK you don't need to tell U-Boot that it runs in secure: unless it
> accesses any secure/non-secure specific peripherals it should work fine
> in both modes.
> Setting ARMV7_BOOT_SEC_DEFAULT just prevents U-Boot to switch into
> non-sec, but there is no real reason to do so - at least not for Linux.
>
> You should do away with the original Raspi firmware snippet - not only
> from a legal point of view.
> Thanks to Marc U-Boot has now a much better implementation than my
> original HYP-mode switcher, also this gives you PSCI support basically
> for free. So just select ARMV7_VIRT and ARMV7_NONSEC.
>
> Do you know if there is a TrustZone Controller in that SoC? That would
> be needed to guard the resident U-Boot code from the OS. Some SoCs have
> secure on-chip SRAM usable for that purpose, that would do it, too.
> But skimming through the BCM2835 .pdf I don't spot any of those,
> unfortunately.
>
> Cheers,
> Andre.
>
> >
> > 2015-02-25 19:38 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org>:
> >
> >> On 02/25/2015 02:30 AM, Vincent wrote:
> >>
> >>> Hi,
> >>> as explained here http://community.arm.com/message/25127, it is
> possible
> >>> to
> >>> boot the raspberry 2 in secure mode, by adding the kernel_old=1 option
> in
> >>> config.txt. The main effects of this option are:
> >>> - all 4 cores start executing in secure SVC mode instead of non-secure
> SVC
> >>> mode
> >>> - all 4 cores start at 0x0000 instead of 0x8000
> >>> - the initial boot code that setup SMP and exits secure mode is not
> >>> executed
> >>>
> >>> After browsing u-boot's source code, it seems that their boot code is
> more
> >>> or less extracted from what u-boot is doing. However I didn't manage to
> >>> compile u-boot for the raspberry 2 supporting this secure mode.
> >>>
> >>> Could anyone explain me what options I need to configure in
> >>> rpi_2_defconfig
> >>> so that u-boot supports secure boot for the raspberry 2 and what the
> boot
> >>> sequence will be in this case ? I don't mind fixing the code if
> necessary
> >>> but I'm a bit lost in the order of events in the initialization.
> >>>
> >>
> >> (Luckily I just happened to notice this message while looking at another
> >> one nearby. CCing the relevant board maintainer(s) explicitly would help
> >> your messages be noticed)
> >>
> >> To modify U-Boot to support the alternate entry point/load address,
> you'd
> >> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in
> >> include/configs/rpi*.h.
> >>
> >> I wasn't aware of the thread/option you mention, so I have not attempted
> >> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself
> will
> >> "just work" once TEXT_BASE is fixed.
> >>
> >> To boot a kernel, you'll probably need to at least configure the ARM
> >> architected timers CNTFRQ register for the kernel. Perhaps there are a
> few
> >> other things like that missing?
> >>
> >> It might be interesting to enable U-Boot's PSCI support on the RPi2, so
> >> that an upstream kernel could gain SMP support without the need for
> >> explicit BCM2836 SMP support code.
> >>
> >> So far, I haven't attempted anything with an (upstream) kernel on RPi2,
> >> just U-Boot.
> >>
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
>

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Vincent]

Oh and I don't think there is a TZ Address space controller on the
raspberry, or at least I am not aware of any.

2015-02-26 10:32 GMT+01:00 Vincent <vincent.siles@gmail.com>:

> I tried what Stephen suggested, and just changing CONFIG_SYS_TEXT_BASE to
> 0x0 (with kernel_old=1) does not work: the board display some garbage on
> the uart then hangs. The content of the garbage makes me thinks that
> nothing is done to handle the four cores in this setting which ends up
> badly. I expected this since raspberry's "firmware" only let one core run
> free. I think I need to configure U-boot so that it deals with this SMP
> scenario (I just don't know how).
>
> My goal is to use U-boot to load some small homemade baremetal kernels on
> the raspberry (using serial or tftp loading), in *secure mode*, so I need
> U-boot to stay in secure mode, or at least let me install my own
> secure_monitor code before switching to non-secure mode.
>
> I made a couple attempts of adding secure mode support by adding options
> in configs/rpi_2_defconfig but they don't seem to be taken into account.
> Where do you suggest I put ARMV7_virt and ARMV7_NONSEC ?
>
> Best,
> Vincent
>
> 2015-02-26 10:17 GMT+01:00 Andre Przywara <andre.przywara@arm.com>:
>
>> Hi Vincent,
>>
>> On 26/02/15 08:27, Vincent wrote:
>> > Hi,
>> > I finally hacked my way through U-boot and I managed to add raspberry's
>> > boot code inside U-boot so that it can start as usual when using
>> kernel_old
>> > = 1. I don't think
>> > we want this as a final solution but it made me understand a few things
>> > about U-boot architecture (in short: I added a new section located at
>> 0x0
>> > which executes raspberry's code, and
>> > then jump to the usual _start entry point). I didn't try to modify
>> > CONFIG_SYS_TEXT_BASE yet, I'll try this morning.
>> >
>> > From what I gathered from the source code, I think I have to activate
>> some
>> > options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot
>> starts
>> > in secure mode,
>> > but adding them to rpi_2_defconfig doesn't seem to change anything in
>> > .config, so I'm not sure that my current U-boot is "secure boot aware".
>> > Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like
>> > that ?
>>
>> AFAIK you don't need to tell U-Boot that it runs in secure: unless it
>> accesses any secure/non-secure specific peripherals it should work fine
>> in both modes.
>> Setting ARMV7_BOOT_SEC_DEFAULT just prevents U-Boot to switch into
>> non-sec, but there is no real reason to do so - at least not for Linux.
>>
>> You should do away with the original Raspi firmware snippet - not only
>> from a legal point of view.
>> Thanks to Marc U-Boot has now a much better implementation than my
>> original HYP-mode switcher, also this gives you PSCI support basically
>> for free. So just select ARMV7_VIRT and ARMV7_NONSEC.
>>
>> Do you know if there is a TrustZone Controller in that SoC? That would
>> be needed to guard the resident U-Boot code from the OS. Some SoCs have
>> secure on-chip SRAM usable for that purpose, that would do it, too.
>> But skimming through the BCM2835 .pdf I don't spot any of those,
>> unfortunately.
>>
>> Cheers,
>> Andre.
>>
>> >
>> > 2015-02-25 19:38 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org>:
>> >
>> >> On 02/25/2015 02:30 AM, Vincent wrote:
>> >>
>> >>> Hi,
>> >>> as explained here http://community.arm.com/message/25127, it is
>> possible
>> >>> to
>> >>> boot the raspberry 2 in secure mode, by adding the kernel_old=1
>> option in
>> >>> config.txt. The main effects of this option are:
>> >>> - all 4 cores start executing in secure SVC mode instead of
>> non-secure SVC
>> >>> mode
>> >>> - all 4 cores start at 0x0000 instead of 0x8000
>> >>> - the initial boot code that setup SMP and exits secure mode is not
>> >>> executed
>> >>>
>> >>> After browsing u-boot's source code, it seems that their boot code is
>> more
>> >>> or less extracted from what u-boot is doing. However I didn't manage
>> to
>> >>> compile u-boot for the raspberry 2 supporting this secure mode.
>> >>>
>> >>> Could anyone explain me what options I need to configure in
>> >>> rpi_2_defconfig
>> >>> so that u-boot supports secure boot for the raspberry 2 and what the
>> boot
>> >>> sequence will be in this case ? I don't mind fixing the code if
>> necessary
>> >>> but I'm a bit lost in the order of events in the initialization.
>> >>>
>> >>
>> >> (Luckily I just happened to notice this message while looking at
>> another
>> >> one nearby. CCing the relevant board maintainer(s) explicitly would
>> help
>> >> your messages be noticed)
>> >>
>> >> To modify U-Boot to support the alternate entry point/load address,
>> you'd
>> >> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in
>> >> include/configs/rpi*.h.
>> >>
>> >> I wasn't aware of the thread/option you mention, so I have not
>> attempted
>> >> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself
>> will
>> >> "just work" once TEXT_BASE is fixed.
>> >>
>> >> To boot a kernel, you'll probably need to at least configure the ARM
>> >> architected timers CNTFRQ register for the kernel. Perhaps there are a
>> few
>> >> other things like that missing?
>> >>
>> >> It might be interesting to enable U-Boot's PSCI support on the RPi2, so
>> >> that an upstream kernel could gain SMP support without the need for
>> >> explicit BCM2836 SMP support code.
>> >>
>> >> So far, I haven't attempted anything with an (upstream) kernel on RPi2,
>> >> just U-Boot.
>> >>
>> > _______________________________________________
>> > U-Boot mailing list
>> > U-Boot at lists.denx.de
>> > http://lists.denx.de/mailman/listinfo/u-boot
>> >
>>
>
>

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Andre Przywara]

Hi Vincent,

On 26/02/15 09:32, Vincent wrote:
> I tried what Stephen suggested, and just changing CONFIG_SYS_TEXT_BASE to
> 0x0 (with kernel_old=1) does not work: the board display some garbage on
> the uart then hangs. The content of the garbage makes me thinks that
> nothing is done to handle the four cores in this setting which ends up
> badly. I expected this since raspberry's "firmware" only let one core run
> free. I think I need to configure U-boot so that it deals with this SMP
> scenario (I just don't know how).

Ah yes, it seems like there should be code to branch off on secondary
codes based on MPIDR reading in start.S early. I try to take a look at
it later.

> My goal is to use U-boot to load some small homemade baremetal kernels on
> the raspberry (using serial or tftp loading), in *secure mode*, so I need
> U-boot to stay in secure mode, or at least let me install my own
> secure_monitor code before switching to non-secure mode.

So you should set ARMV7_BOOT_SEC_DEFAULT in this case then. Do you
desperately need the other three cores? If not you could get away with
disabling the SMP parts of the code for the time being, putting the
other cores in WFI or WFE.

> I made a couple attempts of adding secure mode support by adding options in
> configs/rpi_2_defconfig but they don't seem to be taken into account. Where
> do you suggest I put ARMV7_virt and ARMV7_NONSEC ?

adding:
------
config ARMV7_NONSEC
	default y
config ARMV7_VIRT
	default y
------
to board/raspberrypi/rpi_2/Kconfig did the trick for me, though it
(correctly) complains about some missing bits. I will not find time
until tonight to work on this, so you may want to take a look at commits
fafbc6c000db and e261c83aa04c meanwhile to see what needs to be done in
this regard for a new board.
I couldn't get u-boot to output anything at all with kernel_old=1 on my
quick try yesterday, what is your current setup to get to the UART
garbage? Did you enable some kind of early debug or did you put any
extra code at 0x0? I tried setting SYS_TEXT_BASE to 0x0, but that didn't
change anything.

Cheers,
Andre.

>> Hi Vincent,
>>
>> On 26/02/15 08:27, Vincent wrote:
>>> Hi,
>>> I finally hacked my way through U-boot and I managed to add raspberry's
>>> boot code inside U-boot so that it can start as usual when using
>> kernel_old
>>> = 1. I don't think
>>> we want this as a final solution but it made me understand a few things
>>> about U-boot architecture (in short: I added a new section located at 0x0
>>> which executes raspberry's code, and
>>> then jump to the usual _start entry point). I didn't try to modify
>>> CONFIG_SYS_TEXT_BASE yet, I'll try this morning.
>>>
>>> From what I gathered from the source code, I think I have to activate
>> some
>>> options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot
>> starts
>>> in secure mode,
>>> but adding them to rpi_2_defconfig doesn't seem to change anything in
>>> .config, so I'm not sure that my current U-boot is "secure boot aware".
>>> Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something like
>>> that ?
>>
>> AFAIK you don't need to tell U-Boot that it runs in secure: unless it
>> accesses any secure/non-secure specific peripherals it should work fine
>> in both modes.
>> Setting ARMV7_BOOT_SEC_DEFAULT just prevents U-Boot to switch into
>> non-sec, but there is no real reason to do so - at least not for Linux.
>>
>> You should do away with the original Raspi firmware snippet - not only
>> from a legal point of view.
>> Thanks to Marc U-Boot has now a much better implementation than my
>> original HYP-mode switcher, also this gives you PSCI support basically
>> for free. So just select ARMV7_VIRT and ARMV7_NONSEC.
>>
>> Do you know if there is a TrustZone Controller in that SoC? That would
>> be needed to guard the resident U-Boot code from the OS. Some SoCs have
>> secure on-chip SRAM usable for that purpose, that would do it, too.
>> But skimming through the BCM2835 .pdf I don't spot any of those,
>> unfortunately.
>>
>> Cheers,
>> Andre.
>>
>>>
>>> 2015-02-25 19:38 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org>:
>>>
>>>> On 02/25/2015 02:30 AM, Vincent wrote:
>>>>
>>>>> Hi,
>>>>> as explained here http://community.arm.com/message/25127, it is
>> possible
>>>>> to
>>>>> boot the raspberry 2 in secure mode, by adding the kernel_old=1 option
>> in
>>>>> config.txt. The main effects of this option are:
>>>>> - all 4 cores start executing in secure SVC mode instead of non-secure
>> SVC
>>>>> mode
>>>>> - all 4 cores start at 0x0000 instead of 0x8000
>>>>> - the initial boot code that setup SMP and exits secure mode is not
>>>>> executed
>>>>>
>>>>> After browsing u-boot's source code, it seems that their boot code is
>> more
>>>>> or less extracted from what u-boot is doing. However I didn't manage to
>>>>> compile u-boot for the raspberry 2 supporting this secure mode.
>>>>>
>>>>> Could anyone explain me what options I need to configure in
>>>>> rpi_2_defconfig
>>>>> so that u-boot supports secure boot for the raspberry 2 and what the
>> boot
>>>>> sequence will be in this case ? I don't mind fixing the code if
>> necessary
>>>>> but I'm a bit lost in the order of events in the initialization.
>>>>>
>>>>
>>>> (Luckily I just happened to notice this message while looking at another
>>>> one nearby. CCing the relevant board maintainer(s) explicitly would help
>>>> your messages be noticed)
>>>>
>>>> To modify U-Boot to support the alternate entry point/load address,
>> you'd
>>>> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE in
>>>> include/configs/rpi*.h.
>>>>
>>>> I wasn't aware of the thread/option you mention, so I have not attempted
>>>> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself
>> will
>>>> "just work" once TEXT_BASE is fixed.
>>>>
>>>> To boot a kernel, you'll probably need to at least configure the ARM
>>>> architected timers CNTFRQ register for the kernel. Perhaps there are a
>> few
>>>> other things like that missing?
>>>>
>>>> It might be interesting to enable U-Boot's PSCI support on the RPi2, so
>>>> that an upstream kernel could gain SMP support without the need for
>>>> explicit BCM2836 SMP support code.
>>>>
>>>> So far, I haven't attempted anything with an (upstream) kernel on RPi2,
>>>> just U-Boot.
>>>>
>>> _______________________________________________
>>> U-Boot mailing list
>>> U-Boot at lists.denx.de
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Vincent]

2015-02-27 10:41 GMT+01:00 Andre Przywara <andre.przywara@arm.com>:

> Hi Vincent,
>
> On 26/02/15 09:32, Vincent wrote:
> > I tried what Stephen suggested, and just changing CONFIG_SYS_TEXT_BASE to
> > 0x0 (with kernel_old=1) does not work: the board display some garbage on
> > the uart then hangs. The content of the garbage makes me thinks that
> > nothing is done to handle the four cores in this setting which ends up
> > badly. I expected this since raspberry's "firmware" only let one core run
> > free. I think I need to configure U-boot so that it deals with this SMP
> > scenario (I just don't know how).
>
> Ah yes, it seems like there should be code to branch off on secondary
> codes based on MPIDR reading in start.S early. I try to take a look at
> it later.
>
> > My goal is to use U-boot to load some small homemade baremetal kernels on
> > the raspberry (using serial or tftp loading), in *secure mode*, so I need
> > U-boot to stay in secure mode, or at least let me install my own
> > secure_monitor code before switching to non-secure mode.
>
> So you should set ARMV7_BOOT_SEC_DEFAULT in this case then. Do you
> desperately need the other three cores? If not you could get away with
> disabling the SMP parts of the code for the time being, putting the
> other cores in WFI or WFE.
>

I don't care about the other cores for now, I only need one core. I put
them in wfi quite early in the process.


>
> > I made a couple attempts of adding secure mode support by adding options
> in
> > configs/rpi_2_defconfig but they don't seem to be taken into account.
> Where
> > do you suggest I put ARMV7_virt and ARMV7_NONSEC ?
>
> adding:
> ------
> config ARMV7_NONSEC
>         default y
> config ARMV7_VIRT
>         default y
> ------
> to board/raspberrypi/rpi_2/Kconfig did the trick for me, though it
> (correctly) complains about some missing bits. I will not find time
> until tonight to work on this, so you may want to take a look at commits
> fafbc6c000db and e261c83aa04c meanwhile to see what needs to be done in
> this regard for a new board.
>

Thank you, I was changing rpi_2_defconfing instead of rpi_2/Kconfig.


> I couldn't get u-boot to output anything at all with kernel_old=1 on my
> quick try yesterday, what is your current setup to get to the UART
> garbage? Did you enable some kind of early debug or did you put any
> extra code at 0x0? I tried setting SYS_TEXT_BASE to 0x0, but that didn't
> change anything.
>
> Indeed I tried again earlier and nothing showed up... I might have had
other changes that I don't remember (like
ARMV7_BOOT_SEC_DEFAULT or something like that).

Thank you for your interest, I'll have a look at the commits you pointed
out. I don't think I'll be able to have a clear look
before next week, so there's no rush :)

Best,
Vincent



> Cheers,
> Andre.
>
> >> Hi Vincent,
> >>
> >> On 26/02/15 08:27, Vincent wrote:
> >>> Hi,
> >>> I finally hacked my way through U-boot and I managed to add raspberry's
> >>> boot code inside U-boot so that it can start as usual when using
> >> kernel_old
> >>> = 1. I don't think
> >>> we want this as a final solution but it made me understand a few things
> >>> about U-boot architecture (in short: I added a new section located at
> 0x0
> >>> which executes raspberry's code, and
> >>> then jump to the usual _start entry point). I didn't try to modify
> >>> CONFIG_SYS_TEXT_BASE yet, I'll try this morning.
> >>>
> >>> From what I gathered from the source code, I think I have to activate
> >> some
> >>> options (like the ones in arch/arm/cpu/armv7/Kconfig) so that U-boot
> >> starts
> >>> in secure mode,
> >>> but adding them to rpi_2_defconfig doesn't seem to change anything in
> >>> .config, so I'm not sure that my current U-boot is "secure boot aware".
> >>> Should I add ARMV7_BOOT_SEC_DEFAULT by hand in .config or something
> like
> >>> that ?
> >>
> >> AFAIK you don't need to tell U-Boot that it runs in secure: unless it
> >> accesses any secure/non-secure specific peripherals it should work fine
> >> in both modes.
> >> Setting ARMV7_BOOT_SEC_DEFAULT just prevents U-Boot to switch into
> >> non-sec, but there is no real reason to do so - at least not for Linux.
> >>
> >> You should do away with the original Raspi firmware snippet - not only
> >> from a legal point of view.
> >> Thanks to Marc U-Boot has now a much better implementation than my
> >> original HYP-mode switcher, also this gives you PSCI support basically
> >> for free. So just select ARMV7_VIRT and ARMV7_NONSEC.
> >>
> >> Do you know if there is a TrustZone Controller in that SoC? That would
> >> be needed to guard the resident U-Boot code from the OS. Some SoCs have
> >> secure on-chip SRAM usable for that purpose, that would do it, too.
> >> But skimming through the BCM2835 .pdf I don't spot any of those,
> >> unfortunately.
> >>
> >> Cheers,
> >> Andre.
> >>
> >>>
> >>> 2015-02-25 19:38 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org>:
> >>>
> >>>> On 02/25/2015 02:30 AM, Vincent wrote:
> >>>>
> >>>>> Hi,
> >>>>> as explained here http://community.arm.com/message/25127, it is
> >> possible
> >>>>> to
> >>>>> boot the raspberry 2 in secure mode, by adding the kernel_old=1
> option
> >> in
> >>>>> config.txt. The main effects of this option are:
> >>>>> - all 4 cores start executing in secure SVC mode instead of
> non-secure
> >> SVC
> >>>>> mode
> >>>>> - all 4 cores start at 0x0000 instead of 0x8000
> >>>>> - the initial boot code that setup SMP and exits secure mode is not
> >>>>> executed
> >>>>>
> >>>>> After browsing u-boot's source code, it seems that their boot code is
> >> more
> >>>>> or less extracted from what u-boot is doing. However I didn't manage
> to
> >>>>> compile u-boot for the raspberry 2 supporting this secure mode.
> >>>>>
> >>>>> Could anyone explain me what options I need to configure in
> >>>>> rpi_2_defconfig
> >>>>> so that u-boot supports secure boot for the raspberry 2 and what the
> >> boot
> >>>>> sequence will be in this case ? I don't mind fixing the code if
> >> necessary
> >>>>> but I'm a bit lost in the order of events in the initialization.
> >>>>>
> >>>>
> >>>> (Luckily I just happened to notice this message while looking at
> another
> >>>> one nearby. CCing the relevant board maintainer(s) explicitly would
> help
> >>>> your messages be noticed)
> >>>>
> >>>> To modify U-Boot to support the alternate entry point/load address,
> >> you'd
> >>>> hopefully only need to change the definition of CONFIG_SYS_TEXT_BASE
> in
> >>>> include/configs/rpi*.h.
> >>>>
> >>>> I wasn't aware of the thread/option you mention, so I have not
> attempted
> >>>> to boot the RPi2 U-Boot in secure mode. If you're lucky, U-Boot itself
> >> will
> >>>> "just work" once TEXT_BASE is fixed.
> >>>>
> >>>> To boot a kernel, you'll probably need to at least configure the ARM
> >>>> architected timers CNTFRQ register for the kernel. Perhaps there are a
> >> few
> >>>> other things like that missing?
> >>>>
> >>>> It might be interesting to enable U-Boot's PSCI support on the RPi2,
> so
> >>>> that an upstream kernel could gain SMP support without the need for
> >>>> explicit BCM2836 SMP support code.
> >>>>
> >>>> So far, I haven't attempted anything with an (upstream) kernel on
> RPi2,
> >>>> just U-Boot.
> >>>>
> >>> _______________________________________________
> >>> U-Boot mailing list
> >>> U-Boot at lists.denx.de
> >>> http://lists.denx.de/mailman/listinfo/u-boot
> >>>
> >>
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
>

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Stephen Warren]

On 02/26/2015 02:32 AM, Vincent wrote:
> I tried what Stephen suggested, and just changing CONFIG_SYS_TEXT_BASE
> to 0x0 (with kernel_old=1) does not work: the board display some garbage
> on the uart then hangs. The content of the garbage makes me thinks that
> nothing is done to handle the four cores in this setting which ends up
> badly. I expected this since raspberry's "firmware" only let one core
> run free. I think I need to configure U-boot so that it deals with this
> SMP scenario (I just don't know how).

That expectation seems correct! I hacked in some code right at the start
of U-Boot (reset: in arch/arm/cpu/armv7/start.S) that extracted the
CPUID from the MPIDR register, and only allowed CPU0 to continue. With
that in place, kernel_old=1 and CONFIG_SYS_TEXT_BASE=0 worked.

Interesting that all CPU cores get released at reset; the other SoCs
I've used only release CPU0 and you have to explicitly boot CPUn.

> My goal is to use U-boot to load some small homemade baremetal kernels
> on the raspberry (using serial or tftp loading), in *secure mode*, so I
> need U-boot to stay in secure mode, or at least let me install my own
> secure_monitor code before switching to non-secure mode.
> 
> I made a couple attempts of adding secure mode support by adding options
> in configs/rpi_2_defconfig but they don't seem to be taken into account.
> Where do you suggest I put ARMV7_virt and ARMV7_NONSEC ?

I would suggest adding #defines to include/configs/rpi_2.h.

[U-Boot] u-boot on raspberry 2: booting in SVC secure mode

[Vincent]

Thank to your last email, I finally managed to boot in secure mode with
(what I consider as) minimal changes:
- kernel_old=1
- CONFIG_SYS_TEXT_BASE=0
- halting other cores in start.S:reset
- commenting away line 113 in arch/arm/cpu/armv7/virt-v7.c:
smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1);
- hack around _smp_pen so the code compiles correctly
- adding two defines to rpi_2.h
  #define CONFIG_ARMV7_NONSEC
  #define CONFIG_ARMV7_BOOT_SEC_DEFAULT

I'm uploading this fork on github (https://github.com/vsiles/u-boot) if
anyone is interested. I'm pretty sure that not the "right" way to do it,
but it works for now :)
Thank you very much for your help
V.

2015-02-28 5:58 GMT+01:00 Stephen Warren <swarren@wwwdotorg.org>:

> On 02/26/2015 02:32 AM, Vincent wrote:
> > I tried what Stephen suggested, and just changing CONFIG_SYS_TEXT_BASE
> > to 0x0 (with kernel_old=1) does not work: the board display some garbage
> > on the uart then hangs. The content of the garbage makes me thinks that
> > nothing is done to handle the four cores in this setting which ends up
> > badly. I expected this since raspberry's "firmware" only let one core
> > run free. I think I need to configure U-boot so that it deals with this
> > SMP scenario (I just don't know how).
>
> That expectation seems correct! I hacked in some code right at the start
> of U-Boot (reset: in arch/arm/cpu/armv7/start.S) that extracted the
> CPUID from the MPIDR register, and only allowed CPU0 to continue. With
> that in place, kernel_old=1 and CONFIG_SYS_TEXT_BASE=0 worked.
>
> Interesting that all CPU cores get released at reset; the other SoCs
> I've used only release CPU0 and you have to explicitly boot CPUn.
>
> > My goal is to use U-boot to load some small homemade baremetal kernels
> > on the raspberry (using serial or tftp loading), in *secure mode*, so I
> > need U-boot to stay in secure mode, or at least let me install my own
> > secure_monitor code before switching to non-secure mode.
> >
> > I made a couple attempts of adding secure mode support by adding options
> > in configs/rpi_2_defconfig but they don't seem to be taken into account.
> > Where do you suggest I put ARMV7_virt and ARMV7_NONSEC ?
>
> I would suggest adding #defines to include/configs/rpi_2.h.
>