Vybrid Mfg_Tool Released

[RossMcLuckie]

Hi all,

Thought this was worth a new separate thread, appreciate over time there have been several threads on this topic, but hopefully this is the last.

The Vybrid GA release of the Mfg_Tool is now available for download on freescale.com, can find a link to it on any of the VF6, VF5 or VF3 web pages, under the Software & Tools tab, Programmers section.

e.g. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx&fpsp=1&tab=Design_Tools_Tab

Support is for TWR board, A5 only, SD, NAND and QuadSPI (parallel mode not supported), uBoot source for customisation included in the archive, there are no further development plans at this time, this is currently expected to the the final Vybrid Mfg_Tool release.

Regards

Ross

[kef2]

Hi Ross,

is it possible to pipe two files to nand? I have this in specific *.xml profiles file:

<CMD state="Updater" type="push" body="nandinit addr=0x80000">Initializing NAND</CMD>

  <CMD state="Updater" type="push" body="pipenand addr=0x80000" file="files/u-boot-nand.vybrid">Sending and writing NAND U-Boot</CMD>

  <CMD state="Updater" type="push" body="pipenand addr=0xE0000" file="files/mtd1">Sending and writing ENVIRONMENT</CMD>

I see this on serial console:

---------------

nandwrite 80000 0x3f41d954 10000

Flashing image @ 0x3f41d954; size 65536 to 0x80000

Erasing 0x80000

after write to nand flash

utp_handle_message: Sending UTP_SS_BUSY

Type 0x0, tag 0x00000002, param 0

Type 0x3, tag 0x00000002, param 1

utp_handle_message: PUT, 65536 bytes

got data chunk, size: 10000

blkcnt: 20, index: 20, bufsize: 10000

nandwrite 90000 0x3f41d954 10000

Flashing image @ 0x3f41d954; size 65536 to 0x90000

after write to nand flash

utp_handle_message: Sending UTP_SS_BUSY

Type 0x0, tag 0x00000002, param 0

Type 0x3, tag 0x00000002, param 2

utp_handle_message: PUT, 65536 bytes

got data chunk, size: 10000

blkcnt: 20, index: 40, bufsize: 10000

nandwrite a0000 0x3f41d954 10000

Flashing image @ 0x3f41d954; size 65536 to 0xa0000

Erasing 0xa0000

after write to nand flash

utp_handle_message: Sending UTP_SS_BUSY

Type 0x0, tag 0x00000002, param 0

Type 0x3, tag 0x00000002, param 3

utp_handle_message: PUT, 56880 bytes

got data chunk, size: de30

blkcnt: 1c, index: 60, bufsize: de30

nandwrite b0000 0x3f41d954 de30

Flashing image @ 0x3f41d954; size 56880 to 0xb0000

after write to nand flash

utp_handle_message: Sending UTP_SS_PASS

Type 0x0, tag 0x00000002, param 0

Type 0x1, tag 0x00000003, param 0

utp_handle_message: EXEC

utp_exec: pass

/Type 0x0, tag 0x00000003, param 0

Type 0x1, tag 0x00000004, param 20000

utp_handle_message: EXEC

addr: 0xe0000

utp_exec: pass

Type 0x0, tag 0x00000004, param 0

Type 0x3, tag 0x00000004, param 0

utp_handle_message: PUT, 65536 bytes

got data chunk, size: 10000

blkcnt: 20, index: 7c, bufsize: 10000

nandwrite 11e000 0x3f41d8f4 10000

Flashing image @ 0x3f41d8f4; size 65536 to 0x11e000

after write to nand flash

utp_handle_message: Sending UTP_SS_BUSY

Type 0x0, tag 0x00000004, param 0

Type 0x3, tag 0x00000004, param 1

utp_handle_message: PUT, 65536 bytes

got data chunk, size: 10000

blkcnt: 20, index: 9c, bufsize: 10000

nandwrite 12e000 0x3f41d954 10000

Flashing image @ 0x3f41d954; size 65536 to 0x12e000

--------------

U-boot programs well, you may see 4 chunks of data up to 64k bytes long to 0x80000, 0x90000 and so on.

