[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 at 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