Initializing and Using DDR while running from internal

I have another question and it fits to this topic too.

I have a global variable defined in a .c file, it's extern defined in a .h file.

In the c file, It was defined as:

Uint32 dtxa_6437_put_packet_fail;

But it gives a warning like this:

warning: Detected a near (.bss section relative) data reference to the symbol
            _dtxa_6437_put_packet_fail defined in section .external.  The
            reference occurs in
            S:\\ddx4\\ddx4\\dsp\\bootrom\\dtxa_6437\\Debug\\dtxa_6437_enet_test_functions.obj, section .text, SPC offset 00000008.  Either make the symbol near data by placing it in the .bss section, or make the references to the symbol far.  For C/C++ code use 'far' or 'near' modifiers on the type definition of the symbol or compile with the --mem_model:data switch.

So I redefined it as:

far Uint32 dtxa_6437_put_packet_fail;

but the warning still continues. What should cause this problem?

Note: .bss is map to internal memory. but I map this variable to DDR using #pragma DATA_SECTION(dtxa_6437_put_packet_fail,".external");

Thanks.

I believe most of your questions can be answered within SPRU187, the optimizing compiler guide, as it defines what the .bss section is and also other information about what it means to have a far versus near modifier.

The .bss section is where global and static variables are stored, that is if you have a variable and it is not local on the stack, it is probably here (the DATA_SECTION pragma and far keyword you mention can change this). It is an uninitialized (by the binary image) section, so it is really just a reserved space in RAM that the executable can create and store variables in, however if there are variables with an initial value they are set during the c_int00 call which initializes the C environment, this being said the location of .bss must be accessable before c_int00 runs (i.e. your DDR must be configured in the boot loader if anything in your .out file references it). The .far section is essentially the same thing for variables that are declared as far.

The reason you have far is because a load instruction on the C6x requires a relative address that has only a certain range (32k) so if you have data that is too far from the data page pointer it can go into the far section. The advantage of using the near model is that the code can be faster with single instruction loads, with the far section it means that it takes multiple instructions to access the data but you can have more data, this is discussed a bit in section 6.4.4.1 of SPRU187 mentioned above. I believe your second issue with the warning is covered by this section, the fact that you used DATA_SECTION implies that the variable is referenced using the far method, therefore anywhere this variable is referenced it must have the far keyword (i.e. your header file should declare it extern far).

Bernie, thanks for the answer.

If I don't get it wrong, you say that DDR must be configured in boot loader if anything in .out file references it. The sections .far and .bss are map to internal memory. But I map some of the far and global variables to DDR using pragma. None of this variables are used before the DDR initialization. Is this still a problem?

Theoretically if they are never written to or initialized to a value before DDR is initialized than the values themselves should be ok, though it is possible that there is something else that will force you to have the DDR ready before c_int00 that I am not thinking of off the top of my head, in general I would suggest having the external memory initialization in the boot loader as a 'good engineering practice' as it takes away any doubt of corruption related to DDR and allows you to more freely allocate variables.

Usually a failure to execute when running from flash when the same code works when running from a CCS JTAG load will relate to device initialization, in particular the DDR and sometimes the clocks and such that the GEL file handles when loading from CCS that must be handled instead by the boot code (and could be handled incorrectly or not at all).

Bernie, thanks for answer.

I know the external memory should be initiazlied in the bootloader, but this project itself is our boot project, which should be burned to flash, and when it is run, should initialize the hardware and download the system project code.

But we have some problems on the size of the project and can't fit into internal memory.

I tried the solution above, and it runs without any problem, at least for now. Nothing is forced to DDR before c_int00 and before it is initialized. But, if you can can give any document reference about the boot loader that you mentioned, I will examine it. Thanks again.

Hi Bernie,

I have a question regarding .bss.  I have run Qualiti tool and XDAIS rule 26 fails with this error:

********************************************************************************************

Test failed. Found a '.bss' section in object file 'platefinder_csync_det_hipf2.o64P'. It is a nightmare for ROMing and also has some total-application-size limits since .bss must be < 32Kb.

Fix this problem by finding the offending data and making it far or const, or rebuild the library with --mem_model:data=far.

*********************************************************************************************

I am using  Bios, under linux not ccs.  I have tried to make global variables to be initialized  to 0 using zeroInitSectionsCmdFile in my .tcf file. Which worked. I have also followed the step in this thread and reference the variables using .far method but the test fail.

Any suggestions please?

Thanks

It sounds like at least something is being declared globally and is not making it to the .far section, have you tried putting the --mem_model:data=far flag into your compiler options for building the object file? Using that should force everything to .far for you, otherwise you would have to dig through and find what global is doing this, potentially some global that is being referenced by a header file which you may not necessarily want to change.

Hi Bernie,

Thanks for your quick reply.

 Which file do I change to add the compiler options on linux? I know on CCS is just ticking the boxes.

Thanks

Hi Bernie,

I modified the config.bld with the  following and it worked thanks.

var C64P = xdc.useModule('ti.targets.C64P');
C64P.platform       = "ti.platforms.evmDM6446";
C64P.ccOpts.prefix += " --mem_model:data=far " ;

