OMAP-L138 Booting from SPI ATMEL

Hi Ran Shalit,

I hope you have interfaced the SPI Flash according to the user guide which is avaialbale at the following URL

http://focus.ti.com/dsp/docs/litabsmultiplefilelist.tsp?sectionId=3&tabId=409&literatureNumber=sprab41c&docCategoryId=1&familyId=1621

Looks the constraints specified in above user guide are met by your device,  24-Bit addr and support a read command value of (0x03).

I hope you are not using any chip select other than CS0.

Regards,

GSR

I agree with 1258021(aka GSR). The read command (0x03) is supported by the device as "Continuous Array Read (Low Frequency Mode)".  The address is 22 bits in 512 byte mode (which you will have to use, as the addressing scheme in 528 byte mode is not compatible).

Since this appears to be a custom board, you may also need to change some aspects of the UBL. In particular, I thinking that if you have an oscillator or crystal that works at a different frequency, the UBL included will not setup the UART as needed for 1152008n1 operation.

Finally, if you have the JTAG connection, you can try using the debug GEL files to see if you can get more info about what is going on during a failed boot.

Regards, Daniel

Hi Dandiel & GSR,

Thank you for your ideas.

Hi Daniel & GSR,

Thank you for your ideas.

• the continous read command (0x3) is supported by AT45DB321D.
  
• I see that for 528 page it uses 23 bits, and for 512 page it uses 22 bits:

 "Buffer addressing for the DataFlash standard page size (528 bytes) is referenced in the
datasheet using the terminology BFA9 - BFA0 to denote the 10 address bits required to designate
a byte address within a buffer. Main memory addressing is referenced using the
terminology PA12 - PA0 and BA9 - BA0, where PA12 - PA0 denotes the 13 address bits
required to designate a page address and BA9 - BA0 denotes the 10 address bits required to
designate a byte address within the page.
For “Power of 2” binary page size (512 bytes) the Buffer addressing is referenced in the
datasheet using the conventional terminology BFA8 - BFA0 to denote the 9 address bits
required to designate a byte address within a buffer. Main memory addressing is referenced
using the terminology A21 - A0, where A21 - A9 denotes the 13 address bits required to designate
a page address and A8 - A0 denotes the 9 address bits required to designate a byte
address within a page.

On my previous trials, I configured the flash for 512 page size, and flash the UBL again,
but still I did not see any characters in the UART when booting from SPI Flash.

• what did you mean about changing some aspects of the UBL ? does the UBL fits itslef only to the OMAP-L138 EVM? how do I change the UBL and what should I change in it?
• I saw in the CC studio that the boot configuration register is set for booting from spi flash (0xc) , is there something else maybe I should watch in particular on the failed boot.

I have attached the atmel datasheet in the previous post (sorry for sending the previous message not complete).

>Interesting thing to Note here is that the flash program read phase (after the writing) verifies that writing is successful , so does not that mean that the flashing was OK ?

Thank you !!!

Ran

Hello GSR,

Thank you for your support,
I see that the atmel uses 22 bit address for 512 page, and 23-bit for 528 address, Does it mean that there is problem here with the 24-bit addressing constrain ?
I have attched the datasheet in the previous message.

>Interesting thing to Note here is that the flash program read phase (after the writing) verifies that writing is successful , so does not that mean that the flashing was OK ?

Thank you !!!

Ran

ran shalit said:

Hello GSR,

Thank you for your support,
I see that the atmel uses 22 bit address for 512 page, and 23-bit for 528 address, Does it mean that there is problem here with the 24-bit addressing constrain ?
I have attched the datasheet in the previous message.

The ROM boot loader will linearly increment the address (unless you turn on sequential read, in which case a single read command and address is sent and then the memory device is just expected to spit out data while incrementing on its own). In any case, the ROM boot loader does not know anything about pages and splitting the address bits between pages and blocks, so the 528 byte mode won't work. It may work in sequential read mode because all of the upper address bits during the reads from the start of the memory will be zero, but the device data sheet can specify what happens in that case.

