Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix

Quoted 66 lines · Jan Kiszka

Quoted 57 lines · Stephen Warren

Quoted 56 lines · Jan Kiszka

Quoted 54 lines · Stephen Warren

Quoted 41 lines · Jan Kiszka

Quoted 35 lines · Ian Campbell

Quoted 29 lines · Jan Kiszka

Quoted 18 lines · Stephen Warren

Quoted 8 lines · Tom Rini

Quoted 6 lines · Jan Kiszka

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

Quoted 8 lines

Quoted 2 lines

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!

Quoted 9 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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?

Quoted 4 lines

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?

Quoted 7 lines

Quoted 4 lines

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.

Quoted 7 lines

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.