First working DFU capable u-boot

Harald Welte laforge at
Sun Feb 25 10:53:30 CET 2007

On Sun, Feb 25, 2007 at 12:51:02AM -0300, Werner Almesberger wrote:
> Regarding bug #209:
> To avoid race conditions, I'd propose the following scheme. Assumes that
> - there are no other interrupts doing serious I/O during a DFU interrupt,
> - DFU runs only from interrupts,
> - if not ready, DFU can drop/ignore requests,
> - foreground polls input frequenty,
> - user input can polled, i.e., we don't need to call any "sleep until
>   data is ready" sort of function.
> Shared:
> extern volatile enum { DFU_NONE, DFU_REQ, DFU_ACK } dfu_req = DFU_NONE;

this is basically 'struct usb_device_instance'.dfu_State which can be
either DFU_STATE_appIDLE (runtime mode) or different (DFU mode).

so basically all we need is to add the checks to the getchar polling
code.  And please let's just enable/disable the single USBD interrupt,
not all system interrupts as a whole.   We have an interrupt 'framework'
for arm920t/s3c2410, so we might also want to use it for other things...

What's not yet clear to me is the inter-twisted-ness of usbtty and dfu.
both are running from the same interrupt :)

A different option (which I like way better) is to move the load of the
DFU work (flashing, etc.) out of the interrupt handler, just like
'hardirq/softirq' in the linux kernel.   There's nothing wrong with
copying data from USB to (privately allocated) RAM while still
interacting with the menu.  

- Harald Welte <laforge at>         
Software for the world's first truly open Free Software mobile phone

More information about the openmoko-uboot mailing list