[U-Boot] Unbricking process with separate environment binary?

[John Faith <jfaith7@gmail.com>]

 Hello,
I am putting together a factory bring-up/unbrick procedure for a blank
iMX7 board with eMMC and no SD card.  I'd like to use the USB port
with something like imx_usb_loader to drive the whole process and not
have the flashing script also use the serial console to expect-edly
talk to u-boot.

I ran across this nicely-documented example:
http://free-electrons.com/blog/factory-flashing-with-u-boot-and-fastboot-on-freescale-i-mx6/
, which requires a specially-built u-boot with CONFIG_BOOTCOMMAND set
to "fastboot" so the first binary loaded on the target can be used to
flash the rest of the bits.

Instead of having 2 builds of u-boot, one which defaults to fastboot
and one for normal booting, is it possible to have one u-boot binary
and a separate environment piece (especially for bootcmd, but maybe
also for some scripts)?  This would be similar to how
CONFIG_OF_SEPARATE allows for dtb cat'ed with the u-boot binary that
gives the device tree at $fdtcontroladdr.

One implementation might be: put environment variables in their own
dts file, not in the u-boot source tree, but used post-build with a
deploy/unbrick script.  A bit of code added to u-boot, enabled with
CONFIG_ENV_SEPARATE, could setenv variables based on a "uboot-env"
node, like:
/ {
   uboot-env {
       bootcmd = "fastboot";
       other_env_vars = "other values...";
   };
};

The first binary run on the target would be made with "cat
u-boot-nodtb.bin first_boot_env.dtb > u-boot-first-boot.bin", and the
normal boot binary that gets flashed would not have the environment
piece "cp u-boot-nodtb.bin u-boot.bin".

Or, instead of trying to reuse the current dtb mechanism and possibly
changing process_fdt_options() and CONFIG_OF_CONTROL etc. #ifdefs,
would it make more sense to add code to read an appended environment
binary produced with mkenvimage?

Thanks!,
John