Re: [PATCH v6 9/9] ARM: vexpress: Add Device Tree for V2P-CA15 core tile (TC1 variant)

On Mon, Jan 30, 2012 at 02:31:15PM -0700, Grant Likely wrote:

On Mon, Jan 30, 2012 at 05:42:12PM +0000, Dave Martin wrote:

quoted

On Wed, Jan 25, 2012 at 05:43:16PM +0000, Pawel Moll wrote:

quoted

On Thu, 2012-01-19 at 17:00 +0000, David Vrabel wrote:

quoted

quoted

Ok, /include/ "skeleton.dtsi" is gone then :-)

The problem wasn't with including skeleton.dtsi.  With
CONFIG_ARM_ATAG_DTB_COMPAT the zImage decompressor modifies the appended
DTB using information from the ATAGs (see atags_to_fdt()).

If there's an ATAG giving the amount of RAM the DTB's "memory" node is
replaced with a new one.  Since the vexpress DTBs don't have a "memory"
node it's added and the DTB ends up with two nodes describing memory.

As it turned out it was just the "skeleton.dtsi" problem after all - I
mean the fact that there where two device_type="memory" nodes in the
tree.

The decompressor's setprop()
(arch/arm/boot/compressed/atags_to_fdt.c:12) uses libfdt's
fdt_setprop(), which correctly ignores the "@00000000" component of the
node name and sets the reg property as expected. So as long as there is
exactly one "memory[@address]" node in the tree,
CONFIG_ARM_ATAG_DTB_COMPAT is happy.

I will remove the /include/ from the dts files for VE (see below) in the
v3.3-rc1 based series.

Thanks for spotting this!

Pawe??

This carries a significant risk of unintended fragmentation and buggy
maintenance.  This patch is a good example of the kind of change which
could easily go wrong.  (I'm not saying that it is wrong -- just using
it as an example.)

Since we will end up with a significantly large number of device trees
for vexpress, I can foresee that we'll end up with a highly reduncant
set of .dts{,i} files (each of which is often rather internally redundant
too).

Does anyone have a view on whether it's acceptable to generate device
tree sources from another form, instead of having them verbatim in the
kernel tree?  This could involve a preprocessor, or something more
heavyweight.

Yes, the xilinx folks have been using a dts generator to create the
device tree that matches an FPGA design.  This works on ppc and
microblaze, and they'll do the same thing for their ARM FPGA SoC.

OK, well I guess it's good to know we have the option to consider such
techniques for vexpress in the future.

For now, I suggest we paste in the .dts files as-is, since the situation
is not too unmanageable for now, and we don't unnecessary feature creep
to hold up merging of the series.

Cheers
---Dave