| Message ID | 20160825214541.22896-2-afd@ti.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
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@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.
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@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). 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/). Andrew
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@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.
diff --git a/common/Kconfig b/common/Kconfig index 46e7173..a05d2ab 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -156,6 +156,75 @@ config SPI_BOOT booted via SPI flash. This is not a must, some SoCs need this, somes not. +menu "SPL Boot media" + depends on SPL && (AM33XX || AM43XX) + +config SPL_NOR_BOOT + bool "Support for booting SPL from NOR flash" + default n + help + Enabling this will make an SPL binary that is capable of being + booted via NOR flash. This is not a must, some SoCs need this, + some do not. + +config SPL_NAND_BOOT + bool "Support for booting SPL from NAND flash" + default n + help + Enabling this will make an SPL binary that is capable of being + booted via NAND flash. This is not a must, some SoCs need this, + some do not. + +config SPL_ONENAND_BOOT + bool "Support for booting SPL from ONENAND" + default n + help + Enabling this will make an SPL binary that is capable of being + booted via ONENAND. This is not a must, some SoCs need this, + some do not. + +config SPL_QSPI_BOOT + bool "Support for booting SPL from QSPI flash" + default n + help + Enabling this will make an SPL binary that is capable of being + booted via QSPI flash. This is not a must, some SoCs need this, + some do not. + +config SPL_SATA_BOOT + bool "Support for booting SPL from SATA" + default n + help + Enabling this will make an SPL binary that is capable of being + booted via SATA. This is not a must, some SoCs need this, + some do not. + +config SPL_SD_BOOT + bool "Support for booting SPL from SD/MMC/eMMC" + default n + help + Enabling this will make an SPL binary that is capable of being + booted via SD/MMC/eMMC. This is not a must, some SoCs need this, + some do not. + +config SPL_SPI_BOOT + bool "Support for booting SPL from SPI flash" + default n + help + Enabling this will make an SPL binary that is capable of being + booted via SPI flash. This is not a must, some SoCs need this, + some do not. + +config SPL_UART_BOOT + bool "Support for booting SPL from UART" + default n + help + Enabling this will make an SPL binary that is capable of being + booted via UART. This is not a must, some SoCs need this, + some do not. + +endmenu + endmenu config BOOTDELAY
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@ti.com> --- common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+)