[U-Boot] [PATCH 3/7] arm: use generic dtb rule with CONFIG_DEFAULT_DEVICE_TREE

[Simon Glass]

+Masahiro

Hi Thomas,

On 5 January 2016 at 06:16, Thomas Chou <thomas at 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