[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 at 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 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
> >>>
> >>
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
>