summaryrefslogtreecommitdiff
path: root/drivers/dfu/Makefile
Commit message (Collapse)AuthorAgeLines
* dfu: add SF backendStephen Warren2014-08-09-0/+1
| | | | | | This allows SPI Flash to be programmed using DFU. Signed-off-by: Stephen Warren <swarren@nvidia.com>
* drivers: convert makefiles to Kbuild styleMasahiro Yamada2013-10-31-23/+4
| | | | Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
* dfu: ram supportAfzal Mohammed2013-09-24-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DFU spec mentions it as a method to upgrade firmware (software stored in writable non-volatile memory). It also says other potential uses of DFU is beyond scope of the spec. Here such a beyond the scope use is being attempted - directly pumping binary images from host via USB to RAM. This facility is a developer centric one in that it gives advantage over upgrading non-volatile memory for testing new images every time during development and/or testing. Directly putting image onto RAM would speed up upgrade process. This and convenience was the initial thoughts that led to doing this, speed improvement over MMC was only 1 second though - 6 sec on RAM as opposed to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing DFU framework to avoid multiple copy for ram (if worth) may help, and on other platforms and other boot media like NAND maybe improvement would be higher. And for a platform that doesn't yet have proper DFU suppport for non-volatile media's, DFU to RAM can be used. Another minor advantage would be to increase life of mmc/nand as it would be less used during development/testing. usage: <image name> ram <start address> <size> eg. kernel ram 0x81000000 0x1000000 Downloading images to RAM using DFU is not something new, this is acheived in openmoko also. DFU on RAM can be used for extracting RAM contents to host using dfu upload. Perhaps this can be extended to io for squeezing out register dump through usb, if it is worth. Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com> Cc: Heiko Schocher <hs@denx.de> Cc: Marek Vasut <marex@denx.de> Cc: Lukasz Majewski <l.majewski@samsung.com> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Gerhard Sittig <gsi@denx.de> Acked-by: Marek Vasut <marex@denx.de> Acked-by: Lukasz Majewski <l.majewski@samsung.com> Acked-by: Heiko Schocher <hs@denx.de>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-24-17/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* dfu: NAND specific routines for DFU operationPantelis Antoniou2013-04-10-0/+1
| | | | | | | | Support for NAND storage devices to work with the DFU framework. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> Signed-off-by: Tom Rini <trini@ti.com> Acked-by: Scott Wood <scottwood@freescale.com>
* dfu: MMC specific routines for DFU operationLukasz Majewski2012-09-01-0/+1
| | | | | | | | Support for MMC storage devices to work with DFU framework. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Marek Vasut <marex@denx.de>
* dfu: DFU backend implementationLukasz Majewski2012-09-01-0/+43
New, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU. It has been extended to use new MMC level of command abstraction. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Marek Vasut <marex@denx.de>