| Message ID | 1451223875-20914-3-git-send-email-thomas@wytron.com.tw |
|---|---|
| State | Superseded |
| Delegated to: | Simon Glass |
| Headers | show |
On Sun, Dec 27, 2015 at 9:44 PM, Thomas Chou <thomas@wytron.com.tw> wrote: > Use generic dtb rule with CONFIG_DEFAULT_DEVICE_TREE, so that > there is no need to list all the dtb for different targets/boards. > > Signed-off-by: Thomas Chou <thomas@wytron.com.tw> > Cc: Albert Aribaud <albert.u.boot@aribaud.net> > --- > arch/arm/dts/Makefile | 192 +------------------------------------------------- > 1 file changed, 1 insertion(+), 191 deletions(-) > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Hi Thomas, On 27 December 2015 at 19:16, Bin Meng <bmeng.cn@gmail.com> wrote: > On Sun, Dec 27, 2015 at 9:44 PM, Thomas Chou <thomas@wytron.com.tw> wrote: >> Use generic dtb rule with CONFIG_DEFAULT_DEVICE_TREE, so that >> there is no need to list all the dtb for different targets/boards. >> >> Signed-off-by: Thomas Chou <thomas@wytron.com.tw> >> Cc: Albert Aribaud <albert.u.boot@aribaud.net> >> --- >> arch/arm/dts/Makefile | 192 +------------------------------------------------- >> 1 file changed, 1 insertion(+), 191 deletions(-) >> > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com> The problem with these patches is that it prevents building all the compatible device tree files for a board family. The default device tree is just that - it is not the only one that can be used. A build system can taken one of the output device tree files and package it with U-Boot. If we don't build then, then that becomes impossible. What is the purpose of these patches? A better solution might be to add an option to list the files which should be built. Then we gain control over this, if that is what you are trying to achieve. Regards, Simon
Hi Simon, On 2015年12月29日 08:22, Simon Glass wrote: > Hi Thomas, > > On 27 December 2015 at 19:16, Bin Meng <bmeng.cn@gmail.com> wrote: >> On Sun, Dec 27, 2015 at 9:44 PM, Thomas Chou <thomas@wytron.com.tw> wrote: >>> Use generic dtb rule with CONFIG_DEFAULT_DEVICE_TREE, so that >>> there is no need to list all the dtb for different targets/boards. >>> >>> Signed-off-by: Thomas Chou <thomas@wytron.com.tw> >>> Cc: Albert Aribaud <albert.u.boot@aribaud.net> >>> --- >>> arch/arm/dts/Makefile | 192 +------------------------------------------------- >>> 1 file changed, 1 insertion(+), 191 deletions(-) >>> >> >> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> > > The problem with these patches is that it prevents building all the > compatible device tree files for a board family. The default device > tree is just that - it is not the only one that can be used. A build > system can taken one of the output device tree files and package it > with U-Boot. If we don't build then, then that becomes impossible. > > What is the purpose of these patches? > > A better solution might be to add an option to list the files which > should be built. Then we gain control over this, if that is what you > are trying to achieve. The device tree describes hardware. Each board is a hardware, and should have only one device tree. The u-boot is a boot loader, which might have different options to load the next stage, eg. Linux. As I see in the configs/ dir, there can be several defconfig for a board and uses the same device tree. With device tree controlled u-boot, the output is u-boot-dtb.bin for each configuration. The next stage, say, Linux, gets device tree from u-boot. A single kernel can work on many different boards bond with possibly different device tree blob and booting configuration. We can use buildman to build a family of target binary including device tree blob. So I don't see the reason to keep the list of device tree per target. Best regards, Thomas
Hi Thomas, On 28 December 2015 at 17:55, Thomas Chou <thomas@wytron.com.tw> wrote: > > Hi Simon, > > On 2015年12月29日 08:22, Simon Glass wrote: >> >> Hi Thomas, >> >> On 27 December 2015 at 19:16, Bin Meng <bmeng.cn@gmail.com> wrote: >>> >>> On Sun, Dec 27, 2015 at 9:44 PM, Thomas Chou <thomas@wytron.com.tw> wrote: >>>> >>>> Use generic dtb rule with CONFIG_DEFAULT_DEVICE_TREE, so that >>>> there is no need to list all the dtb for different targets/boards. >>>> >>>> Signed-off-by: Thomas Chou <thomas@wytron.com.tw> >>>> Cc: Albert Aribaud <albert.u.boot@aribaud.net> >>>> --- >>>> arch/arm/dts/Makefile | 192 +------------------------------------------------- >>>> 1 file changed, 1 insertion(+), 191 deletions(-) >>>> >>> >>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> >> >> >> The problem with these patches is that it prevents building all the >> compatible device tree files for a board family. The default device >> tree is just that - it is not the only one that can be used. A build >> system can taken one of the output device tree files and package it >> with U-Boot. If we don't build then, then that becomes impossible. >> >> What is the purpose of these patches? >> >> A better solution might be to add an option to list the files which >> should be built. Then we gain control over this, if that is what you >> are trying to achieve. > > > The device tree describes hardware. Each board is a hardware, and should have only one device tree. The u-boot is a boot loader, which might have different options to load the next stage, eg. Linux. As I see in the configs/ dir, there can be several defconfig for a board and uses the same device tree. With device tree controlled u-boot, the output is u-boot-dtb.bin for each configuration. > > The next stage, say, Linux, gets device tree from u-boot. A single kernel can work on many different boards bond with possibly different device tree blob and booting configuration. > > We can use buildman to build a family of target binary including device tree blob. So I don't see the reason to keep the list of device tree per target. One of the benefits of device tree is that we can run the same code paths on multiple boards. Then buildman has less work to do. For example, if it builds 'snow' then we know that 'pit' and 'pi' are good also. If you change the way device trees work then we lose this benefit. It would be great if we could build (say) 100 boards for 100% code coverage instead of 1000 boards. If you can find a way to build all the device tree files for a particular SoC without listing them out in the Makefile, then fine. But I really don't want to lose that feature. It is very useful. Another example is sandbox, which builds both 'sandbox.dts' and 'test.dts'. It allows us to run a test easily: ./sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb -c "ut dm usb_kdb" for example. If we didn't have that it would be a right pain to run tests. I still don't understand what problem you are trying to solve. Can you explain again what is wrong with the status quo? Regards, Simon
Hi Simon, On 2016年01月05日 08:56, Simon Glass wrote: > One of the benefits of device tree is that we can run the same code > paths on multiple boards. Then buildman has less work to do. For > example, if it builds 'snow' then we know that 'pit' and 'pi' are good > also. If you change the way device trees work then we lose this > benefit. It would be great if we could build (say) 100 boards for 100% > code coverage instead of 1000 boards. > > If you can find a way to build all the device tree files for a > particular SoC without listing them out in the Makefile, then fine. > But I really don't want to lose that feature. It is very useful. > I am preparing an update v2 to support building list of DT from configs. By adding support of list to DEFAULT_DEVICE_TREE, This option specifies a space-separated list of Device Tree used for DT control. Each DT in the list will be compiled. The first will be used as default to ship. > Another example is sandbox, which builds both 'sandbox.dts' and > 'test.dts'. It allows us to run a test easily: > > ./sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb -c "ut dm > usb_kdb" for example. > > If we didn't have that it would be a right pain to run tests. > No problem. The test.dtb rules is retained. > I still don't understand what problem you are trying to solve. Can you > explain again what is wrong with the status quo? The current build generate too many DTB that users probably don't want/need. And the arch//dts/Makefile grows fat as every new board/target add lines to it. There should be some way to handle it in a cleaner style. Best regards, Thomas
+Masahiro Hi Thomas, On 5 January 2016 at 06:16, Thomas Chou <thomas@wytron.com.tw> wrote: > Hi Simon, > > On 2016年01月05日 08:56, Simon Glass wrote: >> >> One of the benefits of device tree is that we can run the same code >> paths on multiple boards. Then buildman has less work to do. For >> example, if it builds 'snow' then we know that 'pit' and 'pi' are good >> also. If you change the way device trees work then we lose this >> benefit. It would be great if we could build (say) 100 boards for 100% >> code coverage instead of 1000 boards. >> >> If you can find a way to build all the device tree files for a >> particular SoC without listing them out in the Makefile, then fine. >> But I really don't want to lose that feature. It is very useful. >> > > I am preparing an update v2 to support building list of DT from configs. > > By adding support of list to DEFAULT_DEVICE_TREE, > This option specifies a space-separated list of Device Tree used > for DT control. Each DT in the list will be compiled. The first will be > used as default to ship. It would be better if we could ship all of them, and select the right tone at run-time. > >> Another example is sandbox, which builds both 'sandbox.dts' and >> 'test.dts'. It allows us to run a test easily: >> >> ./sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb -c "ut dm >> usb_kdb" for example. >> >> If we didn't have that it would be a right pain to run tests. >> > > No problem. The test.dtb rules is retained. > >> I still don't understand what problem you are trying to solve. Can you >> explain again what is wrong with the status quo? > > > The current build generate too many DTB that users probably don't want/need. > And the arch//dts/Makefile grows fat as every new board/target add lines to > it. There should be some way to handle it in a cleaner style. But at least we get a clear list of what is includes, and what SoC it relates to. Linux uses the same approach. I'm really not sold on this idea. Regards, Simon
Hi Simon, On 2016年01月06日 08:24, Simon Glass wrote: > +Masahiro > > Hi Thomas, > > On 5 January 2016 at 06:16, Thomas Chou <thomas@wytron.com.tw> wrote: >> Hi Simon, >> >> On 2016年01月05日 08:56, Simon Glass wrote: >>> >>> One of the benefits of device tree is that we can run the same code >>> paths on multiple boards. Then buildman has less work to do. For >>> example, if it builds 'snow' then we know that 'pit' and 'pi' are good >>> also. If you change the way device trees work then we lose this >>> benefit. It would be great if we could build (say) 100 boards for 100% >>> code coverage instead of 1000 boards. >>> >>> If you can find a way to build all the device tree files for a >>> particular SoC without listing them out in the Makefile, then fine. >>> But I really don't want to lose that feature. It is very useful. >>> >> >> I am preparing an update v2 to support building list of DT from configs. >> >> By adding support of list to DEFAULT_DEVICE_TREE, >> This option specifies a space-separated list of Device Tree used >> for DT control. Each DT in the list will be compiled. The first will be >> used as default to ship. > > It would be better if we could ship all of them, and select the right > tone at run-time. > >> >>> Another example is sandbox, which builds both 'sandbox.dts' and >>> 'test.dts'. It allows us to run a test easily: >>> >>> ./sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb -c "ut dm >>> usb_kdb" for example. >>> >>> If we didn't have that it would be a right pain to run tests. >>> >> >> No problem. The test.dtb rules is retained. >> >>> I still don't understand what problem you are trying to solve. Can you >>> explain again what is wrong with the status quo? >> >> >> The current build generate too many DTB that users probably don't want/need. >> And the arch//dts/Makefile grows fat as every new board/target add lines to >> it. There should be some way to handle it in a cleaner style. > > But at least we get a clear list of what is includes, and what SoC it > relates to. Linux uses the same approach. I'm really not sold on this > idea. > Thanks for the explanation. Now I understand. But there is no harm to add list support for building DT to configs. Please review and pick 1/9 and 2/9 of PATCH v2. And leave the rest to arch custodians. Best regards, Thomas
Hi Thomas, 2016-01-06 10:57 GMT+09:00 Thomas Chou <thomas@wytron.com.tw>: > Thanks for the explanation. Now I understand. But there is no harm to add > list support for building DT to configs. Please review and pick 1/9 and 2/9 > of PATCH v2. And leave the rest to arch custodians. I want this consistent throughout U-Boot tree. Please do not leave it to each custodian. 1/9 is OK. If we decide to not do 3/9 - 9/9, 2/9 will be useless.
Hi Masahiro, On 2016年01月06日 10:22, Masahiro Yamada wrote: > Hi Thomas, > > 2016-01-06 10:57 GMT+09:00 Thomas Chou <thomas@wytron.com.tw>: >> Thanks for the explanation. Now I understand. But there is no harm to add >> list support for building DT to configs. Please review and pick 1/9 and 2/9 >> of PATCH v2. And leave the rest to arch custodians. > > > I want this consistent throughout U-Boot tree. > Please do not leave it to each custodian. OK. > > 1/9 is OK. > Thanks. This is actually a bug fix. > If we decide to not do 3/9 - 9/9, > 2/9 will be useless. > OK. Please drop them. Best regards, Thomas
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 0bcd316..6c57200 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -2,197 +2,7 @@ # SPDX-License-Identifier: GPL-2.0+ # -dtb-$(CONFIG_S5PC100) += s5pc1xx-smdkc100.dtb -dtb-$(CONFIG_S5PC110) += s5pc1xx-goni.dtb -dtb-$(CONFIG_EXYNOS4) += exynos4210-origen.dtb \ - exynos4210-smdkv310.dtb \ - exynos4210-universal_c210.dtb \ - exynos4210-trats.dtb \ - exynos4412-trats2.dtb \ - exynos4412-odroid.dtb - -dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \ - exynos5250-snow.dtb \ - exynos5250-spring.dtb \ - exynos5250-smdk5250.dtb \ - exynos5420-smdk5420.dtb \ - exynos5420-peach-pit.dtb \ - exynos5800-peach-pi.dtb \ - exynos5422-odroidxu3.dtb -dtb-$(CONFIG_ARCH_ROCKCHIP) += \ - rk3288-firefly.dtb \ - rk3288-jerry.dtb \ - rk3036-sdk.dtb -dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \ - tegra20-medcom-wide.dtb \ - tegra20-paz00.dtb \ - tegra20-plutux.dtb \ - tegra20-seaboard.dtb \ - tegra20-tec.dtb \ - tegra20-trimslice.dtb \ - tegra20-ventana.dtb \ - tegra20-whistler.dtb \ - tegra20-colibri.dtb \ - tegra30-apalis.dtb \ - tegra30-beaver.dtb \ - tegra30-cardhu.dtb \ - tegra30-colibri.dtb \ - tegra30-tec-ng.dtb \ - tegra114-dalmore.dtb \ - tegra124-jetson-tk1.dtb \ - tegra124-nyan-big.dtb \ - tegra124-venice2.dtb \ - tegra210-e2220-1170.dtb \ - tegra210-p2371-0000.dtb \ - tegra210-p2371-2180.dtb \ - tegra210-p2571.dtb - -dtb-$(CONFIG_ARCH_MVEBU) += \ - armada-388-gp.dtb \ - armada-xp-gp.dtb - -dtb-$(CONFIG_ARCH_UNIPHIER) += \ - uniphier-ph1-ld4-ref.dtb \ - uniphier-ph1-ld6b-ref.dtb \ - uniphier-ph1-pro4-ref.dtb \ - uniphier-ph1-pro5-4kbox.dtb \ - uniphier-ph1-sld3-ref.dtb \ - uniphier-ph1-sld8-ref.dtb \ - uniphier-proxstream2-gentil.dtb \ - uniphier-proxstream2-vodka.dtb -dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \ - zynq-zc706.dtb \ - zynq-zed.dtb \ - zynq-zybo.dtb \ - zynq-microzed.dtb \ - zynq-picozed.dtb \ - zynq-zc770-xm010.dtb \ - zynq-zc770-xm011.dtb \ - zynq-zc770-xm012.dtb \ - zynq-zc770-xm013.dtb -dtb-$(CONFIG_ARCH_ZYNQMP) += \ - zynqmp-ep108.dtb -dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb am335x-evm.dtb -dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb - -dtb-$(CONFIG_ARCH_SOCFPGA) += \ - socfpga_arria5_socdk.dtb \ - socfpga_cyclone5_mcvevk.dtb \ - socfpga_cyclone5_socdk.dtb \ - socfpga_cyclone5_de0_nano_soc.dtb \ - socfpga_cyclone5_sockit.dtb \ - socfpga_cyclone5_socrates.dtb \ - socfpga_cyclone5_sr1500.dtb - -dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb -dtb-$(CONFIG_TARGET_BEAGLE_X15) += am57xx-beagle-x15.dtb -dtb-$(CONFIG_TARGET_STV0991) += stv0991.dtb - -dtb-$(CONFIG_LS102XA) += ls1021a-qds.dtb \ - ls1021a-twr.dtb -dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \ - fsl-ls2080a-rdb.dtb -dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds.dtb \ - fsl-ls1043a-rdb.dtb - -dtb-$(CONFIG_MACH_SUN4I) += \ - sun4i-a10-a1000.dtb \ - sun4i-a10-ba10-tvbox.dtb \ - sun4i-a10-chuwi-v7-cw0825.dtb \ - sun4i-a10-cubieboard.dtb \ - sun4i-a10-gemei-g9.dtb \ - sun4i-a10-hackberry.dtb \ - sun4i-a10-hyundai-a7hd.dtb \ - sun4i-a10-inet1.dtb \ - sun4i-a10-inet-3f.dtb \ - sun4i-a10-inet-3w.dtb \ - sun4i-a10-inet97fv2.dtb \ - sun4i-a10-inet9f-rev03.dtb \ - sun4i-a10-itead-iteaduino-plus.dtb \ - sun4i-a10-jesurun-q5.dtb \ - sun4i-a10-marsboard.dtb \ - sun4i-a10-mini-xplus.dtb \ - sun4i-a10-mk802.dtb \ - sun4i-a10-mk802ii.dtb \ - sun4i-a10-olinuxino-lime.dtb \ - sun4i-a10-pcduino.dtb \ - sun4i-a10-pov-protab2-ips9.dtb -dtb-$(CONFIG_MACH_SUN5I) += \ - sun5i-a10s-auxtek-t003.dtb \ - sun5i-a10s-auxtek-t004.dtb \ - sun5i-a10s-mk802.dtb \ - sun5i-a10s-olinuxino-micro.dtb \ - sun5i-a10s-r7-tv-dongle.dtb \ - sun5i-a10s-wobo-i5.dtb \ - sun5i-a13-ampe-a76.dtb \ - sun5i-a13-empire-electronix-d709.dtb \ - sun5i-a13-hsg-h702.dtb \ - sun5i-a13-inet-86vs.dtb \ - sun5i-a13-inet-98v-rev2.dtb \ - sun5i-a13-olinuxino.dtb \ - sun5i-a13-olinuxino-micro.dtb \ - sun5i-a13-q8-tablet.dtb \ - sun5i-a13-utoo-p66.dtb \ - sun5i-r8-chip.dtb -dtb-$(CONFIG_MACH_SUN6I) += \ - sun6i-a31-app4-evb1.dtb \ - sun6i-a31-colombus.dtb \ - sun6i-a31-hummingbird.dtb \ - sun6i-a31-i7.dtb \ - sun6i-a31-m9.dtb \ - sun6i-a31-mele-a1000g-quad.dtb \ - sun6i-a31-mixtile-loftq.dtb \ - sun6i-a31s-cs908.dtb \ - sun6i-a31s-primo81.dtb \ - sun6i-a31s-sinovoip-bpi-m2.dtb -dtb-$(CONFIG_MACH_SUN7I) += \ - sun7i-a20-ainol-aw1.dtb \ - sun7i-a20-bananapi.dtb \ - sun7i-a20-bananapro.dtb \ - sun7i-a20-cubieboard2.dtb \ - sun7i-a20-cubietruck.dtb \ - sun7i-a20-hummingbird.dtb \ - sun7i-a20-i12-tvbox.dtb \ - sun7i-a20-lamobo-r1.dtb \ - sun7i-a20-m3.dtb \ - sun7i-a20-m5.dtb \ - sun7i-a20-mk808c.dtb \ - sun7i-a20-olimex-som-evb.dtb \ - sun7i-a20-olinuxino-lime.dtb \ - sun7i-a20-olinuxino-lime2.dtb \ - sun7i-a20-olinuxino-micro.dtb \ - sun7i-a20-orangepi.dtb \ - sun7i-a20-orangepi-mini.dtb \ - sun7i-a20-pcduino3.dtb \ - sun7i-a20-pcduino3-nano.dtb \ - sun7i-a20-primo73.dtb \ - sun7i-a20-wexler-tab7200.dtb \ - sun7i-a20-wits-pro-a20-dkt.dtb \ - sun7i-a20-yones-toptech-bd1078.dtb -dtb-$(CONFIG_MACH_SUN8I_A23) += \ - sun8i-a23-evb.dtb \ - sun8i-a23-gt90h-v4.dtb \ - sun8i-a23-q8-tablet.dtb -dtb-$(CONFIG_MACH_SUN8I_A33) += \ - sun8i-a33-ga10h-v1.1.dtb \ - sun8i-a33-q8-tablet.dtb \ - sun8i-a33-sinlinx-sina33.dtb -dtb-$(CONFIG_MACH_SUN8I_A83T) += \ - sun8i-a83t-allwinner-h8homlet-v2.dtb -dtb-$(CONFIG_MACH_SUN8I_H3) += \ - sun8i-h3-orangepi-pc.dtb \ - sun8i-h3-orangepi-plus.dtb -dtb-$(CONFIG_MACH_SUN9I) += \ - sun9i-a80-optimus.dtb \ - sun9i-a80-cubieboard4.dtb - -dtb-$(CONFIG_VF610) += vf500-colibri.dtb \ - vf610-colibri.dtb - -dtb-$(CONFIG_SOC_KEYSTONE) += k2hk-evm.dtb \ - k2l-evm.dtb \ - k2e-evm.dtb \ - k2g-evm.dtb +dtb-y += $(CONFIG_DEFAULT_DEVICE_TREE:"%"=%).dtb targets += $(dtb-y)
Use generic dtb rule with CONFIG_DEFAULT_DEVICE_TREE, so that there is no need to list all the dtb for different targets/boards. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Cc: Albert Aribaud <albert.u.boot@aribaud.net> --- arch/arm/dts/Makefile | 192 +------------------------------------------------- 1 file changed, 1 insertion(+), 191 deletions(-)