Hi Frank,
On 10/19/2017 08:46 PM, Frank Rowand wrote:
On 10/19/17 07:59, 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
Yes, phandles are only created if referenced, unless compiled
for loading overlays into:
Are there DTC "extra" options to use to not build those useless phandles
? I just tried to revert the dtb to dts (using following command:
./scripts/dtc/dtc -I dtb -O dts -o stm32f469-disco-flat.dts
arch/arm/boot/dts/stm32f469-disco.dtb)
I see that phandles not used are in the dts output file. It is
especially an issue for pinmux phandles. All pinmux groups possibilities
are written inside (in my case) stm32f4-pinctrl.dtsi. This file is
included in each stm32 board dts files, and in those stm32 board dts
files only required node are enabled. But I see that all pinmux
definitions are embedded inside dtb binary (even ones not used in board
dts file).
regards
Alex
$ cat test1.dts
/dts-v1/;
/ {
mynode: node {
};
};
$ cat test2.dts
/dts-v1/;
/ {
mynode: node {
myprop = < &mynode >;
};
};
$ scripts/dtc/dtx_diff test1.dts
/dts-v1/;
/ {
mynode: node {
};
};
$ scripts/dtc/dtx_diff test2.dts
/dts-v1/;
/ {
mynode: node {
myprop = <0x1>;
phandle = <0x1>;
};
};
If symbols are enabled for a base device tree, so that overlays
can later reference them, then all symbols generate phandles:
$ dtc -@ -O dts test1.dts
/dts-v1/;
/ {
mynode: node {
phandle = <0x1>;
};
__symbols__ {
mynode = "/node";
};
};
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.
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.
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.
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.
Rob
_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@xxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
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
