i.MX ProcessorsのトピックRe: mfgtool optimisable for mass production

mfgtool optimisable for mass production

boudewijn-ame — Tue, 24 Feb 2015 12:47:07 GMT

Hello,

I have a very simple yet necessary question. This is mostly aimed at Freescale employees.

We have created a custom imx6s board with almost all peripherals onboard. We would like to start mass production very soon and want to use the mfgtool (IMX_6_MFG_L3.10.17_1.0.0_TOOL --> Without rootfs)). We would only like to use the tool to push u-boot to the device. However I have an issue using this tool.

The -noui window never closes. Our automated system cannot handle windows that do not close after a successful boot. Is it possible to add an extra command such as "-pass 1" to the tool that closes after one succesful operation?

We tried using the application source code (IMX_MFG_TOOL_V2_SOURCE) to do it ourselves, but whenever we build it in visual studio 2012 we get a mass of errors mostly related to a dot in the mapname. When we got things finally working and building, the application crashes when trying to boot the device. Very weird because we never changed the downloaded source code. Can anyone try to download the website code, extract it into C:\ and open it in visual studio?)

Original Attachment has been moved to: ucl2.xml.zip

Re: mfgtool optimisable for mass production

KursadOney — Tue, 24 Feb 2015 13:54:33 GMT

One possible workaround is to launch mfgtool2.exe in the background, wait for a while, and use taskkill to terminate it. For example:

mfgtool2.exe -noui &

timeout 30

taskkill /IM mfgtool2.exe

Re: mfgtool optimisable for mass production

andrewdyer — Thu, 26 Feb 2015 19:26:37 GMT

I just ran into the same problem today. Add my vote to this feature request.

In addition to terminating after the <LIST> is run through, MfgTool2.exe should return a code that can be tested with %ERRORLEVEL% in a batch file for success.

Re: mfgtool optimisable for mass production

boudewijn-ame — Fri, 27 Feb 2015 08:47:23 GMT

Hello Kursad Oney,

Thanks for your answer. I understand that there are workarounds, but those are not nice solutions. Besides, I am using a test machine that can only open programs via commandline (Windows) and its testprogram can only continue if the application closes. I know it is a flaw of the machine as well, but a feature like this really suits the mfgtool.

Can someone also check the source code on this website and open the solution in visual basic?

Re: mfgtool optimisable for mass production

KursadOney — Fri, 27 Feb 2015 14:24:18 GMT

I agree with you and will try to raise this issue to the mfgtool development team. I wish we had a way for the public to open issues/bugs against the SW and track it.

Re: mfgtool optimisable for mass production

andrewdyer — Fri, 27 Feb 2015 17:07:32 GMT

Another possible work-around is to use sb_loader.exe which is a simple standalone download program. The downside is that sb_loader doesn't implement the UTP protocol that mfgtool uses to push commands and data across the link. I was looking at replacing the usb mass storage gadget and UTP daemon with the ethernet over USB g_ether gadget and using ssh/scp over that link. This would require a new kernel build and new ramdisk image. You might also modify the disk image of the ramdisk and pre-load some scripts on it to do things. In any case I haven't got that part going yet.

sb_loader.exe is on the freescale forum in this thread:

sb_loader.exe not supported for imx6 solo

(The version linked at the end does work on the Solo)

My ucl2.xml for loading the kernel looks like so:

<CMD state="BootStrap" type="boot" body="BootStrap" file ="u-boot-ct200.imx" >Loading U-boot</CMD>

<CMD state="BootStrap" type="load" file="uImage" address="0x12000000" loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE" >Loading Kernel.</CMD>

<CMD state="BootStrap" type="load" file="initramfs.cpio.gz.uboot" address="0x12C00000" loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE" >Loading Initramfs.</CMD>

<CMD state="BootStrap" type="load" file="imx6dl-ct200-ldo.dtb" address="0x18000000" loadSection="OTH" setSection="OTH" HasFlashHeader="FALSE" >Loading Device Tree.</CMD>

<CMD state="BootStrap" type="jump" >Jumping to OS image.</CMD>

To replicate this with sb_loader I do the following:

on a linux machine:

run "mkimage -l u-boot-ct200.imx | grep Entry" to get the entry address of the u-boot. For me it was 0x17800000. This is used as the parameter for the sb_loader -exec option below

on windows:

REM load u-boot image with register setup script

sb_loader.exe -nojump -f u-boot-ct200.imx

REM load linux kernel image

sb_loader.exe -trans 0x12000000 -f uImage

REM load initial RAM filesystem

sb_loader.exe -trans 0x12C00000 -f initramfs.cpio.gz.uboot

REM load device tree

sb_loader.exe -trans 0x18000000 -f imx6dl-ct200-ldo.dtb

REM start u-boot

sb_loader.exe -exec 0x17800000

after the -exec command the u-boot ran and booted linux up until it was waiting for a command to come across the link for the Freescale UTP protocol.