[U-Boot] [PATCH v2 2/3] dts: move device tree sources to arch/$(ARCH)/dts/

Michal Simek monstr at monstr.eu
Tue Feb 18 15:59:26 CET 2014


On 02/18/2014 03:32 PM, Tom Rini wrote:
> On Thu, Feb 06, 2014 at 02:50:50PM +0900, Masahiro Yamada wrote:
>> Hello Simon,
>>
>>
>>> Hi Masahiro,
>>>
>>> On 4 February 2014 02:38, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
>>>> Unlike Linux Kernel, U-Boot historically had *.dts files under
>>>> board/$(VENDOR)/dts/ and *.dtsi files under arch/$(ARCH)/dts/.
>>>>
>>>> I think arch/$(ARCH)/dts dicretory is a better location
>>>> to store both *.dts and *.dtsi files.
>>>>
>>>> For example, before this commit, board/xilinx/dts directory
>>>> had both MicroBlaze dts (microblaze-generic.dts) and
>>>> ARM dts (zynq-*.dts), which are totally unrelated.
>>>>
>>>> This commit moves *.dts to arch/$(ARCH)/dts/ directories,
>>>> allowing us to describe nicely mutiple DTBs generation in the next commit.
>>>
>>> What is the motivation for this? I worry that we might end up with a
>>> lot of files in one directory.
>>
>> We have only 35 .dtsi and .dts for ARM.
>> I think it will be OK at least until we have 500.
>>
>> Linux v3.13 has 500 .dtsi and .dts files in arch/arm/boot/dts/
>> and they are still adding device trees to that directory.
> 
> Last I saw the plan, still, is to remove them from the kernel "someday".
> Hopefully when that happens we can also leverage what comes next.
> 
>> I have no idea if they will keep going, or someone will scream and turn
>> around.
>>
>> Anyway, when Linux guys someday invents a nice idea to work arond
>> increasing device trees, we can import it to U-Boot.
>> It should be easy for us because we already have a similar build system.
> 
> True.
> 
>>> One benefit of the current approach is
>>> that .dts files are split up by vendor. Even if we put the SoC .dtsi
>>> files in arch/arm, perhaps there is a benefit in leaving the board
>>> .dts files in board/<vendor>?
>>
>> I don't like the idea to split up by vendor.
>>
>> Now Xilinx has device trees both for ARM and Microblaze,
>> resulting in totally unrelated device trees in one directory.
>
> This, I think is backwards.  Xilinx has (and Freescale and others are or
> will be joining them) a lot of things shared between them as IP blocks
> get reused from non-ARM to ARM CPUs.  So there's a level of DT sharing
> for these blocks between the CPUs.  The kernel is going to start having
> this problem as vendors start dropping their arm IP blocks into ARMv8
> SoCs, and those would be in arch/arm64/.  The question is, will people
> care enough about the duplication, or just live with it.

We share all soft IP drivers between ARM and Microblaze and we will continue
in this style. The point is to have the same binding which we have.
We are using device-tree generator to get the latest binding which is
in sync with kernel. When we adopt u-boot configured by device-tree
(when variable handling in u-boot is fixed) we will use the same binding
in uboot too.

I personally don't care where DTS files will be placed because we will
generate them as we are doing now.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140218/b0dc8f72/attachment.pgp>


More information about the U-Boot mailing list