[U-Boot] [PATCH v3 01/11] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option

[Tom Rini]

On Mon, Aug 29, 2016 at 01:30:01PM -0500, Andrew F. Davis wrote:
> On 08/26/2016 04:27 PM, Tom Rini wrote:
> > On Thu, Aug 25, 2016 at 04:45:31PM -0500, Andrew F. Davis wrote:
> > 
> >> Currently U-Boot proper has Kconfig options that enable the generation
> >> of U-Boot binaries that are capable of being booted from the selected
> >> boot media type. The same set of generation targets for SPL are assumed
> >> with various methods and config header hackery. On some platforms the
> >> options for SPL, such as load address, are dependent on boot type
> >> and cannot depend on boot image type selected for U-Boot proper.
> >> Add a Kconfig menu to select SPL boot image types, and populate it
> >> with the same media types as are already available for U-Boot proper.
> >>
> >> NOTE: As only a couple TI devices use make correct use of these options
> >> we limit the menu to these devices for now. The only other users
> >> of these seem to be some PPC boards that incorrectly use these as both
> >> SPL and TPL build options.
> >>
> >> Signed-off-by: Andrew F. Davis <afd at ti.com>
> > 
> > OK, sorry, I feel we've gone off on a wild goose chase here.  Of all the
> > options that get added here, only two appear to be used at all and it's
> > by the "old" Freescale SPL and not the current iteration of SPL.  Those
> > conversions should end up in board/freescale/Kconfig I think.
> > 
> 
> These are used in patch 3 of this series, but I can drop that use by
> simply always building SPLs for all supported media types. Most of our
> platforms only need two image types anyway (QSPI and MLO for everything
> else).

Yes, this sounds best, thanks!

> We could do the same for the existing {media}_BOOT, they are rarely used
> correctly as described by the Kconfig help (formatting the U-Boot binary
> output image for a specific media type), often mistaken for
> {media}_SUPPORT options.
> 
> Masahiro would probably be happy to help remove these options altogether
> (taking this patch a step further:
> https://patchwork.ozlabs.org/patch/661706/).

Yes, I think we're all in agreement here then, thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160829/c539e87a/attachment.sig>