Zoe

Hi Bernie,

even though the qualiti passed, I now receive the following warning/s when i run make the project

>> warning: Detected a near (.bss section relative) data reference to the symbol
            _VISA_checked defined in section .far.  The reference occurs in
            universal.o64P
            (/home/zoe/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/universal/lib/release/universal.a64P), section .text, SPC offset 00000010.  Either make the symbol near data by placing it in the .bss section, or make the references to the symbol far.  For C/C++ code use 'far' or 'near' modifiers on the type definition of the symbol or compile with the --mem_model:data switch.

>> warning: Detected a near (.bss section relative) data reference to the symbol
            _LogServer_stackSize defined in section .far.  The reference occurs
            in LogServer.o64P
            (/home/zoe/dvsdk_2_00_00_22/codec_engine_2_23_01/packages/ti/sdo/ce/bioslog/lib/release/bioslog.a64P), section .text, SPC offset 00000bb4.  Either make the symbol near data by placing it in the .bss section, or make the references to the symbol far.  For C/C++ code use 'far' or 'near' modifiers on the type definition of the symbol or compile with the --mem_model:data switch.

This means that something you are linking in, namely universal.o64P and LogServer.o64P, is not built with the same --mem_model:data=far option and contains objects that are referenced 'near' that you have defined as 'far'. This seems a bit strange to me as I would have expected them to be built this way out of the box, you may want to try rebuilding the entire DVSDK with a 'make clean' and than a 'make' to see if that helps with this. There may be something going wrong at a more foundational level here, as I would not expect the codec engine objects you are supposed to link in to have these near references, I may have to look into this further.

Thanks for your reply,

I have rebuild the entire DVSDK as suggested. The above warnings are still there.

Rebuilding the DVSDK content is probably too aggressive, and in many cases, impossible since we don't provide build scripts/sources to components like BIOS and others.

Memory models confuse me, too.  This article helps me when debugging similar build issues:

http://tiexpressdsp.com/wiki/index.php?title=C6000_Memory_models

Also, FWIW, when we built the universal.o64P library, this is the exact compile command we used:

# cl64P package/package_ti.sdo.ce.universal.c ...
/db/toolsrc/library/tools/vendors/ti/c6x/6.0.16/Linux/bin/cl6x -c  -qq -pdsw225 -pden -pds=195  -mv64p -eo.o64P -ea.s64P  -D__xdc_bld_pkg_c__=package.bld.c -Dxdc_target_name__=C64P -Dxdc_target_types__=ti/targets/std.h -Dxdc_bld__profile_release -Dxdc_bld__vers_1_0_6_0_16 -O2  -I. -I../../../../../hijacks -I../../../../../imports -I/db/toolsrc/library/tools/packages -I/db/rtree/install/trees/products/xdcprod-j57/product/Linux/xdctools_3_10_03/packages -I../../../.. -I/db/toolsrc/library/tools/vendors/ti/c6x/6.0.16/Linux/include -fs=./package/lib/lib/release/universal/package -fr=./package/lib/lib/release/universal/package -fc package/package_ti.sdo.ce.universal.c

No mem-model flag thrown, so we're getting the defaults as described on that article.

Chris

Thanks Chris for the info,

1. This means the default mem-model is far_aggregates..Correct.?

2. If so, are the above warnings  due to the fact that I am trying to force everything to use far mem-model? 

3. It is also suggested that linker diagnostic emitted when a data memory model mistake occurs is a warning, not an error. Can I ignore these warnings without consequences? if not,

4. To fix this, will it involves  far  declaration and near definition of my code variables manually inorder to match the default far_aggregates mem-model?

Thanks

Zoe

zoe said:

This means the default mem-model is far_aggregates..Correct.?

Yes, the default build of Codec Engine does not use the pure far model.

zoe said:

If so, are the above warnings  due to the fact that I am trying to force everything to use far mem-model? 

Yes, unfortunately it seems that though the QualiTI tool suggests using the forced far memory model, this will not be feasible with the out of the box Codec Engine (I am looking to have the QualiTI output mention this).

zoe said:

It is also suggested that linker diagnostic emitted when a data memory model mistake occurs is a warning, not an error. Can I ignore these warnings without consequences? if not,

In a typical use case this is actually an error (that is, a functionally crippling problem) and not a warning, it would only be a warning in some specific hand assembly use cases, as mentioned here.

zoe said:

To fix this, will it involves  far  declaration and near definition of my code variables manually inorder to match the default far_aggregates mem-model?

This looks like the only practical solution at the moment, so you would have to go back to your platefinder_csync_det_hipf2.o64P source C file and figure out what particular object is not being marked as far.

In the future you may be able to rebuild Codec Engine with alternative memory mapping options, but that is a road you probably do not want to go down today.

Bernie Thompson said:

In the future you may be able to rebuild Codec Engine with alternative memory mapping options, but that is a road you probably do not want to go down today.

Just a minor update here, if you want to rebuild codec engine there is a new article up here.