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

[Jan Kiszka]

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.

Jan

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