<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=2>simpleImage should also create an .elf (for xmd or systemAce loading)<BR>
If dtbImage and simpleImage could be merged, I'd be all for it...<BR>
<BR>
At some point of course, I need to figure merge the Device Tree in BRAM code that I've been using, which would be a simpleImage which wouldn't need a device tree.&nbsp; However, I don't see this happening before August.<BR>
<BR>
Steve<BR>
<BR>
-----Original Message-----<BR>
From: glikely@secretlab.ca on behalf of Grant Likely<BR>
Sent: Fri 6/27/2008 9:22 PM<BR>
To: Stephen Neuendorffer<BR>
Cc: Josh Boyer; John Linn; linuxppc-dev@ozlabs.com; paulus@samba.org; petermendham@computing.dundee.ac.uk; Scott Wood; Geoff Levand<BR>
Subject: Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets<BR>
<BR>
On Thu, Jun 26, 2008 at 1:16 PM, Stephen Neuendorffer<BR>
&lt;stephen.neuendorffer@xilinx.com&gt; wrote:<BR>
&gt; Forgive my ignorance here, but what specifically does this imply?&nbsp; As<BR>
&gt; far as I can tell, generally speaking, some of the board-specific<BR>
&gt; information is passed into the boot wrapper, which then stuffs it into<BR>
&gt; the device tree.<BR>
<BR>
Yes, you are correct.&nbsp; I'll fill out the documentation more here.<BR>
<BR>
&gt;&gt; uImage is for device-tree aware U-Boot versions<BR>
&gt;<BR>
&gt; And this differs from above because it gets a device tree passed in,<BR>
&gt; which uboot has already stuffed correctly.<BR>
<BR>
Correct.<BR>
<BR>
&gt;&gt; dtbImage is used for boards that can take an ELF zImage, but still<BR>
&gt; need<BR>
&gt;&gt; a dtb provided.<BR>
&gt;&gt;<BR>
&gt;&gt; simpleImage, not sure here.<BR>
&gt;<BR>
&gt; So both of these are elfs...&nbsp; but how do they differ?&nbsp; Is it only in how<BR>
&gt; the right head.s file gets picked up?<BR>
<BR>
simpleImage is not an elf.&nbsp; Its a raw position-independent binary<BR>
which can be loaded anywhere in RAM.<BR>
<BR>
Some dtbImages are elfs; but there are a flat binaries.&nbsp; The main<BR>
difference is that all simpleImages assume that firmware provides<BR>
nothing interesting; but the flat dtbImages have custom code for<BR>
extracting a little bit of data out of the boards firmware.<BR>
<BR>
It's all a bit of a confusing mess.&nbsp; It might be a good idea to rework<BR>
all the image names to stuff not so non-obvious, but I'm not sure the<BR>
best way to go about it.&nbsp; There is a lot of historical stuff in there<BR>
where the various 'zImage.*' targets grew and morphed over time in<BR>
ways that are hard to follow.&nbsp; It may make more sense to change the<BR>
flat-binary dtbImages to be simpleImages instead with overrides for<BR>
specific boards (just like is done for virtex405-*).&nbsp; ps3 is the other<BR>
major user of dtbImage.&nbsp; I created the whole dtbImage stuff in the<BR>
first place to eliminate overloaded makefile targets where some<BR>
zImage% target were providing a device tree and other zImage% targets<BR>
were not.&nbsp; Splitting dtb-provided from dtb-not-provided targets<BR>
clarified the Makefile quite a bit.&nbsp; dtbImage is not a fantastic name,<BR>
but I needed something different from zImage for images with an<BR>
embedded device tree.<BR>
<BR>
Looking at the Makefile, dtbImage and simpleImage targets are<BR>
virtually identical.&nbsp; Perhaps it would be best to merge the targets<BR>
and deal with all the differences in the wrapper script (with the<BR>
default to just use simpleboot.S as the init code).&nbsp; Thoughts?<BR>
<BR>
Cheers,<BR>
g.<BR>
<BR>
--<BR>
Grant Likely, B.Sc., P.Eng.<BR>
Secret Lab Technologies Ltd.<BR>
<BR>
<BR>
</FONT>
</P>

<br clear=all> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
</BODY>
</HTML>