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

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.

The dts /include/ mechanism solves this problem only for the simplest
of cases.

Cheers
---Dave