From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Mon, 17 Sep 2012 13:16:19 -0500
Subject: [U-Boot] [PATCH v2 10/11] Add u-boot-ubl.bin target to the
 Makefile
In-Reply-To: <505763A5.1030101@ti.com> (from trini@ti.com on Mon Sep 17
	12:53:41 2012)
Message-ID: <1347905779.19543.14@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 12:53:41 PM, Tom Rini wrote:
> On 09/17/12 10:32, Scott Wood wrote:
> > 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.
> 
> Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and
> this is the biggie to me, just U-Boot.
> 
> >> 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.
> 
> Right.  So I'm saying we need to set new expectations for everyone and
> some human helper symlinks to help.  A new top-level out or images or
> something, with symlinks inside.

How about something like "u-boot-final.bin"[1], "u-boot-all.bin",  
"u-boot-image.bin", etc. as the end-user output, with ".bin" changed to  
something else if it's a well known file type?  At least for the boards  
that only require one output file.

-Scott

[1] Though then LDFLAGS_FINAL becomes confusing...