From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 14 Mar 2006 16:52:54 -0700 From: "Mark A. Greer" To: David Gibson Subject: Re: dtc: .quad asm directive generation Message-ID: <20060314235254.GA6045@mag.az.mvista.com> References: <20060313212105.GA11995@mag.az.mvista.com> <20060314033135.GA24168@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20060314033135.GA24168@localhost.localdomain> Cc: linuxppc-dev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 .S -V 16 .dts > > > > Then I build the .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 */ > > > > > > > > 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 > > > > > > 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?