Has anyone used serial download to bootup imx6?

[EdSutter]

My (future) iMX6-based board will not have any removeable memory, so I need to be able to boot a raw board with the serial downloader.  I did a similar thing with the iMX53-QSB, but now I need to do it for the iMX6 (currently on the SABRESDB); however, apparently the iMX6 doesn't support UART-ish serial download (ARRGGHH!!), so the process is a bit more complicted (I think)...

Has anyone walked this path yet?

[ericmar81]

Sorry guys. May I check with you guys if anyone did try using Serial Downloader with UART interface instead?

I am using iMX53 and I am experiencing problem sometimes while trying to download the Boot code into the iMX53 processor.

Thanks & Regarads,

Eric

[EdSutter]

Eric,

This discussion was actually based on the iMX6 (imx6 does not support UART-based boot-download); however, I have done it with the imx53, and don't recall having any problems.  If I recall correctly, I was doing it with a uCon (http://www.umonfw.com/ucon) script conveniently.

What issues are you having?

Ed

[ericmar81]

Ed,

First of all, thanks for replying! I had actually posted on the following but yet to receive any reply for my issue.

https://community.freescale.com/message/503298

My board is working intermittently. There are 2 boards in my product, Board 1 (Control board) is with a Coldfire processor which acts as a host and sending the boot codes to the Board 2 (Display board) which has the iMX53 processor as the co-processor for handling graphic display. Sometimes the iMX53 is not responding to the GetStatus query form Board 1, which then fails the process to download the boot codes from Board 1 to Board 2. When such issue happens, we trigger a reset to power cycle the PMIC that supplies the power to the iMX53. We are not sure if such issue is caused by power management or baud rate mismatch.

The Serial UART connection between the 2 processors are of 115.2kbps. Do you know what is the default baud rate for iMX53 upon power up? Does the Automatic baud rate detection mechanism work even before there is any boot code is downloaded into the iMX53?

Thanks.

Eric

[EdSutter]

Eric,

Not sure what to say... I use 115200, and have not seen a problem.  Note my hardware is the IMX53qsb and I have the boot pins wired to powerup in UART-boot mode.

I use a PC COM port running 115200.

When you issue the GET-STATUS, are you appending 14 zeros to the message?

The complete message should be (Ahex): 0505 0000 0000 0000 0000 0000 0000 0000

Ed

[ericmar81]

Ed,

Yes. We do append 14 zeros to the mesage. Below is what we captured during a successful communication between the 2 boards.

When Board 1 is sending out (CTRL_TX) the GetStatus query, the baud rate seems to be in 114200bps (1/8.75us).

But when Board 2 responses back (DISP_TX), the baud rate seems to be in 117647 bps (1/8.5us).

Not sure if there is anything wrong with the baud rate difference.

Eric

[EdSutter]

All of these thoughts you've probably pondered/tested already...

- Does this happen on all board sets?

- Have you verified the frequency of the clock source from which the UART's baud rate is derived?

- Common ground between boards?

- Are there voltage converters used here or are you running board-to-board directly?  If the latter, are

  the voltage levels the same?

- etc...

Sorry, I know most of this is obvious, just wanna make sure...

[ericmar81]

- Does this happen on all board sets?

--> No all boards but random units.

- Have you verified the frequency of the clock source from which the UART's baud rate is derived?

--> Yes. Clock source does not show anything abnormal. Frequencies are correct.

- Common ground between boards?

--> Yes.

- Are there voltage converters used here or are you running board-to-board directly?  If the latter, are

  the voltage levels the same?

Voltage converters are used. Voltage levels are the same.

[EdSutter]

Can't think of anything else; except maybe to isolate the two boards and use an external host to pump your iMX53.

Also, if you haven't already seen this, you may want to mention your problem to the guys on this post...

Exercising the i.MX Serial Download Protocol with a Python Script

IIRC, that python script is what  I based my uCon script on.

Ed

[ericmar81]

Ed,

Thanks for your suggestion. Will definitely try isolatiing the two board.

