USB DFU - The USB Device Firmware Upgrade standard - Revision history

Phobie: linkfix

2008-10-22T14:45:36Z

linkfix

Phobie: linkfix

2008-10-22T14:41:25Z

linkfix

Phobie: Template:Languages

2008-10-22T14:39:02Z

Template:Languages

MinhHaDuong: USB DFU moved to USB DFU - The USB Device Firmware Upgrade standard: Acronym only unclear

2008-09-03T05:54:31Z

USB DFU moved to USB DFU - The USB Device Firmware Upgrade standard: Acronym only unclear

DolfjeBot1: Replacing 'OpenMoko' with 'Openmoko'

2008-08-23T09:28:02Z

Replacing 'OpenMoko' with 'Openmoko'

Glenn: catchg

2008-07-13T09:55:16Z

catchg

Coolcat: /* USB DFU Interfaces */

2008-02-27T09:30:48Z

‎USB DFU Interfaces

Jollen at 09:21, 18 February 2008

2008-02-18T09:21:40Z

TuukkaH: move the partition list to partition

2007-11-23T01:30:08Z

move the partition list to partition

Glenn: catspec

2007-07-16T12:39:03Z

catspec

@@ Line 29: / Line 29: @@
 The Neo1973 has enough SDRAM to accomodate a download mechanism according to Chapter 6.1 Mechanism "1." (to receive the entire image into a buffer and perform the actual programming during the manifestation phase).  We are using this mechanism for the u-boot [[Partitions|partition]] to prevent users from "bricking" their device if something goes wrong during the transfer.
-For other [[partitions]] (kernel, rootfs, ...) however, future devices will have more NAND than SDRAM.  Thus, we implement a download mechanism according Chapter 6.1 Mechanism "2." for all non-bootloader partitions.
+For other [[Partitions|partitions]] (kernel, rootfs, ...) however, future devices will have more NAND than SDRAM.  Thus, we implement a download mechanism according Chapter 6.1 Mechanism "2." for all non-bootloader partitions.
 ==== USB DFU Interfaces ====
-The DFU in the Neo1973 has a USB Alternate Interface name "RAM 0x32000000" number 0 for downloading executable code into RAM (address 0x32000000) and executing it. The rest of the Alternate Interfaces are for each internal NAND flash [[partition]].
+The DFU in the Neo1973 has a USB Alternate Interface name "RAM 0x32000000" number 0 for downloading executable code into RAM (address 0x32000000) and executing it. The rest of the Alternate Interfaces are for each internal NAND flash [[Partitions|partition]].
 {{Languages|USB DFU}}

@@ Line 27: / Line 27: @@
 ==== Type of DFU Download ====
-The Neo1973 has enough SDRAM to accomodate a download mechanism according to Chapter 6.1 Mechanism "1." (to receive the entire image into a buffer and perform the actual programming during the manifestation phase).  We are using this mechanism for the u-boot [[partition]] to prevent users from "bricking" their device if something goes wrong during the transfer.
+The Neo1973 has enough SDRAM to accomodate a download mechanism according to Chapter 6.1 Mechanism "1." (to receive the entire image into a buffer and perform the actual programming during the manifestation phase).  We are using this mechanism for the u-boot [[Partitions|partition]] to prevent users from "bricking" their device if something goes wrong during the transfer.
 For other [[partitions]] (kernel, rootfs, ...) however, future devices will have more NAND than SDRAM.  Thus, we implement a download mechanism according Chapter 6.1 Mechanism "2." for all non-bootloader partitions.

@@ Line 1: / Line 1: @@
 USB Device Firmware Upgrade (DFU) is an official USB device class specification of the USB Implementers Forum.
@@ Line 7: / Line 9: @@
 The current version is 1.1, it can be found for free download at http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf
 Despite its clear architecture and DFU being an official USB standard, very few companies are known to have implemented it in their products.  In the Free Software / Hardware area, most notably the [http://www.openpcd.org/ OpenPCD] project has used it for their Free RFID readers.
 == Openmoko and USB DFU ==
@@ Line 36: / Line 38: @@
 [[Category:Flashing Openmoko]]
-[[Category:USB| ]]
+[[Category:USB|USB]]

@@ Line 9: / Line 9: @@
 Despite its clear architecture and DFU being an official USB standard, very few companies are known to have implemented it in their products.  In the Free Software / Hardware area, most notably the [http://www.openpcd.org/ OpenPCD] project has used it for their Free RFID readers.
-== OpenMoko and USB DFU ==
+== Openmoko and USB DFU ==
-Since OpenMoko is a big supporter of open standards and protocols, it has chosen USB DFU as the way to do "firmware" (actually, general software) updates on its official devices.
+Since Openmoko is a big supporter of open standards and protocols, it has chosen USB DFU as the way to do "firmware" (actually, general software) updates on its official devices.
 === USB DFU host utility ===

@@ Line 34: / Line 34: @@
 {{Languages|USB DFU}}
-[[Category:Hardware]]
 [[Category:USB| ]]

← Older revision		Revision as of 09:30, 27 February 2008
Line 35:		Line 35:
	{{Languages\|USB DFU}}		{{Languages\|USB DFU}}
	[[Category:Hardware]]		[[Category:Hardware]]
		+	[[Category:USB\| ]]

← Older revision		Revision as of 09:21, 18 February 2008
Line 33:		Line 33:
	The DFU in the Neo1973 has a USB Alternate Interface name "RAM 0x32000000" number 0 for downloading executable code into RAM (address 0x32000000) and executing it. The rest of the Alternate Interfaces are for each internal NAND flash [[partition]].		The DFU in the Neo1973 has a USB Alternate Interface name "RAM 0x32000000" number 0 for downloading executable code into RAM (address 0x32000000) and executing it. The rest of the Alternate Interfaces are for each internal NAND flash [[partition]].

		+	{{Languages\|USB DFU}}
	[[Category:Hardware]]		[[Category:Hardware]]

@@ Line 25: / Line 25: @@
 ==== Type of DFU Download ====
-The Neo1973 has enough SDRAM to accomodate a download mechanism according to Chapter 6.1 Mechanism "1." (to receive the entire image into a buffer and perform the actual programming during the manifestation phase).  We are using this mechanism for the u-boot partition to prevent users from "bricking" their device if something goes wrong during the transfer.
+The Neo1973 has enough SDRAM to accomodate a download mechanism according to Chapter 6.1 Mechanism "1." (to receive the entire image into a buffer and perform the actual programming during the manifestation phase).  We are using this mechanism for the u-boot [[partition]] to prevent users from "bricking" their device if something goes wrong during the transfer.
-For other partitions (kernel, rootfs, ...) however, future devices will have more NAND than SDRAM.  Thus, we implement a download mechanism according Chapter 6.1 Mechanism "2." for all non-bootloader partitions.
+For other [[partitions]] (kernel, rootfs, ...) however, future devices will have more NAND than SDRAM.  Thus, we implement a download mechanism according Chapter 6.1 Mechanism "2." for all non-bootloader partitions.
 ==== USB DFU Interfaces ====
-The Neo1973 has the following USB Alternate Interfaces for DFU:
+The DFU in the Neo1973 has a USB Alternate Interface name "RAM 0x32000000" number 0 for downloading executable code into RAM (address 0x32000000) and executing it. The rest of the Alternate Interfaces are for each internal NAND flash [[partition]].
-−
-# RAM.  This downloads executable code into RAM (address 0x32000000) and executes it
-# the u-boot bootloader partition in NAND flash
-# the u-boot environment partition in NAND flash
-# the kernel partition in NAND flash
-# the splash partition in NAND flash
-# the rootfs partition in NAND flash.
 [[Category:Hardware]]

← Older revision		Revision as of 12:39, 16 July 2007
Line 40:		Line 40:
	# the rootfs partition in NAND flash.		# the rootfs partition in NAND flash.

−	[[Category:~~Categories~~]]	+	[[Category:Hardware]]