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

[Stephen Warren <swarren@wwwdotorg.org>]

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.