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