questions regarding initial booting of OMAP 35x

burchmere said:

I have several questions regarding initial booting (nothing in flash) of the OMAP 35x, some specific to the EVM and others specific to a new design based on the OMAP35x.  If there is documentation that details this area of functionality, please let me know.

I would suggest reviewing the TRM (SPRUF98), specifically Chapter 25 entitled Applications Processor Initialization.  This section discusses the booting process for all boot modes.  Regarding the EVM specifics, the OMAP35x EVM Getting Started Guide provided with the Linux BSP is a good resource for many of the questions below.  This document literature number is SPRC655.

burchmere said:

1.  Does the DownloadUtility.exe only work with a COM port, or will it work with a USB port?

Yes, it only support UART mode.  It does not support the USB port.

burchmere said:

2.  Is source code available for DownloadUtility.exe?  If so, can the source be built for Linux?  Why is it only available for Windows?

No, the source code for DownloadUtility.exe is not available.

burchmere said:

3.  Does the DownloadUtility.exe automatically download "dnld_startup_omap3_evm.bin" to the OMAP prior to downloading u-boot.bin?  (The SDK-0.9.5 explicitly calls out this file as the "secondary image" while SDK-1.0.0 does not.)  Can you give the sequence of events when using DownloadUtility.exe for peripheral booting via UART3?  Is the sequence different between 0.9.5 and 1.0.0?

Yes, the DownloadUtility.exe automatically downloads "dnld_startup_omap3_evm.bin" to the OMAP35x prior to downloading u-boot.bin.

The steps for using DownloadUtility.exe is detailed in the OMAP35x EVM Getting Started Guide (SPRC655) in Section 5.3.

burchmere said:

4.  What is the significance of the "40T" that is sent to the terminal program when S2 of the EVM is pressed?

The 40T that is sent by the OMAP35x tells the DownloadUtility.exe running on the host that the device is present and ready to begin downloading.

burchmere said:

5.  During peripheral booting, is it necessary to have a first stage loader (like x-loader) for the same reason it's necessary during memory booting?  (The reason being that the internal memory isn't big enough to hold the u-boot image?)  Or could u-boot.bin be downloaded directly (as seems to happen when using SDK-1.0.0 DownloadUtility.exe)?

Yes, it is necessary to have a first stage loader small enough to fit in internal memory.  The rom code of the OMAP35x, which is what enables the peripheral booting, does not make any assumptions on what DRAM memory is used.  Therefore, it does not initialize the SDRC which would enable larger sized bootloaders.

u-boot appears to be downloaded directly because DownloadUtilitiy.exe actually downloads the dnld_startup_omap3_evm.bin first.

Thanks for your help.  A few follow-up questions:

Can the DownloadUtility.exe source code be made available?  Otherwise I guess I'll have to dig into dnld_startup_omap3_evm code to determine what functionality to build into our own equivalent to DownloadUtility.exe (that we intend to use in an automated process during a late stage of manufacturing).  Is some type of automated process typical for first-time booting/flashing of OMAP-based products coming off the manufacturing line?

At this time, no, the DownloadUtility.exe source code will not be available.

I would say that yes, either the boot from UART or USB is a method to use for intial flashing on the manufacturing line (or just off the manufacturing line).

If your product uses a managed NAND device like eMMC, or similar, the boot from SD/MMC option is available and you could likely flash the eMMC using other means as well.

We are considering using eMMC memory as our only flash storage.  You suggest that the eMMC could be flashed using some other means - but I'm not clear on that.  Can you outline the initial boot sequence and initial eMMC flashing process, assuming the flash is blank on a board fresh from manufacturing?  We'll have console access to UART3 and eMMC connected at MMC2.

This could be difficult to do as I do not believe U-Boot has the capability to format a MMC card, though you do have the source so you may be able to write in a command to do so.

I would suspect you would use the serial loader utility to load a customized U-Boot on to the board and then use that U-Boot to format and write your images to the MMC (likely loading the images over Ethernet/TFTP).

If you could access the eMMC before mounting to the board it would be easiest to format and write your images to the eMMC on a PC, of course having a method to recover once the eMMC is mounted would also be a handy.

I presume there are alternative ways to program eMMC.  Either pre-programmed, or via something like a bed-of-nails fixture which requires the I/O on the OMAP35xx to be in a high-impedence state.  The test fixture could then drive the eMMC signals directly to program the device.

Hi,

I have exactly the same problem... We are designing a system that will boot from eMMC and has no NAND and no SDCard slot. We use MMC2 port of the DM3730. Currently we don't know how to flash our eMMC... How can we flash it?
Have you some idea?

Thanks in advance,

Best Regards,

Pierre

Pierre,

As Bernie mentioned you should be able to use the FlashTools to load u-boot in RAM.

You will have to adapt the target parameters to your own board. It might be easier to start with a development board that is by default supported by the flash tools like the DM3730 EVM or the Beaggle board and then progress step by step.

The Flash tools 1.6 user's guide is available online:
      http://processors.wiki.ti.com/index.php/Flash_v1.6_User_Guide
See the below section to use with the DM3730 EVM. Modification might be needed for other boards:
         Example 1:  Flashing the AM/DM37x Evaluation Module (2.6.37 Kernel)

Hope it helps.

Anthony

Hi Anthony,

thanks for your help. Indeed I tried a lot of combination with Flash V1.6.0.0 and it works from this morning !! :-)

Here it is the configuration that I used for Beagleboard-xM:

• Choose Target : AM37xx(Micron)
• UART
• desired memory type : SDRAM
• Choose operation parameters : Download and execute
• Offset : 0x00008000
• Image Selection : u-boot.bin

In fact the value of the offset is very important because I tested a long time by leaving 0 and therefore that did not work.

Thanks,

Pierre