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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
