From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Freddie Chopin <freddie_chopin-FWhLrETftxM@public.gmane.org>
Cc: devicetree-spec
<devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: How to describe internal flash (ROM) in the microcontroller
Date: Mon, 8 May 2017 15:38:21 +1000 [thread overview]
Message-ID: <20170508053821.GD25748@umbus.fritz.box> (raw)
In-Reply-To: <1493806658.9572.2.camel-FWhLrETftxM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3941 bytes --]
On Wed, May 03, 2017 at 12:17:38PM +0200, Freddie Chopin wrote:
> Hi!
>
> On Mon, 2017-05-01 at 14:38 +1000, David Gibson wrote:
> > There are existing CPU bindings which include additional properties
> > giving lists or bitmasks of optional features. For example the PAPR
> > standard requires this for guest device trees on POWER. It also
> > requires that there be a 'cpu-version' property which gives the
> > "logical PVR" which the OS is supposed to look at in most cases
> > instead of the physically discoverable PVR register contents. This
> > has applications for CPUs put into compatibility modes for
> > virtualization, so the use case isn't a perfect match, but the ideas
> > may be adaptable.
> >
> > What *is* a really good rule of thumb is don't invent a new way of
> > encoding this information if you can possibly avoid it. I don't know
> > if the few cases of DT being used on x86 have something similar, but
> > if they do I'd expect it to use the same bitmask as the cpuid
> > instruction returns. In your case, if there are existing (read only)
> > registers that give the information you need, you could mirror their
> > value into the device tree
>
> I've just browsed the manual for ARMv7-M architecture and there are 3
> read-only registers which have that info, but with a small twist (;
>
> If the core has single-precision FPU, MVFR0-MVFR2 register values are
> 0x10110021, 0x11000011 and 0x00000000. This would be ARM Cortex-M4 with
> FPv4-SP-D16 or ARM Cortex-M7 with FPv5-SP-D16. If the core has double-
> precision FPU, the values of these registers are 0x10110221, 0x12000011
> and 0x00000040. This is a case for ARM Cortex-M7 with FPv5-D16. The
> slight twist is when the core has no FPU at all, as in that case the
> manual says these registers are not implemented at all, but I haven't
> checked yet whether any attempt to read them causes a fault or just
> returns zeroes.
That's ok - you can encode "register not present" by simply leaving
the property out, or leaving it empty (these are different and
distinguishable options).
> Could you point me to the binding which describes the properties you
> mentioned? I couldn't find 'cpu-version' in the device-tree-rebasing
> repository...
That should be in the LoPAPR spec, which you can get from
https://members.openpowerfoundation.org/document/dl/469
> Maybe - after all - it would be easier and more readable to have FPU as
> a subnode of the CPU? Sth like:
>
> cpus {
> cpu@0 {
> compatible = "arm,cortex-m4";
>
> fpu@0 {
> compatible = "arm,fpv4-sp-d16";
> };
> };
> };
>
> In this case it's pretty easy to extend that with an optional 'status =
> "okay";' / 'status = "disabled";' for the cases where the user doesn't
> want FPU to be "globally enabled" (useful when only one thread uses
> FPU, so there's no point in saving its context).
Urgh..
So, if this was a completely new binding for a completely new CPU, I'd
say that sounds like an excellent way of doing it. But it's not.
There are lots and lots of existing ARM bindings out there for lots of
ARM CPUs, mostly higher end ones, many of which I presume include an
FPU, but which won't have this new proposed node. This is pretty much
what I mean when I say "don't invent new ways of encoding things".
I think this is an argument for using "empty property" rather than
"missing property" for encoding a missing FPU. That way your DT
client code has these options:
no property => unknown FPU state => this DT is not suitable
empty property => no FPU
properties present => FPU present, tells you which type
In the first case you can at least error out sensibly
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2017-05-08 5:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-22 18:47 How to describe internal flash (ROM) in the microcontroller Freddie Chopin
[not found] ` <1492886823.1240.5.camel-FWhLrETftxM@public.gmane.org>
2017-04-24 1:27 ` David Gibson
[not found] ` <20170424012734.GB16882-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2017-04-28 7:21 ` Freddie Chopin
[not found] ` <1493364100.1425.6.camel-FWhLrETftxM@public.gmane.org>
2017-04-28 12:59 ` Rob Herring
[not found] ` <CAL_Jsq+Gbu35bps2VcQ=pO3WyQE9VZhsuvpKtZ3TJ++B10jPWA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-28 15:20 ` Freddie Chopin
[not found] ` <1493392846.1425.12.camel-FWhLrETftxM@public.gmane.org>
2017-05-01 4:38 ` David Gibson
[not found] ` <20170501043819.GE13773-K0bRW+63XPQe6aEkudXLsA@public.gmane.org>
2017-05-03 10:17 ` Freddie Chopin
[not found] ` <1493806658.9572.2.camel-FWhLrETftxM@public.gmane.org>
2017-05-08 5:38 ` David Gibson [this message]
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=20170508053821.GD25748@umbus.fritz.box \
--to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
--cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=freddie_chopin-FWhLrETftxM@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).