[U-Boot] Saving environment variables in MMC

[Nitin Mahajan <nitinm76@yahoo.com>]

Hello,

--- On Thu, 1/4/10, Detlev Zundel <dzu@denx.de> wrote:

> From: Detlev Zundel <dzu@denx.de>
> Subject: Re: [U-Boot] Saving environment variables in MMC
> To: nitinm76 at yahoo.com
> Cc: "U-Boot user list" <u-boot@lists.denx.de>
> Date: Thursday, 1 April, 2010, 5:35 PM
> Hi Nitin,
> 
> >> It is rather common to write to the U-Boot
> environment in projects
> >> for example to switch to a new set of kernel+file
> system after an
> >> update from within linux for the next boot.
> >> 
> > My use case is exactly same, to switch to a new set of
> kernel+fs after
> > an update for the next boot.
> >
> > I also have another usecase of updating the env
> variable 'bootargs' if
> > required in the field. So this use-case combined with
> fw_env, what is
> > your feedback?
> 
> It is doable of course.? Maybe if I did not mention it
> before, I advise
> using a redundant environment for such procedures so that
> even a
> powerloss during this upgrade will not brick the device.

Can I get some pointers to some example implementation of a redundant environment. I mean how does a switching between the environments happen?
Who clears or sets the obsolete flag for the redundant env?

-Nitin

> 
> > Could you give me some pointers on upgrading u-boot
> itself, but I
> > don't have a spare partition for that. I would have to
> replace working
> > copy itself?
> 
> I would not recommend upgrading U-Boot in the field.?
> As it is not
> possible to build in redundancy for U-Boot (on most systems
> I know),
> there is always the possibility to kill the device with
> such an update.
> 
> > I would wanted to have more info(in addition to what I
> have
> > implemented) regarding the failsafe upgrade mechanisms
> for
> > embedded-linux apps and kernel? Could you please point
> me to right
> > forums regarding this. I understand that this is not
> specific to
> > u-boot, but just give me some pointers.
> 
> I'm sorry that I cannot point you to a ready to use recipe
> here, as this
> really depends on your strategy regarding upgrades, i.e.
> will you do the
> upgrade from within Linux? (judging by your questions, you
> will...)? Do
> you have enough ressources to keep two self-contained
> "program images"
> (at least kernel+dtb+rootfs) so you can always update "the
> other half"?
> If not, you will probably want to build a non-upgradeable
> fallback
> system which is only capable to update "the other part".
> 
> As you see, solving your problem really requires you to
> define your
> problem more rigorously first.
> 
> In order to protoect against interrupts during the update,
> you may very
> well want to have a watchdog on your system and use the
> "bootcount"
> (grep the documentation for it) feature of U-Boot to detect
> failing boot
> attempts.
> 
> I hope this is enough to get you started.
> 
> Cheers
> ? Detlev
> 
> -- 
> Thanks so much for Emacs.? What a wondrous system --
> one of the real
> seven wonders of the world.? Forced to choose between
> Emacs and, say,
> any pyramid, I'd take Emacs.? ?
> ???-- Robert Boyer
> --
> DENX Software Engineering GmbH,? ? ? MD:
> Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,? Office: Kirchenstr.5, D-82194
> Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email:
> dzu at denx.de
> 


      New Email names for you! 
Get the Email name you&#39;ve always wanted on the new @ymail and @rocketmail. 
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/aa/