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

Scott Wood
2012-09-17T17:32:51Z

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