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

Scott Wood
2012-09-17T18:16:19Z

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