Make the following modification in recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch:

Yes, this is more or less the type of patch I envisioned. My only concern is that some users with special needs may be using other storage locations than MMC and UBI, hence the list above. We don't necessarily recommend or support these, but I don't think we should block them either. The only configuration which we should block is having no environment at all, which we (mistakenly) thought the CONFIG_ENV_IS_NOWHERE check would catch.

I don't know if the Mender team wants to make the leap to supporting/expanding the supported u-boot environment storage locations at this time?

Probably not. The bottom part of your modifications is specific to your setup, not applicable to the very generic auto-patcher, and I think this belongs in your own layer.

I think the two locations that I have pointed out are the files/functions of interest for any expansion work to support alternate "CONFIG_ENV_IS_IN" locations other than MMC and UBI.

Strictly speaking we do not really want to support more than these two, unless there is a very good reason. This comes from the fact that with these two we are in theory able to support all boards, and any deviation from these are just adding complexity. However, that doesn't mean we want to actively block other methods, if people want to venture there on their own. And valid use cases do pop up from time to time, such as yours.

My initial proposed solution was:

Make the following modification in recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch:

Make the following modification in recipes-bsp/u-boot/files/uboot_auto_configure.sh:

This solution would keep the checks similar to the way they were previously, while allowing/adding the "CONGIH_ENV_IS_NOWHERE" option as well. I don't know if the Mender team wants to make the leap to supporting/expanding the supported u-boot environment storage locations at this time? 

However, as you have indicated there are many places where the the environment could be saved in u-boot.  

I think the two locations that I have pointed out are the files/functions of interest for any expansion work to support alternate "CONFIG_ENV_IS_IN" locations other than MMC and UBI.

Thanks for explaining. I think I understand now: You are using the same U-Boot binary in several locations, one in which there is no environment.

The CONFIG_ENV_IS_NOWHERE check is a very valuable check though, it is a common point where people make mistakes, and the message is correct in at least 90% of the cases. We could remove it though, if we replaced it with a check which tests that at least one of the other methods are enabled. These are the ones available in U-Boot, using a quick search:

• ENV_IS_IN_DEVICE

• ENV_IS_IN_EEPROM

• ENV_IS_IN_EXT

• ENV_IS_IN_FAT

• ENV_IS_IN_FLASH

• ENV_IS_IN_MMC

• ENV_IS_IN_NAND

• ENV_IS_IN_NVRAM

• ENV_IS_IN_ONENAND

• ENV_IS_IN_REMOTE

• ENV_IS_IN_SATA

• ENV_IS_IN_SPI_FLASH

• ENV_IS_IN_SPI_NOR

• ENV_IS_IN_UBI

Just to provide some more information the u-boot environment location is priority based and searched based on what CONFIG_ENV_IS are defined.

In u-boot/env/env.c see the following function:

The default priority list for the environment variables is:

I would think that it might eventually be desirable for mender mender to support other environment storage locations aside from just MMC and UBI (but this is a different topic).

As you can see CONFIG_ENV_IS_NOWHERE is the lowest priority, so under normal circumstances it would never run with any other CONFIG_ENV_IS_IN defined.

Yes, you are correct it would be possible to create two distinct recipes (this is always an option), but two recipes complicates what could be accomplished without any additional work by development teams if Mender were to allow the simultaneous definition of CONFIG_ENV_IS_IN_MMC and CONFIG_ENV_IS_NOWHERE.

In fact this is what Variscite (I know) and NXP (I think) do in their distributions to solve this issue. Users of the UUU tool currently have both options defined simultaneously, and they don't tend to create two distinct recipes.     

For example the following developer had a similar issue and solved their issue by defining both options: https://community.nxp.com/t5/i-MX-Processors/uuu-flash-u-boot-but-did-not-start-it/td-p/1250965

By defining both options the integration of Mender into existing BSPs that are using the UUU tool would be seamless, creating a much better user experience. 

What do you see as the the downside to defining both options? In my testing the solution I provided would still allow Mender to function as designed.