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