Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v6 Latest posting 2/20 of 15 patches 0 repliesNew
- v6 posting 1/20 of 15 patches 0 repliesSuperseded
- v5 posting 2/21 of 14 patches 0 repliesSuperseded
Earlier versions · 2
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v5 posting 1/2 | 0 of 14 patches | 0 replies | Superseded | |
| v4 | 1 of 14 patches | 0 replies | Superseded |
Patches in v6 posting 2/2 No applies recorded yet
None of the 15 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v6 yet.
Cover letter [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix
Quoted 10 lines · Stephen Warren
Quoted 8 lines · Jan Kiszka
Quoted 3 lines · Ian Campbell
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:
Quoted 6 lines
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?
Right, if this doesn't work then it is certainly a bug somewhere on the u-boot side.
I fixed one such issue a while back ("ARM: bootm: do not add PSCI to fdt when booting in secure mode.") but that's ancient history, but I know that at that time it was working for me (I'm reasonably sure that was on Tegra with my earlier PSCI patches)
Ian.