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

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

[John Faith]

 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] Unbricking process with separate environment binary?

[Lukasz Majewski]

Hi John,

> nstead 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)? 

If I might ask - where your envs are stored? Do they have a separate
area in NAND or eMMC memory?

If yes, then I suppose that you also have the possibility to write data
to this memory in the production?

If yes (again) then maybe it would be better to only adjust (and
replace) the default environment on board?

For example:

1. You extract envs by using the scripts/get_default_envs.sh - modify
it and then use mkenvimage to produce new env image.

2. You store u-boot (with NAND/eMMC not programmed) to your device.
This u-boot has default environment with instructions for flashing.

3. You flash your final envs prepared in point 1.

p.s. This scheme also works with "redundant" envs.

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de

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

[Lukasz Majewski]

Hi John,

> Hi Lukasz,
> 
> On Tue, Apr 11, 2017 at 12:40 AM, Lukasz Majewski <lukma@denx.de>
> wrote:
> > Hi John,
> >
> >> 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)?
> >
> > If I might ask - where your envs are stored? Do they have a separate
> > area in NAND or eMMC memory?
> >
> > If yes, then I suppose that you also have the possibility to write
> > data to this memory in the production?
> 
> The production redundant environment will have its own area in eMMC.
> The environment could be written to the eMMC from the development host
> after running fastboot or ums in u-boot, but the question is how
> fastboot/ums gets run when starting with a completely blank, freshly
> soldered, non-partitioned board.

I've already used two approaches (with TI SoC):

- Use "factory" SD card (if the slot is available) with tunned u-boot
  (by altering envs)

- Use serial port (you mentioned that you want to talk with the
  board with 'expect') to transfer SPL(MLO)/u-boot 

The above option though is relatively slow, but at least for me it
worked reliably.

- Maybe you can boot from USB stick (I don't know what is your target
  SoC).

> 
> > If yes (again) then maybe it would be better to only adjust (and
> > replace) the default environment on board?
> >
> > For example:
> >
> > 1. You extract envs by using the scripts/get_default_envs.sh -
> > modify it and then use mkenvimage to produce new env image.
> >
> > 2. You store u-boot (with NAND/eMMC not programmed) to your device.
> > This u-boot has default environment with instructions for flashing.
> >
> > 3. You flash your final envs prepared in point 1.
> 
> It seems that flashing the environment binary, or any other piece,
> first requires something running on the target to accept the bits and
> flash. 

Yes, correct.

> Setting CONFIG_BOOTCOMMAND at compile time will do, but
> ideally, I can use the same bootloader binary and decide the bootcmd
> at deploy time.

Personally, I would go for some script file (like boot.scr), which then
would be imported to u-boot envs.
That file can be also easily replaced at factory time, by just changing
the file content.

> 
> Thanks,
> John




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de