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