Serial Download Example/Instructions or Tool?

[Michael_ng]

Need to be able to use the serial download (micro usb for example) to boot new executables rather than loading them onto the micro SD...any guidance help would be appreciated.

[nedkonz]

There is also the Boundary Devices imx_usb_loader (see http://trac.gateworks.com/wiki/ventana/serial_downloader ) which will run from Linux and can start (for instance) a properly compiled u-boot image.

[rajansrivastava]

Is SDP (serial download protocol) Freescale proprietary protocol or an open source or something else?

Regards,

Rajan

[lily_zhang]

SDP protocol is adopted into i.MX ROM. Regarding the protocol description, you can get the information from SoC RM "8.8.2 Serial Download protocol".

[rajansrivastava]

Thanks Xiaoli, the section that you told provides good details of SDP.

Has SDP been developed by FSL? I couldn't find this information in i.MX6 RM and also I couldn't find any RFC or standard for SDP on Internet? Can you please help me on this matter as well?

Regards

[lily_zhang]

It’s the protocol defined by FSL. So you can get the information from FSL SoC RM and Boot relative documents.

I downloaded MX6DQ SoC RM from FSL web site. It includes the section “8.8.2 Serial Download protocol” in “Chapter 8 System Boot”.

In additional,  When ROM download firmware to the board and the host starts to communication with MFGTool RAM firmware, the protocol adopted is named as UTP. The introduction about UTP is located under MFGTool document folder.

[rajansrivastava]

Thanks Lily for complete answer.

[Michael_ng]

I'll double check that..but (for example) when capturing the traffic for the MfgTool as it set up and loaded a Linux variant the first command to send was 020253FA855420000000000030000000...the reason I tried to put in DEADBEEF was to see what was going on since it didn't seem like the 00300000 wrote into the memory properly.  However, since this I have been able to set up RAM properly and write to it, copy it back and confirm it is correct and jump properly receiving the 88 88 88 88 code.

Thanks.

[FlorentAuger]

I think it's probably time to read the i.MX reference manual...

0x53FA8554 is a register where most of the bits are not writable !!!

[Michael_ng]

If I do:

write_mem 0x53fa8554 -32 0xDEADBEEF    (for example)...the write says it works...

then

read_mem 0x53fa8554 -32 4 out.txt    the result says:

00 28 00 20  ?

Florent Auger said:

You can't use hex number without starting with 0x:

python iMX*.py write_mem 0xd1002040 -32 cc058077   => nok

it must be:

python iMX*.py write_mem 0xd1002040 -32 0xcc058077   => ok

otherwise you'll have to change the script to accept both.

0xD1002040 is part of the SDRAM chip select CSD1, is there any memory there? If not, you can not write there.

After a write, the i.MX sends an acknowledge, as long as it is received, it means the processor is ready for the next command.

[Michael_ng]

I noticed that later about stripping the other 0x...thanks.  Yes, I think it's making sense now on the chip select.  I noticed the Mfg Tool does the write to addresses starting with 53fa8554 and moves through 63 and ends at 7000000 (RAM)...then that tool does a file write including the 0xd1002040 and other needed parts (IVT etc.).

Starting to make sense...thanks.

[FlorentAuger]

You can't use hex number without starting with 0x:

python iMX*.py write_mem 0xd1002040 -32 cc058077   => nok

it must be:

python iMX*.py write_mem 0xd1002040 -32 0xcc058077   => ok

otherwise you'll have to change the script to accept both.

0xD1002040 is part of the SDRAM chip select CSD1, is there any memory there? If not, you can not write there.

After a write, the i.MX sends an acknowledge, as long as it is received, it means the processor is ready for the next command.

[Michael_ng]

Getting there on the tool... I added a function to the script to set up the RAM needed starting with address 53FA8554, but every other write gives me the "unable to write" error?  I'm wondering if it's perhaps a timing issue?  I tried to put in a sleep for 1 second between the 1st and 2nd calls to write_mem but the 2nd call still gets the error?

Any thoughts?

Thanks,

Mike

Florent Auger said:

Mike,

The Serial Download Protocol can just write a memory location, that is memory mapped. A SD card requires a driver, and is not a memory directly accessible by the core. Therefore, you can't write directly to a SD, to a NAND flash, NOR flash, ...

This means that the write file must be done typically to a RAM location where the code will be executed: SDRAM, SRAM, internal RAM, NAND flash buffer,...

Actually, the file should be loaded at the same place than if it was loaded by the ROM code during boot. This address is the one given in the "Boot Data Structure" defined in the manual (7.6.1.2): "start: Absolute address of the image".

This is typically somewhere in the SDRAM, and hopefully the address where the code was linked.

[FlorentAuger]

Mike,

The Serial Download Protocol can just write a memory location, that is memory mapped. A SD card requires a driver, and is not a memory directly accessible by the core. Therefore, you can't write directly to a SD, to a NAND flash, NOR flash, ...

This means that the write file must be done typically to a RAM location where the code will be executed: SDRAM, SRAM, internal RAM, NAND flash buffer,...

Actually, the file should be loaded at the same place than if it was loaded by the ROM code during boot. This address is the one given in the "Boot Data Structure" defined in the manual (7.6.1.2): "start: Absolute address of the image".

This is typically somewhere in the SDRAM, and hopefully the address where the code was linked.

[Michael_ng]

Thanks Florent...one last question though..on the new page you mention Bootstrap_protocol.py write_file memory_address file to download the executable img...is this still writing the SD card or other media?  This will still work as a quicker solution than pulling the card out and doing a dd from my Linux based system but not bypassing the SD media..just want to be clear.

Thanks again for the script!

Florent Auger said:

To explain what could be done with the Python script, I created that page in this new group:

http://imxcommunity.org/group/tools-and-utilities/page/exercising-t...

I hope it will help. Note, that the manufacturing tool or AdvancedToolKit could be used as well. I'll try to deal with this later on.

[FlorentAuger]

To explain what could be done with the Python script, I created that page in this new group:

http://imxcommunity.org/group/tools-and-utilities/page/exercising-the-i-mx-serial-download-protocol-...

I hope it will help. Note, that the manufacturing tool or AdvancedToolKit could be used as well. I'll try to deal with this later on.

[Yuri]

Florent, please post the Python example. 

Florent Auger said:

The serial download protocol is documented in the System Boot guide of the reference manual.

You could possibly develop your own tool to simply initialize the memory, load the code, and execute it.

If your familiar with Python, I can send you an example that uses pyserial, so will use the serial port instead of USB.

Note that any file that is downloaded and executed through the serial download protocol must have a valid image vector table at the offset 0x0 of the binary. That one should have at least a valid header, entry and self address.

[Michael_ng]

Florent,

  Thanks for your post.  Yes!  Please send me the python example.  This is what I'm looking for.  I did look at the serial downloader protocol and in fact I used a USB protocol analyzer last night to capture the MfgTool's interaction with the board...it mapped out nicely (mostly) with the codes given in the serial downloader section and I'm much clearer on what I need to do in order to put an image straight into memory and execute.

I was able to identify the memory writes/ reads/ file writes and clearly identified the IVT header and the DCD that was used to initialize RAM.

Thanks for your response and I look forward to getting a copy of the pyserial.  Is the example set up for the iMX53 already or just a starting point to tinker with?

Mike

Florent Auger said:

The serial download protocol is documented in the System Boot guide of the reference manual.

You could possibly develop your own tool to simply initialize the memory, load the code, and execute it.

If your familiar with Python, I can send you an example that uses pyserial, so will use the serial port instead of USB.

Note that any file that is downloaded and executed through the serial download protocol must have a valid image vector table at the offset 0x0 of the binary. That one should have at least a valid header, entry and self address.

[FlorentAuger]

The serial download protocol is documented in the System Boot guide of the reference manual.

You could possibly develop your own tool to simply initialize the memory, load the code, and execute it.

If your familiar with Python, I can send you an example that uses pyserial, so will use the serial port instead of USB.

Note that any file that is downloaded and executed through the serial download protocol must have a valid image vector table at the offset 0x0 of the binary. That one should have at least a valid header, entry and self address.

[RandyKrakora]

Can you use uboot to load the kernel via the network ( tftpboot ) and run it? Or are you not wanting to run any code at all before your kernel? ( once set up, this would be easiest in my opinion )

I've not used the mfg tool much, but I thought there were config files that basically ran linux commands, I think there were a couple commands needed to load the mfg. kernel to communicate with the tool, but once past that they were all linux commands, so you could create a custom config to just load your kernel. There should be docs with the tool describing this, and you could use one of the base configs, copy it and modify it for this...but I would think tftpboot would be easiest...

[Michael_ng]

I've used the tool but the only options are to load the OS into one of the media (SD, eMMC...etc.)..what I Really want to do is to be able to skip that step and download via the serial connection straight to memory and have the OS start.  Also, when using the tool it seemed to work reasonably well for the first couple of steps and then gave me an error (Update Error 0x100).. I read the log but it was unclear to me what the issue was.  The other problem with the MfgTool is that it's Windows based and I'm doing my development on a Linux machine.  This is just another step in the process for trying to update the image.

Yuri Muhin said:

Please use the MFG tool 

https://www.freescale.com/webapp/Download?colCode=IMXMFG_TOOL&a...

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX5...