From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 27 Feb 2015 21:58:03 -0700 Subject: [U-Boot] u-boot on raspberry 2: booting in SVC secure mode In-Reply-To: References: <54EE16AF.9070304@wwwdotorg.org> <54EEE49B.2000602@arm.com> Message-ID: <54F14ADB.4000101@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.