On Fri, Apr 28, 2017 at 05:20:46PM +0200, Freddie Chopin wrote:
> Hello Rob!
>
> On Fri, 2017-04-28 at 07:59 -0500, Rob Herring wrote:
> > > I'm not so sure about the "standardization" and "publication" part.
> > > I
> > > do realize that primary usage of devicetrees will be on "desktop
> > > PC"
> >
> > PC's use ACPI.
>
> Yes, what I wrote was wrong, because I was thinking about something
> else (; I was thinking about devices capable of running a general
> purpose operating system (like Linux), which are quite different from
> microcontrollers. Sorry for the confusion, I have no idea why I wrote
> about "PC" (;
>
> > uC's capable of running Linux generally use DT, too.
>
> You're right, and I'm targeting some of these microcontrollers too
> (like STM32F4 or STM32F7). But my needs are a little bit different when
> it comes to the "basics" (like on-chip flash memory, which is
> completely ignored in Linux). I hope that's only an initial obstacle,
> as I think using DT for typical peripherals like USART, SPI, DMA,
> external hardware and so on will be very similar.
>
> Generally my problems are not related to the hardware itself - it
> doesn't really matter whether it's a small microcontroller of a
> multicore applications processor. I think the root cause of the issues
> I'm facing is that my "use case" (small embedded RTOS for
> microcontrollers) is completely different from the use case of a huge
> general purpose OS like Linux. I hope that this use case of mine is not
> so different to be completely incompatible with devicetree (;
So far it doesn't sound like it. It really just seems that you need
some details that have so far been left out because Linux doesn't
typically need them.
> > > Anyway - a few more days with devicetree and I have another
> > > question. I
> > > don't want to start a new thread for that, as it is related to the
> > > first one anyway. This one is harder, as I found no examples at
> > > all, so
> > > I have absolutely nothing to start with. There are microcontroller
> > > cores which may or may not contain a floating-point unit (FPU) -
> > > for
> > > example ARM Cortex-M4 may have one or none. There are also
> > > microcontroller cores which may contain either a single-precision
> > > or
> > > double-precision FPU - for example ARM Cortex-M7, which may have
> > > either
> > > fpv5-sp-d16 or fpv5-d16 FPU. Currently I include that info in the
> > > kconfig system, where appropriate hidden options are set when
> > > selecting
> > > a particular chip model/family. As you may imagine I would also
> > > like to
> > > have that info in the devicetree. I see several options to express
> > > that
> > > information, but I'm not sure which one fits best.
> >
> > Doesn't the M7 have ID registers registers with define the FP
> > capabilities? It should not be in DT if the feature is discoverable.
> >
> > Or are you trying to use DT at build time like Zephyr?
>
> This is exactly my plan here. As I'm also targeting much smaller
> devices, I'm planning to use DT only during compilation, with no
> support for embedded binary devicetree blobs handled at run-time.
> That's why I actually need some of the things which are discoverable to
> be known during the build. For example if the device has no FPU, the
> code to do context switching is much smaller (and faster) and uses less
> stack space to save context. Other than that I will also need different
> compiler flags to build the RTOS for targets with or without FPU. It
> wouldn't be a good RTOS if the code size would be needlessly big... For
> Linux is doesn't really matter whether the binary size is 10 or 11MB,
> but here I'm dealing with targets which can have as little as a few
> dozen kB of flash space for the whole executable, and typically
> something around 128-256kB.
Ok. Using the DT at build time does complicate things a bit, but
probably not fatally.
> But you mentioned an important thing here - indeed DT contains (at
> least it should) only the things which cannot be discovered during run-
> time... So maybe my plan to add info about FPU to DT is not such a good
> idea.
So, usually, yes, leaving out run-time discoverable information is a
good idea. But again, there are definitely some grey areas and
trade-offs here. In fact on POWER servers (where the device tree
content originates, though not the flattened encoding) it's quite
common to have run-time discoverable things duplicated in the device
tree. Generally that's either because they wanted to encourage OSes
to generalize to allow them to support potential future devices
without code changes, or because they wanted to allow firmware to
filter the available features by changing what was advertised.
There can be some overlap there: virtualization can give you guest
cpus that are missing features that the model theoretically always
has, because the hypervisor won't let you have access to it.
So I don't think it's unreasonable for you to add some information
like this, even if it's theoretically runtime discoverable. Some more
discussion of this below..
> Generally for my project I need some way to easily describe "board"
> (interfaces, external devices, GPIO pins, DMA channels, interrupts,
> ...), preferably in a single file, easily editable by hand. My current
> plan is to use such "board description" to generate some real C++ code
> with Python scripts - this code will define global objects (like serial
> ports, GPIOs, EEPROM chips, ...), perform some low-level
> initialization, configure interrupts and GPIOs, ... Some of that
> functionality is already present and uses *.json file as input. But
> after some reading I come to conclusion that there's no point in
> inventing my own format to describe hardware, when there already is one
> - devicetree. *.dts generally fits my needs pretty good, there are just
> some small details which I need to handle somehow, and I'm still
> thinking about the best way to integrate my concepts with kconfig and
> build system.
So. The disctinction between runtime discoverable and not information
is actually not super important. It's ok for the dt to have redundant
information, as long as it has enough; the OS will just ignore bits it
doesn't need, after all.
What is important is to distinguish between true hardware information
- what the hardware is capable of - and configuration information -
a suggested way to use it. Restricting the DT to the former and the
latter is pretty important. But even there, there's quite a lot of
grey areas.
For example, is the way firmware has set things up hardware
information or configuration. In some cases the "firmware" might
include the hypervisor, so how you use things is enforced and might
not otherwise be discoverable. In other cases it might be technically
not hardware information - the OS could use things a different way -
but doing so would badly violate platform conventions. For example it
would mean the OS doing low-level reprogramming of board logic which
is usually set up by the firmware and left that way. In that case
it can be best on balance to include the information in the device
tree, even though it's technically configuration and not hardware.
Then there's things that really are OS configuration, but it's just
awkward not to include. Those can be ok if 1) kept to a minimum, 2)
clearly prefixed with vendor/OS tags, 3) are present *as well as* all
the necessary hardware information, not instead of.
> > > 2. I could just add a non-standard property to cpu nodes (or maybe
> > > to
> > > cpus node?), something like:
> > >
> > > distortos,fpu = "fpv5-d16";
> >
> > Please don't. That would not scale if every OS out there did that.
> >
> > I would probably append something to the cpu compatible if you must.
> > In any case, Zephyr folks are going to have the same problem, so we
> > should have a common solution.
Hm. So, I'm not terribly familiar with ARM, so that might mislead
me. But this actually wouldn't be my first choice.
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
> Do you mean "append" as "add suffix" (compatible = "arm,cortex-m7f";)
> or "append" as "add another value" (compatible = "arm,cortex-m7",
> "arm,fpv5-d16";)?
>
> In case of Zephyr - from what I understand - for now part of the
> configuration is inside kconfig anyway, and this includes the FPU
> information. Maybe I should do the same and just associate the
> "compatible" property of the chip with some kconfig part? For example I
> would require the board's compatible to have the chip model like that:
>
> / {
> compatible = "some-board", "st,stm32f407vg";
> ...
>
> Which I would then map somehow to a kconfig fragment, which would be
> just:
>
> select HAS_FPU
> select HAS_MPU
> ...
>
> This way I wouldn't have to "pollute" the devicetree with that info. Do
> you think this would be the preferable solution here?
>
> I'm still trying to get a good grasp of devicetree, so some of my
> questions and ideas are probably completely dumb (I hope they don't
> make you mad (; ). As I wrote above - probably 90% of my needs are
> already covered by DT, but some of the concepts important for small
> platforms require me to improvise (; These would generally stem from
> the fact that OS like Linux uses "compiled" *.dts file in run-time,
> while I want to use *.dts file only as an input format for source code
> generator and maybe during project configuration/compilation (for
> example to select proper piece of code to be compiled - like context
> switching routine for appropriate core, with or without FPU).
>
> Another idea - maybe I should just include every such "non-standard"
> information in /chosen?
>
> Thanks for the advices already offered and thanks in advance for any
> further guidance you could share with me!
>
> Regards,
> FCh
--
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:
signature.asc
Description: PGP signature