Regards, Daniel

Hi Daniel,

So does it mean that Although it is 22 bit address for 512 page, and not 24 bits, I can still use it?
I see that the spi-flash-writer, verifies that file match, which means (if I'm correct) that the UBL is flashed correctly in the SPI flash.  
But after setting 512 page configuration, and getting "file match" for the UBL flash, there is still nothing in the UART.
Does it mean that the UBL does not fit my configuration. What steps you suggest me to take ?

Regards,

Ran

spi-flash-writer/main.c

.....

  while(!feof(fPtr))
    {
  unsigned int nbytes;

     if(!feof(fPtr)) {
   nbytes = fread(tx, 1, page_size, fPtr);
  }  
  tx[nbytes] = '\0';

  flash->read (flash, i * page_size, page_size, (Uint8 *)rx);
        rx[nbytes] = '\0';
  if(strcmp((const char *)rx,(const char *)tx)!= 0) {
   printf("Files did not match @ %d\n", ftell(fPtr));
   goto finish;
  }
  i++;
    }

 printf("Files matched \n");

The ROM will always send out 24 address bits.  This matches with what this Atmel device expects, so there is no issue (only 22 of the bits will mean anything to the Atmel device and unless the ROM tries to read past the end of the flash, those upper two bits will always be zero anyways).

Please use the debug gel file I mentioned earlier to try and get the status of the ROM boot process.

Also, have you followed the directions in the section 13 of the datasheet to permanently configure the device for 512 byte (power of two) page size? Is that what you mean when you say "setting 512 page configuration"?

Regards, Daniel

Yes, I've configured the device to permanently use 512 byte page (and reset the system afterwards), and the flashed the UBL again (I was able to see that the ATMEL configuration was changed to 512 bytes page, becuase it prints the page size in the probing function).

I use the LogicPD Gel file (same as in the EVM), meanwhile without any changes. What did you mean about the boot process state ? should I see where the PC is and try to understand what functions were fetched from the SPI memory?

Do I need to create new UBL file before flashing it into the SPI flash or does the UBL file should match any configuration?

Regards,

Ran

ran shalit said:

I use the LogicPD Gel file (same as in the EVM), meanwhile without any changes. What did you mean about the boot process state ? should I see where the PC is and try to understand what functions were fetched from the SPI memory?

See the link I mentioned earlier: http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

If the boot fails, you can use this file to get some info from the device about what happened.

Regards, Daniel

Hi Daniel,

I have continued the diagnostics today, I see some interesting things:

1. I am trying to burn only boot-strap meanwhile (without u-boot). As I undestand it should give me some printing in UART anyway, even if u-boot is not flashed. Also if I'm currect I can flash the boot-strap also in other boot modes (not only emulator) since the emulator will always take control on the board. I hope it is OK to work this way.

2. I see that flashing the SPI flash image/boot-strap/arm-spi-ais.bin does not give me any printings in UART. the disagnotics are at the end of this message. I then tried to flash the bin image of the "flash and boot utils" called ubl_OMAPL138_SPI_MEM.bin. I was surprised to see that the UBL now starts and gives printings in UART , although I get "no magic number is found" in the printings (?). the diagnotics here are the same( except to PC register) for both case.

3. Same thing as 2 happend when I tried to flash the Nand in my board: flashing the bin from  image/boot-strap/arm-nand-ais.bin gives nothing, but flashing the ubl_OMAPL138_NAND.bin gives printing (UBL works). the diagnotics here are the same( except to PC register) for both cases.

Any advice is appreciated , Thank you for the help !

Ran

ARM9_0: Output:  Target Connected.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  Memory Map Cleared.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  Memory Map Setup Complete.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  KICK Unlocked.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  PSC Enable Complete.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  PLL0 init done for Core:300MHz, EMIFA:25MHz
ARM9_0: Output:  mDDR initialization is in progress....
ARM9_0: Output:  PLL1 init done for DDR:150MHz
ARM9_0: Output:  Using mDDR settings
ARM9_0: Output:  mDDR init for 150 MHz is done
ARM9_0: Output:  ---------------------------------------------
ARM9_0: Output:  DSP Wake Complete.
ARM9_0: Output:  ---------------------------------------------
ARM9_0: GEL Output:
---------------------------------------------
ARM9_0: GEL Output: |             Device Information            |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: DEV_INFO_00 = 0x1B7D102F
ARM9_0: GEL Output: DEV_INFO_01 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_02 = 0x0000000C
ARM9_0: GEL Output: DEV_INFO_03 = 0x00000032
ARM9_0: GEL Output: DEV_INFO_04 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_05 = 0x000003E0
ARM9_0: GEL Output: DEV_INFO_06 = 0x00000080
ARM9_0: GEL Output: DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 0-0-5621784-22-46-19
ARM9_0: GEL Output: DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 2,0,0,11272
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_17 = 0x00030003
ARM9_0: GEL Output: DEV_INFO_18 = 0x00000000
ARM9_0: GEL Output: DEV_INFO_19 =ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output: 0ARM9_0: GEL Output:
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_20 = 0x30303864
ARM9_0: GEL Output: DEV_INFO_21 = 0x3630306B
ARM9_0: GEL Output: DEV_INFO_22 = 0x30303864
ARM9_0: GEL Output: DEV_INFO_23 = 0x3630306B
ARM9_0: GEL Output: -----
ARM9_0: GEL Output: DEV_INFO_24 = 0x1601302E
ARM9_0: GEL Output: DEV_INFO_25 = 0x0055C818
ARM9_0: GEL Output: DEV_INFO_06 = 0x00000080
ARM9_0: GEL Output: DEV_INFO_26 = 0x58100002
ARM9_0: GEL Output:

ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |               BOOTROM Info                |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: ROM ID: d800k006
ARM9_0: GEL Output: Silicon Revision 2.0
ARM9_0: GEL Output: Boot Mode: SPI1 Flash
ARM9_0: GEL Output:
ROM Status Code: 0x00000000
Description:ARM9_0: GEL Output: No error
ARM9_0: GEL Output:
Program Counter (PC) = 0x019482B8
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              Clock Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: PLLs configured to utilize crystal.
ARM9_0: GEL Output: ASYNC3 = PLL0_SYSCLK2
ARM9_0: GEL Output:
ARM9_0: GEL Output: NOTE:  All clock frequencies in following PLL sections are based
ARM9_0: GEL Output: off OSCIN = 24 MHz.  If that value does not match your hardware
ARM9_0: GEL Output: you should change the #define in the top of the gel file, save it,
ARM9_0: GEL Output: and then reload.
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PLL0 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: PLL0_SYSCLK1 = 300 MHz
ARM9_0: GEL Output: PLL0_SYSCLK2 = 150 MHz
ARM9_0: GEL Output: PLL0_SYSCLK3 = 25 MHz
ARM9_0: GEL Output: PLL0_SYSCLK4 = 75 MHz
ARM9_0: GEL Output: PLL0_SYSCLK5 = 300 MHz
ARM9_0: GEL Output: PLL0_SYSCLK6 = 300 MHz
ARM9_0: GEL Output: PLL0_SYSCLK7 = 50 MHz
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PLL1 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: PLL1_SYSCLK1 = 300 MHz
ARM9_0: GEL Output: PLL1_SYSCLK2 = 150 MHz
ARM9_0: GEL Output: PLL1_SYSCLK3 = 300 MHz
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PSC0 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: State Decoder:
ARM9_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)
ARM9_0: GEL Output:  1 = SyncReset (reset assered, clock on)
ARM9_0: GEL Output:  2 = Disable (reset de-asserted, clock off)
ARM9_0: GEL Output:  3 = Enable (reset de-asserted, clock on)
ARM9_0: GEL Output: >3 = Transition in progress
ARM9_0: GEL Output:
ARM9_0: GEL Output: Module 0: EDMA3CC (0)        STATE = 3
ARM9_0: GEL Output: Module 1: EDMA3 TC0          STATE = 3
ARM9_0: GEL Output: Module 2: EDMA3 TC1          STATE = 3
ARM9_0: GEL Output: Module 3: EMIFA (BR7)        STATE = 3
ARM9_0: GEL Output: Module 4: SPI 0              STATE = 3
ARM9_0: GEL Output: Module 5: MMC/SD 0           STATE = 3
ARM9_0: GEL Output: Module 6: AINTC              STATE = 3
ARM9_0: GEL Output: Module 7: ARM RAM/ROM        STATE = 3
ARM9_0: GEL Output: Module 9: UART 0             STATE = 3
ARM9_0: GEL Output: Module 10: SCR 0 (BR0/1/2/8)  STATE = 3
ARM9_0: GEL Output: Module 11: SCR 1 (BR4)        STATE = 3
ARM9_0: GEL Output: Module 12: SCR 2 (BR3/5/6)    STATE = 3
ARM9_0: GEL Output: Module 13: PRUSS              STATE = 0
ARM9_0: GEL Output: Module 14: ARM                STATE = 3
ARM9_0: GEL Output: Module 15: DSP                STATE = 3
ARM9_0: GEL Output:
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output: |              PSC1 Information             |
ARM9_0: GEL Output: ---------------------------------------------
ARM9_0: GEL Output:
ARM9_0: GEL Output: State Decoder:
ARM9_0: GEL Output:  0 = SwRstDisable (reset asserted, clock off)
ARM9_0: GEL Output:  1 = SyncReset (reset assered, clock on)
ARM9_0: GEL Output:  2 = Disable (reset de-asserted, clock off)
ARM9_0: GEL Output:  3 = Enable (reset de-asserted, clock on)
ARM9_0: GEL Output: >3 = Transition in progress
ARM9_0: GEL Output:
ARM9_0: GEL Output: Module 0: EDMA3CC (1)        STATE = 3
ARM9_0: GEL Output: Module 1: USB0 (2.0)         STATE = 3
ARM9_0: GEL Output: Module 2: USB1 (1.1)         STATE = 3
ARM9_0: GEL Output: Module 3: GPIO               STATE = 3
ARM9_0: GEL Output: Module 4: UHPI               STATE = 3
ARM9_0: GEL Output: Module 5: EMAC               STATE = 3
ARM9_0: GEL Output: Module 6: DDR2 and SCR F3    STATE = 3
ARM9_0: GEL Output: Module 7: MCASP0 + FIFO      STATE = 3
ARM9_0: GEL Output: Module 8: SATA               STATE = 3
ARM9_0: GEL Output: Module 9: VPIF               STATE = 3
ARM9_0: GEL Output: Module 10: SPI 1              STATE = 3
ARM9_0: GEL Output: Module 11: I2C 1              STATE = 3
ARM9_0: GEL Output: Module 12: UART 1             STATE = 3
ARM9_0: GEL Output: Module 13: UART 2             STATE = 3
ARM9_0: GEL Output: Module 14: MCBSP0 + FIFO      STATE = 3
ARM9_0: GEL Output: Module 15: MCBSP1 + FIFO      STATE = 3
ARM9_0: GEL Output: Module 16: LCDC               STATE = 3
ARM9_0: GEL Output: Module 17: eHRPWM (all)       STATE = 3
ARM9_0: GEL Output: Module 18: MMC/SD 1           STATE = 3
ARM9_0: GEL Output: Module 19: UPP                STATE = 3
ARM9_0: GEL Output: Module 20: eCAP (all)         STATE = 3
ARM9_0: GEL Output: Module 21: EDMA3 TC2          STATE = 3
ARM9_0: GEL Output: Module 24: SCR-F0 Br-F0       STATE = 3
ARM9_0: GEL Output: Module 25: SCR-F1 Br-F1       STATE = 3
ARM9_0: GEL Output: Module 26: SCR-F2 Br-F2       STATE = 3
ARM9_0: GEL Output: Module 27: SCR-F6 Br-F3       STATE = 3
ARM9_0: GEL Output: Module 28: SCR-F7 Br-F4       STATE = 3
ARM9_0: GEL Output: Module 29: SCR-F8 Br-F5       STATE = 3
ARM9_0: GEL Output: Module 30: Br-F7 (DDR Contr)  STATE = 3
ARM9_0: GEL Output: Module 31: L3 RAM, SCR-F4, Br-F6 STATE = 3

