[U-Boot] SPL Dfu update
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 and then do a cpu board reset and let it boot from the booting device.
What is for you the best approch?
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 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(); }
Michael
Michael
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
Hi Lukasz
On Wed, Oct 30, 2013 at 1:58 PM, Lukasz Majewski l.majewski@samsung.com wrote:
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).
This is not a problem because this should not be supported by all the architecture. Optimization can come later on
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
Michael
-- Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
Hi Lukasz, hi Michael,
On 30/10/2013 13:58, Lukasz Majewski wrote:
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).
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
Best regards, Stefano Babic
Hi
On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic sbabic@denx.de wrote:
Hi Lukasz, hi Michael,
On 30/10/2013 13:58, Lukasz Majewski wrote:
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).
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
USB flashing (no serial, no display) only otg
Michael
Best regards, Stefano Babic
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================
On Wed, Oct 30, 2013 at 02:29:32PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic sbabic@denx.de wrote:
Hi Lukasz, hi Michael,
On 30/10/2013 13:58, Lukasz Majewski wrote:
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).
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
USB flashing (no serial, no display) only otg
OK, but how are we getting SPL loaded? I know of, today, some solutions using U-Boot + DFU for flashing/restore (and some other non-DFU flashing solutions) that do SPL+regular U-Boot. I think this highlights, in part, once again that Scott is right and we need to think of SPL as a differently configured U-Boot, because the flip side here is, why should we load even more data before doing the payload when we know we're a single purpose run?
Hi Tom
On Wed, Oct 30, 2013 at 2:44 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 02:29:32PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic sbabic@denx.de wrote:
Hi Lukasz, hi Michael,
On 30/10/2013 13:58, Lukasz Majewski wrote:
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).
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
USB flashing (no serial, no display) only otg
OK, but how are we getting SPL loaded? I know of, today, some solutions using U-Boot + DFU for flashing/restore (and some other non-DFU flashing solutions) that do SPL+regular U-Boot. I think this highlights, in part, once again that Scott is right and we need to think of SPL as a differently configured U-Boot, because the flip side here is, why should we load even more data before doing the payload when we know we're a single purpose run?
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
Michael
-- Tom
Michael,
On Wed, Oct 30, 2013 at 11:52 AM, Michael Trimarchi michael@amarulasolutions.com wrote:
On Wed, Oct 30, 2013 at 2:44 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 02:29:32PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic sbabic@denx.de wrote:
Hi Lukasz, hi Michael,
On 30/10/2013 13:58, Lukasz Majewski wrote:
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).
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
USB flashing (no serial, no display) only otg
OK, but how are we getting SPL loaded? I know of, today, some solutions using U-Boot + DFU for flashing/restore (and some other non-DFU flashing solutions) that do SPL+regular U-Boot. I think this highlights, in part, once again that Scott is right and we need to think of SPL as a differently configured U-Boot, because the flip side here is, why should we load even more data before doing the payload when we know we're a single purpose run?
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
Best regards, Stefano
On 10/30/2013 07:24 AM, Stefano Babic wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
If I understand Tom's comment, I think the question surrounds a "bare metal" use case, when a full U-Boot isn't available in the normal place.
In the case of our i.MX boards that boot to SPI-NOR, it would be nice to simply load an SPL image over the i.MX downloader and have immediate access to DFU so we can use it to program the SPI-NOR.
Regards,
Eric
Hi
On Wed, Oct 30, 2013 at 3:32 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
On 10/30/2013 07:24 AM, Stefano Babic wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
If I understand Tom's comment, I think the question surrounds a "bare metal" use case, when a full U-Boot isn't available in the normal place.
In the case of our i.MX boards that boot to SPI-NOR, it would be nice to simply load an SPL image over the i.MX downloader and have immediate access to DFU so we can use it to program the SPI-NOR.
This should be a more complete example (just compile in my platform)
Michael
Regards,
Eric
Dear Eric Nelson,
In message 52711896.6010900@boundarydevices.com you wrote:
In the case of our i.MX boards that boot to SPI-NOR, it would be nice to simply load an SPL image over the i.MX downloader and have immediate access to DFU so we can use it to program the SPI-NOR.
Rewrite this as "...simply load an image over the i.MX downloader" and then explain again, why the DFU support needs to be in the SPL instead of the "real" U-Boot?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On 10/30/2013 01:01 PM, Wolfgang Denk wrote:
Dear Eric Nelson,
In message 52711896.6010900@boundarydevices.com you wrote:
In the case of our i.MX boards that boot to SPI-NOR, it would be nice to simply load an SPL image over the i.MX downloader and have immediate access to DFU so we can use it to program the SPI-NOR.
Rewrite this as "...simply load an image over the i.MX downloader" and then explain again, why the DFU support needs to be in the SPL instead of the "real" U-Boot?
I can't because it doesn't (of course), and this is what we're doing right now, since we only have "real" U-Boot...
And we don't yet have DFU support until the next release.
I should get back to work and send some patches...
Cheers,
Eric
Hi
On Wed, Oct 30, 2013 at 3:24 PM, Stefano Babic sbabic@denx.de wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg - using dfu to flash the u-boot.img, kernel .. etc
dfu is another way to upload and write second stage or what you want. I don't see the point to don't have this option. We have merged USBETH spl support and dfu is more useful.
./usb_load MLO.flash ./dfu-util ... MLO ./dfu-util ... u.boot.img .. ./dfu-util -R
Michael
Best regards, Stefano
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================
On Wed, Oct 30, 2013 at 03:34:45PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 3:24 PM, Stefano Babic sbabic@denx.de wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg
- using dfu to flash the u-boot.img, kernel .. etc
dfu is another way to upload and write second stage or what you want. I don't see the point to don't have this option. We have merged USBETH spl support and dfu is more useful.
./usb_load MLO.flash ./dfu-util ... MLO ./dfu-util ... u.boot.img .. ./dfu-util -R
Right. The point of USBETH is to continue the flow from ROM in cases where we're already sending the initial payload this way. It would be analogous to adding support for the USB mode omap3+ support to SPL so that you do: ./usb_load MLO.flash u-boot-flash.img ./dfu-util ... MLO .. ./dfu-util -R
All of that said, I wouldn't mind seeing how the code to make a DFU loop looks, but you're likely to run into the problem of (per Wolfgang) SPL needing to move stack pointerinto DDR once DDR is up so that you have environment, and all of the other big stack users functional.
Hi Tom
On Wed, Oct 30, 2013 at 8:33 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 03:34:45PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 3:24 PM, Stefano Babic sbabic@denx.de wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg
- using dfu to flash the u-boot.img, kernel .. etc
dfu is another way to upload and write second stage or what you want. I don't see the point to don't have this option. We have merged USBETH spl support and dfu is more useful.
./usb_load MLO.flash ./dfu-util ... MLO ./dfu-util ... u.boot.img .. ./dfu-util -R
Right. The point of USBETH is to continue the flow from ROM in cases where we're already sending the initial payload this way. It would be analogous to adding support for the USB mode omap3+ support to SPL so that you do: ./usb_load MLO.flash u-boot-flash.img ./dfu-util ... MLO .. ./dfu-util -R
All of that said, I wouldn't mind seeing how the code to make a DFU loop looks, but you're likely to run into the problem of (per Wolfgang) SPL needing to move stack pointerinto DDR once DDR is up so that you have environment, and all of the other big stack users functional.
The stack pointer can be moved using the CONFIG_SPL_RELOC_STACK
I need to give a try but dfu is more standard then send MLO and then move to a different protocol. What tool are you using to send MLO + u-boot.img in SPLETH way now?
Michael
-- Tom
On Wed, Oct 30, 2013 at 08:43:09PM +0100, Michael Trimarchi wrote:
Hi Tom
On Wed, Oct 30, 2013 at 8:33 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 03:34:45PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 3:24 PM, Stefano Babic sbabic@denx.de wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg
- using dfu to flash the u-boot.img, kernel .. etc
dfu is another way to upload and write second stage or what you want. I don't see the point to don't have this option. We have merged USBETH spl support and dfu is more useful.
./usb_load MLO.flash ./dfu-util ... MLO ./dfu-util ... u.boot.img .. ./dfu-util -R
Right. The point of USBETH is to continue the flow from ROM in cases where we're already sending the initial payload this way. It would be analogous to adding support for the USB mode omap3+ support to SPL so that you do: ./usb_load MLO.flash u-boot-flash.img ./dfu-util ... MLO .. ./dfu-util -R
All of that said, I wouldn't mind seeing how the code to make a DFU loop looks, but you're likely to run into the problem of (per Wolfgang) SPL needing to move stack pointerinto DDR once DDR is up so that you have environment, and all of the other big stack users functional.
The stack pointer can be moved using the CONFIG_SPL_RELOC_STACK
Note that this isn't supported under CONFIG_SPL_FRAMEWORK (..yet).
I need to give a try but dfu is more standard then send MLO and then move to a different protocol. What tool are you using to send MLO + u-boot.img in SPLETH way now?
In the SPL_ETH case we do dhcp + tftp requests, which is what the ROM also does to load MLO over (and the ROM supports doing this over the physical ethernet port, or USB as an RNDIS gadget, SPL_USBETH does RNDIS gadget).
Hi
On Wed, Oct 30, 2013 at 8:47 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 08:43:09PM +0100, Michael Trimarchi wrote:
Hi Tom
On Wed, Oct 30, 2013 at 8:33 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 03:34:45PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 3:24 PM, Stefano Babic sbabic@denx.de wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
> OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the > second stage boot. We have already SPL USBETH in u-boot but in production > otg flashing can be very useful. Think SPL as a differently configured U-BOOT > doesn't change the problem but yes it's a nice idea.
But you'd usually want to have an 'upgrade mode' which allows DFU to run. In this case, this could be done using complete U-Boot instead of SPL, no? In case customer needs a slim version of it, it could be accomplished using a specific config and having:
SPL Update mode U-Boot (normal U-Boot with less features) Complete U-Boot (interactive and like)
or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg
- using dfu to flash the u-boot.img, kernel .. etc
dfu is another way to upload and write second stage or what you want. I don't see the point to don't have this option. We have merged USBETH spl support and dfu is more useful.
./usb_load MLO.flash ./dfu-util ... MLO ./dfu-util ... u.boot.img .. ./dfu-util -R
Right. The point of USBETH is to continue the flow from ROM in cases where we're already sending the initial payload this way. It would be analogous to adding support for the USB mode omap3+ support to SPL so that you do: ./usb_load MLO.flash u-boot-flash.img ./dfu-util ... MLO .. ./dfu-util -R
All of that said, I wouldn't mind seeing how the code to make a DFU loop looks, but you're likely to run into the problem of (per Wolfgang) SPL needing to move stack pointerinto DDR once DDR is up so that you have environment, and all of the other big stack users functional.
The stack pointer can be moved using the CONFIG_SPL_RELOC_STACK
Note that this isn't supported under CONFIG_SPL_FRAMEWORK (..yet).
I need to give a try but dfu is more standard then send MLO and then move to a different protocol. What tool are you using to send MLO + u-boot.img in SPLETH way now?
In the SPL_ETH case we do dhcp + tftp requests, which is what the ROM also does to load MLO over (and the ROM supports doing this over the physical ethernet port, or USB as an RNDIS gadget, SPL_USBETH does RNDIS gadget).
/* * In the context of SPL, board_init_f must ensure that any clocks/etc for * DDR are enabled, ensure that the stack pointer is valid, clear the BSS * and call board_init_f. We provide this version by default but mark it * as __weak to allow for platforms to do this in their own way if needed. */ void __weak board_init_f(ulong dummy) { /* Set the stack pointer. */ asm volatile("mov sp, %0\n" : : "r"(CONFIG_SPL_STACK));
/* Clear the BSS. */ memset(__bss_start, 0, __bss_end - __bss_start);
/* Set global data pointer. */ gd = &gdata;
board_init_r(NULL, 0); }
You mean this code here.
and do somenthing like the code here
board/freescale/p1022ds/spl_minimal.c
Ok, this is a problem but we are discussing if in your opinion is something useful for several manufactured. If not I can just implement and use internally
Michael
-- Tom
On Wed, Oct 30, 2013 at 08:58:23PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 8:47 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 08:43:09PM +0100, Michael Trimarchi wrote:
Hi Tom
On Wed, Oct 30, 2013 at 8:33 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 03:34:45PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 3:24 PM, Stefano Babic sbabic@denx.de wrote:
Hi Otavio,
On 30/10/2013 15:19, Otavio Salvador wrote:
>> OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the >> second stage boot. We have already SPL USBETH in u-boot but in production >> otg flashing can be very useful. Think SPL as a differently configured U-BOOT >> doesn't change the problem but yes it's a nice idea. > > But you'd usually want to have an 'upgrade mode' which allows DFU to > run. In this case, this could be done using complete U-Boot instead of > SPL, no? In case customer needs a slim version of it, it could be > accomplished using a specific config and having: > > SPL > Update mode U-Boot (normal U-Boot with less features) > Complete U-Boot (interactive and like) > > or am I missing something?
Right, I agree completely with you.
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg
- using dfu to flash the u-boot.img, kernel .. etc
dfu is another way to upload and write second stage or what you want. I don't see the point to don't have this option. We have merged USBETH spl support and dfu is more useful.
./usb_load MLO.flash ./dfu-util ... MLO ./dfu-util ... u.boot.img .. ./dfu-util -R
Right. The point of USBETH is to continue the flow from ROM in cases where we're already sending the initial payload this way. It would be analogous to adding support for the USB mode omap3+ support to SPL so that you do: ./usb_load MLO.flash u-boot-flash.img ./dfu-util ... MLO .. ./dfu-util -R
All of that said, I wouldn't mind seeing how the code to make a DFU loop looks, but you're likely to run into the problem of (per Wolfgang) SPL needing to move stack pointerinto DDR once DDR is up so that you have environment, and all of the other big stack users functional.
The stack pointer can be moved using the CONFIG_SPL_RELOC_STACK
Note that this isn't supported under CONFIG_SPL_FRAMEWORK (..yet).
I need to give a try but dfu is more standard then send MLO and then move to a different protocol. What tool are you using to send MLO + u-boot.img in SPLETH way now?
In the SPL_ETH case we do dhcp + tftp requests, which is what the ROM also does to load MLO over (and the ROM supports doing this over the physical ethernet port, or USB as an RNDIS gadget, SPL_USBETH does RNDIS gadget).
/*
- In the context of SPL, board_init_f must ensure that any clocks/etc for
- DDR are enabled, ensure that the stack pointer is valid, clear the BSS
- and call board_init_f. We provide this version by default but mark it
- as __weak to allow for platforms to do this in their own way if needed.
*/ void __weak board_init_f(ulong dummy) { /* Set the stack pointer. */ asm volatile("mov sp, %0\n" : : "r"(CONFIG_SPL_STACK));
/* Clear the BSS. */ memset(__bss_start, 0, __bss_end - __bss_start); /* Set global data pointer. */ gd = &gdata; board_init_r(NULL, 0);}
You mean this code here.
and do somenthing like the code here
board/freescale/p1022ds/spl_minimal.c
Ok, this is a problem but we are discussing if in your opinion is something useful for several manufactured. If not I can just implement and use internally
Yes, something along those lines looks correct.
Dear Michael Trimarchi,
In message CAOf5uw=gn4=k9K2pjUA6nxocKWStJ4-GP+sb6_+HGiyW1Nv23Q@mail.gmail.com you wrote:
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg
- using dfu to flash the u-boot.img, kernel .. etc
Why should the image "sent over the otg" be just the SPL, and not include the real U-Boot?
dfu is another way to upload and write second stage or what you want. I don't
Why make it so complicated and write a second part at all? Why not write it in a single go?
Best regards,
Wolfgang Denk
Hi Wolfgang
On Wed, Oct 30, 2013 at 9:03 PM, Wolfgang Denk wd@denx.de wrote:
Dear Michael Trimarchi,
In message CAOf5uw=gn4=k9K2pjUA6nxocKWStJ4-GP+sb6_+HGiyW1Nv23Q@mail.gmail.com you wrote:
That's the reason I do not understand why we have to push DFU into SPL. Maybe we both are missing something.
It's simple:
- first stage boot can be sent over the otg
- using dfu to flash the u-boot.img, kernel .. etc
Why should the image "sent over the otg" be just the SPL, and not include the real U-Boot?
dfu is another way to upload and write second stage or what you want. I don't
Why make it so complicated and write a second part at all? Why not write it in a single go?
The discussion seems already closed, I will use it internally
Michael
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Premature optimization is the root of all evil. -- D.E. Knuth
On Wed, Oct 30, 2013 at 02:52:25PM +0100, Michael Trimarchi wrote:
Hi Tom
On Wed, Oct 30, 2013 at 2:44 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 02:29:32PM +0100, Michael Trimarchi wrote:
Hi
On Wed, Oct 30, 2013 at 2:28 PM, Stefano Babic sbabic@denx.de wrote:
Hi Lukasz, hi Michael,
On 30/10/2013 13:58, Lukasz Majewski wrote:
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).
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
USB flashing (no serial, no display) only otg
OK, but how are we getting SPL loaded? I know of, today, some solutions using U-Boot + DFU for flashing/restore (and some other non-DFU flashing solutions) that do SPL+regular U-Boot. I think this highlights, in part, once again that Scott is right and we need to think of SPL as a differently configured U-Boot, because the flip side here is, why should we load even more data before doing the payload when we know we're a single purpose run?
OMAP4/3 can boot over the otg, so you can send MLO and let it wait for the second stage boot. We have already SPL USBETH in u-boot but in production otg flashing can be very useful. Think SPL as a differently configured U-BOOT doesn't change the problem but yes it's a nice idea.
The point I'm trying to make with thinking of SPL as a differently configured U-Boot is that you're saying, in essance "I want a U-Boot that can init the hardware, start up DFU and wait". A general problem has been pointed out a few times now that when we want to make SPL+foo we're bringing more and more stuff in and adding more and more CONFIG_SPL_FOO that matches up with CONFIG_FOO. What we need to, longer term, move to is CONFIG_SPL + CONFIG_FOO, roughly, and then one build to make SPL one build to make U-Boot. Very roughly at least.
Dear Michael Trimarchi,
In message CAOf5uw=1yvf8xde--7bP2y0joPhj9WcEhE8jS8Y05+WYZ_wGBQ@mail.gmail.com you wrote:
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
USB flashing (no serial, no display) only otg
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
Best regards,
Wolfgang Denk
Hi
On Wed, Oct 30, 2013 at 8:58 PM, Wolfgang Denk wd@denx.de wrote:
Dear Michael Trimarchi,
In message CAOf5uw=1yvf8xde--7bP2y0joPhj9WcEhE8jS8Y05+WYZ_wGBQ@mail.gmail.com you wrote:
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
USB flashing (no serial, no display) only otg
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
Because it's not possible, internal memory size of some cpus. You need to have a way to load the second stage and I'm discussing a general way to do.
Best regards,
Wolfgang Denk
What is your alternative way?
Michael
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe, Inclu- ding This Product, May One Day Collapse Back into an Infinitesimally Small Space. Should Another Universe Subsequently Re-emerge, the Existence of This Product in That Universe Cannot Be Guaranteed.
Dear Michael Trimarchi,
In message CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com you wrote:
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
Because it's not possible, internal memory size of some cpus. You need to have a way to load the second stage and I'm discussing a general way to do.
I'm not sure that there are many use cases where you have sufficient room for all that is needed for DFU (including I/O buffers); and if you move to RAM early, you have other options as well.
What is your alternative way?
Depending on your hardware there is a zillion ways to do this. For low to medium volumes good old JTAG is still a very powerful tool; for high volumes you will probably just fit pre-programmed NAND on your board. And of course there is the growing number of systems that can just boot and install from a SDCard or USB MSD.
Best regards,
Wolfgang Denk
Hi
On Wed, Oct 30, 2013 at 9:11 PM, Wolfgang Denk wd@denx.de wrote:
Dear Michael Trimarchi,
In message CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com you wrote:
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
Because it's not possible, internal memory size of some cpus. You need to have a way to load the second stage and I'm discussing a general way to do.
I'm not sure that there are many use cases where you have sufficient room for all that is needed for DFU (including I/O buffers); and if you move to RAM early, you have other options as well.
No because you need anyway to have a way to load it and dfu is a way.
What is your alternative way?
Depending on your hardware there is a zillion ways to do this. For low to medium volumes good old JTAG is still a very powerful tool; for high volumes you will probably just fit pre-programmed NAND on your board. And of course there is the growing number of systems that can just boot and install from a SDCard or USB MSD.
I accept the lesson even I don't thing that I need a lesson on it. We are talking that we have only otg. BTW Forget about it.
Best regards,
Wolfgang Denk
Michael
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de But the only way of discovering the limits of the possible is to venture a little way past them into the impossible. - _Profiles of the Future_ (1962; rev. 1973) ``Hazards of Prophecy: The Failure of Imagination''
Hello Michael,
On Wed, Oct 30, 2013 at 6:35 PM, Michael Trimarchi michael@amarulasolutions.com wrote:
On Wed, Oct 30, 2013 at 9:11 PM, Wolfgang Denk wd@denx.de wrote:
Dear Michael Trimarchi,
In message CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com you wrote:
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
Because it's not possible, internal memory size of some cpus. You need to have a way to load the second stage and I'm discussing a general way to do.
I'm not sure that there are many use cases where you have sufficient room for all that is needed for DFU (including I/O buffers); and if you move to RAM early, you have other options as well.
No because you need anyway to have a way to load it and dfu is a way.
What is your alternative way?
Depending on your hardware there is a zillion ways to do this. For low to medium volumes good old JTAG is still a very powerful tool; for high volumes you will probably just fit pre-programmed NAND on your board. And of course there is the growing number of systems that can just boot and install from a SDCard or USB MSD.
I accept the lesson even I don't thing that I need a lesson on it. We are talking that we have only otg.
I see your user-case and I think I agree with you.
BTW Forget about it.
Please don't. I think it is a valuable contribution and I think it is good to have a mechanism which work for your user-case in U-Boot; it is easy to maintain long term and avoid duplication of work in case users has some problem.
I got a little bit lost when Tom gave an example where he 'loads' MLO and U-Boot image from OTG; just clarify it for me as it is not clear if it works for you or does not.
From what I understand, your use-case would be:
OTG -> SPL -> DFU -> U-Boot Image -> Jump to U-Boot ?
Hi
On Wed, Oct 30, 2013 at 9:53 PM, Otavio Salvador otavio@ossystems.com.br wrote:
Hello Michael,
On Wed, Oct 30, 2013 at 6:35 PM, Michael Trimarchi michael@amarulasolutions.com wrote:
On Wed, Oct 30, 2013 at 9:11 PM, Wolfgang Denk wd@denx.de wrote:
Dear Michael Trimarchi,
In message CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com you wrote:
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
Because it's not possible, internal memory size of some cpus. You need to have a way to load the second stage and I'm discussing a general way to do.
I'm not sure that there are many use cases where you have sufficient room for all that is needed for DFU (including I/O buffers); and if you move to RAM early, you have other options as well.
No because you need anyway to have a way to load it and dfu is a way.
What is your alternative way?
Depending on your hardware there is a zillion ways to do this. For low to medium volumes good old JTAG is still a very powerful tool; for high volumes you will probably just fit pre-programmed NAND on your board. And of course there is the growing number of systems that can just boot and install from a SDCard or USB MSD.
I accept the lesson even I don't thing that I need a lesson on it. We are talking that we have only otg.
I see your user-case and I think I agree with you.
BTW Forget about it.
Please don't. I think it is a valuable contribution and I think it is good to have a mechanism which work for your user-case in U-Boot; it is easy to maintain long term and avoid duplication of work in case users has some problem.
I got a little bit lost when Tom gave an example where he 'loads' MLO and U-Boot image from OTG; just clarify it for me as it is not clear if it works for you or does not.
From what I understand, your use-case would be:
OTG -> SPL -> DFU -> U-Boot Image -> Jump to U-Boot ?
My use case is:
OTG->SPL->DFU ----> flash MLO on flash/NAND/eMMC -----> flash u-boot.img on NAND/flash/eMMC -----> .....
done? OK so dfu-util -R
Board should reset and boot from flashed image. One big thing that I missed (and thanks to Tom Rini) is stack relocation on DDR
Michael
-- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
On Wed, Oct 30, 2013 at 09:11:43PM +0100, Wolfgang Denk wrote:
Dear Michael Trimarchi,
In message CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com you wrote:
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
Because it's not possible, internal memory size of some cpus. You need to have a way to load the second stage and I'm discussing a general way to do.
I'm not sure that there are many use cases where you have sufficient room for all that is needed for DFU (including I/O buffers); and if you move to RAM early, you have other options as well.
No, it's true. We have some "small" amount of image download area in some sort of on-chip RAM (OMAP3 is between 54 and 62KiB, depending on how we think about stack, AM335x is ~110KiB) which is where our first stage _has_to_ fit. We can still do a two-step process here of loading a regular SPL and then a full U-Boot, but this requires more complicated host side tooling.
But this is what I was trying to highlight, about how Scott's comment is right. What's desired here, rightly is a U-Boot build with limited IO and a main loop that drops right into DFU. You can do this today with SPL+U-Boot and a CONFIG_BOOTCOMMAND that just kicks off DFU. But that means transferring more data, which is taking more time and yes, programming time is a concern.
What is your alternative way?
Depending on your hardware there is a zillion ways to do this. For low to medium volumes good old JTAG is still a very powerful tool; for high volumes you will probably just fit pre-programmed NAND on your board. And of course there is the growing number of systems that can just boot and install from a SDCard or USB MSD.
Exactly. But you're leaving out "system boots via USB gadget", which is what Michael is trying to solve.
Hi Tom
On Thu, Oct 31, 2013 at 2:20 PM, Tom Rini trini@ti.com wrote:
On Wed, Oct 30, 2013 at 09:11:43PM +0100, Wolfgang Denk wrote:
Dear Michael Trimarchi,
In message CAOf5uw=hCkwPaqogCO3KvM1erhS-dvC5BRT4USU3uqKETtTQ7A@mail.gmail.com you wrote:
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
Because it's not possible, internal memory size of some cpus. You need to have a way to load the second stage and I'm discussing a general way to do.
I'm not sure that there are many use cases where you have sufficient room for all that is needed for DFU (including I/O buffers); and if you move to RAM early, you have other options as well.
No, it's true. We have some "small" amount of image download area in some sort of on-chip RAM (OMAP3 is between 54 and 62KiB, depending on how we think about stack, AM335x is ~110KiB) which is where our first stage _has_to_ fit. We can still do a two-step process here of loading a regular SPL and then a full U-Boot, but this requires more complicated host side tooling.
But this is what I was trying to highlight, about how Scott's comment is right. What's desired here, rightly is a U-Boot build with limited IO and a main loop that drops right into DFU. You can do this today with SPL+U-Boot and a CONFIG_BOOTCOMMAND that just kicks off DFU. But that means transferring more data, which is taking more time and yes, programming time is a concern.
What is your alternative way?
Depending on your hardware there is a zillion ways to do this. For low to medium volumes good old JTAG is still a very powerful tool; for high volumes you will probably just fit pre-programmed NAND on your board. And of course there is the growing number of systems that can just boot and install from a SDCard or USB MSD.
Exactly. But you're leaving out "system boots via USB gadget", which is what Michael is trying to solve.
This should make more sense. Try to have all the dfu support in the first stage is complicated for the writing routine but having just ram loading can be more simple considering the image size
#define STR_HELPER(x) #x #define STR(x) STR_HELPER(x) #define DFU_BOARD_FLASHINFO "RAM" STR(DFU_RAM_DEVICE_ADDRESS) ";"
void spl_dfu_load_image() { int ret; struct image_header *header;
printf("SPL load image\n");
ret = dfu_config_entities(DFU_BOARD_FLASHINFO, "ram", 0); g_dnl_register("dfu"); while(1) { if (ctrlc()) goto exit; ret = usb_gadget_handle_interrupts(); if (ret) goto exit; }
g_dnl_unregister(); dfu_free_entities();
header = (struct image_header *)DFU_RAM_DEVICE_ADDRESS; spl_parse_image_header(header); memcpy((void *)DFU_RAM_DEVICE_ADDRESS, (void *)spl_image.load_addr, spl_image.size); return; exit: g_dnl_unregister(); dfu_free_entities(); }
-- Tom
Michael
On Wed, Oct 30, 2013 at 08:58:14PM +0100, Wolfgang Denk wrote:
Dear Michael Trimarchi,
In message CAOf5uw=1yvf8xde--7bP2y0joPhj9WcEhE8jS8Y05+WYZ_wGBQ@mail.gmail.com you wrote:
Apart of the fact that is possible to add DFU to SPL, I am missing which is the real advantage. One goal of having split U-Boot into two images (SPL and U-Boot) is also to get a simpler and smaller image, letting the main U-Boot image doing the rest (hush shell, further drivers, and so on). We are now trying to push features that we currently have into SPL. Well, why cannot we simply run U-Boot if we need a DFU update ? Which are the real advantages for having DFU in SPL ?
USB flashing (no serial, no display) only otg
This does not answer Stefano's question: why do it in SPL, what's wrong with loading the real U-Boot for this purpose?
The answer, of debatable value, is that we can't download the whole thing at once to the target device. One could wrap the logic and load SPL, then load special task U-Boot, at least in the examples I know well enough to talk about them (the TI parts).
participants (7)
-
Eric Nelson -
Lukasz Majewski -
Michael Trimarchi -
Otavio Salvador -
Stefano Babic -
Tom Rini -
Wolfgang Denk