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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
