Anyone have experience using the UART as the BOOT device (using the serial download protocol)?

[EdSutter]

I modified my QSB so that I can install a jumper that will put the board in serial-bootloader mode (BOOT_MODE[1:0] = 11).  I've got a small bootloader built and fairly well tested that I would like to install into the imx's SRAM (using the serial download protocol) and run it.  I assume I need to convert the .elf file to a program image (as specified in section 7.6 of the reference manual).  Does anyone have any experience with any of this?

[FlorentAuger]

Ed,

I am impressed by your analyze. You are totally right.

The purpose of the DCD is to initialize the chip and some of the memories early in the boot procedure. It is just a chunk of data processed by the ROM code.

A plugin could do the same with more flexibility that offers real code, as it is somehow an extended and customized function of the ROM code.

For most of the devices, the plugin method overloads the boot code and is not needed. It is simpler to use a single IVT + DCD table.

Not entering in too many details about why u-boot uses the plugin method, it is actually recommended to use the above method for a secure boot, as it makes the signature process much more complex to prevent backdoors.

You can still revert to the common DCD method from an older version like:

http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/board/freescale/mx53_loco/flash_header....

Though, I suggest to ensure that the value to configure are the same than in the last u-boot, and if not to change them in the DCD table.

[EdSutter]

I'm trying to understand the flash_header.S code in u-boot as I'm reading section 7.  There are two IVTs, DCD pointers are null in both of them, and text implies that there are several downloads using SDP and the "host manufacturing application".  Then the UG refers to "MXC_DCD_ITEM" macros which are not-to-be found.  Is this explained anywhere?  Is this a typical example of how the imx53s boot?

I don't quite understand the need for the plugin and DCD code.  Sounds like the DCD is a block of code that should be executed to do boot-specific device initialization (DRAM in particular) and the plugin code just extends the capability of the rom bootloader to additional (more complex) devices.  Then, in the case of the u-boot flash_header.S code it appears that the plugin code is being used in the same way the DCD would be used.  Am I making any sense?

[FlorentAuger]

That is correct if the security configuration for boot is open (section 7.2.6 of the RM for more information), and if you are not validating a secure boot.

In the case of close configuration, the boot code must be authenticated prior to its execution. So, the CSF pointer must be set, and the CSF be part of the downloaded code.

In both cases, if the DCD pointer is NULL, it will not be processed, but will if present.

[EdSutter]

So, in the case of the bootmode == "serial downloader", the IVT apparently only uses the IVT header, entrypoint and self pointer correct?  Is there ever a case (in serial downloader mode) where other entries in the IVT are actually used?

[FlorentAuger]

Ed,

Right, the command must actually be Get Status. That's certainly not clear from the RM, but I never noticed that this was missing.

Thanks for the catch.

[EdSutter]

I managed to get booted through the serial downloader.  After spinning my wheels on the "Completed" issue above (I just use GetStatus after WriteFile) I'm now able to do a raw boot over the serial port. 

By the way, I'm just using a tool I wrote called uCon (http://www.umonfw.com/ucon) to do this, if anyone has interest in that lemme know.

Ed

[EdSutter]

I just joined "Tools and Utilities" group, and now see your instructions for using your python script say to do "Get Status" after the Writefile (instead of "Completed").  I'm not using your tool, just referring to the RM; hence, didn't see this.  Is this specified in some other documentation?

[EdSutter]

Florent,

I'm able to do all the various commands (GetStatus, Read/WriteMemory, WriteFile) except that I never get a response when I do a Completed after a WriteFile. My "Completed" command is just 16 arbitrary bytes, so I just tried replacing that with a GetStatus (05050000...) and then I get the expected 88888888 response.  Does this make any sense?

Ed

[FlorentAuger]

Ed,

The IVT can be added through a piece of code such what you find in u-boot. I sometimes do it manually in a binary with hexplorer for instance, as the IVT + boot data is made of 11 words of 32-bit...whose most are zero. The elf file gives the code entry point, the linker script the load address, etc

No, the empty 1k is not stripped off, this is typically to let that space for the MBR and file system related information of a SD card, hard drive,...

