Hi everyone,
I got a custum board with an OMAP-L138. On my board I have: OMAP-L138, NOR, NAND, DDR, TP65070. The board is identical to the EVM except that I have DDR2 instead of mDDR.
I'm trying to do the first boot and to write ubl and u-boot in NOR flash with OMAP-L138_FlashAndBootUtils_2_25.
First I tried to use the sfh_OMAP-L138.exe already compiled in the package with my ubl and my u-boot that works on the EVM. This is the result I had:
sfh_OMAP-L138.exe -flashType NOR -flash ubl-nor.bin u-boot.bin -p COM1 -baud 115200
[TYPE] UBL and application image
[UBL] ubl-nor.bin
[APP IMAGE] u-boot.bin
[DEVICE] NOR
Attempting to connect to device COM1...
Press any key to end this program at any time.
(AIS Parse): Waiting for BOOTME... (power on or reset target now)
(AIS Parse): BOOTME received!
Waiting for SFT on the OMAP-L138... <= It freezes here.
I investigated about the problem and I saw that the SFH never receive BOOTUBL from the SFT.
So I wanted to check if my OMAP was ok, so I connected to the target with the emulator. I tried to write in DDR2 with CCS and I saw that I was not writing at the right place. Then I modified the GEL file to init the OMAP DDR registers properly. After that my DDR2 was working correctly.
I tought that I had the same problem with SFH & SFT so I recompiled both with the same registers value than the GEL file and I got the same behaviour, it freezes.
I think that even if my DDR2 was not well initialised by the SFT it will continue to “talk” with SFH to write the UBL into NOR. From what I have read, it’s only the OMAP internal RAM located at address 0x80000000 that is used to execute SFT. Maybe you can correct me if I’m wrong.
I think that the best was to solve this would be to trace the SFT and SFH code.. but I’m not able to do it from what I know from the tools...
Do you have any idea that could help me.
Thank you.
Nicolas
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
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
----------------------------------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.----------------------------------------------------------------------------------------------------------
Useful Links:OMAP-L1x/C674x/AM18x Debug GEL File
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.
[UBL] ./GNU/ubl/ubl_OMAPL138_NOR.bin
[APP IMAGE] ../myapp/u-boot.bin
Attempting to connect to device /dev/ttyS0...
(AIS Parse): Read magic word 0x41504954.
(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): Loaded 1180-Byte section to address 0x800035EC.
(AIS Parse): Processing command 2: 0x58535906.
(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.
Regards,
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.
Have you tried to debug this any more?
I modified my DDR2 timing and now it works. Probably that my DDR2 timing was too tight... I was able to read/write in DDR2 with Memory view in CCS (probably because it is very slow), but I was unable to execute properly the application.
Thanks for the support.
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.
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,
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,
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!
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?