What I can't understand why mtd1 file, which is supposed to go to 0xE0000, seems being programmed to 0x11e000?

I'm going to find a way to program whole nand in one MfgTool programming step. Do I need to combine all my files to single file and program it? It is not possible to call MfgTool several times to program each partition separately. U-boot, which comes with MfgTool has following line in vf610twr_nand.h and thus has to be recompiled.

#define CONFIG_BOOTCOMMAND "nand erase.chip; ums 0"

Every time

[juangutierrez]

Not sure why it goes to 0x11e000 intead of 0xE0000.

I think what you can do is to program in two steps:

First program the u-boot using a prfile like:

<CMD state="Updater" type="push" body="nandinit addr=0x80000">Initializing NAND</CMD>

<CMD state="Updater" type="push" body="pipenand addr=0x80000" file="files/u-boot-nand.vybrid">Sending and writing NAND U-Boot</CMD>

And then program the mtd using a different profile like:

<CMD state="Updater" type="push" body="nandinit addr=0xE0000">Initializing NAND</CMD>

<CMD state="Updater" type="push" body="pipenand addr=0xE0000" file="files/mtd1">Sending and writing ENVIRONMENT</CMD>

Also combininig in one single file I think should work

[kef2]

Dear Juan Antonio,

perhaps I was not clear, but it is not possible to write two binaries to NAND in two sessions. U-boot used by MfgTool2 erases all NAND memory, it is not controllable by *.xml profile settings.

I'd like to save manufacturing time not programming unused memory holes, which may be quite big.

Regards

Edward

[juangutierrez]

Well, one option is to rebuild the u-boot image with the change below:

     -  #define CONFIG_BOOTCOMMAND "nand erase.chip; ums 0"

     + #define CONFIG_BOOTCOMMAND "ums 0"

This way the nand is not erased at start. If you still need to erase the nand, you can add a line on your script as:

    <CMD state="Updater" type="push" body="ubootcmd nand erase.chip">Erase nand</CMD>

But, actually, inspecting the code it seems the problem with the wrong address (0x11E000) is because the destination address is computed as follows

dest = pinfo.addr + pinfo.blksz * pinfo.index

due to the previous write the pinfo.index has a invalid value, but that should be reset when calling the nandinit.

So I think if you place the next lines in the SAME script, it should work

<CMD state="Updater" type="push" body="nandinit addr=0x80000">Initializing NAND</CMD>

<CMD state="Updater" type="push" body="pipenand addr=0x80000" file="files/u-boot-nand.vybrid">Sending and writing NAND U-Boot</CMD>

<CMD state="Updater" type="push" body="nandinit addr=0xE0000">Initializing NAND</CMD>

<CMD state="Updater" type="push" body="pipenand addr=0xE0000" file="files/mtd1">Sending and writing ENVIRONMENT</CMD>

The nandinit should reset both pinfo.addr and pinfo.index

[kef2]

Hi

Trick with nandinit doesn't work. It does something almost good pushing two files, but fails pushing 3 or more. Nandinit writes FCB struct to NAND block 0. Doing nandinit 2x or more times, needs erase of block 0 before doing 2nd and further nandinit's. I tried adding nand erase 0 0x20000, but looks like it is ignored, page 0 gets wrong checksums and u-boot doesn't boot.

It would be nice if someone fixed these issues.

Edward

[RossMcLuckie]

Hi Edward,

Yes, multiple file pushes should work fine, that's how we do it in iMX land, but the mechanics here are different, in iMX we load a full kernel and file system into DDR and them use 'dd' to program the numerous files, but we had to take a different approach with Vybrid, but I don't know the details personally, juangutierrez can you help out on the details here?

Thanks

Ross

[kef2]

Dear Ross

