All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: HYP/non-sec: Add MIDR check to detect unsupported CPUs
Date: Wed, 6 Aug 2014 10:49:47 +0100	[thread overview]
Message-ID: <20140806094947.GA8330@leverpostej> (raw)
In-Reply-To: <1407310693.23472.67.camel@dagon.hellion.org.uk>

On Wed, Aug 06, 2014 at 08:38:13AM +0100, Ian Campbell wrote:
> On Mon, 2014-08-04 at 16:14 +0100, Marc Zyngier wrote:
> 
> > My personal feeling is that booting in secure mode is always the wrong
> > thing to do.
> 
> FWIW I agree.
> 
> > If you want to go down the road of a single bootloader that is able to
> > run on several SOCs, then do it the proper way: parse the device tree
> > and have separate constraints for your SoC. But please don't blacklist
> > random cores just because it fits your environment.
> 
> I think there is a CPU feature register which indicates whether support
> for HYP mode is present, isn't there?

ID_PFR1[15:12] should tell you if the CPU has the virtualization
extensions.

> In which case a tolerable fix for now (going all the way DT is a big
> yakk to shave...) would be to use that to decide between booting in
> NS.HYP vs NS.SVC (nb: not NS.HYP vs S.SVC).

That sounds ideal.

> I don't recall if the GIC has a feature bit for the security extensions,
> but if not then inferring it from the CPUs support wouldn't be the worst
> thing in the world under the circumstances.

GICD_TYPER[10] (SecurityExtn) should tell you if the GIC has the
security extensions. I don't know whether you'll encounter a platform
where the CPU and GIC are mismatched w.r.t. security extensions.

Mark.

  reply	other threads:[~2014-08-06  9:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-03  2:36 [U-Boot] [PATCH] ARM: HYP/non-sec: Add MIDR check to detect unsupported CPUs Siarhei Siamashka
2014-08-04 15:14 ` Marc Zyngier
2014-08-06  7:38   ` Ian Campbell
2014-08-06  9:49     ` Mark Rutland [this message]
2014-08-06 10:10       ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140806094947.GA8330@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.