Hello, --- On Thu, 1/4/10, Detlev Zundel <d...@denx.de> wrote:
> From: Detlev Zundel <d...@denx.de> > Subject: Re: [U-Boot] Saving environment variables in MMC > To: nitin...@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: > d...@denx.de > New Email names for you! Get the Email name you've always wanted on the new @ymail and @rocketmail. Hurry before someone else does! http://mail.promotions.yahoo.com/newdomains/aa/ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot