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

Vincent vincent.siles at gmail.com
Thu Feb 26 10:33:27 CET 2015


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 at 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 at 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 at 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
>> >
>>
>
>


More information about the U-Boot mailing list