On 2015-04-17 16:43, Stephen Warren wrote: > On 04/17/2015 08:20 AM, Jan Kiszka wrote: >> On 2015-04-17 16:12, Stephen Warren wrote: >>> On 04/17/2015 08:02 AM, Jan Kiszka wrote: >>>> On 2015-04-17 15:57, Stephen Warren wrote: >>>>> On 04/17/2015 12:47 AM, Jan Kiszka wrote: >>>>>> On 2015-04-14 16:30, Ian Campbell wrote: >>>>>>> On Tue, 2015-04-14 at 16:12 +0200, Jan Kiszka wrote: >>>>>>>> On 2015-04-14 16:06, Stephen Warren wrote: >>>>>>>>> On 04/14/2015 07:46 AM, Tom Rini wrote: >>>>>>>>>> On Mon, Apr 13, 2015 at 06:48:05AM +0200, Jan Kiszka wrote: >>>>>>>>>> >>>>>>>>>>> Changes in v6: >>>>>>>>>>> - rebased over master >>>>>>>>>>> - included Thierry's SMMU enabling patch >>>>>>>>>>> - moved activation patch at the end so that it can be held >>>>>>>>>>> back >>>>>>>>>>> >>>>>>>>>>> This version can also be found at >>>>>>>>>>> https://github.com/siemens/u-boot/tree/jetson-tk1-v6. >>>>>>>>>> >>>>>>>>>> So what level of coordination do we need on applying this series >>>>>>>>>> so that >>>>>>>>>> kernels (both old and new) can continue to function? And perhaps >>>>>>>>>> README >>>>>>>>>> updates or similar? Thanks! >>>>>>>>> >>>>>>>>> Hopefully this series doesn't change anything by default, and >>>>>>>>> simply >>>>>>>>> allows people to turn on support for booting kernels in non-secure >>>>>>>>> mode >>>>>>>>> if they want to? If so, there shouldn't be any co-ordination >>>>>>>>> required. >>>>>>>>> If it changes the default behaviour, co-ordination is probably >>>>>>>>> required, >>>>>>>>> and that'd be a bad thing. >>>>>>>> >>>>>>>> Sorry, forgot to mention: I can't flip the default behaviour to >>>>>>>> leave >>>>>>>> virtualization support off only for the TK1. That's a generic >>>>>>>> default. >>>>>>> >>>>>>> Would enabling it in the compile but adding "bootm_boot_mode=sec" >>>>>>> to the >>>>>>> default environment (so it isn't used by default) be considered >>>>>>> sufficiently backwards compatible? >>>>>> >>>>>> This turned out to not work as expected: booting in secure mode seems >>>>>> to prevent that Linux can bring up CPUs 1-3. Not sure if this is >>>>>> to be >>>>>> expected or a bug, but I will now take a different route: >>>>> >>>>> That was the whole point of the environment variable suggestion; the >>>>> environment variable would default to off so nobody got new behaviour, >>>>> but anyone who wanted to boot in secure mode could simply set the >>>>> environment variable and get it. That way, nobody who doesn't want the >>>>> feature needs to co-ordinate U-Boot and kernel updates. Why doesn't >>>>> that >>>>> work? >>>> >>>> Because it breaks SMP on Linux, namely the boot of secondary cores. >>>> Don't ask me why, I didn't debug the details. But you can probably >>>> reproduce by specifying bootm_boot_mode=sec with current U-boot and >>>> recent upstream kernels. >>> >>> I suspect the environment variable isn't working, and Linux is still >>> being booted in non-secure mode. That would be a bug in U-Boot. >> >> Yes, might be. Linux reports being started (with that single CPU) in SVC >> mode. I'll recheck if it is a regression of my series. >> >> Anyway, even if it worked, I think the cleaner way is flipping defaults >> at the config root level (virt support) as long as things are not >> working out of the box with Linux. That's what my other patch is doing >> now. Any concerns regarding it? > > Yes. > > This should be runtime configurable so that there's no need for a user > to co-ordinate U-Boot and kernel updates. This also allows users to > easily test the kernel in secure and NS mode without having to rebuild a > bootloader.
Got it fixed. The bug was the unconditional execution of ap_pm_init in my series. Now I can freely switch between secure and non-secure mode during boot, and all CPUs will be brought up. I will flip CONFIG_ARMV7_BOOT_SEC_DEFAULT to y for Tegra so that we keep the current behaviour (secure boot), the virt folks among us can tune to permanent non-sec boot via expert settings, and other can define bootm_boot_mode=nonsec for single experiments without rebuilds. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
