[U-Boot] [RFC PATCH 1/5] spl: dfu: add dfu support in SPL

[B, Ravi]

Hi Lukasz

>> 
>> >My point here is to first load SPL u-boot (which size is around 110 
>> >KiB), and then download via DFU full-featured u-boot, which would be 
>> >placed in SDRAM.
>> 
>> Yes this is good idea, so the SPL-DFU will have only RAM device 
>> support (to load u-boot into DDR). But we don't have DFU command to 
>> jump to u-boot after loading u-boot into DDR.

>I think that we don't need dfu command in SPL to boot fully-featured u-boot.

>Lets consider following scenario:

>- ROM bootloader (IPL) fetches SPL u-boot via USB. Then it passes
>  execution to it.
>- The running SPL downloads fully-fledged u-boot [*] to RAM and passes
>  execution to it (as it is done in board_init_r @ ./common/spl/spl.c).
>  There is no need for any special command(s) to do that.
>- Fully-blown u-boot flashes all needed images and reboots the board.
>- Now the board is setup with proper u-boot, kernel and rootfs

> [*] - This version of u-boot only requires to have hardcoded "bootcmd"
>env variable. It would consist the list of commands needed for flashing your target board. The "dfu_alt_info" should be hardcoded as well.


>> The DFU basically just
>> download firmware to memory devices like mmc/sd/eMMC/RAM.
>> So the
>> question is how to transfer control to u-boot after downloading the 
>> u-boot to DDR using SPL-DFU/RAM.

> Please consult board_init_r function at ./common/spl/spl.c
 
Yes, this is common u-boot flow, make sense, I was thinking exiting from DFU loop, user has to press Ctrl+C to exit from DFU after download of u-boot to IRAM. 
We can leverage the existing DFU/RAM support.  Main concern is SPL+DFU size. I will rework and come back on how much size can be reduced.

Thanks Lukasz for great support. 

Regards
Ravi