By the way, can I also check with you something?

1. When you connect uCon to the port at 115200 and then powerup your iMX53QSB in UART-boot mode, do you always communicate with it successfully on first try?

2. How do you know the iMX53QSB is connected and ready to be downloaded? Do you wait for a few seconds before you try communicating? Do you always start with Get Status command too in your script?

3. How did you connect the Receiver pin of other unused UART ports? Leave them floating or Pull High/Low?

Thanks & regards,

Eric

[EdSutter]

Eric,

1. I can't recall it ever failing.  This was a while ago, so I just blew off the dust from the board and powered it up and reset/downloaded it about a half-dozen times and all is well.

2. No protocol here.  I just reset the board (with uCon connected to the port) and about a second later start the script.

3. However they are configured on the QSB is how they are for me.

Ed

[ericmar81]

Ed,

May I know how do you reset your board? Do you power cycle it or there is a button for you to reset?

Can you try power cycle it and see if you always able to communicate and download successfully?

What I do here is the worst case which I power it up and then sending Get Status command after 2secs. If I do not receive a response, I will power it down for 1sec and the power up again to try again. I am using a benchtop power supply to power up my board instead of using AC adapter.

Thanks.

Eric

[EdSutter]

I was (in previous test) just hitting the reset button.

To test for you, I just ran through about 10 cycles of:

1. remove power (AC adapter) at the board

2. re-insert power

3. hit "power" button

4. run GET STATUS command

5  receive f0f0f0f0

It never failed.

[ericmar81]

Ed,

Thank you so much for your help.

It is interesting to learn that the iMX53QSB is so robust.

I will try the uCon script that you provided me previously and also the python script to see if my board behaves differently.

Thanks & regards,

Eric

[EdSutter]

No problem.  Let me know what you figure out.

Personally I really like it when these SOCs provide the UART boot option.

I have been working with the iMX6 recently, and it (as you can read from the top of this

discussion) doesn't support simple UART-boot mode.

I know its a bit slower than the other interfaces, but simplicity is still a wonderful thing IMHO.

Regards,

Ed

[ericmar81]

Ed,

Could you please share with me how you use the uCon to do the Serial downloader through UART for iMX53?

Did you write a script to do it?

Thanks.

Eric

[EdSutter]

Eric,

Yea, I use a script.

I just connect uCon to the port at 115200, then powerup the iMX53QSB in UART-boot mode.

Then I run the script below.  It installs a ram-based version of Micromonitor (i can send you

that image if you wanna test it).

HTH

Ed

# This uCon script is used to transfer an program image to an iMX53

# Quick Start Board (QSB) that is waiting to be booted through the

# serial download protocol using a UART.

CLS

GOSUB SETUP

GOSUB GET_FILE_LOCAL

GOSUB WRITE_IMAGE_USING_SDP

EXIT

# SETUP:

# Change these parameters as needed...

SET FSENDFILE  ramtst.bin

SET ADDR F8006000

SET DS 20

RETURN

# GET_FILE_LOCAL:

FILE size $FSENDFILE

IF $FILE seq NULL GOTO LOCAL_FILE_FAILURE

SET FSIZE $FILE

IF $FSIZE ge 0x19fff GOTO FILESIZE_FAILURE

SET DLEN=hex8($FSIZE)

RETURN

# WRITE_IMAGE_USING_SDP:

ECHO "\r\nWRITE FILE: ADDR=$ADDR, DS=$DS, FILE:$FSENDFILE, SIZE:$FSIZE"

RECV blkinit

LOG screenoff

SEND -nx 0404${ADDR}00${DLEN}00000000AA

SLEEP 1000

LOG screenon

RECV -a blkcpy

IF $RECVBLKTOT ne 4 goto WRITE_FAILURE

IF $RECVBLOCK sne 56787856 goto WRITEFAIL

CONFIG dbc 0

SET ODBC $CONFIG

FSEND $FSENDFILE

CONFIG dbc $ODBC

