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.