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

[Simon Glass]

Hi Thomas,

On 28 December 2015 at 17:55, Thomas Chou <thomas at 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 at gmail.com> wrote:
>>>
>>> On Sun, Dec 27, 2015 at 9:44 PM, Thomas Chou <thomas at 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 at wytron.com.tw>
>>>> Cc: Albert Aribaud <albert.u.boot at aribaud.net>
>>>> ---
>>>>   arch/arm/dts/Makefile | 192 +-------------------------------------------------
>>>>   1 file changed, 1 insertion(+), 191 deletions(-)
>>>>
>>>
>>> Reviewed-by: Bin Meng <bmeng.cn at 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