From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Mon, 17 Sep 2012 12:32:51 -0500
Subject: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the
 Makefile
In-Reply-To: <50575528.7000606@ti.com> (from trini@ti.com on Mon Sep 17
	11:51:52 2012)
Message-ID: <1347903171.19543.13@snotra>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 09/17/2012 11:51:52 AM, Tom Rini wrote:
> On 09/17/12 09:27, Scott Wood wrote:
> > On 09/17/2012 04:24:34 AM, Jos? Miguel Gon?alves wrote:
> [snip]
> >> If no one else has anything against, I will change the name of the  
> new
> >> target to u-boot-pad.bin
> >
> > What exactly is u-boot-pad.bin supposed to be?  I hope that's not  
> being
> > proposed as the final output file the user sees.
> >
> > With old nand_spl we had u-boot-nand.bin for the final concatenated
> > binary, but that's not appropriate for a generic spl.  I think it  
> would
> > be better for the user to see "u-boot.bin" as the actual image to  
> put on
> > the boot device, regardless of implementation details like spl, if
> > there's no requirement of a specific file format.  The second stage
> > could become "u-boot-main.bin" or similar on builds where spl is  
> used.
> 
> We need some name that means "U-Boot SPL with U-Boot tacked on at the
> end".  This can optionally be padded to a defined size to make writing
> to hardware easier.  We also have the problem that "u-boot.bin"  
> already
> means something so it needs to be clear.

u-boot.bin has traditionally (except for nand_spl and derivatives)  
meant the final image ready to put into flash, after any  
platform-specific layout issues are taken care of (e.g. on mpc83xx it  
will have a reset control word embedded, on mpc85xx it will be padded  
to 512K with a reset vector at the end, etc.).  That we did the  
tweaking in the linker script rather than after linking seems like an  
inconsequential implementation detail.

> I further fear that even if we
> made an "out" directory if we put u-boot.bin in there and it's not the
> same as the objcopy -O binary u-boot u-boot.bin as before we've  
> violated
> the rule of least surprise and the end user problems from people that
> read "the" document (that happened to be out of date) will be our  
> problem.

In this case I think you can't meet one user's expectations without  
violating another's.  I think it's more important to make it clear to  
the user what file they're supposed to put into flash.  Users of  
platforms that are currently supported by nand_spl would probably like  
to continue seeing u-boot-nand.bin -- it's a tradeoff of historical  
stability versus current consistency.

> In short, at least a few people have said something along the lines of
> "We need generic output nameo $mediums and targets" but there's two  
> hard
> problems, one of which is that every SoC _needs_ things tweaked just  
> so
> (no header? no boot!), sometimes wants things tweaked further (pad the
> final image out to be easier to write to $medium) and sometimes needs
> multiple files (the whole of 'SPL' will be read so it must fit into
> $SMALL_MEMORY).  The other is naming.

A simple concatenation of a padded SPL plus the main U-Boot was good  
enough for all the nand_spl boards AFAIK, so it's not quite every SoC  
that needs something special here.  For those that do require a special  
format (or multiple files) with a file extension that is familiar to  
people working with that platform, using that extension makes sense.   
"pad" does not, and a proliferation of SoC-specific suffixes isn't much  
better.

-Scott