From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Chou Date: Wed, 6 Jan 2016 09:57:12 +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> <568BC23D.4040500@wytron.com.tw> Message-ID: <568C7478.6060305@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?06? 08:24, Simon Glass wrote: > +Masahiro > > Hi Thomas, > > On 5 January 2016 at 06:16, Thomas Chou 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