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

Grant Likely grant.likely at secretlab.ca
Tue Jan 31 08:31:15 EST 2012


On Mon, Jan 30, 2012 at 05:42:12PM +0000, Dave Martin wrote:
> 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:
> > > > 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.

g.


More information about the devicetree-discuss mailing list