2015-02-27 10:41 GMT+01:00 Andre Przywara <andre.przyw...@arm.com>: > Hi Vincent, > > On 26/02/15 09:32, 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). > > Ah yes, it seems like there should be code to branch off on secondary > codes based on MPIDR reading in start.S early. I try to take a look at > it later. > > > 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. > > So you should set ARMV7_BOOT_SEC_DEFAULT in this case then. Do you > desperately need the other three cores? If not you could get away with > disabling the SMP parts of the code for the time being, putting the > other cores in WFI or WFE. >
I don't care about the other cores for now, I only need one core. I put them in wfi quite early in the process. > > > 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 ? > > adding: > ------ > config ARMV7_NONSEC > default y > config ARMV7_VIRT > default y > ------ > to board/raspberrypi/rpi_2/Kconfig did the trick for me, though it > (correctly) complains about some missing bits. I will not find time > until tonight to work on this, so you may want to take a look at commits > fafbc6c000db and e261c83aa04c meanwhile to see what needs to be done in > this regard for a new board. > Thank you, I was changing rpi_2_defconfing instead of rpi_2/Kconfig. > I couldn't get u-boot to output anything at all with kernel_old=1 on my > quick try yesterday, what is your current setup to get to the UART > garbage? Did you enable some kind of early debug or did you put any > extra code at 0x0? I tried setting SYS_TEXT_BASE to 0x0, but that didn't > change anything. > > Indeed I tried again earlier and nothing showed up... I might have had other changes that I don't remember (like ARMV7_BOOT_SEC_DEFAULT or something like that). Thank you for your interest, I'll have a look at the commits you pointed out. I don't think I'll be able to have a clear look before next week, so there's no rush :) Best, Vincent > Cheers, > Andre. > > >> 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 > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