Hi Daniel,

In addition to the diagnostic information I gave before, When I compare the difference between the custom board to the EVM, I also see that the device ID in the board is:
d800k006 - silicon revision 2.0 and in the EVM board: d800k004 - silicon revision 1.1 (difference in bootrom info category), there are also difference in device information category , maybe becuase the device id is different. There is no more difference in the other categories in the diagnostic information.
As I undestand it is just the revision of the cpu - Meanwhile I have no idea why the custom board behaves different from the EVM.

Regards,

Ran

Ran,

Thanks for providing the update.  I think the lesson here is that the low-level boot loaders can be very much tied to the particulars of the board or platform, and therefore it is very likely that these will need to be customized for a custom platform.

Regards, Daniel

Hi Ran:

We also use AT45DB321D on our custom OMAP-L137 board. How did you add AT45DB321D support to spi-flash-writer? Can you share the modified spi-flash-writer code with us?

You help is very appreciated!

Jimmy

Hi jimmy,

- I don't have now access to the code, maybe tomorrow, but it was very simple: I just took the atmel driver from u-boot (or linux I'm not sure, but probably from u-boot source).
I also did some very minor changes just to fit into the frame of the spi-flash-writer (not any important change). You should also be aware of the 512/528 bytes issue. When I first tried to flash the Atmel flash it seemed that flashing was done well, but the booting failed. I then figured out that it is becuase the flash came as 528 bytes per page from factory. 

