[U-Boot] [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile

[Marek Vasut <marex@denx.de>]

Dear Scott Wood,

> On 09/21/2012 12:43:48 AM, Wolfgang Denk wrote:
> > Dear Tom,
> > 
> > In message
> > <5FBF8E85CA34454794F0F7ECBA79798F379F6FD992@HQMAIL04.nvidia.com> you
> > 
> > wrote:
> > > If you flash u-boot-dtb-tegra.bin, you'll get a fully functioning
> > > U-Boot. There's an intermediate file (u-boot-dtb.bin) that I assume
> > > is u-boot.bin+dtb - I'm not sure why it's left around - Allen could
> > > comment here.
> > 
> > I _dislike_ the idea of having image names which include architecture
> > or even board parts.  I would really like to have generic names, that
> > can be used in a consistent way across platforms, architectures and
> > boards.
> > 
> > > So in my eyes, all you really need is u-boot-dtb-tegra.bin - an
> > > unwieldy name, to be sure, but it seems to satisfy your request for
> > 
> > a
> > 
> > > Soc identifier in the name. I voted for just having u-boot.bin be
> > 
> > the
> > 
> > Please reconsider.  I definitely do NOT want to have SoC names or that
> > in any such images!
> > 
> > 
> > IIRC, the original idea was to provide image names (common for all
> > architectures, SoCs, boards) that only depend on where you install
> > U-Boot to.  in this way, we would have:
> > 
> > - u-boot.bin	for the generic case (say, for installation into NOR
> > 
> >                 flash, no SPL or similar needed).
> > 
> > - u-boot-nand.bin
> > 
> > 		for installation in NAND (with all needed headers,
> > 		padding etc. included)
> > 
> > - u-boot-onenand.bin
> > 
> > 		for installation in OneNAND
> > 
> > - u-boot.sd	for installation on a SDCard
> > 
> > 		[actually we have an inconsistency in names here; this
> > 		should have been "u-boot-sd.bin" or maybe even better
> > 		"u-boot-sdcard.bin"]
> > 
> > etc.
> > 
> > It is very important to me that we do NOT include any architectures,
> > SoCs, or board specifc parts in the names because this will cause
> > major PITA for all kind of automatic test suites etc.
> 
> The awkwardness with naming based on nand/onenand/sd is that we no
> longer have build infrastructure that is specific to the type of boot
> device -- and IIRC with some of the newer SPL targets, the same image
> works on multiple types of boot device.
> 
> Having u-boot.bin be the final output regardless of internal
> implementation details such as spl would avoid that problem, and be
> even nicer to automated testing than the nand/onenand/sd names.

On the other hand, I use u-boot.bin and expect it to always be the raw linked 
binary of u-boot .

> -Scott

Best regards,
Marek Vasut