dtc: .quad asm directive generation

[Mark A. Greer]

On Tue, Mar 14, 2006 at 02:31:35PM +1100, David Gibson wrote:
> On Mon, Mar 13, 2006 at 02:21:05PM -0700, Mark A. Greer wrote:
> > Hi David,
> > 
> > I'm playing around with moving some 32-bit embedded platforms (that don't
> > have OF or dev-tree-aware uboot) to the powerpc tree.  Basically, I make an
> > initial .dts file for that platform then dtc-compile it using:
> > 
> > dtc -I dts -O asm -o <platform>.S -V 16 <platform>.dts
> > 
> > Then I build the <platform>.S file with the normal bootwrapper/kernel build.
> > 
> > The problem I'm having is that dtc generates some .quad directives that
> > is causing my 32-bit assembler to choke (.quad not supported).  Do we need
> > a 32-bit switch for dtc or should I be giving some sort of switch to
> > gcc(version 3.4.3)/gas(version 2.15.94) to make it work?
> 
> [snip]
> > dtc asm output:
> > ---------------
> > 
> > /* autogenerated by dtc, do not edit */
> > 
> > <snip>
> > 
> > dt_reserve_map:
> > _dt_reserve_map:
> > 	.quad	0, _dt_blob_start
> > 	.quad	0, _dt_blob_end - _dt_blob_start
> > /* Memory reserve map from source file */
> > 	.quad	0
> > 	.quad	0
> > 
> > <snip>
> 
> Oh, bother.  I guess I never tried with a 32-bit only assembler.  Um,
> a number of observations are applicable here:
> 	- The flattened tree spec defines the memory range fields to
> be 64-bit quantities, always, so these things shouldn't just become
> ".long" for 32-bit targets.
> 	- For the "spacer" 0 entries, we can and should just replace
> the .quad with two ".long" directives, easy change.
> 	- The autogenerated entry reserving the tree itself, however,
> is trickier.  It genuinely needs to be a .quad for 64-bit targets.  So
> I guess we'd have to have a 32/64 bit target option.  Yuck.
> 	- IIRC BenH was contemplating revising the spec so that the
> range for the device tree is reserved implicitly, like the range for
> the kernel image, so it wouldn't have to be listed in the blob.  This
> would sidestep the problem, though we would have to change dtc to omit
> this entry, at least for suitable output blob versions.
> 	- I've been thinking for a while, that the whole memory
> reserve thing needs some work in dtc.  The fact that the range for the
> tree blob is included automatically for asm output, but not for blob
> output is a wart, at least.  I was thinking about instead of
> automatically generating it, including a new keyword, or form for the
> /memreserve/ directive that will generate this range if necessary /
> possible.  I never got around to implementing that, though.
> 
> And finally, as of, well right about now, until October or so, I'm
> expecting to be unavailable, off travelling and things.  In the
> interim Jon Loeliger of Freescale has agreed to be dtc maintainer.

Jon, any comments?