The branch to entry point instruction at offset 0x0 is a legacy of another boot mode for some previous i.MX. You can dismiss that.

Finally, I think it's time to read the reference manual for all the remaining questions you have on boot, and especially section 7.6 "Program Image" :-)

[EdSutter]

Ok, sorry I gotta RTFM... I see the offset, as explained in the RM! :-(

[EdSutter]

Ok, referring to the u-boot code, I see the file flash_header.S apparently constructs the IVT; however it appears to start at a 1K offset from the base of the u-boot.bin file.  Not quite sure what's up with that, but I assume that initial 1K (which appears to only have a branch-to-start instructino) is stripped off prior to loading it onto the SD card.

[EdSutter]

Florent,  thanks for the details.  Referring to step 1 in your response...

At this point, I'm looking for the easiest way to insert the IVT and boot data section into the final binary image.  Is there a standard way to do that or do I just do some post processing on the .elf (I've done a lot of that in the past) to insert the IVT/Bootdata onto the base of the binary image?

[FlorentAuger]

Any boot code must embed an Image Vector Table that helps the ROM code to localized the different bricks required at boot.

If this misses from the boot code or if the boot device is blank, the ROM code jumps to the serial download mode. So, that was probably not needed to tweak the QSB with a jumper.

You can find more details in the "System Boot" section of the reference manual.

1. Your bootmonitor.elf must contain that IVT and boot data section.

2. Moving from an elf to a binary is simple by using your ARM compiler objcopy command like:

arm-none-eabi-objcopy -O binary bootmonitor.elf bootmonitor.bin

3. When loading code to internal RAM at boot, the code can't be loaded anywhere. It has to be in the iRAM Free space which starts at 0xF8006000 (figure 2-2 in the manual). Otherwise, it overrides area reserved for the ROM code execution.

By using the mfgtool, you should be able to download and execute that code. A simple way to do that is to use a profile like this one in the ucl.xml:

<LIST name="DWLD_IN_SDP" desc="Download and execute a binary!">
    <CMD type="find" body="Recovery" timeout="180"/>
    <CMD type="boot" body="Recovery" file ="bootmonitor.bin" > Loading bootmonitor </CMD>

    <CMD type="jump" > Jumping to bootmonitor. </CMD>
</LIST>

The destination where the code must be loaded is specified in the IVT, so that the mfgtool uses it to extract the address automatically.

You can use other methods, such the python script that I posted some time ago.

[KrishnaPavan]

hi,

use boot load commands in LTIB. but a binary file has to be used.

[RandyKrakora]

You should be able to use the mfg. tool to do what you want, I think.

Look through the docs and the ucl files. You may even be able to find one out there that does exactly what you want. Basically, once the mfg tool downloads the special kernel and starts communicating with it, you can use linux commands ( in the ucl file ). I've not messed with it much, but I know some people have and get it to do lots of things. As far as converting your .elf file, there should be tools to do that as well.

[EdSutter]

Thanks! I was actually interested in getting more information on the whole process as well.

My assumption is the following...

1. I build some bootable image (call it: bootmonitor.elf).

2. Something (a tool or my own code?) converts the .elf to a "Program Image" file.

3. That file is transferred to internal SRAM using the serial downloader, and after the file is written to SRAM and the download is completed, the CPU retreives information from the headers at the beginning of the program image to start up.

Does that make sense?

By the way, I downloaded the mfg tool's source code, but the VS2008 build failed.  :-(  I've got a question to that group as well.

Thanks,

[RandyKrakora]

Someone here has a python script to download and run programs. You may be able to use the mfg. tool as well.

http://imxcommunity.org/group/imx53quickstartboard/forum/topics/serial-download-example-instructions...

I got it working in Windows by installing ActivePython ( with python 2.7 ) and pyserial 2.5. Had to modify the COM port in the script, but it works for talking to the imx53. Had to boot the imx53 QSB board without a uSD card installed, this dropped it into serial mode. I think you have 32 seconds to talk to the part then.

I think I had it working in my VM as well, with less effort.

-Randy