First working DFU capable u-boot
Harald Welte
laforge at openmoko.org
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 openmoko.org> http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-uboot
mailing list