[OpenWrt-Devel] [PATCH 4/8] mvebu: image: keep global DTS_DIR intact

[Adrian Schmutzler]

Hi,

> -----Original Message-----
> From: Tomasz Maciej Nowak [mailto:tomek_n at o2.pl]
> Sent: Freitag, 31. Januar 2020 19:39
> To: Adrian Schmutzler <mail at adrianschmutzler.de>; openwrt-
> devel at lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH 4/8] mvebu: image: keep global DTS_DIR
> intact
> 
> W dniu 31.01.2020 o 17:02, Adrian Schmutzler pisze:
> > Hi,
> >
> >> -----Original Message-----
> >> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org] On
> >> Behalf Of Tomasz Maciej Nowak
> >> Sent: Freitag, 31. Januar 2020 16:46
> >> To: openwrt-devel at lists.openwrt.org
> >> Subject: [OpenWrt-Devel] [PATCH 4/8] mvebu: image: keep global DTS_DIR
> intact
> >>
> >> Don't rewrite global DTS_DIR, instead, use proper variable for
> >> specifying devices dts directory.
> >
> > Have you build-tested this?
> 
> Yes, images built fine before sending and from glance, they looked fine. What I
> did not test was Image Builder. Will do that and send a feedback.

On a second look, if you introduce DEVICE_DTS_DIR for Default-arm64, we should also introduce it to Device/Default:

DEVICE_DTS_DIR := $(DTS_DIR)

Otherwise, we would have part of the target relying on the device-specific variable and part on the global one, and I do not think that's desirable. With the change, the whole target will use DEVICE_DTS_DIR.

> 
> > DEVICE_DTS_DIR and DTS_DIR might behave differently
> > when it comes to includes in DTS files.
> > That's why I couldn't replace SUNXI_DTS_DIR with DEVICE_DTS_DIR when
> touching
> > this some months ago.
> 
> The issue might stem from DEVICE_VARS defined inside the profile, which might
> be exported too late? I'm not so good at Makefile syntax so maybe others can
> comment on that.

For sunxi, no. There the problem is that DEVICE_DTS_DIR is present in conditions in image.mk (or one of those files), and the device setup in sunxi itself assumes that subdirs are part of DEVICE_DTS. But this effectively might be a separate issue, as it is connected to the setup in sunxi.
It's not easy to fix that in a proper way.

Best

Adrian

> 
> >
> > Best
> >
> > Adrian
> 
> Regards
> 
> >
> >>
> >> Signed-off-by: Tomasz Maciej Nowak <tomek_n at o2.pl>
> >> ---
> >>  target/linux/mvebu/image/Makefile | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/target/linux/mvebu/image/Makefile
> >> b/target/linux/mvebu/image/Makefile
> >> index d9e4b1acce..ae4d3b9594 100644
> >> --- a/target/linux/mvebu/image/Makefile
> >> +++ b/target/linux/mvebu/image/Makefile
> >> @@ -91,7 +91,7 @@ endef
> >>
> >>  define Device/Default-arm64
> >>    BOOT_SCRIPT := generic-arm64
> >> -  DTS_DIR := $(DTS_DIR)/marvell
> >> +  DEVICE_DTS_DIR := $(DTS_DIR)/marvell
> >>    IMAGES := sdcard.img.gz
> >>    IMAGE/sdcard.img.gz := boot-scr | boot-img-ext4 | sdcard-img-ext4 | gzip |
> >> append-metadata
> >>    KERNEL_NAME := Image
> >> --
> >> 2.25.0
> >>
> >>
> >> _______________________________________________
> >> openwrt-devel mailing list
> >> openwrt-devel at lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> 
> 
> --
> TMN


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel