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

[Masahiro Yamada]

Hello Simon,


> >>
> >> 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.
> >
> > 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.
> 
> Hmm, but would it be such a big problem to keep the general ARM and
> SOC stuff in arch/arm/dts and the board-specific stuff in board/ ?
> One of the problems with Linux is that their board-specific code is
> spread all over the place, and I'm not sure we want to emulate it?

Opposite.
Board-specific code mostly resides under
arch/arm/mach-* or arch/arm/plat-*.
And what else is arch/arm/configs and arch/arm/boot/dts. That's it.


We have board-specific part
 - entries in boards.cfg
 - include/configs/<board_config>.h
 - board/<vendor>/<board> or board/<board>
 - arch/<ARCH>/include/am/arch-<soc> includes sometimes
   board-specific headers  as well as SoC specific headers.
   (Because there is no other place to store board-specific header files)

Various stuff under include/, for exmple
  - include/xilinx.h:  vendor specific?
  - include/sandboxblockdev.h:  arch specific?

And we often missed to remove remainders of dead boards.

U-Boot has more troublesome directory structure.


> >> 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.
> 
> Shouldn't the SoC part go in arch/arm and arch/microblaze? Then just
> the board-specific stuff can go in board/

What is SoC part? What is Board part?

> >
> > What if Freescale decided to adopt device tree?
> > They support various boards on ARM, PowerPC, M68K.
> >
> > Renesus is the same. They have ARM and SuperH boards.
> 
> I'm not convinced yet. I think maybe you have forgotten about the
> .dtsi files for SoCs. They are common, but no one is going to include
> a board .dts file (nor can they), so putting them in a common area
> does not seem like a win to me.

I do know that *.dtsi files are included from others, while
*.dts files are not included from anywhere.
And I understand your policy, *.dtsi to arch dir and *.dts to vendor dir.
(No that I care, we have two exceptions:
./board/avionic-design/dts/tegra20-tamonten.dtsi
./board/avionic-design/dts/tegra30-tamonten.dtsi)

If I have to mention a win,
we can save makefiles by not putting almost same ones in
vendor directories.


Anyway, we have 3 structures proposed so far.

[1] board/$(VENDOR)/dts/  (current structure)
[2] arch/$(ARCH)/dts/  (suggested by me)
[3] dts/  for all architectures (suggested by Scott)

In my option, [2] and [3] seem to be reasonable enough.

If we cannot reach an agreement,
shall we postpone 2/3 and 3/3 and apply only 1/3?


> > On the other hand, different vendors can produce similar boards.
> > For example avionic design, which develops Tegra boards,
> > are using nVidia's sources.
> >
> > When I saw  board/nvidia/common/common.mk
> > and board/avionic-design/*/Makefile, etc., I think we're screwed up
> > with <vendor> directory.
> 
> Well the probably as I see it is that board/nvidia has some SoC code
> that other boards want to use. The solution to that might be to move
> the code to arch/arm/cpu/armv7/tegra... instead?

Concerning the result, board/nvidia/common turned out to be
SoC-specific code, not Vendor-specific (board-specific) code.

But I guess the difference between SoC-specific code and board-specific
code was not clear when nVidia develpers posted that code first.

Maybe I am digressing, but it also happens to me quite often.
It is difficult for me to decide whether each code should
go to board/panasonic or arch/arm/cpu/armv7/uniphier.

I'd say, vendor (and board) directories are harmful.


Best Regards
Masahiro Yamada