dtc: .quad asm directive generation

dtc: .quad asm directive generation

[Mark A. Greer]

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?

Thanks,

Mark
---

dts:
----

/ {
	linux,phandle = <100>;
	model = "Sandpoint";
	compatible = "MPC10x";
	#address-cells = <1>;
	#size-cells = <1>;

	cpus {
		linux,phandle = <200>;
		#cpus = <1>;
		#address-cells = <1>;
		#size-cells = <0>;

		PowerPC,7447A {
			linux,phandle = <201>;
			linux,boot-cpu;
			device_type = "cpu";
			reg = <0>;
			clock-frequency = <ee6b280>;	/* 250 MHz on 82xx */
			timebase-frequency = <3b9aca0>;	/* 250/4 MHz */
			i-cache-line-size = <20>;
			d-cache-line-size = <20>;
			i-cache-size = <4000>;		/* 16MB L1 on 8245 */
			d-cache-size = <4000>;		/* 16MB L1 on 8245 */
		};
	};

	memory {
		linux,phandle = <300>;
		device_type = "memory";
		reg = <00000000 02000000>;	/* 32 MB */
	};

	chosen {
		linux,phandle = <400>;
		linux,platform = <1>;
		bootargs = "";
		linux,stdout-path = "/dev/ttyS0";
/*		interrupt-controller = <XXXX>; */
	};
};

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>

Re: dtc: .quad asm directive generation

[David Gibson]

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

Re: 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?

Re: dtc: .quad asm directive generation

[Jon Loeliger]

So, like, the other day "Mark A. Greer" mumbled:
> > 
> > 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?

For 9 months nothing.  Dave abdicates his DTC maintainer role to me.
The very next day, all hell breaks loose!  Of _course_ I have comments!

Uh, I've been bitten by the difference between the binary and asm
form of these outputs before as well.  Specifically where the reserve
map included its own layout region as a reserve block.  IIRC, though,
it was a physical versus virtual address problem that, though understood,
we didn't really resolve.

I was eventually forced to move along, as that was not the battle I
was looking for.  Our U-Boot eventually went to a straight binary
form that was directly munged into a C array definition and side-stepped
that issue.

As for the 64-bit-ness problem, I'm willing to accept donated 64-bit
hardware that would allow me to test the problems you are seeing. :-)

I mean, any patches that drift my way will be considered. :-)

Oh, and, give me a couple days to clone and set up a repository too...

jdl

Re: dtc: .quad asm directive generation

[Mark A. Greer]

On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> So, like, the other day "Mark A. Greer" mumbled:
> > > 
> > > 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?
> 
> For 9 months nothing.  Dave abdicates his DTC maintainer role to me.
> The very next day, all hell breaks loose!  Of _course_ I have comments!
> 
> Uh, I've been bitten by the difference between the binary and asm
> form of these outputs before as well.  Specifically where the reserve
> map included its own layout region as a reserve block.  IIRC, though,
> it was a physical versus virtual address problem that, though understood,
> we didn't really resolve.
> 
> I was eventually forced to move along, as that was not the battle I
> was looking for.  Our U-Boot eventually went to a straight binary
> form that was directly munged into a C array definition and side-stepped
> that issue.
> 
> As for the 64-bit-ness problem, I'm willing to accept donated 64-bit
> hardware that would allow me to test the problems you are seeing. :-)
> 
> I mean, any patches that drift my way will be considered. :-)

Heh!

Okay, right now the kernel/prom.c code is choking on the dt from the asm
file so I'll figure that out and then start poking into the dtc code and
see what I can figure out.

Mark

Re: dtc: .quad asm directive generation

[Mark A. Greer]

On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> 
> For 9 months nothing.  Dave abdicates his DTC maintainer role to me.

Jon,

I can't find dtc under ~dgibson on ozlabs anymore.  Do you have it
somewhere now?

Mark

Re: dtc: .quad asm directive generation

[David Gibson]

On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> > 
> > For 9 months nothing.  Dave abdicates his DTC maintainer role to me.
> 
> Jon,
> 
> I can't find dtc under ~dgibson on ozlabs anymore.  Do you have it
> somewhere now?

Ah, bother.  I did arrange for one of the old addresses of the tree to
keep working, but forgot that it wasn't the one which had been widely
announced.  Just a minute, I'll send an announcement to the lists.

-- 
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

Re: dtc: .quad asm directive generation

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Wed, 15 Mar 2006 17:00:59 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> I can't find dtc under ~dgibson on ozlabs anymore.  Do you have it
> somewhere now?

http://dtc.ozlabs.org/  has a link to a tarball, or
git://ozlabs.org/~dgibson/git/dtc.git

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: dtc: .quad asm directive generation

