AM1705 ARM-UBL Source Code

1,2) You should be able to use the source from the PSP. Just make sure that the oversampling and dividers end up giving the correct 115200 baud rate.

3) Do you only get that error you get when you try to connect to CCS after booting in NAND flashmode? If you reset the device then the error goes away and you can connect?

4) In order to boot U-boot, a magic number header must be flash with U-boot. The ARM UBL will look for this magic number at a predefined offset in the flash. The issue was the magic number flashed by the serial tool differed from the one expected by the ARM UBL.

5, 6) You should be using the AM1707 target type. Can you use the -V option to check if there were any errors?

Jeff

Jeff,

I really appreciate your support. For the most part, I've resolved my issues through trial and error.  If you have a moment, please sanity check my findings. They may apply to other AM1705 users trying to utilize the existing psp components as well as the OMAP-L137_FlashAndBootUtils.

Firstly, the OMAP-L137_FlashAndBootUtils_2_20 utilities are great, when used properly. Hopefully my ramblings will go beyond stating the obvious and help new users get up and running sooner. I personally spent a good deal of time determining changes required to get the tools to support the AM1705 (and my board configuration). The majority of this time was spent stuck on "Waiting for SFT on the omap-l137" and trying to determine the development flow. 

jc-ti said:

3) Do you only get that error you get when you try to connect to CCS after booting in NAND flashmode? If you reset the device then the error goes away and you can connect?

When I first connect and "Debug Active Project" I get the described error. If I halt the processor and execute a "Restart," I do not continue to get the error. In the interest of full disclosure, we are using a reduced JTAG header with EMU0 and EMU1 pulled high. 

jc-ti said:

4) In order to boot U-boot, a magic number header must be flash with U-boot. The ARM UBL will look for this magic number at a predefined offset in the flash. The issue was the magic number flashed by the serial tool differed from the one expected by the ARM UBL.

After doing some digging, I realized that the AISgen tool forces the correct magic magic number(0x41504954) at the start of the output image (ARM_UBL_AIS.bin). I believe the SFH tool takes care of building the application header for U-Boot that the ARM UBL is looking for. 

jc-ti said:

5, 6) You should be using the AM1707 target type. Can you use the -V option to check if there were any errors?

When using the AM1705 processor there are some conflicts in the generated sft_AM1707_NAND.bin or sft_AM1707_SPI_MEM.bin images. For the sfh_OMAP_L137.exe to work properly with the AM1705, some changes need to be made to the sft source. These include the following:

OMAP-L137/Common/src/device.c : DEVCIE_init()

    #if defined(AM1707)

    // CPU(s) at 456 MHz

     status |= DEVICE_PLL0Init(0, 18, 0, 3, 3, 5, 441);

//status |= DEVICE_PLL0Init(0, 24, 1, 2, 2, 5, 441);

    #else

    // CPU(s) at 300 MHz

    status |= DEVICE_PLL0Init(0, 24, 1, 2, 2, 5, 441);

    #endif  

This will force AM1705 processors, using the AM1707 targetType, to initialize the PLL to an incorrect multiplier(assuming 24Mhz input). To my understanding, the AM1705 is operational at a maximum frequency of 300 MHz. For proper bring up, make sure the CPU is running at 300 MHz. 

It is also worth noting that if your board has a different SDRAM than what the EVM uses, update the parameters passed in to DEVICE_ExternalMemInit(...) to match your timing requirements:

  // External Memory Timing Setup

  if (status == E_PASS)

  {

    status |= DEVICE_ExternalMemInit(0x00018421, 0x10912A08, 0x70090005, 0x000003FA, TRUE);

  }

Finally, make sure you have updated the UART_config settings to match your device. If you are running at 300Mhz, the proper divider is 81. That means the "#elif defined(AM1707)" has the incorrect value for a AM1705 running at 300MHz with a desired baud rate of 115200.

OMAP-L137/Common/src/device_uart.c :

  const UART_ConfigObj DEVICE_UART_config = 

{

 UART_OSM_X16,         // osm

  UART_PARITY_NONE,     // parity

  UART_STOP_BITS_1,     // stopBits

  8,                    // charLen

#if defined(OMAPL137_v1)

  41                    // divider

#elif defined(AM1707)

  123 // divider

#else

  81                    // divider

#endif

};

And, define the proper UART boot peripheral number for your board.

OMAP-L137/Common/src/device_uart.h :

#define DEVICE_UART_PERIPHNUM         (2)

Once all these changes have been made, rebuild sft_AM1707_NAND.bin, sft_AM1707_SPI_MEM.bin, sfh_OMAP_L137.exe and slf_OMAP_L137.exe. From what I could tell, these executables link the target images statically. Making changes to the sft source code and rebuilding does not impact what is loaded on to the target unless the .exe utilities are rebuilt (make clean). 

When you have rebuilt the tools, write yourself a script (batch file) to invoke sfh_OMAP_L137.exe properly:

sfh_OMAP-L137.exe -v -p COMx -targetType AM1707 -flash -flashType NAND your_arm_ubl_ais.bin your_u_boot.bin 

Where:

-p COMx - equals your host COM

-targetType AM1707 - This will work for the AM1705 if you have made the above described changes.

-flash - This means you want to load an ARM UBL and application image (U-boot, or whatever you choose).

-flashType NAND - or omit this parameter for SPI_MEM.

your_arm_ubl_ais.bin - This should be your custom ARM_UBL.out image ran though AISgen tools with the proper board settings. This will ensure that you have a "proper" ubl image with the correct magic number. 

your_u_boot.bin - This should be the binary image of your desired application image. It does not need ran through the AISgen tools. 

Good luck,

Andrew Foster