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

[Jan Kiszka]

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?

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux