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.si...@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.przyw...@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 <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
