- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Hello,
I think I asked they a few years ago, but now all my history was purged... So here we go again. Since it's been a few years, I have no idea where to start looking.
(I am using CCS 10, SYSBIOS 6.76, GCC Compiler... but I don't think that has any bearing on this)
The AM335x bootstraps from EMMC or SD into address 0x402f0400 That's fine.
The utility "tiimage.exe" will place a 4 byte size, and a 4 byte load address at the front of the binary (after it's been stripped down with arm-none-eabi-objcopy)
That's fine if you are NOT using a SYSBIOS project.
A little test SYSBIOS project I just build has an entry point that is NOT at 0x80000000 but c_int00 is located at 0x800040e0 (as I found out from the MAP file).
Except the IMAGE has to load starting at address 0x80000000.
So, I can set the entry point using a conventional linker script, but the penchant to hide everything when using SYSBIOS means not only do I not know how to set the entry address, but I have to address these settings so rarely, that I forget... because I don't deal with these concerns except every few years.
As far as I can tell, this isn't gonna work. SYSBIOS placed the MMU table at address 0x8000000, and the "tiimage.exe" utility just ASSUMES that the start of the image is also the entry point.
Any suggestions, short of writing a CUSTOM BOOTLOADER every time there is a new SYSBIOS program that changes it's c_int00 address?
-CSW
Jianzhong,
That didn't take long to fail.
Using CCS Import Projects, and navigating to the PDK folder,
The PDK folder has only two examples in it.
Great... So nothing will happen for a week, short of me troubleshooting this obfuscated environment.
So I continued to dig into your environment and here is what I found...
The target device is a BeagleBoneBlack.
This is an app created by CCS using the menu "Project | New CCS Project" and picking "SYS/BIOS | GNU Target Examples | Typical"
I am including MY OWN interface functions, not the PDK libs. So all the GPIO calls are from source code within the project. Not linked in.
I added a file CMD in the root to set the entry point to the start of DDR:
At that point, the entry is set to 0x8000000
But it is failing.
I modified the bootloader to generate some diagnostic messages. I verified that the bootloader is working correctly. it is.
The bootloader will also load and run the Example GPIO_LedBlink_bbbAM335x_armTestProject so I know the bootloader functions.
I reset the device, and step through the bootloader execution from address 0x402F0400. The loader correctly loads the 'app' and executes a call to the target address of 0x80000000.
Here it enters EITHER the sample program GPIO_LedBlink_bbbAM335x_armTestProject -OR- my program created with the Project | New CCS Project...
The assembly at address 0x800000 is IDENTICAL between the two apps.
However they jump to different locations at address 0x...98.
On the EXAMPLE project imported:
The instruction at address ...98 is BLX r0 and the content of R0 is 0x80000C04
I can see this in the map file (xdc_runtime_Startup_reset), and it is one of those XDC generated source files:
On the app generated by CCS, the same instruction at address is jumping to a different address. The contents of R0 is 0x80008EA8.
When I look at the map file, that is not even an entry point. It is in the middle of my function GPIO2ModuleClkConfig
Therefore, where the bootstrap code is jumping to is NOT correct. All this is stuff in XDC, deep under the covers, and not anything I can find controls for.
Now, please explain how these differences occur, and where I can control the something...(XDC, GNU, Project...?) to build the app correctly.
-CSW
Here we go again... Lets hope this one POSTS...
The subject "How to Set the Entry Point" still mostly applies. How is it set in the Example, and why is it NOT set in a wizard based project?
Import an example:
Build and examine the map file:
It is correct.
Change the target from ti.platforms.evmAM3359 to ti.platforms.beaglebone and rebuild... NO CHANGE
Create a SYSBIOS project using the wizard.
The files are there, auto-generated:
Build and examine the map file:
IT IS WRONG. 9The c_int00 code block appears the same size... but in the wrong place )
In BOTH cases, the settings are Platform:gnu.targets.arm.A8F and Target: ti.platforms.beaglebone
In BOTH cases, the environment is creating the linker script.
in BOTH cases, the XDC is 3.55 and SYSBIOS is 6.76
In the case that DOES NOT correctly, simply throwing in more "products" in the project settings makes no difference.
Trying to find what is in the CFG file that is doing it has turned up nothing.
I can fix the second one ONLY by adding my own CMD file. But it IS NOT there in the example.
Last time, my other post helped me fix the entry point by what now appears to be a work-around HACK.
WHAT IS THE DIFFERENCE between these two projects?
WHY does one generate a linker script that correctly sets the entry point, and the OTHER project doesn't??
WHY does it need a HACK?
