Dear Marcel, In message <201002012159.29244.korg...@home.nl> you wrote: > > I'm using u-boot for a while now for my AVR (ap7000) project and while happy > with it as a developer tool I wonder how I can make it useful for end-user > firmware upgrades. > > The way I think about it is that end-user can never be allowed to interact > directly with u-boot. It's something I don't want and the users of my > devices > also. Unfortunately I can't find anything yet to how I can make it easy for > my > end-users to upgrade firmware of the device.
I recommend to rethink this attitude. It may be a wise decision not to require that end users interact with U-Boot for normal operation of the device, but on the other hand many experienced users consider it a tremendous advantage if they can get such access if they really want it. > 1) Using USB : This is easy for end-users because it doesn't depend on > network > configuration. Unfortunately there's no USB support in u-boot (at least not > for > my CPU). I found something at openmoko which may be suitable, but no other > valid solutions so far. > > 2) Ethernet : No idea how to do this in an easy way. If it can be done, I'd > be > happy to hear about it. > > Either way, I have no clue if there are any options in u-boot available > already to do what I want or must I implement this from scratch ? Both has been done before. Re USB: search for examples of auto_update.c in the U-Boot source tree - at least 3 boards in mainline support this. Typically U-Boot will check during the power-on sequence if a USB mass storage device is plugged in, if this contains a readable file system, checks then if this contains one or more known image files. Additionally it is possible to check if the image versions on the USB device are more recent than those already stored in flash. If all programmed criteria match, and if the images can be read without error, the content of the on-board storage (flash, NAND, etc.) gets automatically updated. Re Network: there is also auto-update support over TFTP; for this you can tweak the TFTP timeout behaviour with environment variables like TftpRRQTimeoutMSecs and TftpRRQTimeoutCountMax, see commit e83cc063. The TFTP auto-update itself is controlled using the environment variable "updatefile" in combination with config options CONFIG_UPDATE_TFTP*; for details see commit 4bae9090 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Status quo. Latin for "the mess we're in." _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
