From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DA2F.BC0405AC" Subject: RE: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets Date: Sun, 29 Jun 2008 14:30:08 -0700 References: <20080625202104.30114.47902.stgit@trillian.secretlab.ca><20080626164842.1D3AB1358053@mail15-sin.bigfish.com><1214507238.7698.3.camel@weaponx><20080626201643.D01221788058@mail223-wa4.bigfish.com> From: Stephen Neuendorffer To: "Grant Likely" Message-ID: <20080629213315.485331AB8053@mail79-dub.bigfish.com> Cc: linuxppc-dev@ozlabs.com, Scott Wood , paulus@samba.org, John Linn , petermendham@computing.dundee.ac.uk List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , ------_=_NextPart_001_01C8DA2F.BC0405AC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable simpleImage should also create an .elf (for xmd or systemAce loading) If dtbImage and simpleImage could be merged, I'd be all for it... At some point of course, I need to figure merge the Device Tree in BRAM cod= e that I've been using, which would be a simpleImage which wouldn't need a = device tree. However, I don't see this happening before August. Steve -----Original Message----- From: glikely@secretlab.ca on behalf of Grant Likely Sent: Fri 6/27/2008 9:22 PM To: Stephen Neuendorffer Cc: Josh Boyer; John Linn; linuxppc-dev@ozlabs.com; paulus@samba.org; peter= mendham@computing.dundee.ac.uk; Scott Wood; Geoff Levand Subject: Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrapper= targets = On Thu, Jun 26, 2008 at 1:16 PM, Stephen Neuendorffer wrote: > Forgive my ignorance here, but what specifically does this imply? As > far as I can tell, generally speaking, some of the board-specific > information is passed into the boot wrapper, which then stuffs it into > the device tree. Yes, you are correct. I'll fill out the documentation more here. >> uImage is for device-tree aware U-Boot versions > > And this differs from above because it gets a device tree passed in, > which uboot has already stuffed correctly. Correct. >> dtbImage is used for boards that can take an ELF zImage, but still > need >> a dtb provided. >> >> simpleImage, not sure here. > > So both of these are elfs... but how do they differ? Is it only in how > the right head.s file gets picked up? simpleImage is not an elf. Its a raw position-independent binary which can be loaded anywhere in RAM. Some dtbImages are elfs; but there are a flat binaries. The main difference is that all simpleImages assume that firmware provides nothing interesting; but the flat dtbImages have custom code for extracting a little bit of data out of the boards firmware. It's all a bit of a confusing mess. It might be a good idea to rework all the image names to stuff not so non-obvious, but I'm not sure the best way to go about it. There is a lot of historical stuff in there where the various 'zImage.*' targets grew and morphed over time in ways that are hard to follow. It may make more sense to change the flat-binary dtbImages to be simpleImages instead with overrides for specific boards (just like is done for virtex405-*). ps3 is the other major user of dtbImage. I created the whole dtbImage stuff in the first place to eliminate overloaded makefile targets where some zImage% target were providing a device tree and other zImage% targets were not. Splitting dtb-provided from dtb-not-provided targets clarified the Makefile quite a bit. dtbImage is not a fantastic name, but I needed something different from zImage for images with an embedded device tree. Looking at the Makefile, dtbImage and simpleImage targets are virtually identical. Perhaps it would be best to merge the targets and deal with all the differences in the wrapper script (with the default to just use simpleboot.S as the init code). Thoughts? Cheers, g. -- = Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. This email and any attachments are intended for the sole use of the named r= ecipient(s) and contain(s) confidential information that may be proprietary= , privileged or copyrighted under applicable law. If you are not the intend= ed recipient, do not read, copy, or forward this email message or any attac= hments. Delete this email message and any attachments immediately. ------_=_NextPart_001_01C8DA2F.BC0405AC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PATCH] powerpc/bootwrapper: Add documentation of boot wrapperta= rgets

simpleImage should also create an .elf (for xmd or system= Ace loading)
If dtbImage and simpleImage could be merged, I'd be all for it...

At some point of course, I need to figure merge the Device Tree in BRAM cod= e that I've been using, which would be a simpleImage which wouldn't need a = device tree.  However, I don't see this happening before August.

Steve

-----Original Message-----
From: glikely@secretlab.ca on behalf of Grant Likely
Sent: Fri 6/27/2008 9:22 PM
To: Stephen Neuendorffer
Cc: Josh Boyer; John Linn; linuxppc-dev@ozlabs.com; paulus@samba.org; peter= mendham@computing.dundee.ac.uk; Scott Wood; Geoff Levand
Subject: Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrapper= targets

On Thu, Jun 26, 2008 at 1:16 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Forgive my ignorance here, but what specifically does this imply? = ; As
> far as I can tell, generally speaking, some of the board-specific
> information is passed into the boot wrapper, which then stuffs it into=
> the device tree.

Yes, you are correct.  I'll fill out the documentation more here.

>> uImage is for device-tree aware U-Boot versions
>
> And this differs from above because it gets a device tree passed in, > which uboot has already stuffed correctly.

Correct.

>> dtbImage is used for boards that can take an ELF zImage, but still=
> need
>> a dtb provided.
>>
>> simpleImage, not sure here.
>
> So both of these are elfs...  but how do they differ?  Is it= only in how
> the right head.s file gets picked up?

simpleImage is not an elf.  Its a raw position-independent binary
which can be loaded anywhere in RAM.

Some dtbImages are elfs; but there are a flat binaries.  The main
difference is that all simpleImages assume that firmware provides
nothing interesting; but the flat dtbImages have custom code for
extracting a little bit of data out of the boards firmware.

It's all a bit of a confusing mess.  It might be a good idea to rework=
all the image names to stuff not so non-obvious, but I'm not sure the
best way to go about it.  There is a lot of historical stuff in there<= BR> where the various 'zImage.*' targets grew and morphed over time in
ways that are hard to follow.  It may make more sense to change the flat-binary dtbImages to be simpleImages instead with overrides for
specific boards (just like is done for virtex405-*).  ps3 is the other=
major user of dtbImage.  I created the whole dtbImage stuff in the
= first place to eliminate overloaded makefile targets where some
zImage% target were providing a device tree and other zImage% targets
were not.  Splitting dtb-provided from dtb-not-provided targets
clarified the Makefile quite a bit.  dtbImage is not a fantastic name,=
but I needed something different from zImage for images with an
embedded device tree.

Looking at the Makefile, dtbImage and simpleImage targets are
virtually identical.  Perhaps it would be best to merge the targets and deal with all the differences in the wrapper script (with the
default to just use simpleboot.S as the init code).  Thoughts?

Cheers,
g.

--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.


This email and any attachments are intended for the sole u= se of the named recipient(s) and contain(s) confidential information that m= ay be proprietary, privileged or copyrighted under applicable law. If you a= re not the intended recipient, do not read, copy, or forward this email mes= sage or any attachments. Delete this email message and any attachments imme= diately. ------_=_NextPart_001_01C8DA2F.BC0405AC--