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