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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot