From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Chou Date: Tue, 5 Jan 2016 21:16:45 +0800 Subject: [U-Boot] [PATCH 3/7] arm: use generic dtb rule with CONFIG_DEFAULT_DEVICE_TREE In-Reply-To: References: <1451223875-20914-1-git-send-email-thomas@wytron.com.tw> <1451223875-20914-3-git-send-email-thomas@wytron.com.tw> <5681DA11.9030908@wytron.com.tw> Message-ID: <568BC23D.4040500@wytron.com.tw> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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