Hi Michael,
Hi
On Wed, Oct 30, 2013 at 9:28 AM, Michael Trimarchi michael@amarulasolutions.com wrote:
Hi Lukasz
We have discussed during the u-boot mini-summit the possibility to have the dfu update from SPL. Right now I'm trying to understand what is the best way to do:
void spl_dfu_load_image() { int rv;
env_init(); env_relocate(); setenv("dfu_alt_info", DFU_BOARD_FLASHINFO); board_usb_init(); g_dnl_register(s);One option could be do the same of do_dfu command and let upload all the image that is needed to flash and the issue a usb reset. I don't sure if the reset can be triggered
With the dfu-util -R you can issue reset on the board. It already works in mainline (please refer to CMD_DFU).
and then do a cpu board
reset and let it boot from the booting device.
What is for you the best approch?
better pseudo code
void spl_dfu_load_image() { ret = dfu_config_entities(DFU_BOARD_FLASHINFO, DFU_BOARD_INTERFACE, DFU_BOARD_NUMBER); board_usb_init(); g_dnl_register(s); while(1) { if (ctrlc()) goto exit; ret = usb_gadget_handle_interrupts(); if (ret) goto exit; }
exit: g_dnl_unregister(); dfu_free_entities(); board_reset(); }
In general the presented structure is correct.
However, I've got other concerns:
The DFU + composite + gadget + UDC driver code is large (around 24KiB in binary size [1] for the TRATS).
I'm not sure if this size would be acceptable for SPL. Of course there are some spots for code base size reduction (like optimizing and often hardcoding code ported from linux kernel).
I _predict_, that with really aggressive approach for optimization the size [1] can be reduced, maybe up to 30%.
Michael
Michael