OMAP-L138 first boot

Ok so here are some updates:

I removed some data and addr lines on my EVM and re-tested SFH with the EVM and it freezes at the same place.

So my conclusion is that the DDR2 is important when executing SFH. Also, it seems that my compilation of SFH & SFT didn't work properly.

I followed this wiki to recompile SFT & SFH: http://processors.wiki.ti.com/index.php?title=Serial_Boot_and_Flash_Loading_Utility#Compiling .

If I do make at the top directory it complies a lot of stuff, even if my SFH have been updated, there are some error on ubl directory. Maybe my modifications to device.c have not been taken into the new SFT.

Is anyone successfully recompiled SFH & SFT using OMAP-L138_FlashAndBootUtils_2_25?

Thanks

Nicolas

Hi Nicolas,

You should be able to recompile both SFH & SFT as long as your compiler tools are up to date. Do you have the latest package from CodeSourcery (http://www.codesourcery.com/sgpp/lite/arm/portal/subscription3057), as well as a current version of the .NET platform from Microsoft? If so, can you please list the compilation errors you got so we can help debug? You can run  "make" in the  SFT or SFH directories individually while you try and debug the issue.

One step I would first take would be to redownload the serial flasher code and try to make it without any modifications. If you cannot, that would point to an issue with you tools. If you can, we can look closer at the modifications you made to device.c.

Jeff

Hi Jeff,

So I recompiled successfully SFT & SFH. Under linux, I was missing c16x compiler tools for the DSP.

I tried my new SFH with modification to support DDR2. (I used mDDR_DDR2_Memory_Controller_Register_Calc_Rev2.xls) The SFH is not freezing anymore to "Waiting for SFT on the OMAP-L138" but it freezes a bit further in the execution. Here is the output of SFH :

sfh_OMAP-L138.exe -flashType NOR -flash ubl-nor.bin u-boot.bin

Platform is Unix/Linux.

[TYPE] UBL and application image

[UBL] ./GNU/ubl/ubl_OMAPL138_NOR.bin

 [APP IMAGE] ../myapp/u-boot.bin

 [DEVICE] NOR

Attempting to connect to device /dev/ttyS0...

Press any key to end this program at any time.

(AIS Parse): Read magic word 0x41504954.

(AIS Parse): Waiting for BOOTME... (power on or reset target now)

(AIS Parse): BOOTME received!

(AIS Parse): Performing Start-Word Sync...

(AIS Parse): Performing Ping Opcode Sync...

(AIS Parse): Processing command 0: 0x58535901.

(AIS Parse): Performing Opcode Sync...

(AIS Parse): Loading section...

(AIS Parse): Loaded 13804-Byte section to address 0x80000000.

(AIS Parse): Processing command 1: 0x58535901.

(AIS Parse): Performing Opcode Sync...

(AIS Parse): Loading section...

(AIS Parse): Loaded 1180-Byte section to address 0x800035EC.

(AIS Parse): Processing command 2: 0x58535906.

(AIS Parse): Performing Opcode Sync...

(AIS Parse): Performing jump and close...

(AIS Parse): AIS complete. Jump to address 0x80000000.

(AIS Parse): Waiting for DONE...

(AIS Parse): Boot completed successfully.

Waiting for SFT on the OMAP-L138...

Flashing UBL ./GNU/ubl/ubl_OMAPL138_NAND.bin (13576 bytes) at 0x00000000 <= It freezes here!

I traced SFH execution with printf on console and what I noticed is that it freezes in sfh_ais.cs at line 839 -  if (!SerialIO.waitForSequence("SENDIMG\0", "BOOTUBL\0", MySP, cmdParams.verbose))

So it seems that SFT is not sending SENDIMG.

I did few tests with CCS to be sure that my NOR is correct, and it is. I'm also able to write/read at address 0xC000000 which is DDR2 offset, I did it with Memory view.

I also recompiled SFH & SFT with the old mDDR config and I tried it on EVM and it works, so the compilation is good.

Do you have any idea why the SFT is still freezing even if my DDR2 seems to work now.

Thank you.

Regards,

Nicolas

Make sure you removed all the GEL files from CCS. When you connect it will automatically configure the DDR if you still have a GEL in CCS.

Also please run the program in verbose mode (-v) and the SFT will print out some debug info that might be helpful.

Jeff

Have you tried to debug this any more?

Jeff

Hi Nicolas,

I have exactly the same problem, which part of the DDR2 timing did you modify to "loosen" the timing?  At the moment I have just used the values from the DDR2 datasheet...

Thanks,

Chris 

Hi Chris,

I have the same DDR2 memory than Hawkboard (Micron MT47H64M16HR-3), so I used the same timing and it solved my problem. These timing can be found at http://elinux.org/Hawkboard#Signing_u-boot_for_UART_boot . I didn't check the difference between the timing I used from datasheet and those from the website. Maybe I will when I will have extra time.

If you use the same chip and you want to change directly SFT and SFH, go in OMAP-L138_FlashAndBootUtils_2_25\OMAP-L138\Common\src\device.c, function DEVICE_init and change DEVICE_ExternalMemInit(..) to status |= DEVICE_ExternalMemInit(0x00000043, 0x00134632, 0x26492a09, 0x7d13c722, 0x00000249, 0x00000000); then recompile serial flash utility.

Hopes it will help.

Regards,

Nicolas

Hi Nicolas,

Thank you for the quick response, much appreciated.  I'll have a look at the Hawkboard timings and give them a shot, fingers crossed!

Best regards,

Chris

Chris,

Did it work. I am also facing the same problem. if it worked for you i'll also try. fingers crossed...

Ajay

Hi Ajay,

No, this didn't help me, it turned out that the SDRAM weren't even relevant at the stage I was getting to.  When I had the "waiting for sfh" line, the PC software was waiting for a response from the board.  The demo board has a complicated power supply management IC that I had replaced as it was overkill for my design.  Unfortunately (and completely undocumented as far as I can tell) the boot code was waiting for a response from this device (on I2C perhaps?  It was a while ago now..) before it would continue.  The software engineer removed this requirement from the code and rebuilt and finally got past this stage.  It might be worth mentioning that the SDRAM values I calculated where different to those calculated by TI and I never got a clear answer as to why, most matched but there were a couple of differences which might have caused problems later if we hadn't enlisted TI apps guys to sort it all out by that stage.

Good luck, as a hardware engineer this whole process seemed to require a degree in black magic..

Cheers,

Chris

Hi chris,

can you find out which part of the code was taken out? I am also having this issue with our custom board.

I can compile the application and it runs fine on the EVM board, but not on our board (after changing the PLLs and memory initialisation to the same settings that i am using to generate AIS images, which i have successfully uploaded through the CCS nor writer and booted off, so i expect that they should be the same for this)

cheers,

colin

Hi Colin,

As stated above, I work on the hardware side so I can't give you the exact details.  The following comes from an email from a TI apps guy, with luck it will point you in the right direction:

One thing we did have to do was edit the power management setting in the ubl. On our board we use a TPS65xxx PMIC device and communicate via I2C to set the voltage for the operating point, you do not have this device on your design and the ubl was hanging on I2C waiting for the PMIC to respond. I am not sure if the ubl associated with sft makes the same assumptions about the power management companion chip.

This worked for us, but I never had reason to look at the code directly to see what exactly had been changed.  I hope this helps!  If you remain stuck send me a message and I'll pass on the details of the apps guy who sorted this out, he may be able to talk you through the changes a bit better than me.

Good luck!

Chris

it appears that my issue was far simpler. helps if i use the right uart

Hi Luna,

I have a problem with the configuration of DDR2. I uses MT47H32M16HR-25E DDR2 and I'm looking for the values to write in device.c .

You said in a post that you uses the file "mDDR_DDR2_Memory_Controller_Register_Calc_Rev2.xls".

Could you said me where is this file or how to calculate the right values to write in device.c?

Thanks

Hi Luna:

Could you please share your GEL files for the Hawkboard?

Thanks a lot!

Cheers,

Mushtaq

Hi Mushtaq,

Sorry for the delay, do you still need it ?

Regards,

Nicolas

Hi Nicolas:

Yes, I still need it!

Please send it!

Thanks a lot!

Cheers,

Mushtaq

Mushtaq Syed said:

Hi Nicolas:

Yes, I still need it!

Please send it!

Thanks a lot!

Cheers,

Mushtaq

Hi Nicolas:

Thanks a lot!

Cheers,

Mushtaq

Hi!

I have custom board with AM1705.

According to spec it runs on 375 MHz.

I was able to recompile tools under Linux for 1705 - but it still hangs on

Waiting for SFT on the OMAP-L137 ...

As far as I understand the problem is incorrect values in PLL0Init, in external memory initialization and in device_uart.

Can somebody advice correct way to compute those values?