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

[Tom Rini]

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.

>> 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.

I think we're running into PowerPC vs ARM "fun".  We've got 7 or so
different "whack the image for this SoC for this medium" type things
already.

-- 
Tom