- I added simple command at start of flash to convert it to 512 bytes per page. That is maybe the only "important" adding to code, I have made. If your flash is 512bytes then you won't need such anyway.

- Are you working with the updated sdk from TI ? Isn't there still support for the atmel in the spi-flash-writer ? 

Bye,

Ran

Hi Ran:

We have solved the problems and now we can programme AT45DB321D and boot from it. The following is what I have done:

1. Configure the page size of AT45DB321D-SU to 512 bytes; then did a power cycle;

2. Modified spi-falsh-writer to support AT45DB321D.

Thank you very much for your help!

Best regards,

Jimmy

Mr. Zhang, could you give modified version of spi-falsh-writer (with support of AT45DB321D)?

My e-mail: dtp-avb@yandex.ru

---

Thanks at advance.

8357.dsp_spi_flash_writer.zipHi Alexander:

1. Configure the page size of AT45DB321D to 512 bytes. The default page size is 528 bytes. You need to configure the page size to 512 bytes. I added the following code in “main.c” of SPI Flash Writer. You need to uncomment the following code in “main.c” the first time.

    /*The follow code is to config the page size of AT45DB321D to 512 Byte.*/

//    Uint8 config_cmd[4] = { 0x3d, 0x2a, 0x80, 0xa6 };

//    ret = spi_xfer(slave, 32, &config_cmd[0], NULL, SPI_XFER_BEGIN);

//    if (ret) {

//          printf("SF: Failed to send config command %02x: %d\n", config_cmd, ret);

//          return ret;

//    }   

//    while(1);    //Added by Jimmy

1. After you build and run the “main.c”, you need to power off the board, then power on the board. Now the page size of AT45DB321D is 512 bytes.
2. Comment the above code.
3. Build and run SPI Flash Writer. The you can program the AT45DB321D following the instructions.

The attachment is the modified driver.  

 Please let me know if the code works.

Best regards,

Jimmy