SEND -nx 05050000000000000000000000000000

ECHO Done

RETURN

# WRITE_FAILURE:

ECHO WRITEMEM Failed.

EXIT

# LOCAL_FILE_FAILURE:

ECHO File: $FSENDFILE not found.

EXIT

# FILESIZE_FAILURE:

ECHO Incoming file is too big to be put in iRAM space.

EXIT

[EdSutter]

After a few days of sniffing around, I think I have a better grasp on this problem, so I'll just post a reply to my question (adding a new question) here just in case others walk this path...

Whenever possible I like to have the option to "de-brick" a board without the need to plug in some kind of JTAG-ish device; hence the reason for this question.  The iMX53 (and others) has a nice-and-simple UART-based mechanism for doing this; but for some reason that mechanism is not available on iMX6 (ARRRGGHH!!!).  I was figuring that there must be some way to just do that same thing, but now over USB instead of a UART.  As far as I can tell, the only way to do this is with the mfgtool2.

The mfgtool uses an xml file to guide its path to basically allow you to do the following:

1. Put your board in "boot-from-USB" mode (usually via dip-switch).

2. Reset your board.

3. Run mfgtool and click the "START" button to kick off a "LIST" of steps specified in an xml file.

The steps go something like this:

a. Download u-boot

b. Download a minimal kernel and FS.

c. Allow the target to start up, and assume u-boot will know how to launch the previously loaded OS.

d. The OS starts up and it then talks to mfgtool over USB to complete the steps of formatting memory

    and installing the images into non-volatile space.

e. The LIST of steps completes and mfgtool says "Done" (this too is script driven).

Nice, but all I want to do is push a bootloader into RAM and start it up.  So, I use a LIST as follows:

<CMD state="BootStrap" type="boot" body="BootStrap" file ="u-boot-mx6q-sabresd.bin" >Loading U-boot</CMD>

<CMD state="BootStrap" type="jump" > Jumping to U-boot. </CMD>

This successfully puts u-boot in RAM and starts it up, but the script never gets passed the "BootStrap-Jump" because (apparently) its waiting for some USB-ish interaction with the OS.  So, while I can use this, I'd like to have the tool complete successfully.  Is there a way to do that?  I could hack the mfgtool source, but if there's already a way to do this, that would be better.

[sinanakman]

Hi Ed, I do this regularly with our board without any problem. Are you receiving any type of error ?

Please make sure you set the internal mode with the dip switches. At this point if the board is not able to boot or if the flash is empty lsusb should list the USB ID of your board (in my case it i 15a2:0054).

At that point you should run ./imx_usb u-boot.bin

(u-boot.bin from freescale or if you built a mainline u-boot then use u-boot.imx)

Once you have the u-boot coming up you can erase the flash and reprogram again.

To boot back from the flash you need to set the switches back to USB mode.

Hope this helps

[EdSutter]

Sinan,

Thanks for the quick reply.  Note, that the download of u-boot is successful (I've traced through this by running mfgtool2 in VS2008).  After the "JUMP" command (in the xml file) I am able to access the running u-boot console; however, the mfgtool doesn't complete (i.e. the button doesn't go back to "Start").  Does this happen to you?

Further, you mention a few tools that I'm not aware of...

What are "lsusb" and "imx_usb"?

<EDIT>

RULE: always google before asking questions... :-(

Found them...

</EDIT>

Ed

[sinanakman]

Hi Ed, I think I don't use the same tools, what I use is all command line, there is no XML etc. That lsusb is Linux tool that lists the USB devices connected. I probably grabbed the imx_usb from the board manufacturers web site (Boundary Devices). It runs on Linux, I can send you my executable to you if you like.

Alternatively as you mentioned, you can actually access the u-boot console, are you able to simply erase the flash and reprogram a new u-boot? Despite the button does not go back to "Start", perhaps you are just fine that you can upgrade a working u-boot and boot properly.

Let me know if you need the Linux tool I am using, I can zip the bin file and send it to you.