[Mark A. Greer]

On Thu, Mar 16, 2006 at 11:49:48AM +1100, David Gibson wrote:
> On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> > On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> > > 
> > > For 9 months nothing.  Dave abdicates his DTC maintainer role to me.
> > 
> > Jon,
> > 
> > I can't find dtc under ~dgibson on ozlabs anymore.  Do you have it
> > somewhere now?
> 
> Ah, bother.  I did arrange for one of the old addresses of the tree to
> keep working, but forgot that it wasn't the one which had been widely
> announced.  Just a minute, I'll send an announcement to the lists.

Okay, thanks guys.

Here is a patch that fixes a problem I'm having with asm output.  My
host system is a x86 box so its 32-bit, little endian.

Disclaimer: Everything below is AFAICT.

The problem is that asm_emit_cell() was swapping its asm output when
it shouldn't be (because the assembler will do the necessary swapping).
The cell values (asm_emit_cell()) are different from the data values
(asm_emit_data()) because the cell values are generated within the
program and don't get swapped like the data values read from the dts file.
They should be left as they are so that the assembler will swap them,
if necessary.  For example, when the property length field was 4,
the asm output contained ".long 0x4000000" and sent the kernel prom.c
dt parsing code into the weeds.

The dtb output is correct.

Did any of that make sense?

/me knows he's rambling...

Anyway, here is a simple patch the fixes it for me (i.e., the
cross-assembled asm output matches the dtb).

Mark
---

diff -Nurp dtc/flattree.c dtc_new/flattree.c
--- dtc/flattree.c	2006-02-24 10:57:56.000000000 -0700
+++ dtc_new/flattree.c	2006-03-15 18:02:07.000000000 -0700
@@ -121,7 +121,7 @@ static void asm_emit_cell(void *e, cell_
 {
 	FILE *f = e;
 
-	fprintf(f, "\t.long\t0x%x\n", be32_to_cpu(val));
+	fprintf(f, "\t.long\t0x%x\n", val);
 }
 
 static void asm_emit_string(void *e, char *str, int len)

Re: dtc: .quad asm directive generation

[David Gibson]

On Wed, Mar 15, 2006 at 06:59:24PM -0700, Mark A. Greer wrote:
> On Thu, Mar 16, 2006 at 11:49:48AM +1100, David Gibson wrote:
> > On Wed, Mar 15, 2006 at 05:00:59PM -0700, Mark A. Greer wrote:
> > > On Tue, Mar 14, 2006 at 06:06:57PM -0600, Jon Loeliger wrote:
> > > > 
> > > > For 9 months nothing.  Dave abdicates his DTC maintainer role to me.
> > > 
> > > Jon,
> > > 
> > > I can't find dtc under ~dgibson on ozlabs anymore.  Do you have it
> > > somewhere now?
> > 
> > Ah, bother.  I did arrange for one of the old addresses of the tree to
> > keep working, but forgot that it wasn't the one which had been widely
> > announced.  Just a minute, I'll send an announcement to the lists.
> 
> Okay, thanks guys.
> 
> Here is a patch that fixes a problem I'm having with asm output.  My
> host system is a x86 box so its 32-bit, little endian.
> 
> Disclaimer: Everything below is AFAICT.
> 
> The problem is that asm_emit_cell() was swapping its asm output when
> it shouldn't be (because the assembler will do the necessary swapping).
> The cell values (asm_emit_cell()) are different from the data values
> (asm_emit_data()) because the cell values are generated within the
> program and don't get swapped like the data values read from the dts file.
> They should be left as they are so that the assembler will swap them,
> if necessary.  For example, when the property length field was 4,
> the asm output contained ".long 0x4000000" and sent the kernel prom.c
> dt parsing code into the weeds.
> 
> The dtb output is correct.
> 
> Did any of that make sense?

Ah, yes, that be32_to_cpu() is, indeed, complete crap.

> /me knows he's rambling...
> 
> Anyway, here is a simple patch the fixes it for me (i.e., the
> cross-assembled asm output matches the dtb).
> 
> Mark
> ---
> 
> diff -Nurp dtc/flattree.c dtc_new/flattree.c
> --- dtc/flattree.c	2006-02-24 10:57:56.000000000 -0700
> +++ dtc_new/flattree.c	2006-03-15 18:02:07.000000000 -0700
> @@ -121,7 +121,7 @@ static void asm_emit_cell(void *e, cell_
>  {
>  	FILE *f = e;
>  
> -	fprintf(f, "\t.long\t0x%x\n", be32_to_cpu(val));
> +	fprintf(f, "\t.long\t0x%x\n", val);
>  }
>  
>  static void asm_emit_string(void *e, char *str, int len)
> 

-- 
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