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

[Thomas Chou <thomas@wytron.com.tw>]

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