On Tue, Jun 2, 2015 at 7:25 AM, Tom Rini trini@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