Currently I am planning to develop the flash utility develoment for OMAP processor similar to DVflasher utility for DM644x processor. (This is for some customer)
As a part of that I have developed an application on Windows PC which does transfer of Image from PC to OMAP over UART3 port during the processor boot up. I was able to download the Image over UART and this was confirmed by checking the Internal RAM (IRAM) of OMAP through CCS tool. ROM booloader code (running on OMAP which takes care of UART3 boot up) downloads the image from PC and start storing it in IRAM with starting address as 0x40200000. RBL assumes that execution point is same as starting address and hence after the Image is downloaded, Image execution starts from 0x4020000.
In my set up I am using X-loader.bin (raw) file as an Image which gets downloaded during boot up but I do not see X-loader getting executed (Some prints appear on Console Terminal when PC is connected to OMAP over UART1/2 port). Digging deep into the X-loader code I found out that X-loader is built to execute from address 0x40200800.
I have tried modifying config.mk file present in "OMAP3EVM" of X-loader to the required address but Issue still exists
My Questions:1. Is it possible to change the execution address of X-loader from 0x40200800 to 0x40200000? If yes How?2. Which all files require modification?
It will be great if any one of you can give us the clue as this is bit urgent.
Thanks in advance.
I have not really gone into much detail about X-loader's execution address, so I cannot answer your questions directly, though I did have something you may want to look at, in particular there is an open source serial loader utility similar to the DVFlasher available here. This may be useful either directly or as something to compare to so you can see how Nishanth resolved load vs. execute addresses.
You need to "sign" your raw x-loader file. What this does is pre-pend your image with the length of the image and then the load address of the image. The boot ROM reads these values and know swhere and how much to read into internal RAM. Below is a simple hexdump -C of a signed image:
00000000 80 4f 00 00 00 08 20 40 12 00 00 ea 14 f0 9f e5
Notice that the length is 0x4f80 while the load address is 0x40200800. While I have not done much with moving the image to a different location, I would say you'd have to modify the config.mk and also pre-pend the image with the new address for this to work.
2 things to be done here as I found out last week.
1. Change the load address in SignGP.c It is a poor man' signing tool source code. The load address if not passed as an argument defaults to 0x40200800. This may be changed to any other address in SRAM. e.g 0x40200000
2. Look for a variable TEXT_BASE in config.mk. Change this to 0x40200000.
While this is theoritically correct, please pay special heed to areas earmarked for relocations and stack. Some due diligence is generally required.
Thanks for the information.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.