[U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

[Jan Kiszka]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150418/8f88e64c/attachment.sig>