Part Number: BEAGLEBK
Other Parts Discussed in Thread: SYSBIOS
Tool/software: Code Composer Studio
Regarding the posting :
Which was never answered, I will say the following:
1. As typical for support on from TI, they simply marked it as "TI Thinks Resolved", and locked it off. Without ever answering.
2. How the XDC/SysBios actually assigned the entry vector is just "FM" (F - Magic) from the point of view of us in the real world. When it works, you have NO CLUE what, where, or how. When it doesn't work there is no doc or support to make it work. And that is about 50% of the time. Even one of the helpful replies to one of my questions said "I don't know why XDC and SYS/BIOS have not been changed to make this detail easier. I'll ask those experts to comment on this thread." Of course, there was silence.
3. Trying to use the linker commands are mostly useless, because the build tool recreates the entire linker cmd file from ...? (i..e. Pulls them out of it's... air), and overriding them is a nightmare.
processors.wiki.ti.com/.../Linker_Command_File_Primer
4.Trying to use the recommended custom.cmd to "enhance" the scripts apparently doesn't work in GNU, as was discussed in 
apparently the syntax is different.
So... here is a summary and a couple ideas...
When using the SD card on the BBB, the bootloader has two integer values that it reads from the "app" file. The length, and the location to load it to... This second value is the same as the place to jump to the start the program. (think about it... should there have been three values, and then the base address would not have to be the same as the entry?? But that's the way they made it... ) So, we must set the beginning of the program to be the same as the load address.
So... the goal of the original post from Riccardo is to get the entry point of the program to be at location 0x8000 0000. Most likely, it is not. The actual origin (where the initialization before "main" happens) is a function called "c_int00". The fastest way to determine where it is, is to look in the "debug" folder, and open the *.MAP file of the same name as the project, and do a search for "c_int00". You will likely see a couple of spots. One is the name of the module that the linker took it from. Another will be the memory location of the function, along with it's length. In my sample, it says:
LOAD ./main_led_blink.o
.c_int00 0x80000000 0xb4
*(.c_int00)
.c_int00 0x80000000 0xb4 C:\ti\bios_6_46_05_55\packages\gnu\targets\arm\rtsv7A\lib\boot.aa8fg(boot.oa8fg)
0x80000000 _c_int00
*(.c_int00)
Which tells me it was loaded at memory location 0x8000 0000, and is 0xb4 bytes long. This is the way it is supposed to be. If not, we are left out in the cold with no help and no useful support. So, if you are grasping as straws... read on.
I offer these total and complete HACKS, which I take no responsibility for them working or not.
1. If there is any *.lds file, REMOVE IT. This is a linker script which tells the link stage what to do. I am guessing that XDC/SysBios is creating it's own and any script that the CCS/Eclipse tosses in there is a template, and will not work (must be customized). It is very easy to accidentally have CCS toss one in there when you make a changes to the project properties. I've fallen victim to this defective behavior myself. But, of course the XDC system just lets you shoot yourself in the foot.
Try the build again, and see if the "c_int00" is now in the right place.
NOTE: That if you are not building a SysBios project, you will need to create a linker script, or use one of the templates that CCS throws into your project. Then you will have to examine, and perhaps modify, the startup_ARMCA8.s (assembler) code that CCS created for you, and tweak the linker script to place the compiled sections in the right place. But that is a whole other thread. It is actually easier to do that once you know how... you are not fighting with the XDC/SysBios tools which do all this stuff for you, thinking it's a favor, but just binding you in a straight jacket which you can't figure out. (Non-SysBios is how I built my own bootloader, which runs from eMMC, and I even wrote a copier to move "app" from the SD card to eMMC - Now I can boot the BBB from eMMC and even copy programs over. And not rely on the mechanical SD card connection, or pressing the "boot" button)
2. If that didn't work, then we assume that XDC/SysBios isn't placing your entry point where it needs. I have no idea what might cause that, or how to fix it. Try adding you own new script at the project root. You can do what I did and name it "custom.cmd". The environment "just knows" to use that when linking. The complete contents of mine are:
MEMORY
{
DDR : org = 0x80000000, len = 0x20000000
}
SECTIONS {
.c_int00 : {
KEEP (*(.c_int00))
} > DDR
}
I just lifted this out of the "linker.cmd" file that appears to be generated from a working Sys/Bios project, preserved only the DDR memory address, and changed the name so it didn't conflict with the name "DDR3" which is in the auto-generated linker cmd file.
If neither of these work, I'm currently out of ideas (not to say I won't find another idea later). Or maybe, just maybe, TI will offer some help.
By the way Riccardo , if it's not an issue with company confidential code, it's usually useful to post the zipped up project, but first delete any "debug" and/or "release" folder from the zip. They are recreated during the build process.
Hope this helps. And my sarcasm gets some support attention from real TI people. Not fellow amateurs, such as myself.
.
