From: Ian Campbell Date: Fri, 17 Apr 2015 15:04:36 +0100 Subject: [U-Boot] [PATCH v6 00/15] Add PSCI support for Jetson TK1/Tegra124 + CNTFRQ fix In-Reply-To: <55311148.3090309@wwwdotorg.org> References: <20150414134636.GH16702@bill-the-cat> <552D1EDC.7060307@wwwdotorg.org> <552D2037.5050207@siemens.com> <1429021814.15516.72.camel@hellion.org.uk> <5530AC6B.7010707@siemens.com> <55311148.3090309@wwwdotorg.org> Message-ID: <1429279476.25195.333.camel@hellion.org.uk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, 2015-04-17 at 07:57 -0600, Stephen Warren wrote: > On 04/17/2015 12:47 AM, Jan Kiszka wrote: > > On 2015-04-14 16:30, Ian Campbell wrote: > >> 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? 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.