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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
