| Message ID | 20160818154146.16788-2-afd@ti.com |
|---|---|
| State | Superseded |
| Headers | show |
On 08/19/2016 01:27 AM, Heiko Schocher wrote: > Hello Andrew, > > first thanks for this series! > > Am 18.08.2016 um 17:41 schrieb Andrew F. Davis: >> Create a new Kconfig file to contain SPL boot media loading support >> options as we begin moving these to the Kconfig system and out of header >> files. Initially add new configs for all the existing boot media types, >> giving them the same definition name as before to allow compatibility >> with systems not yet using Kconfig. >> >> Signed-off-by: Andrew F. Davis <afd@ti.com> >> --- >> common/Kconfig | 7 +++++++ >> common/spl/Kconfig | 54 >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 61 insertions(+) >> create mode 100644 common/spl/Kconfig >> >> diff --git a/common/Kconfig b/common/Kconfig >> index 46e7173..f594db5 100644 >> --- a/common/Kconfig >> +++ b/common/Kconfig >> @@ -156,6 +156,13 @@ config SPI_BOOT >> booted via SPI flash. This is not a must, some SoCs need this, >> somes not. >> >> +menu "SPL Media Loading Support" >> + depends on SPL >> + >> +source "common/spl/Kconfig" >> + >> +endmenu >> + >> endmenu >> >> config BOOTDELAY >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig >> new file mode 100644 >> index 0000000..788ca14 >> --- /dev/null >> +++ b/common/spl/Kconfig >> @@ -0,0 +1,54 @@ >> +config SPL_YMODEM_SUPPORT >> + depends on SPL >> + bool "SPL Support for loading next stage from UART" >> + help >> + This option enables SPL to load the next stage bootloader >> + over a UART line using the x/y/z/modem protocol. >> + >> +config SPL_MMC_SUPPORT >> + bool "SPL Support for loading next stage from SD/MMC/eMMC" >> + help >> + This option enables SPL to load the next stage bootloader >> + from an SD/MMC/eMMC device. > > Hmm.. why do you not move, for existing board configs, which use > this symbols, them into their defconfigs? There is the great > script from Masahiro > > u-boot:tools/moveconfig.py > > which should do the most things for you ... Maybe I'm not understanding this script but after getting it to run it doesn't seem to find any uses of the config, I'm not sure this works with SPL configs, as the check looks only at the non-SPL build case as far as I can tell. There is also the more complex cases where _SUPPORT option are only defined in the config.h files when some other option is defined, this conditional dependency will need to be translated in each defconfig file. Thanks, Andrew > also there is a tbot > testcase, with which you can test, that your new patch(es) do not > break an existing board, see for interests: > > http://lists.denx.de/pipermail/u-boot/2016-June/258119.html > > Same comment applies for your patches: > [U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option > [U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig > option > > May you want to try it? If you have problems, feel free to contact me. > > bye, > Heiko > >> + >> +config SPL_SPI_SUPPORT >> + bool "SPL Support for loading next stage from SPI flash" >> + help >> + This option enables SPL to load the next stage bootloader >> + from SPI flash. >> + >> +config SPL_USB_SUPPORT >> + bool "SPL Support for loading next stage from USB" >> + help >> + This option enables SPL to load the next stage bootloader >> + from a USB device. >> + >> +config SPL_SATA_SUPPORT >> + bool "SPL Support for loading next stage from SATA" >> + help >> + This option enables SPL to load the next stage bootloader >> + from a SATA device. >> + >> +config SPL_NOR_SUPPORT >> + bool "SPL Support for loading next stage from NOR flash" >> + help >> + This option enables SPL to load the next stage bootloader >> + from NOR flash. >> + >> +config SPL_NAND_SUPPORT >> + bool "SPL Support for loading next stage from NAND flash" >> + help >> + This option enables SPL to load the next stage bootloader >> + from NAND flash. >> + >> +config SPL_ONENAND_SUPPORT >> + bool "SPL Support for loading next stage from ONENAND" >> + help >> + This option enables SPL to load the next stage bootloader >> + from ONENAND. >> + >> +config SPL_NET_SUPPORT >> + bool "SPL Support for loading next stage from NET" >> + help >> + This option enables SPL to load the next stage bootloader >> + from NET. >> > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 08/19/2016 02:54 PM, Tom Rini wrote: > On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote: >> On 08/19/2016 01:27 AM, Heiko Schocher wrote: >>> Hello Andrew, >>> >>> first thanks for this series! >>> >>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis: >>>> Create a new Kconfig file to contain SPL boot media loading support >>>> options as we begin moving these to the Kconfig system and out of header >>>> files. Initially add new configs for all the existing boot media types, >>>> giving them the same definition name as before to allow compatibility >>>> with systems not yet using Kconfig. >>>> >>>> Signed-off-by: Andrew F. Davis <afd@ti.com> >>>> --- >>>> common/Kconfig | 7 +++++++ >>>> common/spl/Kconfig | 54 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 61 insertions(+) >>>> create mode 100644 common/spl/Kconfig >>>> >>>> diff --git a/common/Kconfig b/common/Kconfig >>>> index 46e7173..f594db5 100644 >>>> --- a/common/Kconfig >>>> +++ b/common/Kconfig >>>> @@ -156,6 +156,13 @@ config SPI_BOOT >>>> booted via SPI flash. This is not a must, some SoCs need this, >>>> somes not. >>>> >>>> +menu "SPL Media Loading Support" >>>> + depends on SPL >>>> + >>>> +source "common/spl/Kconfig" >>>> + >>>> +endmenu >>>> + >>>> endmenu >>>> >>>> config BOOTDELAY >>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig >>>> new file mode 100644 >>>> index 0000000..788ca14 >>>> --- /dev/null >>>> +++ b/common/spl/Kconfig >>>> @@ -0,0 +1,54 @@ >>>> +config SPL_YMODEM_SUPPORT >>>> + depends on SPL >>>> + bool "SPL Support for loading next stage from UART" >>>> + help >>>> + This option enables SPL to load the next stage bootloader >>>> + over a UART line using the x/y/z/modem protocol. >>>> + >>>> +config SPL_MMC_SUPPORT >>>> + bool "SPL Support for loading next stage from SD/MMC/eMMC" >>>> + help >>>> + This option enables SPL to load the next stage bootloader >>>> + from an SD/MMC/eMMC device. >>> >>> Hmm.. why do you not move, for existing board configs, which use >>> this symbols, them into their defconfigs? There is the great >>> script from Masahiro >>> >>> u-boot:tools/moveconfig.py >>> >>> which should do the most things for you ... >> >> Maybe I'm not understanding this script but after getting it to run it >> doesn't seem to find any uses of the config, I'm not sure this works >> with SPL configs, as the check looks only at the non-SPL build case as >> far as I can tell. > > Hmm, Masahiro? Can we support SPL related migrations easily? Thanks! > Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main Makefile, this way it will pick up SPL_ defines that are blocked of by conditionals for CONFIG_SPL_BUILD. Anyway the bigger problem is that some boards conditionally define an option based on what other configs are enabled, we don't have this kind of thing in Kconfig, at least not at the board level as far as I know. (Select could work, but it would end up with a lot of conditionals per board supported) Thanks, Andrew _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 08/21/2016 01:50 PM, Tom Rini wrote: > On Sun, Aug 21, 2016 at 01:35:48PM -0500, Andrew F. Davis wrote: >> On 08/19/2016 02:54 PM, Tom Rini wrote: >>> On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote: >>>> On 08/19/2016 01:27 AM, Heiko Schocher wrote: >>>>> Hello Andrew, >>>>> >>>>> first thanks for this series! >>>>> >>>>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis: >>>>>> Create a new Kconfig file to contain SPL boot media loading support >>>>>> options as we begin moving these to the Kconfig system and out of header >>>>>> files. Initially add new configs for all the existing boot media types, >>>>>> giving them the same definition name as before to allow compatibility >>>>>> with systems not yet using Kconfig. >>>>>> >>>>>> Signed-off-by: Andrew F. Davis <afd@ti.com> >>>>>> --- >>>>>> common/Kconfig | 7 +++++++ >>>>>> common/spl/Kconfig | 54 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> 2 files changed, 61 insertions(+) >>>>>> create mode 100644 common/spl/Kconfig >>>>>> >>>>>> diff --git a/common/Kconfig b/common/Kconfig >>>>>> index 46e7173..f594db5 100644 >>>>>> --- a/common/Kconfig >>>>>> +++ b/common/Kconfig >>>>>> @@ -156,6 +156,13 @@ config SPI_BOOT >>>>>> booted via SPI flash. This is not a must, some SoCs need this, >>>>>> somes not. >>>>>> >>>>>> +menu "SPL Media Loading Support" >>>>>> + depends on SPL >>>>>> + >>>>>> +source "common/spl/Kconfig" >>>>>> + >>>>>> +endmenu >>>>>> + >>>>>> endmenu >>>>>> >>>>>> config BOOTDELAY >>>>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig >>>>>> new file mode 100644 >>>>>> index 0000000..788ca14 >>>>>> --- /dev/null >>>>>> +++ b/common/spl/Kconfig >>>>>> @@ -0,0 +1,54 @@ >>>>>> +config SPL_YMODEM_SUPPORT >>>>>> + depends on SPL >>>>>> + bool "SPL Support for loading next stage from UART" >>>>>> + help >>>>>> + This option enables SPL to load the next stage bootloader >>>>>> + over a UART line using the x/y/z/modem protocol. >>>>>> + >>>>>> +config SPL_MMC_SUPPORT >>>>>> + bool "SPL Support for loading next stage from SD/MMC/eMMC" >>>>>> + help >>>>>> + This option enables SPL to load the next stage bootloader >>>>>> + from an SD/MMC/eMMC device. >>>>> >>>>> Hmm.. why do you not move, for existing board configs, which use >>>>> this symbols, them into their defconfigs? There is the great >>>>> script from Masahiro >>>>> >>>>> u-boot:tools/moveconfig.py >>>>> >>>>> which should do the most things for you ... >>>> >>>> Maybe I'm not understanding this script but after getting it to run it >>>> doesn't seem to find any uses of the config, I'm not sure this works >>>> with SPL configs, as the check looks only at the non-SPL build case as >>>> far as I can tell. >>> >>> Hmm, Masahiro? Can we support SPL related migrations easily? Thanks! >>> >> >> Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main >> Makefile, this way it will pick up SPL_ defines that are blocked of by >> conditionals for CONFIG_SPL_BUILD. >> >> Anyway the bigger problem is that some boards conditionally define an >> option based on what other configs are enabled, we don't have this kind >> of thing in Kconfig, at least not at the board level as far as I know. >> (Select could work, but it would end up with a lot of conditionals per >> board supported) > > I think the problem is that we have some "soft" dependencies here. ie I > think that when I was making am335x_evm.h work for all of the various > possible board and feature combos that were desired I took some > short-cuts to say that A means lets grab B and C. I think it's > perfectly reasonable that in moving to Kconfig we start out by getting > everything into Kconfig and worry about getting all of the select / > depends statements right as the second step. So the defconfigs might > start out a bit fuller and we'll get options removed from them as the > Kconfig logic improves. > If this is okay then I'll post a series with all these cleanups and the config options moved. I believe they don't now make any changes to the build output of any board (at lease according to buildman). The patch for moving SPL_TEXT_BASE will probably have to be dropped as it breaks a couple old powerpc boards for some strange reason (they look like they depend on SPL_TEXT_BASE being unset, and giving it even a default value breaks build for them) and I don't have any time to look into how the build works on those. So I will depend on the ISW_ENTRY_ADDR as a hacky work-around config option for setting an SPL address in Kconfig like we do in AM43xx boards for now. Thanks, Andrew _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 08/21/2016 02:33 PM, Tom Rini wrote: > On Sun, Aug 21, 2016 at 02:12:03PM -0500, Andrew F. Davis wrote: >> On 08/21/2016 01:50 PM, Tom Rini wrote: >>> On Sun, Aug 21, 2016 at 01:35:48PM -0500, Andrew F. Davis wrote: >>>> On 08/19/2016 02:54 PM, Tom Rini wrote: >>>>> On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote: >>>>>> On 08/19/2016 01:27 AM, Heiko Schocher wrote: >>>>>>> Hello Andrew, >>>>>>> >>>>>>> first thanks for this series! >>>>>>> >>>>>>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis: >>>>>>>> Create a new Kconfig file to contain SPL boot media loading support >>>>>>>> options as we begin moving these to the Kconfig system and out of header >>>>>>>> files. Initially add new configs for all the existing boot media types, >>>>>>>> giving them the same definition name as before to allow compatibility >>>>>>>> with systems not yet using Kconfig. >>>>>>>> >>>>>>>> Signed-off-by: Andrew F. Davis <afd@ti.com> >>>>>>>> --- >>>>>>>> common/Kconfig | 7 +++++++ >>>>>>>> common/spl/Kconfig | 54 >>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>>> 2 files changed, 61 insertions(+) >>>>>>>> create mode 100644 common/spl/Kconfig >>>>>>>> >>>>>>>> diff --git a/common/Kconfig b/common/Kconfig >>>>>>>> index 46e7173..f594db5 100644 >>>>>>>> --- a/common/Kconfig >>>>>>>> +++ b/common/Kconfig >>>>>>>> @@ -156,6 +156,13 @@ config SPI_BOOT >>>>>>>> booted via SPI flash. This is not a must, some SoCs need this, >>>>>>>> somes not. >>>>>>>> >>>>>>>> +menu "SPL Media Loading Support" >>>>>>>> + depends on SPL >>>>>>>> + >>>>>>>> +source "common/spl/Kconfig" >>>>>>>> + >>>>>>>> +endmenu >>>>>>>> + >>>>>>>> endmenu >>>>>>>> >>>>>>>> config BOOTDELAY >>>>>>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig >>>>>>>> new file mode 100644 >>>>>>>> index 0000000..788ca14 >>>>>>>> --- /dev/null >>>>>>>> +++ b/common/spl/Kconfig >>>>>>>> @@ -0,0 +1,54 @@ >>>>>>>> +config SPL_YMODEM_SUPPORT >>>>>>>> + depends on SPL >>>>>>>> + bool "SPL Support for loading next stage from UART" >>>>>>>> + help >>>>>>>> + This option enables SPL to load the next stage bootloader >>>>>>>> + over a UART line using the x/y/z/modem protocol. >>>>>>>> + >>>>>>>> +config SPL_MMC_SUPPORT >>>>>>>> + bool "SPL Support for loading next stage from SD/MMC/eMMC" >>>>>>>> + help >>>>>>>> + This option enables SPL to load the next stage bootloader >>>>>>>> + from an SD/MMC/eMMC device. >>>>>>> >>>>>>> Hmm.. why do you not move, for existing board configs, which use >>>>>>> this symbols, them into their defconfigs? There is the great >>>>>>> script from Masahiro >>>>>>> >>>>>>> u-boot:tools/moveconfig.py >>>>>>> >>>>>>> which should do the most things for you ... >>>>>> >>>>>> Maybe I'm not understanding this script but after getting it to run it >>>>>> doesn't seem to find any uses of the config, I'm not sure this works >>>>>> with SPL configs, as the check looks only at the non-SPL build case as >>>>>> far as I can tell. >>>>> >>>>> Hmm, Masahiro? Can we support SPL related migrations easily? Thanks! >>>>> >>>> >>>> Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main >>>> Makefile, this way it will pick up SPL_ defines that are blocked of by >>>> conditionals for CONFIG_SPL_BUILD. >>>> >>>> Anyway the bigger problem is that some boards conditionally define an >>>> option based on what other configs are enabled, we don't have this kind >>>> of thing in Kconfig, at least not at the board level as far as I know. >>>> (Select could work, but it would end up with a lot of conditionals per >>>> board supported) >>> >>> I think the problem is that we have some "soft" dependencies here. ie I >>> think that when I was making am335x_evm.h work for all of the various >>> possible board and feature combos that were desired I took some >>> short-cuts to say that A means lets grab B and C. I think it's >>> perfectly reasonable that in moving to Kconfig we start out by getting >>> everything into Kconfig and worry about getting all of the select / >>> depends statements right as the second step. So the defconfigs might >>> start out a bit fuller and we'll get options removed from them as the >>> Kconfig logic improves. >>> >> >> If this is okay then I'll post a series with all these cleanups and the >> config options moved. I believe they don't now make any changes to the >> build output of any board (at lease according to buildman). > > With sizechecks enabled? You may way to look at the tbot test that > Heiko got setup after the last problematic Kconfig migration: > http://lists.denx.de/pipermail/u-boot/2016-June/258119.html > >> The patch for moving SPL_TEXT_BASE will probably have to be dropped as >> it breaks a couple old powerpc boards for some strange reason (they look >> like they depend on SPL_TEXT_BASE being unset, and giving it even a >> default value breaks build for them) and I don't have any time to look >> into how the build works on those. So I will depend on the >> ISW_ENTRY_ADDR as a hacky work-around config option for setting an SPL >> address in Kconfig like we do in AM43xx boards for now. > > OK. Can you do it as an RFC at the end of the series? I'll try and take > a look at fixing that one up. Thanks! > Sure, this works well for me, should have v2 ready this afternoon. Thanks, Andrew _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
diff --git a/common/Kconfig b/common/Kconfig index 46e7173..f594db5 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -156,6 +156,13 @@ config SPI_BOOT booted via SPI flash. This is not a must, some SoCs need this, somes not. +menu "SPL Media Loading Support" + depends on SPL + +source "common/spl/Kconfig" + +endmenu + endmenu config BOOTDELAY diff --git a/common/spl/Kconfig b/common/spl/Kconfig new file mode 100644 index 0000000..788ca14 --- /dev/null +++ b/common/spl/Kconfig @@ -0,0 +1,54 @@ +config SPL_YMODEM_SUPPORT + depends on SPL + bool "SPL Support for loading next stage from UART" + help + This option enables SPL to load the next stage bootloader + over a UART line using the x/y/z/modem protocol. + +config SPL_MMC_SUPPORT + bool "SPL Support for loading next stage from SD/MMC/eMMC" + help + This option enables SPL to load the next stage bootloader + from an SD/MMC/eMMC device. + +config SPL_SPI_SUPPORT + bool "SPL Support for loading next stage from SPI flash" + help + This option enables SPL to load the next stage bootloader + from SPI flash. + +config SPL_USB_SUPPORT + bool "SPL Support for loading next stage from USB" + help + This option enables SPL to load the next stage bootloader + from a USB device. + +config SPL_SATA_SUPPORT + bool "SPL Support for loading next stage from SATA" + help + This option enables SPL to load the next stage bootloader + from a SATA device. + +config SPL_NOR_SUPPORT + bool "SPL Support for loading next stage from NOR flash" + help + This option enables SPL to load the next stage bootloader + from NOR flash. + +config SPL_NAND_SUPPORT + bool "SPL Support for loading next stage from NAND flash" + help + This option enables SPL to load the next stage bootloader + from NAND flash. + +config SPL_ONENAND_SUPPORT + bool "SPL Support for loading next stage from ONENAND" + help + This option enables SPL to load the next stage bootloader + from ONENAND. + +config SPL_NET_SUPPORT + bool "SPL Support for loading next stage from NET" + help + This option enables SPL to load the next stage bootloader + from NET.
Create a new Kconfig file to contain SPL boot media loading support options as we begin moving these to the Kconfig system and out of header files. Initially add new configs for all the existing boot media types, giving them the same definition name as before to allow compatibility with systems not yet using Kconfig. Signed-off-by: Andrew F. Davis <afd@ti.com> --- common/Kconfig | 7 +++++++ common/spl/Kconfig | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 61 insertions(+) create mode 100644 common/spl/Kconfig -- 2.9.2 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot