
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.