| Message ID | 20200111193639.19022-10-mrjoel@lixil.net |
|---|---|
| State | New |
| Headers | show |
| Series | [01/10] arm: mvebu: fix SerDes table alignment | expand |
Hi Joel, On Sat, Jan 11 2020, Joel Johnson wrote: > Remove MMC booting assumptions from clearfog_defconfig. Their > presence in starting config files conflicts with default ENV_IS_IN > selection logic based on boot source, since the "select" option > can't distinguish between user-overridden and defconfig selected. As I mentioned in a previous patch review, I believe that SPI boot support should be in a separate defconfig. One more comment below. > Signed-off-by: Joel Johnson <mrjoel at lixil.net> > --- > > > The real objective is to remove CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC as > well but I couldn't identify an available mechanism to do so. > Requiring it as enabled in the defconfig results in additional items > being unneccessarily included if switching boot device after starting > with the defconfig, as well as ENV_IS_IN_MMC being undesirably > residually defined. > > --- > arch/arm/mach-mvebu/Kconfig | 1 + > board/solidrun/clearfog/Kconfig | 5 +++++ > configs/clearfog_defconfig | 3 --- > 3 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig > index b3239b2b01..3f9aa4b26e 100644 > --- a/arch/arm/mach-mvebu/Kconfig > +++ b/arch/arm/mach-mvebu/Kconfig > @@ -248,6 +248,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC > select SPL_DM_GPIO > select SPL_DM_MMC > select SPL_LIBDISK_SUPPORT > + select SPL_MMC_SUPPORT > > config MVEBU_SPL_BOOT_DEVICE_SATA > bool "SATA" > diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig > index 253b925ba1..bd51df8750 100644 > --- a/board/solidrun/clearfog/Kconfig > +++ b/board/solidrun/clearfog/Kconfig > @@ -52,6 +52,11 @@ config ENV_SECT_SIZE > # Use optimistic 64 KiB erase block, will vary between actual media > default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC > > +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > + hex "Address on the MMC to load U-Boot from" > + default 0x141 > + depends on MVEBU_SPL_BOOT_DEVICE_MMC You might want to take a look at the series linked below, which conflicts with this patch: https://patchwork.ozlabs.org/project/uboot/list/?series=121894 baruch > + > config SYS_SPI_U_BOOT_OFFS > hex "address of u-boot payload in SPI flash" > default 0x20000 > diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig > index 0b55e63079..eab24c32f0 100644 > --- a/configs/clearfog_defconfig > +++ b/configs/clearfog_defconfig > @@ -9,7 +9,6 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y > CONFIG_SYS_MALLOC_F_LEN=0x2000 > CONFIG_TARGET_CLEARFOG=y > CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y > -CONFIG_SPL_MMC_SUPPORT=y > CONFIG_SPL_SERIAL_SUPPORT=y > CONFIG_NR_DRAM_BANKS=2 > CONFIG_SPL=y > @@ -24,7 +23,6 @@ CONFIG_USE_PREBOOT=y > CONFIG_SYS_CONSOLE_INFO_QUIET=y > # CONFIG_DISPLAY_BOARDINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x141 > CONFIG_SPL_I2C_SUPPORT=y > # CONFIG_CMD_FLASH is not set > CONFIG_CMD_GPIO=y > @@ -39,7 +37,6 @@ CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > # CONFIG_SPL_PARTITION_UUIDS is not set > CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" > -CONFIG_ENV_IS_IN_MMC=y > CONFIG_NET_RANDOM_ETHADDR=y > CONFIG_SPL_OF_TRANSLATE=y > CONFIG_AHCI_MVEBU=y -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
On 2020-01-12 03:49, Baruch Siach wrote: > Hi Joel, > > On Sat, Jan 11 2020, Joel Johnson wrote: > >> Remove MMC booting assumptions from clearfog_defconfig. Their >> presence in starting config files conflicts with default ENV_IS_IN >> selection logic based on boot source, since the "select" option >> can't distinguish between user-overridden and defconfig selected. > > As I mentioned in a previous patch review, I believe that SPI boot > support should be in a separate defconfig. As I responded in a previous patch, I like to specifically avoid that, to enable (not by default) mixed media boot and storage locations. The current set I have makes the mixed mode almost achievable, except needing to explicit set CONFIG_ENV_IS_IN_MMC=n when enabling SPI boot, otherwise it boots from SPI and tries to load env from MMC. That's a use case I'm after, but isn't what should be a reasonable default given the surprise factor if not intended. > One more comment below. > >> Signed-off-by: Joel Johnson <mrjoel at lixil.net> >> --- >> >> >> The real objective is to remove CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC as >> well but I couldn't identify an available mechanism to do so. >> Requiring it as enabled in the defconfig results in additional items >> being unneccessarily included if switching boot device after starting >> with the defconfig, as well as ENV_IS_IN_MMC being undesirably >> residually defined. >> >> --- >> arch/arm/mach-mvebu/Kconfig | 1 + >> board/solidrun/clearfog/Kconfig | 5 +++++ >> configs/clearfog_defconfig | 3 --- >> 3 files changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig >> index b3239b2b01..3f9aa4b26e 100644 >> --- a/arch/arm/mach-mvebu/Kconfig >> +++ b/arch/arm/mach-mvebu/Kconfig >> @@ -248,6 +248,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC >> select SPL_DM_GPIO >> select SPL_DM_MMC >> select SPL_LIBDISK_SUPPORT >> + select SPL_MMC_SUPPORT >> >> config MVEBU_SPL_BOOT_DEVICE_SATA >> bool "SATA" >> diff --git a/board/solidrun/clearfog/Kconfig >> b/board/solidrun/clearfog/Kconfig >> index 253b925ba1..bd51df8750 100644 >> --- a/board/solidrun/clearfog/Kconfig >> +++ b/board/solidrun/clearfog/Kconfig >> @@ -52,6 +52,11 @@ config ENV_SECT_SIZE >> # Use optimistic 64 KiB erase block, will vary between actual media >> default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC >> >> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR >> + hex "Address on the MMC to load U-Boot from" >> + default 0x141 >> + depends on MVEBU_SPL_BOOT_DEVICE_MMC > > You might want to take a look at the series linked below, which > conflicts with this patch: > > https://patchwork.ozlabs.org/project/uboot/list/?series=121894 Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD offset business, including relative vs. absolute device offset. I only have non-eMMC units so can't test it, but I'm all for dropping the SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch, in which leaving the defconfig entry does no harm. Any indication of when that patch will be included? It seems to have been stagnant for a while. Joel
Hi Joel, On Sun, Jan 12 2020, Joel Johnson wrote: > On 2020-01-12 03:49, Baruch Siach wrote: >> On Sat, Jan 11 2020, Joel Johnson wrote: >>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR >>> + hex "Address on the MMC to load U-Boot from" >>> + default 0x141 >>> + depends on MVEBU_SPL_BOOT_DEVICE_MMC >> >> You might want to take a look at the series linked below, which >> conflicts with this patch: >> >> https://patchwork.ozlabs.org/project/uboot/list/?series=121894 > > Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD > offset business, including relative vs. absolute device offset. I only have > non-eMMC units so can't test it, but I'm all for dropping the > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch, > in which leaving the defconfig entry does no harm. Any indication of when that > patch will be included? It seems to have been stagnant for a while. Indeed. I'm waiting patiently. baruch
Hi Baruch, On 12.01.20 17:34, Baruch Siach wrote: > Hi Joel, > > On Sun, Jan 12 2020, Joel Johnson wrote: >> On 2020-01-12 03:49, Baruch Siach wrote: >>> On Sat, Jan 11 2020, Joel Johnson wrote: >>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR >>>> + hex "Address on the MMC to load U-Boot from" >>>> + default 0x141 >>>> + depends on MVEBU_SPL_BOOT_DEVICE_MMC >>> >>> You might want to take a look at the series linked below, which >>> conflicts with this patch: >>> >>> https://patchwork.ozlabs.org/project/uboot/list/?series=121894 >> >> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD >> offset business, including relative vs. absolute device offset. I only have >> non-eMMC units so can't test it, but I'm all for dropping the >> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch, >> in which leaving the defconfig entry does no harm. Any indication of when that >> patch will be included? It seems to have been stagnant for a while. > > Indeed. I'm waiting patiently. I have missed addressing this patch series for quite some time, sorry. Could you please rebase this patchset on top of current mainline as it doesn't apply any more. And please do a compile run for all targets as well (Travis). I'll try to push it upstream in this merge window. Thanks, Stefan
Hi Stefan, On Mon, Jan 13 2020, Stefan Roese wrote: > On 12.01.20 17:34, Baruch Siach wrote: >> On Sun, Jan 12 2020, Joel Johnson wrote: >>> On 2020-01-12 03:49, Baruch Siach wrote: >>>> On Sat, Jan 11 2020, Joel Johnson wrote: >>>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR >>>>> + hex "Address on the MMC to load U-Boot from" >>>>> + default 0x141 >>>>> + depends on MVEBU_SPL_BOOT_DEVICE_MMC >>>> >>>> You might want to take a look at the series linked below, which >>>> conflicts with this patch: >>>> >>>> https://patchwork.ozlabs.org/project/uboot/list/?series=121894 >>> >>> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD >>> offset business, including relative vs. absolute device offset. I only have >>> non-eMMC units so can't test it, but I'm all for dropping the >>> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch, >>> in which leaving the defconfig entry does no harm. Any indication of when that >>> patch will be included? It seems to have been stagnant for a while. >> >> Indeed. I'm waiting patiently. > > I have missed addressing this patch series for quite some time, sorry. > Could you please rebase this patchset on top of current mainline as it > doesn't apply any more. And please do a compile run for all targets as > well (Travis). I'll try to push it upstream in this merge window. Thanks. I'll work on that tomorrow. While you are at it can you also push this fix: https://patchwork.ozlabs.org/patch/1205597/ Clearfog can't boot v2020.01 clearfog_defconfig without it :-(. Thanks, baruch
Hi Baruch, On 13.01.20 12:40, Baruch Siach wrote: > Hi Stefan, > > On Mon, Jan 13 2020, Stefan Roese wrote: >> On 12.01.20 17:34, Baruch Siach wrote: >>> On Sun, Jan 12 2020, Joel Johnson wrote: >>>> On 2020-01-12 03:49, Baruch Siach wrote: >>>>> On Sat, Jan 11 2020, Joel Johnson wrote: >>>>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR >>>>>> + hex "Address on the MMC to load U-Boot from" >>>>>> + default 0x141 >>>>>> + depends on MVEBU_SPL_BOOT_DEVICE_MMC >>>>> >>>>> You might want to take a look at the series linked below, which >>>>> conflicts with this patch: >>>>> >>>>> https://patchwork.ozlabs.org/project/uboot/list/?series=121894 >>>> >>>> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD >>>> offset business, including relative vs. absolute device offset. I only have >>>> non-eMMC units so can't test it, but I'm all for dropping the >>>> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch, >>>> in which leaving the defconfig entry does no harm. Any indication of when that >>>> patch will be included? It seems to have been stagnant for a while. >>> >>> Indeed. I'm waiting patiently. >> >> I have missed addressing this patch series for quite some time, sorry. >> Could you please rebase this patchset on top of current mainline as it >> doesn't apply any more. And please do a compile run for all targets as >> well (Travis). I'll try to push it upstream in this merge window. > > Thanks. I'll work on that tomorrow. Thanks. > While you are at it can you also push this fix: > > https://patchwork.ozlabs.org/patch/1205597/ > > Clearfog can't boot v2020.01 clearfog_defconfig without it :-(. Its on my list. I'll pull it with the other patch with my next pull request. Thanks, Stefan
Hi Stefan, On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote: > On 12.01.20 17:34, Baruch Siach wrote: > > On Sun, Jan 12 2020, Joel Johnson wrote: > > > On 2020-01-12 03:49, Baruch Siach wrote: > > > > On Sat, Jan 11 2020, Joel Johnson wrote: > > > > > +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR > > > > > + hex "Address on the MMC to load U-Boot from" > > > > > + default 0x141 > > > > > + depends on MVEBU_SPL_BOOT_DEVICE_MMC > > > > > > > > You might want to take a look at the series linked below, which > > > > conflicts with this patch: > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=121894 > > > > > > Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD > > > offset business, including relative vs. absolute device offset. I only have > > > non-eMMC units so can't test it, but I'm all for dropping the > > > SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch, > > > in which leaving the defconfig entry does no harm. Any indication of when that > > > patch will be included? It seems to have been stagnant for a while. > > > > Indeed. I'm waiting patiently. > > I have missed addressing this patch series for quite some time, sorry. > Could you please rebase this patchset on top of current mainline as it > doesn't apply any more. The original patch series applies cleanly on top of current master as of commit 88366b96ee0d86 ("travis: Switch to QEMU v4.2.0 globally"), and runs successfully. It only trivially conflicts with the clearfog_defconfig SPL_DM_GPIO fix (http://patchwork.ozlabs.org/patch/1205597/). Would you like me to rebase on to of that? > And please do a compile run for all targets as well (Travis). I'll try to > push it upstream in this merge window. buildman for arm and aarch64 is currently running. baruch
Hi Baruch, On 14.01.20 13:55, Baruch Siach wrote: > Hi Stefan, > > On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote: >> On 12.01.20 17:34, Baruch Siach wrote: >>> On Sun, Jan 12 2020, Joel Johnson wrote: >>>> On 2020-01-12 03:49, Baruch Siach wrote: >>>>> On Sat, Jan 11 2020, Joel Johnson wrote: >>>>>> +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR >>>>>> + hex "Address on the MMC to load U-Boot from" >>>>>> + default 0x141 >>>>>> + depends on MVEBU_SPL_BOOT_DEVICE_MMC >>>>> >>>>> You might want to take a look at the series linked below, which >>>>> conflicts with this patch: >>>>> >>>>> https://patchwork.ozlabs.org/project/uboot/list/?series=121894 >>>> >>>> Indeed, the dynamic runtime approach seems much nicer for handling the MMCSD >>>> offset business, including relative vs. absolute device offset. I only have >>>> non-eMMC units so can't test it, but I'm all for dropping the >>>> SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR portion of this patch in favor of that patch, >>>> in which leaving the defconfig entry does no harm. Any indication of when that >>>> patch will be included? It seems to have been stagnant for a while. >>> >>> Indeed. I'm waiting patiently. >> >> I have missed addressing this patch series for quite some time, sorry. >> Could you please rebase this patchset on top of current mainline as it >> doesn't apply any more. > > The original patch series applies cleanly on top of current master as of > commit 88366b96ee0d86 ("travis: Switch to QEMU v4.2.0 globally"), and runs > successfully. It only trivially conflicts with the clearfog_defconfig > SPL_DM_GPIO fix (http://patchwork.ozlabs.org/patch/1205597/). Would you like > me to rebase on to of that? Yes, please. >> And please do a compile run for all targets as well (Travis). I'll try to >> push it upstream in this merge window. > > buildman for arm and aarch64 is currently running. All platforms please. I suggest to use Travis for this. Be prepared that this takes a few hours though. Thanks, Stefan
Hi Stefan, On Tue, Jan 14, 2020 at 02:01:20PM +0100, Stefan Roese wrote: > On 14.01.20 13:55, Baruch Siach wrote: > > On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote: > > > And please do a compile run for all targets as well (Travis). I'll try > > > to push it upstream in this merge window. > > > > buildman for arm and aarch64 is currently running. > > All platforms please. I suggest to use Travis for this. Be prepared that > this takes a few hours though. Do you refer to travis-ci.org integration with github.com? Something else? Travis CI wants access to github repos of all organizations my account is authorized to access. I can't do that. baruch
Hi Baruch, On 14.01.20 15:53, Baruch Siach wrote: > Hi Stefan, > > On Tue, Jan 14, 2020 at 02:01:20PM +0100, Stefan Roese wrote: >> On 14.01.20 13:55, Baruch Siach wrote: >>> On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote: >>>> And please do a compile run for all targets as well (Travis). I'll try >>>> to push it upstream in this merge window. >>> >>> buildman for arm and aarch64 is currently running. >> >> All platforms please. I suggest to use Travis for this. Be prepared that >> this takes a few hours though. > > Do you refer to travis-ci.org integration with github.com? Something else? Yes, that's how I use it. > Travis CI wants access to github repos of all organizations my account is > authorized to access. I can't do that. Hmmm, I don't remember this Travis configuration. I do have a "private" github account with a U-Boot repository, where I push the commits to and Travis automatically starts the build after the push. Perhaps its possible for you to create a new (private?) github account for such a task? Otherwise its of course also ok, if you build all platforms (not only ARM please if your changes touch global files) via buildman locally. Thanks, Stefan
Hi Stefan, On Tue, Jan 14 2020, Stefan Roese wrote: > On 14.01.20 15:53, Baruch Siach wrote: >> On Tue, Jan 14, 2020 at 02:01:20PM +0100, Stefan Roese wrote: >>> On 14.01.20 13:55, Baruch Siach wrote: >>>> On Mon, Jan 13, 2020 at 07:48:34AM +0100, Stefan Roese wrote: >>>>> And please do a compile run for all targets as well (Travis). I'll try >>>>> to push it upstream in this merge window. >>>> >>>> buildman for arm and aarch64 is currently running. >>> >>> All platforms please. I suggest to use Travis for this. Be prepared that >>> this takes a few hours though. >> >> Do you refer to travis-ci.org integration with github.com? Something else? > > Yes, that's how I use it. > >> Travis CI wants access to github repos of all organizations my account is >> authorized to access. I can't do that. > > Hmmm, I don't remember this Travis configuration. I do have a "private" > github account with a U-Boot repository, where I push the commits to > and Travis automatically starts the build after the push. Perhaps its > possible for you to create a new (private?) github account for such a > task? OK. I created a new github account for that. Travis CI build passed: https://travis-ci.com/baruchsiach-travis/u-boot/builds/144357746 I'll post the updated series shortly. baruch
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index b3239b2b01..3f9aa4b26e 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -248,6 +248,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC select SPL_DM_GPIO select SPL_DM_MMC select SPL_LIBDISK_SUPPORT + select SPL_MMC_SUPPORT config MVEBU_SPL_BOOT_DEVICE_SATA bool "SATA" diff --git a/board/solidrun/clearfog/Kconfig b/board/solidrun/clearfog/Kconfig index 253b925ba1..bd51df8750 100644 --- a/board/solidrun/clearfog/Kconfig +++ b/board/solidrun/clearfog/Kconfig @@ -52,6 +52,11 @@ config ENV_SECT_SIZE # Use optimistic 64 KiB erase block, will vary between actual media default 0x10000 if MVEBU_SPL_BOOT_DEVICE_MMC +config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR + hex "Address on the MMC to load U-Boot from" + default 0x141 + depends on MVEBU_SPL_BOOT_DEVICE_MMC + config SYS_SPI_U_BOOT_OFFS hex "address of u-boot payload in SPI flash" default 0x20000 diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 0b55e63079..eab24c32f0 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -9,7 +9,6 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC=y -CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SPL=y @@ -24,7 +23,6 @@ CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x141 CONFIG_SPL_I2C_SUPPORT=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y @@ -39,7 +37,6 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y # CONFIG_SPL_PARTITION_UUIDS is not set CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" -CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_AHCI_MVEBU=y
Remove MMC booting assumptions from clearfog_defconfig. Their presence in starting config files conflicts with default ENV_IS_IN selection logic based on boot source, since the "select" option can't distinguish between user-overridden and defconfig selected. Signed-off-by: Joel Johnson <mrjoel at lixil.net> --- The real objective is to remove CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC as well but I couldn't identify an available mechanism to do so. Requiring it as enabled in the defconfig results in additional items being unneccessarily included if switching boot device after starting with the defconfig, as well as ENV_IS_IN_MMC being undesirably residually defined. --- arch/arm/mach-mvebu/Kconfig | 1 + board/solidrun/clearfog/Kconfig | 5 +++++ configs/clearfog_defconfig | 3 --- 3 files changed, 6 insertions(+), 3 deletions(-)