Re: dtc: .quad asm directive generation

[David Gibson <david@gibson.dropbear.id.au>]

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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson