Thank to your last email, I finally managed to boot in secure mode with (what I consider as) minimal changes: - kernel_old=1 - CONFIG_SYS_TEXT_BASE=0 - halting other cores in start.S:reset - commenting away line 113 in arch/arm/cpu/armv7/virt-v7.c: smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1); - hack around _smp_pen so the code compiles correctly - adding two defines to rpi_2.h #define CONFIG_ARMV7_NONSEC #define CONFIG_ARMV7_BOOT_SEC_DEFAULT
I'm uploading this fork on github (https://github.com/vsiles/u-boot) if anyone is interested. I'm pretty sure that not the "right" way to do it, but it works for now :) Thank you very much for your help V. 2015-02-28 5:58 GMT+01:00 Stephen Warren <swar...@wwwdotorg.org>: > On 02/26/2015 02:32 AM, 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). > > That expectation seems correct! I hacked in some code right at the start > of U-Boot (reset: in arch/arm/cpu/armv7/start.S) that extracted the > CPUID from the MPIDR register, and only allowed CPU0 to continue. With > that in place, kernel_old=1 and CONFIG_SYS_TEXT_BASE=0 worked. > > Interesting that all CPU cores get released at reset; the other SoCs > I've used only release CPU0 and you have to explicitly boot CPUn. > > > 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 ? > > I would suggest adding #defines to include/configs/rpi_2.h. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