It is not supposed to work as is with VF3, right? I tried flashing led demo to QSPI on our VF3 board. After loading bootstrapper and jumping to OS it hangs with both progress bars stucked in middle. No activity on QSPI. Looks like uboot.vybrid should be modified for VF3 and build under proper linux environment, which I don't have and don't know how to make or install :-(.

uboot.vybrid seems beind made to be loaded to 0x3F000000 in RAM and executed from here. I tried substituting it with my own loader, which works fine while debugging, but mfgtool complained with "Boot" body="BootStrap" error, file="... Any guide how I could made my own *.vybrid file? Loading it via USB and executing is all what is required.

Thanks

Edward

[MehmetAliIpin]

Dear Edward,

We are also using VF3 and we succeded to program the QSPI and run it with QSPI boot mode. We just built our project with quadspi_boot.c and quadspi_boot.h files and copied our .bin file in MFGTool kit's profile ..files directory, and modified ucl2.xml file (changed led_bin to our .bin); programmed the flashes in serial mode, then changed boot mode to qspi boot, then reset, we see our messages on display...

Best regards.

[kef2]

Dear Mehmet Ali,

thanks for reply. Looks like the problem is the difference between serial boot and QSPI boot failure mode, which makes boot ROM switching to serial boot. Prior to seeing your reply, I tried MfgTool with Vybrid Tower card. QSPI programming succeds with BOOTMOD set to serial boot and fails programming when QSPI is blank and boot mode is QSPI. In this 2nd case MfgTool sees HID device, starts UBOOT, but fails to program QSPI. Looks like *.vybrid file doesn't take into account that QuadSPI registers can contain weird settings after unsuccessful QSPI boot.

[Edit]

Looks like MfgTool fails with program verify in case Spansion chip is blank and QUAD bit =0 (factory default). MfgTool seems programming well indeed, but reports failure. After power cycle it programms and verifies well

Looks like I need jumper for BOOTMOD on my board.

Regards

Edward

[RossMcLuckie]

Hi Edward,

Assuming you are not familiar with Mfg_Tool and our iMX products. As you have discovered it is used with serial mode, so technically you'll need to have BOOTMODE pin connections. Attempting to boot from QuadSPI memory that is blank will result in unpredictable results as the necessary configuration block read by the ROM code will make no sense.

One useful addition to Vybrid over iMX, you can set your board to boot from fuses via BOOTMODE, effectively the intended production mode. However since virgin parts will not yet have their fuses programmed it will default to serial mode even with BOOTMODE set to boot from fuses, this then lets you use Mfg_Tool, or equivalent to program the board NVM and then fuses, so on next power cycle the board will successfully boot from fuses, allowing you to use the Mfg_Tool for production programming and not requiring to change your board settings.

However if you are not using fuses and plan to boot from the GPI pins this option isn't open to you and you will need to use the BOOTMODE pins, for production set up you could look to use a bed of nails test jig or similar if you want to avoid changing board configurations.

Our release is intended to support the TWR board, nothing more, depends on how different your set up is from the TWR whether you'd need to create your own uBoot or not, if you do then all that should be available and explained on Timesys' website.

Regards

Ross

[kef2]

Hi Ross,

Fuses are write once and thus dangerous.

I would agree with you regarding necessity of BOOTMODE=serial setting if boot ROM didn't jump to serial download mode. It is just a matter of few more QuadSPI registers settings in *.vybrid bootstrapper and it would work also for BOOTMODE=rcon, RCON=quadspi, quadmemory=blank. It doesn't make a lot of sense to use mfgtool only with Vybrid Tower card. Onboard or external debug adapter makes more sense here. But OK, thanks for your answer.

Regards

Edward

[RossMcLuckie]

Sorry if you misunderstood me, Mfg_Tool could be used for ANY platform, OUR release is intended for the TWR only, i.e. that is the only platform we have to test on. We provide the uBoot source to allow customisation, but that is up to the customer, Freescale doesn't support this work, too many variables, differing boot devices and interfaces, differing parts requiring modified algorithms, using different interfaces, e.g. SD card connected to different interface, etc, we have built and tested our release on TWR and that is all we support, customisation is down to the customer, but the same principle can be applied to any board.

What Mfg-Tool provides is a way to program your boards with no need for additional tools, not even a JTAG adapter, many customers like to build their production boards without a JTAG connector now, save on cost/space, if your application uses USB0 in OTG or device mode then you can program your board with virtually no additional overhead.

But as you say, each customer is different and why we try to provide choices, no right or wrong way as long as you get what you need working J

Ross

[kef2]

Thanks