Compiler/TMS320C6424: Cannot apply copy table operator on compiler/linker >=CGT7.3.x

I need to understand more about how your system works now.  When and how do all those sections get copied from FLASH to DDR2_CODE?  I think it has to happen before the boot routine c_int00 starts.

Thanks and regards,

-George

Hello George,

thank you for your reply. I will try to explain a bit more.

The DSP-firmware has been programmed kernel-free. We’re using AIS-boot from an external 32MB parallel NOR-flash memory. The board has 256MB of DDR2-Ram.

The AIS-script will setup the EMIFA, setup the PLL1, setup the PLL2, setup the DDR2 memory controller and call a bootsetup-routine, which will setup caches, do some system and memory testing, that cannot be done at runtime. If the tests have been successful the bootsetup-routine will copy the program code from the NOR-flash to the DDR2-memory by using the linker generated copy table. After the program code has successfully been copied to the DDR2 memory, the bootsetup-routine will return to the AIS script, which will then call c_int00, which resides in DDR2 memory at that time.

The link process fails with reference to the .cinit section given inside the GROUP of sections in the linker-command-file. Somewhere between CGT7.2.12 and CGT7.3.23 something has changed that now prevents a successful link process.

Best regards,

Flux.

Flux said:

the bootsetup-routine will copy the program code from the NOR-flash to the DDR2-memory by using the linker generated copy table.

We did not anticipate that use case.

Since the first release of copy table support, we made improvements to the error handling.  One error we detect is attempting to apply the table operator to the .cinit section.  This section contains, among other things, copy tables for initializing read/write sections like .data.  Therefore, it has be located in its final location when c_int00 starts.  Thus, we issue the error diagnostic you see.

We presumed no one would somehow copy .cinit from elsewhere, and then start c_int00.  Yet that is what you do.  You can suppress the diagnostic with the option --diag_suppress=10320 .  To be honest, I'm not 100% certain this will solve the problem.  But I think it is worth a try.

Thanks and regards,

-George

Hello George,

thank you for the explanation.

But, what is the “correct” way to generate a loadable program-image resided in flash that can be copied by the bootsetup-routine to a certain memory location and THEN be started by calling c_int00?

The reason for our approach is that we want to be able to fully test our hardware at boot-time. The bootsetup-routine among other tests will check all memory locations in DDR2 memory first, that will hold code and data, load the complete code, verify the code and then run the code by calling c_int00.

The bootsetup-routine runs in context of the C6424 boot-rom. The extract of the AIS-script is as follows:

            .global _AisScriptStart              ; make ais script visible to the rest of the code

            .global _AisScriptEnd

            .ref _c_int00                             ; import c_int00

            .ref _BootSetup                        ; bootsetup function to call in C6424 boot-rom context

             .sect ".AIS"

_AisScriptStart:

            <skipped>

            .word 0x58535905                                ; ais JUMP command

            .word _BootSetup                                ; call boot setup function

            .word 0x58535906                                ; ais JUMP CLOSE command

            .word _c_int00                                     ; application start address

            .word 0x00000000                                ; number of sections that should have been loaded

            .word 0x00000000                                ; number of bytes that should have been loaded

_AisScriptEnd:

Indeed, after suppressing the error, the code compiles, but doesn’t run anymore. I tried that with CGT7.3.23.

What is the proper way to do it with the newer CGTools?

Best regards,

Flux.

see above...

Flux,

This doesn't really address the question about the linker/compiler, but I want to add that this use of the AIS JUMP command was never anticipated. That was intended for very simple bits of code to do very targeted operations. It sounds like you have written an entire boot loader of your own to operate inside that jumped to function. The data copy from the flash to the memory was anticipated to be done using AIS load/copy commands, executed by the device's ROM boot loader.

Regards, Daniel

Making it an error to apply a copy table to the .cinit section is viewed as fixing an oversight that goes all the way back to the introduction of copy tables.  It is unfortunate that, in that time, you stumbled into a way to take advantage of this oversight.

So, I filed the entry CODEGEN-5079 in the SDOWP system.  This entry does not report a bug, but requests a change in how the linker works.  The request is to allow the copy table operator to be applied to .cinit.  Such requests are reviewed on a regular basis.  Some are implemented, and some are not.  I have to be honest with you, and point out that you face a disadvantage.  The linker started issuing this error diagnostic about 7 years ago.  In all that time, you are the first to complain.

When a bug is filed in SDOWP, it is typically made public so a customer can track it.  An internal change was recently implemented regarding enhancements.  Right now, there is no way for you to track it.  Though this may change in the near future.

Thanks and regards,

-George

Hello Daniel,

thank you for your thoughts on this issue.

The bootsetup is actually very few lines of C code with small memory footprint that uses the linker generated copy table to copy code/data to its final location. Very simple. Otherwise one had to use the TI Perl script to convert the .out file to AIS and somehow add the memory test before code/data is being finally copied by the C6424-bootrom. Not sure this is even possible. Simply writing some lines of C seemed more flexible to me. And if you take a look at the SPRAAK5B documentation of the C642x bootrom it even suggests to use the JUMP command for Bootloader 2. Whether or not there have  already been loaded some sections by AIS shouldn't make a difference.

Regarding the compiler/linker question, I don't see any logical reason, why having linker generated copy tables inside .cinit should prevent applying the copy table operator with different run/load addresses to .cinit as the newer compilers suggest by throwing the error. The linker knows the load address, knows the run address and can resolve any references inside the copy records inside .cinit.

The older compilers did that correctly. At least it seems so, regarding the map-files of the 6.1.23 or 7.2.12 compilers for example. And its the more regular case than handling .cinit differently from the other sections.

