Hi Virginia, A couple of notes here :-
- At RTSC program configuration time, all packages that are part of an application (e.g. OS, CodecEngine, FrameworkComponents, Codecs, etc) are given the opportunity to contribute a set of libraries (via getLibs) and some corresponding linker command contributions (via getSects). These are linked together with the application sources and the application linker command file to build the executable. - All components delivered as packages should contain the required corresponding linker command file contributions needed for the integrator to correctly link the component into an application. The way a component programmatically provides this information is via the getSects() method of it's package (found in package.xs). This is usually done with a template file (e.g. link.xdt), which has access to the component and program configuration information and can therefore generate different linker command file contributions corresponding to the desired program configuration/usage. - The component producer is responsible for providing sufficient 'configurability' of the package so that it is easy to integrate into the targeted end-user applications - e.g. allowing the integrator to specify the name of the physical memory segments available on the board, or providing different performance options depending on available amount of memory. Better packages will have configuration options that better match customer usage models. - Codec component packages shouldn't provide linker command file contributions that place standard sections (e.g. .text, .bss, etc) - these sections will be placed by OS/Platform package linker definitions. - If all sections in a package are standard compiler sections, they will be placed by the main application linker command file without the component needing to configure this - in this case, the getSects() method may be empty. - If all sections in a package are sub-sections of standard compiler sections (e.g. .text:myFunction) they will also be placed by the main application cmd file - however, it may be beneficial for a package to provide configuration options for these sections to aid system integration and flexibility for the integrator. - If there are USER DEFINED sections (e.g. MYSECTION, EXTERNAL_CONST, ISRAM) - these should be placed by the package to ensure that the sections get placed properly in valid memory areas. If these section are not placed, the linker will place in the first available memory segment, which may not be correct. Now... to try to answer your question... - If a package doesn't provide its linker command file contributions, then you can work around this by adding these sections to your 'application' linker command file. The documentation for the package may give you a piece of example script that shows where and which sections should be placed. - If not, you can use some tools to look inside the library(ies) from the package to find out what sections are found inside the library. - How do you know what sections are contributed from a package and how big they are? - Run sectti utility from cg_xml tools, available at :- https://www-a.ti.com/downloads/sds_support/applications_packages/cg_xml/index.htm e.g. // Dump Section info from lib into XML format, then parse with sectti /codegen/bin/ofd6x -x MyLibraryFromPackage.lib | /cg_xml/sectti You should get some output that looks something like : ************************************************************ REPORT FOR FILE: MyLibraryFromPackage.o64P ************************************************************ Name : Size (dec) Size (hex) Type ------------------------------ : ---------- ---------- ---- EXTERNAL_CONST : 15936 0x00003e40 DATA ISRAM : 363 0x0000016b UDATA .text : 112768 0x0001b880 CODE .cinit : 2995 0x00000bb3 DATA .switch : 164 0x000000a4 DATA ------------------------------------------------------------ Totals by section type ------------------------------------------------------------ Uninitialized Data : 363 0x0000016b Initialized Data : 19095 0x00004a97 Code : 112768 0x0001b880 In this made-up example... this shows that EXTERNAL_CONST is an initialized data section of size 0x3e40 and ISRAM is un-initialized section of 0x16b. At this point, you can either guess (from the name?) where to place... or ask the component producer. You'll also need to find a valid memory segment with enough space to hold the section. A good place to look is at the available program memory segments information at the top of the map file - this is found in one of the generated files at <program>/package/cfg/<program>.<x*>.map **************************************************************************** TMS320C6x COFF Linker Unix v6.0.1 **************************************************************************** >> Linked Mon Dec 17 10:51:27 2007 ... MEMORY CONFIGURATION name origin length used unused attr fill ------------------- -------- --------- -------- -------- ---- --------L1DSRAM 11f04000 00010000 00000000 00010000 RWIX DDRALGHEAP 8f000000 00a00000 00a00000 00000000 RWIX DDR 8fa00000 00400000 003959a5 0006a65b RWIX DSPLINKMEM 8fe00000 00100000 00000000 00100000 RWIX RESET_VECTOR 8ff00000 00000080 00000000 00000080 RWIX - This shows an internal segment L1DSRAM and some external memory called DDR, both with sufficient unused space. In this case, you should be able to simply add the following to your link.cmd to cause these sections to be placed and the warning removed. '>> application link.cmd' SECTIONS { EXTERNAL_CONST > DDR ISRAM > L1DSRAM } - Bottom line though... the package(s) should be contributing this information, so that you (the integrator) don't need to spend much time on these items. This is one of the powerful features of RTSC components, enabling all component integration information (like link info) to be kept together with the libraries inside the package. This is new stuff though, so it will take a bit of time for component producers to start to leverage this capability, with good configuration options hopefully making integration much easier. Hope this helps a bit, ~roger ________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Faro Maza, Virginia Sent: 17 December 2007 16:30 To: [email protected] Subject: warning: creating output section EXTERNAL_CONST without SECTIONS Hi all, I am trying to build a codec engine server with some codecs shipped to us by TI. When I add the MPEG4ENC codec to my server and application, I get the following warning when the application links in the server: >> warning: creating output section EXTERNAL_CONST without SECTIONS Specification When I add the JPEGENC codec to my server and application, I get the same warning but for section ISRAM: >> warning: creating output section ISRAM without SECTIONS specification I believe I need to specify how those sections should be mapped into memory in the codecs' link.xdt and package.xs files (see http://www.mail-archive.com/[email protected]/msg02174.html), but I do not know which area of memory these sections should be mapped to. Any help would be much appreciated. Best regards, Virginia Faro-Maza American Dynamics Email: [EMAIL PROTECTED] ________________________________________ Tyco Safety Products/CEM Systems Ltd. Registered in Northern Ireland: NI 25728. Registered Office: Unit 4 Ravenhill Business Park, Ravenhill Road, Belfast, BT6 8AW.. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately and delete any copies in your possession. _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
