
Hi Pantelis,
On 7 July 2017 at 01:02, Pantelis Antoniou pantelis.antoniou@konsulko.com wrote:
Hi Simon,
On Thu, 2017-07-06 at 21:58 -0600, Simon Glass wrote:
On 30 June 2017 at 10:23, Pantelis Antoniou pantelis.antoniou@konsulko.com wrote:
This patch enables an overlay to refer to a previous overlay's labels by performing a merge of symbol information at application time.
In a nutshell it allows an overlay to refer to a symbol that a previous overlay has defined. It requires both the base and all the overlays to be compiled with the -@ command line switch so that symbol information is included.
base.dts
/dts-v1/; / { foo: foonode { foo-property; }; }; $ dtc -@ -I dts -O dtb -o base.dtb base.dts
bar.dts
/dts-v1/; /plugin/; / { fragment@1 { target = <&foo>; __overlay__ { overlay-1-property; bar: barnode { bar-property; }; }; }; }; $ dtc -@ -I dts -O dtb -o bar.dtb bar.dts
baz.dts
/dts-v1/; /plugin/; / { fragment@1 { target = <&bar>; __overlay__ { overlay-2-property; baz: baznode { baz-property; }; }; }; }; $ dtc -@ -I dts -O dtb -o baz.dtb baz.dts
Applying the overlays:
$ fdtoverlay -i base.dtb -o target.dtb bar.dtb baz.dtb
Dumping:
$ fdtdump target.dtb / { foonode { overlay-1-property; foo-property; linux,phandle = <0x00000001>; phandle = <0x00000001>; barnode { overlay-2-property; phandle = <0x00000002>; linux,phandle = <0x00000002>; bar-property; baznode { phandle = <0x00000003>; linux,phandle = <0x00000003>; baz-property; }; }; }; __symbols__ { baz = "/foonode/barnode/baznode"; bar = "/foonode/barnode"; foo = "/foonode"; }; };
Signed-off-by: Pantelis Antoniou pantelis.antoniou@konsulko.com
lib/libfdt/fdt_overlay.c | 148 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 147 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
I suppose that the upstream version has tests?
Yes, and I could use a couple reviewers in the dtc mailing list.
Ah OK, I will take a look.
Does it make sense to implement this in the live tree instead, or do you need to modify the DT before relocation?
There is a port of a patch that works on the live tree; I guess I can port it to u-boot's live tree as well.
Do you mean 'as well'? I am wondering if we can get away with only supporting the live tree for overlays. Or do you think that will be too limiting?
Obviously the live and flat tree versions do essentially the same thing, so if we can it would be good to include only one version of the code.
Speaking of which I've done quite a bit of work on a different live tree implementation as well. I would propose we split off u-boot's one in a library and port my changes there. That way we can have a definitive live tree implementation, and in the future move dtc's internal live tree to it as well. We keep on implementing the same functionality in different flavors for years, let's consolidate, and start working on ideas for the future.
What about the kernel? I took most of the of_access.c code from there and trying to avoid changing it as much as possible. The extra bits for U-Boot are the ofnode implementation (to permit transparent use of live/flat trees) and of course dev_read_...().
I think it would be great to have a live tree upstream in dtc that we can pull into U-Boot. But I'm keen to line it up with Linux.
Regards, Simon