So, I hope TI tells us, whether the older compilers have been generating correct code in that case or not. And secondly TI adds the more regular case to their newer compilers again.

Best regards,

Flux.

I think it would help if I explained, in general terms, how global variables are initialized, and how the .cinit section is related. (For those reading along, this explanation focuses on the older COFF ABI, which this customer uses. The newer EABI is much more common. There are some similarities at a high level. But the lower level details are quite different.)

Start by reading the section titled System Initialization in the C6x compiler manual for version 7.4.x. Ignore the EABI sections. Focus on the section titled Autoinitialization of Variables at Run Time. This comes closest to your case. The figure there is a bit outdated. Loader should be called Flash Programmer. EXT_MEM should be called FLASH. D_MEM should be called RAM.  

One key thing to understand is that the .cinit section performs a role similar to a copy table. Values start in .cinit, in FLASH. When the system turns on, the startup code processes entries in .cinit to copy those values to locations in RAM. The rest of the system has no idea this ever happened. It acts as if those values are always in the RAM location.

Consider the case where the .cinit section is allocated one address for load, and another address for run. The rest of the system acts like .cinit is always at the run address. When and how does the .cinit section get copied from load to run? The startup code, as supplied, cannot do it. I suppose the startup code be changed. But, so far as we knew, no one needs this capability. So, instead of changing the startup code, we put a diagnostic in the linker. This diagnostic is emitted any time the table operator is applied to .cinit. This diagnostic should have been in the linker when copy tables were introduced. However, this detail was overlooked.   The diagnostic was added later.

How does it work in your specific case? The .cinit section has different load and run addresses. All the rest of the system, including the startup code, acts as if .cinit is located at the run address. You use the AIS boot feature to copy .cinit from load to run. Because this copy completes before the startup code begins, it works.

Thanks and regards,

-George

Thank you for taking the time to provide additional insight.  I view these posts as additional reasons to implement a change in the linker.  I added them to CODEGEN-5079, which is still under review.

Thanks and regards,

-George

You still build your project with the older COFF ABI.  Unfortunately, COFF ABI support has ended.  We no longer plan to implement any improvements for the COFF ABI tools.  

If we agree to implement this change, it would only be available with the newer EABI.  Are you willing to change from COFF ABI to EABI?

Thanks and regards,

-George

Hello George,

thank you for your support. Let me put it this way:

Being able to load a program to a certain location in SDRAM is a must have for embedded applications. Please don’t see the .cinit copy table changes just dependent on our needs. These changes seem to have to be done anyways.

The current 8.2.x compilers are relatively new and we don’t intend to use them for maintaining our C64x+ single core code. Also, first tests show, that our code runs about 15% slower than by using the 6.1.23 CGT. But maybe that’s a cache issue. Don’t know.

Another problem indeed is eabi. The bootloader/application configuration described earlier requires the same calling convention. So, switching to eabi is most likely not an option for this project. Further on TI’s fast RTS library officially comes in coff only. Yes, there is an unofficial elf version somewhere on the forum…

So, the right choice would be to use the 7.4.x compiler, which is mature, supports coff, is comparably fast in coff mode and has been maintained until 2017. Unfortunately if you say you don’t intend to make the changes to them, we will have to stay with the 6.1.23 CGT of 2013 for this project, which is a bit disappointing. On the other hand, the code works very well using the CGT 6.1.23.

The 7.4.x compiler is of status “reactive”. Following your terminology, it means changes can done on a need basis. Using the latest, mature CGT 7.4.x should be the way to go.

Best regards,

Flux.

Once again, thank you for your feedback.  I have added it to the entry CODEGEN-5079, which is still under review.

Thanks and regards,

-George

Here is an update regarding CODEGEN-5079 ... You can look it up with the SDOWP link below in my signature (well, in a few hours).  A fix for COFF ABI will not be implemented.  A fix for EABI is not currently planned, but might be implemented in the future.

Thanks and regards,

-George

I acknowledge our decision has a negative impact on you. Please accept our apologies. I do not expect this post to change your mind. But I hope to explain our decision enough to show that it was reached after careful and diligent consideration. But first I will discuss how you can continue useful work today.

You are welcome to use C6000 compiler version 6.1.23 in combination with CCS version 8.x. The obvious advantage is your system continues to work as is. The downside is you don’t get to use any new features introduced in later versions of the compiler. I suspect that is not of much concern.

Switching to an explanation of our decision …

We have proof, by direct experiment in the field, that, except for you, our customers do not need to copy .cinit from one memory location to another. The linker started issuing the error diagnostic that prevents this copy about 7 years ago. In all that time, you are the only customer to complain.

Why do we no longer support COFF ABI? Removing support for COFF ABI reduces our maintenance and test burden by half.   That is very significant. We introduced support for EABI about 8 years ago. We are confident nearly all our customers have switched to EABI. At some point, we have to tighten our focus on to the use cases most common among our customers. That is the level of support those customers require, and we intend to provide it.

Therefore, we have no plans to fix this issue for COFF ABI. We may yet fix it for EABI, but even that is unlikely.

You raise these points …

Flux said:

The changes to copy tables prevent a) early system hardware/ram tests before the actual application code runs, prevent b) copying a whole application from location A to B and starting it ( the classical, reliable bootloader/application approach).

Flux said:

please describe how requirements a) and b) can be fulfilled using the current and future CGT

I lack the expertise to answer, though I am confident solutions exist. I suggest you start a new thread on this question in the C6400 device forum.

Thanks and regards,

-George