From: Freddie Chopin <freddie_chopin-FWhLrETftxM@public.gmane.org>
To: devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: How to describe internal flash (ROM) in the microcontroller
Date: Sat, 22 Apr 2017 20:47:03 +0200 [thread overview]
Message-ID: <1492886823.1240.5.camel@op.pl> (raw)
Hello!
For my project - http://distortos.org/ - which is a C++ RTOS for
microcontrollers, I decided to use devicetree to configure hardware.
Currently the project uses kconfig, but for configuring hardware this
gets unmanageable and just too big and too restrictive. My plan is to
gradually convert to *.dts and the first step I wanted to make is to
convert addresses and sizes of memory (which I'll later read from *.dts
file to generate linker script).
To cut a long story short - there's no issue in adding RAM (internal
chip's SRAM) - just add that as one or more /memory node. However I
also need to do something for which I found absolutely no info, no
example and no binding - I also need to describe **internal** ROM
(internal on-chip flash memory). Please note that this is _not_
something which can be described as "nand-flash", "nor-flash", "emmc",
"qspi" or things like that - this memory is not externally connected
via some interface - it is "built-in" into the chip.
I have thought about two options to do that, but can't decide which one
fits better, so I decided to ask here, as you've been working with
devicetrees for quite a long time.
Option 1
Generally this is similar to what Zephyr RTOS has done, which is to
just introduce a new /flash node. This has a disadvantage of being non-
standard.
https://github.com/zephyrproject-rtos/zephyr/blob/master/dts/arm/st/stm32l476.dtsi#L11
Option 2
Describe flash as a separate /memory node and add "read-only;" property
there to designate it as "not-RAM". In my personal opinion this fits
nicely with other parts of spec (and fits with /reserved-memory nodes
concept from Linux). However I'm not sure whether the idea of "read-
only" memory region makes any sense according to your concepts. BTW
some other property would also work fine here, generally anything that
would allow me to know which is flash and which is RAM, so I could use
them for different parts of linker script.
Or maybe instead of adding "read-only;" I should use sth like this in
my flash /memory node:
compatible="internal-flash";
For "option 2" there's also another question - I may need to add some
more non-standard properties for such nodes, for example with
configuration of latency or for configuration of LMA address which will
be used by linker (for example in STM32F7 microcontrollers flash can be
accessed via two different buses, but written only via one - as the one
which can be used for writes is slower, it is preferable to use
different VMA/LMA addresses). This can actually be done with virtual-
reg property (where reg would have LMA and virtual-reg - VMA), but I'm
sure the need for something non-standard would arrive some day or
another. Would that still fit?
Thanks in advance for all ideas!
Regards,
FCh
next reply other threads:[~2017-04-22 18:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-22 18:47 Freddie Chopin [this message]
[not found] ` <1492886823.1240.5.camel-FWhLrETftxM@public.gmane.org>
2017-04-24 1:27 ` How to describe internal flash (ROM) in the microcontroller 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
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=1492886823.1240.5.camel@op.pl \
--to=freddie_chopin-fwhlretftxm@public.gmane.org \
--cc=devicetree-spec-u79uwXL29TY76Z2rM5mHXA@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 NNTP newsgroup(s).