Hi Masahiro,
On 5 February 2014 22:50, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hello Simon,
Hi Masahiro,
On 4 February 2014 02:38, Masahiro Yamada yamada.m@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?
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 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.
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?
Best Regards Masahiro Yamada
Regards, Simon