[U-Boot] Booting Wandboard through USB

[Tim Harvey]

On Tue, Jun 2, 2015 at 7:25 AM, Tom Rini <trini at konsulko.com> wrote:
> On Mon, Jun 01, 2015 at 09:38:18AM -0700, Tim Harvey wrote:
> [snip]
>> Honestly I've never used fsl's mfgtool and never want to. I think its
>> way more complicated than a scrip-table linux solution with very few
>> dependencies (imx_usb_loader) and IMHO I think we should not be
>> encumbered with fitting that complicated mould but instead work on
>> breaking it by providing better options.
>
> The counter-point that we can't just dismiss is that we want companies
> on mainline.  Today many use the Freescale mfgtool (which is a big
> wrapper around shoving u-boot.imx over and booting a kernel + ramdisk
> into Linux and then flashing the board.  A solution that continues to
> work within this framework removes a barrier from getting them on
> mainline (and from Freescale shipping a more recent version of U-Boot
> with their refernce SW).

mfgtool is a big 'windows' wrapper around shoving a u-boot.imx over
USB OTG and scripting through serial port to do 'whatever else' is
needed. While fsl may be getting close to mainline that doesn't mean
they are using SPL and thats the difference here.

>
> Thinking about this a bit, as near as I can tell the way the mfgtool
> (and for that matter, imx_usb_loader when passing in multiple files)
> works is to use the header of u-boot.imx (or whatever...) to initialize
> DDR, then start taking files and putting them in.  Could we not add some
> debug (or opt-in CONFIG statement) that would cause SPL to spit out in
> essence the values to plug into a template for header-based DDR init?
> That way the mfgtool itself will continue working and instead of being
> told to use u-boot.imx it's given a script (which iirc it supports) and
> u-boot.img to run and it's normal loads of everything to flash.  Roughly
> speaking :)
>
> --
> Tom

mfgmode uses a windows exe that takes a *.imx which has a DCD table
and sets the regs defined in the DCD table - so it relies on the
non-SPL way of doing things where the MMDC configuration is hard-coded
in the DCD, thus every combination of SoC 'type'
(IMX6DQ|IMX6SDL|IMX6SX) and memory configuration
(chip+width+calib-for-pcb+size) requires a different DCD thus *.imx.

To my knowledge fsl has not 'embraced the SPL' and is still relying on
custom DCD's in the bootloader (someone please correct me if I'm out
of date here). That thought works just fine for customers in large
vertical markets with one or two configs but is very inflexible for
those of us that vary the parameters quite a bit.

The imx_usb_loader works off the assumption that you have a DCD (which
is just a table of register addr's and values) and that the DCD
configures the MMDC properly for your target, so that it can then load
1 or more blobs into DRAM. In our case what we are wanting to do is
let the SPL configure the MMDC then use the SPL to allow a raw DRAM
load option over OTG. I don't see any other way to do it other than
Nikolay's idea which should not be that difficult to implement. I
don't know enough about mfgtool to know how flexible it is. Can you
build imx_usb_loader for windows and choose to use an 'enhanced one'
vs the closed-source one distributed with mfgtool and thus continue to
use the config/scripting portion of the mfgtool package?

It 'could' be possible to make the SPL output all its register writes
I suppose through some wrappers around writel (I've actually done this
in the past to troubleshoot things) to re-create a DCD but I'm not
sure I see the point in where we go from there as you would also need
the SPL to not re-configure the MMDC and not clobber memory.... so
essentially your no longer using the SPL.

If someone wants to use mfgtool they can go down the path of non-SPL
U-Boot's and be fine. If someone wants to use SPL why can't we provide
a better/different approach? Perhaps fsl can release the source for
mfgtools windows cmdline app so that it can be enahnced to support
this as well.

I've run into a similar issue with fsl's 'ddr calibration and stress
test tool' because I think it uses the same approach to mfgtool (it
may even use the same windows exe). The windows tool loads their
stand-alone bare-metal blob (has a DCD so equiv to an *.imx) over OTG
then the bare-metal app immediately implements a USB HID-generic
gadget over OTG and communicates to the windows app that way
(basically serial-console over USB at that point). Now, if you are
able to get the source for the ddr calibration and stress test tool
from fsl (not too hard) you can build it in a way that it doesn't have
the DCD and doesn't use the USB OTG HID-generic gadget as a serial
console and then load it via U-Boot or JTAG (of course in that mode
U-Boot or JTAG needs to be doing what the DCD did to configure the
MMDC so you can run into a catch-22 scenario if your trying to use the
tool to obtain those DDC values). When you get the source for this
tool, its just the source for the bare-metal app not the Windows exe
that is used with it. The only reason you would need the source is if
you needed to boot it in the non-OTG mode with your own UART pinmux
etc.

Tim