Hi Rob,
On 10/19/2017 04:59 PM, Rob Herring wrote:
On Thu, Oct 19, 2017 at 9:00 AM, Alexandre Torgue
<alexandre.torgue@xxxxxx> wrote:
Hi Rob,
On 10/19/2017 01:53 AM, Rob Herring wrote:
On Wed, Oct 18, 2017 at 6:28 PM, Andrew Turner <andrew@xxxxxxxxxxxxx>
wrote:
[...]
From the FreeBSD perspective I’d like it if there was a common repo for
all devicetree consumers to share. We are trying to not have FreeBSD
specific properties as this has caused issues in the past where we had (and
still have) FreeBSD specific dts files. We are trying to remove these as
drivers are updated to handle the common bindings.
Are you aware of this repo[1]? I don't have a sense for how widely
used it is. If not, it is intended to provide a common repository of
binding docs and dts files. If so, what are your issues with using it?
It's generated from the kernel tree with git-filter-branch and through
the kernel tree is the only way to add things currently. But there's
no requirement that you add a Linux driver to submit a binding or dts
change. We could consider taking patches against the tree directly,
and the maintainers (me) can fixup the paths and apply to the kernel
tree.
If there's bindings in the kernel tree you think are crap and Linux
specific, I'd like to know that too. We should start flagging those.
I have also spoken with some NetBSD and OpenBSD developers. They are both
using devicetree to handle device enumeration. Having all 5 projects using a
common set of dts files and binding would simplify keeping them in sync.
There's more than 5 likely: linux, 3x BSD, u-boot, barebox, zephyr,
ARM trusted firmware?, UEFI?, ?
First, sorry to come late in this discussion (please be tolerant if you
already respond to following requests/interrogations in precedent mails :)).
From STmicro point of view we have the same kind of requests/needs than
Andrew. We think about the possibility to use same DTS files for Linux,
U-boot, ATF and Zephir (others could come with other vendors). Currently our
main concerns about this are:
1-How to reduce dtb size:
--> Reading some thread, you already start this task with Nicolas.
Does it concerns only XiP system ?
That's the main focus ATM. Nico has looked at shrinking code usage too
such as the tty layer and scheduler, but those have faced resistance.
We need actual products to prove the value (and that's a chicken and
egg problem).
-->For example, I want to use the same dtsi files between Linux and
U-boot. If in u-boot dts file I overload several "status" entry by
"disabled", is it possible that compiler doesn't build it ? And what about
not used phandle ?
You certainly could remove disabled nodes in dtc. I'm not sure how
hard it would be to plumb into dtc. I think phandle properties are
already only created if there's a reference to them. If that is
created before you deleted nodes, then it would probably be hard to
find and remove all of those. It would be similar to solving the
device dependency problem. Or do you mean something like disable the
clock controller node if there are no enabled references to it? I
don't think we could do something like that generically and reliably.
We did recently stop creating both "phandle" and "linux,phandle"
properties by default in dtc, so that will save some size.
I responded to Frank. On my side, disabled nodes and not used phandles
are presents in DTB binary. Maybe I didn't use correctly the DTC. Are
there specific things to do ?
2- The place of DT files (sources/scripts). I see (and clone) your
"devicetree-rebasing.git" tree, it's a good start point. Currently (correct
me if I'm wrong) the Kernel seems to "lead" the devicetree bindings and
devicetree dts(i) files.
Yes, and there's not really any changing that regardless of where
bindings and dts files live given Linux has the broadest h/w support.
By using this external repo, it would be maybe
easier to integrate changes for other components than Linux Kernel ?
Yes, barebox at least regularly imports it.
Yes, I just saw that. So currently it means that we could push DT
changes by component (ATF/uBOOT) in this repo directly ? and then get
it in our local ATF or Uboot project ?
We
could have (per vendor), same dtsi files which describes the hardware (SoC +
board) and a extra dts files (at least at beginning) per software components
to overload nodes (to disable some nodes not required (see (1)), to change
bindings which are different regarding component ...).
You mean dtsi files to disable nodes for linux, u-boot, etc. That may
make sense for mutually exclusive things like FreeBSD vs. Linux, but
for say u-boot, we really want u-boot and Linux (or whatever OS is
loaded) to use the same dtb. Having different dtbs is going to
increase your memory usage.
We could have different needs. For example I have a board and I would
like to have he following bootchain: ATF then Uboot then Kernel. For
that, I would like to use the same DTs files for the 3 components (and
the memory footprint is not an issue). The idea is to share HW
description between several components. But some differences implies to
overload dts files per component:
-bindings could be slightly different (the case between Linux and uboot)
-frameworks bindings (basically phandles) depends on sw component: ATF
will not define clocks as kernel done.
-Using several DTB is not an issue. For ATF we have to use a DTB as
small as possible.
It's for this reason I said that using the external repo could be a good
thing in order to add extra dts files per components for overloading.
I understand that people wants also to have the same binary for several
components but it doesn't prevent to have the both solutions.
It will also allow to have all dt script / tools for all components at only
one place.
Once again, sorry if I repeat things already discussed but I wanted to
expose what STMicro has in mind for DT. It will be a good topic to discuss
at Prague.
Yes, but I won't be there.
Ok. I hope we will arrive to converge at Prague with Grant and involved
peoples ;). As we (ST) have already several components using DT, we
could help to prototype.
Regards
Alex
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
