Freescale PowerPoint Template - NXP

TM

Freescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © Freescale Semiconductor, Inc. 2009.

Using the sc3000-ld StarCore® Linker for MSC8156 Applications

July 2009

Dragos Badea

TM

2Freescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective owners. © Freescale Semiconductor, Inc. 2009.

Content Overview

►Definition of terms►How things work, relations between terms ►How to define the virtual memory map and output sections►How to define multiple tasks on multicore►Target platform awareness and linker predefines►How to specify the virtual-to-physical memory mapping►About special input sections (lnk_section)►About linker intrinsics►Do’s and Don’ts

►SIMD, MIMD Cases

TM


Definition of terms

►Core - a hardware processing unit, for which, the linker needs to define code, data and other information

►Task - a static software unit, which has a unique ID to be recognized by the operating system and/or hardware. One or more tasks can be mapped on a single core.

► Input section - fragment of user code or data as they are in object files

►Output section - collection of input sections, it is placed in some memory area and it goes into executable file

►Unit - a LCF language construct used to enclose memory and section definitions for an explicitly specified set of tasks.

TM


Definition of terms (cont.)

►Private virtual - memory areas that are accessible by a single task►Private physical - memory areas that are accessible by a single core

►Shared virtual - memory areas that are accessible by a set of tasks►Shared physical - memory areas that are accessible by a set of cores

►Symmetric virtual - private virtual memory areas where the addresses of the contained objects are identical but the object content is different. It is useful for SIMD applications, where the code is shared and the data is private.

►Address translation - procedure to specify the physical address or physical memory range on which a virtual memory range is mapped

TM


Layout example in virtual memory space

Symmetric areas: same symbols/ addresses and different content.

Addr1 – Addr2 Reserved

shared areaAddr3 –Addr4

Addr1 – Addr2 Reserved

Symmetric area Addr5 – Addr56

Symmetric area Addr5 – Addr56

Addr7 – Addr8

Addr7 – Addr8

Task1

Task2

TM


Relations between terms

► More input sections are put together to build an output section

► Each output section is placed into a virtual memory area

► Each virtual memory area is mapped to a physical memory area

► Each symbol in an output section gets both a virtual and a physical address

► Some virtual memory areas are mapped 1:1 in physical memory, i.e. virtual and physical addresses are identical

► We usually refer to tasks in relation to virtual memory

► We usually refer to cores in relation to physical memory

► More tasks can be hosted on a single core

TM


Input and Output Sections

Input sections as they are generated by compiler

.dataOR* (.data)

Outsection1{.datafile1.eln(.tstdata)

}

.data in module1.eln

.data in module2.eln

.mydata in test1.eln

.mydata in test1.eln

.tstdata in file1.eln

.tstdata in file2.eln

file1.eln (.tstdata)

Referring the input sections in linker command files to create output sections

file2.eln (.tstdata)

.mydataOR*(.mydata)

Outsection2{.mydatafile2.eln(.tstdata)

}

How to define output sections in lcf

TM


Relations between terms

► Virtual memory areas can be shared between tasks. This is specified under “unit shared” constructs

► Shared virtual memory areas should be mapped to shared physical memory areas. This is specified under “address_translation” constructs

► Tasks that share virtual memory areas should be hosted on cores that can access shared memory areas

► A symbol S defined in a section placed in a shared virtual memory area SM can be referred by shared and private sections of the tasks that own SM

► A symbol S defined in a private virtual memory PM of task T can be accessed from:• Private sections of the task T• Shared sections of a group of tasks GT where T is in GT, and provided that PM is symmetric (i.e. all

the other tasks in GT do define S in their private sections and S is placed at same address in all private memory areas)

TM


How to define virtual memory areas

► GNU similarity when specifying the virtual memory areas and input/output sections

memory{m3_shared_data_nc_wt ("rw"): org = _M3_SHARED_start, len = 1000;m3_shared_data_c_wb ("rw"): after(m3_shared_data_nc_wt);

…..} Parameters to be specified:

Name of the virtual memory areaAccessibility attributesorg – start address should be an expression that can be evaluated before memory layout takes placelen – maximum length, may miss and the linker computes the minimum sizeafter – indicates that linker should start placement after the end address of the virtual memory area received as parameter

► Flexible specification using after directive or missing len specification will increase the problem search space and the linking time

TM


How to define output sections

sections{ outsec_data {

.cacheabledata

. = . + 0x100;OneTestSymbol = . ;.dataalign(0x200);file2.eln (.tstdata)

} > vmemory1 ;

outsec_text{.text

} > virtual2;}

• Create an output section of several input sections with the sameattributes; this is important for cache-ability attributes because of later MMU attributes setting

• Location counter can be modified, aligned, used in expressions

TM


Extensions for multi-task model

►UNIT structured lcf language construct allows multiplication of enclosed MEMORY and SECTIONS specification for multiple tasks

unit shared (task1, task2) {memory{

m3_shared_textboot_c ("rx"): org = _VBAddr, len = _BootCodeSize; }sections{

outsect_text_boot {.intvec , .text_boot} > m3_shared_textboot_c;

}}• Creates one virtual memory area, shared for the two tasks mentioned in the

task list of UNIT construct and where output section boot code is placed

TM


Extensions for multi-task model (cont.)

unit private (task1, task2) {memory{

data_boot_c ("rw"): org = _VIRTUAL_DATA_BOOT_start, len = _DATA_BOOT_size;}

}• Creates private virtual memory areas for each of the two tasks

mentioned in the task list of the UNIT construct

unit symmetric (*) {memory{

m2_private_data_c_wb ("rw"): org = VIRTUAL_PRIVATE_DATA_start;}

}• Creates symmetric virtual memory areas, one for each of the tasks

defined in lcf (wildcard usage in the task list of the UNIT construct)

TM


Extensions for multi-task model (cont.)

unit private (task1, task2) {memory{

local_reserve RESERVE ("rw"): org = ReserveStart, len = ReserveLen; }

}• For each of the two tasks in the list, makes the virtual memory allocation

to not utilize the reserved area for code and data placement

unit shared (*) {memory{

some_reserve RESERVE ("rw"): org = ReserveOrg, len = ReserveLen; }

}• For all tasks in the list, makes the virtual memory allocation to not utilize

the reserved area for placing code and data

TM


Target architecture specification► It is recommended that for each linking process, the target

architecture is identified by arch directive:arch(msc8156);arch(msc8144);

Other possible values for arch names are: sc140, sc140e, sc3400, sc3450, sc3850

► For homogenous multicore targets, one can define a subset of cores for which the linking is performed, using number_of_coresdirective

number_of_cores(3);

TM


Target architecture specification (cont.)

► Based on the architecture specification, the linker:• Loads platform model of cores, physical memories, MMU features• Predefines names and ranges of physical memories, e.g. M3,M2,DDR• Predefines symbols that are unchangeable on hardware architecture e.g.

MMU_PROG_L2CACHEABLE

► There are two linker options to enable/disable temporary lcf file generation by the machine model:

-disable-emit-machine-model-lcf-enable-emit-machine-model-lcf (this is the default option)

► User may override the defaults redefining the symbols and physical memories where the following overlapping rules are supported and the LCF user definition takes precedence

Private physical memory overlaps private physical memory rangeShared physical memory overlaps shared physical memory range AND the sharing list of cores is the same

TM


Physical memory definitionphysical_memory shared (core0, core1){

M3 (“rwx”): org = 0xd0000000, len = 0xa00000;DDR (“rwx”): org = 0x40000000, len = 0x10000000;

}Accessibility qualifier:

– shared - all cores may access the physical range– private –memory areas are created for each of the cores in list

Name of physical memory (e.g. M2,M3,DDR)org – start addresslen – maximum length

► Specification of internal physical_memory is NOT needed usually if arch spec is used

It is recommended that arch specification is used Predefined names of physical memories are at hand to be used: e.g M2,M3Predefined related symbols are at hand : e.g _M2_size, _M2_start, _M2_end

TM


Physical memory definition (cont.)physical_memory shared (core0, core1){

reserve: org = 0xc0040000, len = 0x1000;}

• Reservation of physical memory areas let the linker know not to occupy the specified areas during the physical memory allocation phase

physical_memory shared (core0, core1){DDR5 (“rwx”): org = 0x50000000, len = 0x10000000;

}physical_memory private (core2){

PPM (“rwx”): org = 0x90000000, len = 0x40000;}• Specification of physical_memory is cumulative

it works even if arch spec was used linker verifies memory overlapping ranges

TM


How to define multiple tasks on multicore

►Linker implicitly creates one task on each core, (task0_c0, task0_c1, …). To override this, multiple tasks can be described for each core with tasks LCF language construct.

tasks{ //core_name: task_name, task_id, pid, did;

c0 : sys0, 0, 0, 0;c0 : sw01, 2, 2, 2;……….c3 : sys3, 0, 0, 0;

}• NOTE: tasks are not explicitly specified at C level with new language

extensions; instead, using the application file or __attribute__ declaration, the associated code and data can be placed in specific input sections that can be associated in LCFs to the task where they belong

TM


How to do virtual-to-physical memory mapping

address_translation (sys0, sys1, sys2, sys3) map11{

m_shared_m3_x ( SYSTEM_PROG_MMU_DEF ) : M3;m_shared_m3_d ( SHARED_DATA_MMU_DEF ) : M3;m_shared_ddr_d (SHARED_DATA_MMU_DEF) map11 : DDR;

}Mapping all the virtual memory areas belonging to the specified list of tasks to specific physical memory areasIf the virtual memory area is a shared one, it will be mapped only once to a shared memory but an entry will be created for each of the MMUsmap11: physical address is the same as virtual addressIf map11 is used and org and len specified for virtual memory area does not fulfill architectural restrictions, the linking process will stop with an errorUltimately, the linker uses all this info to do the MMU programming. In this process it also needs the MMU attributes captured in symbols SYSTEM_PROG_MMU_DEF and SHARED_DATA_MMU_DEF.

TM


How to do virtual-to-physical memory mapping (cont.)

address_translation (*){data_boot_c (SYSTEM_DATA_MMU_DEF): M2,

org = _PRIVATE_DATA_BOOT_start, len = _DATA_BOOT_size;m2_private_text_c (SYSTEM_PROG_MMU_DEF): M2;m2_private_data_c_wb (SYSTEM_DATA_MMU_DEF): after (m2_private_text_c);}

It is recommended that the origin of physical placement is defined by orgspecification. This reduce the problem search space and linking time. Even more reduction can be achieved if specification of exact length of mapped region is present with lenBoth org and len are optional in mapping specification and this provides highestflexibility degree in specification. Note that even not very frequent usage of this flexibility on multicore platforms can quickly increase the problem search space to degrees that will trigger internal thresholds of the memory placement algorithm Usage of after may represent a good trade-off between the above specification solutions as it offers easier specification method for users and may also reduce the problem search space

TM


How to do virtual-to-physical memory mapping (cont.)

address_translation (*){reserve (SYSTEM_DATA_MMU_DEF): paddr, vaddr, size, “rwx”;}

Reservations for MMU entries must be fully specified with physical and virtual start addresses, size and other attributesOne MMU entry will be generated on the host core of each of the tasks in the listLinker evaluates the reservation for each task (the expressions paddr,vaddr,size are evaluated in task context)The virtual memory region [vaddr, vaddr+size-1] is reserved The physical memory region [paddr, paddr+size-1] is reserved

Overlapping rules for tasks on the same core– Perfectly overlapped reserved regions (in physical and virtual space) are

considered legal and shared to involved tasks;– Partial overlapping (in physical space) is illegal and the linker exits with an

error;

TM


About special input sections

lnk_section (sectiontype, “rwx”, size, alignment, sec_name);

• Provides info to linker for some ‘input’ sections that are not actually received from input module files

• Instead, these sections are created at link-time • lnk_section placement in output section content determines the layout of the

special input sections• sectiontype field can be one of the following section types:

BSSATT_MMUSTACKSTACK_AND_HEAPHEAP

• size field is the length of the newly created section• alignment field is the alignment restriction of the newly created section• sec_name field is an user selected name for the linker created section, name that

can be further referenced in lcf files

TM


About special input sections(cont.)

lnk_section (ATT_MMU, “rw”, MMU_TABLE_size, 0x100, “myattmmu”);• Reserves space for an ATT_MMU section whose content is generated

by linker • Placing lnk_section in definitions of output sections have similar effect

as if the section were a true input section read from module files

lnk_section (STACK, “rw”, StackSize, 0x100, “mystack”);• Reserves space for a stack section • Symbols for bottom and top of stack can be defined using intrinsics

lnk_section (HEAP, “rw”, 0x4000, 0x100, “heap”);• Reserves space for a heap section • Symbols for bottom and top of heap can be defined using intrinsics

lnk_section (BSS, “rw”, BSS_size, 0x1000, “lnkbss”);• Creates a bss section

TM


Linker intrinsics

►Can be context-dependent or context independent

• Context-dependent intrinsics can only be used in certain scopese.g. align() intrinsic aligns location counter and can be used only in sections

• Context-independent intrinsics can be used anywhere in the LCFeg. num_task() returns the total number of tasks

►Some of them can be evaluated only after the layout phase is complete and may be used in expressions to define symbols

e.g. sizeof(“output_section_name”)

TM


Linker intrinsics table (1)

Name Functionality Usage scopealign(align-value) align location counter to

align-valueSECTIONS

sizeof(“sec_name”) size of input /output section UNIT, ADDRESS_TRANSLATION

originof(“sec_name”) virtual start address of input /output section

UNIT

endof(“sec_name”) virtual address of input /output section end

UNIT

vmorg(“vm-name”) virtual start address of virtual memory space

UNIT, ADDRESS TRANSLATION

physical_address(“sym_name”) physical address of symbol anywhere

to_physical(“virtual_address”) Physical address mapping to virtual address

UNIT, ADDRESS_TRANLATION

TM


Linker intrinsics table (2)

Name Functionality Usage scopetask_id() current task ID UNIT,

ADDRESS_TRANSLATION

num_task() total number of cores anywhere

core_id() current core ID UNIT, ADDRESS_TRANSLATION

num_core() total number of cores anywhere

defined(“symbol name”) if a symbol is defined in a input file

anywhere

assert(expression, “message”) linker exits with custom error message in case the expression does not evaluate to true

anywhere

. location counter SECTIONS

TM


Preprocessing capability

►Two types of comments:• Single-line //• Multi-line /* … */

►Includes• Syntax: #include “file_name”• Includes cannot be nested more than 10 levels deep

►Defines• 2 types:

macro: #define symbolassignment: #define symbol value

►Conditionals• #if, #ifdef, #else• Expression operators: ||, &&, ==, !=, >, >=, <, <=

TM


Other syntax considerations

►Keywords are accepted both uppercase and lowercase, not mixed

►C/C++ style comments are accepted for single line and multi-line

►For symbol definitions, use C-like assignment expressions• Expressions may use linker intrinsics whose evaluation is context dependent

►All white spaces, tab and newline characters are ignored

TM


The Do Not’s

►Do NOT define an absolute symbol and expect that the section containing that symbol is placed relative to that symbol.

►Do NOT set the length of virtual or physical memory areas using expressions dependent on intrinsics that compute the size or origin of sections or virtual memory areas.

►Do NOT set the origin of virtual or physical memory areas using expressions dependent on intrinsics that compute the size or origin of sections or virtual memory areas.

►Do NOT generate debug information on MIMD projects built from different C-sources for each core (known tool limitation).

TM


SIMD, MIMD cases

TM


SIMD

►We have seen usual use cases with below characteristics• SIMD like• Code is shared• Some data is shared• Some data is in symmetric areas

Un-initialized data Identical initialized data content for all cores

This type of application is generated from same C sources.There is no indication at C level that the target is multicore, only the linker

is aware of this configuration by LCF.

TM


SIMD (cont.)

► Similar to the previous case, plus one more characteristic• Different initialized data content for all cores

This type of application is generated from different C sources.Write the private initialized data in different modules for each core

Special indication needs to be done in application file to lock data in different modules to associated cores

data = [Data0 : ".data" core="c0" /* private section c0`.data for core 0 */, ...]module "private_data_c0" [ data = Data0 ]

In LCF, use symmetric areas and core filtered input sections

unit symmetric (*) {memory {

private_init ("rw"): org = _VIRTUAL_PRIVATE_MEM_DATA_start;}

sections{someoutsec {

c*`.data} > private_init ;

}}

TM


MIMD►Pure MIMD applications

• No shared code • No shared data• No symbol name reuse from one core to another (i.e. all symbols are unique at application

level)

This type of application is generated from different C sources. It is recommended that each C-file source belongs to only one of the cores

Use the application file to lock data in different modules to associated coresdata = [Data0 : "data_for_core0" /* private section for core 0 */, ...]

module "private_data_c0" [ data = Data0 ]

In LCFs all UNIT specs are private

unit private (task0_c0) {memory {

true_private_1 ("rw"): org = _VIRTUAL_PRIVATE_MEM_DATA_start_1;}sections{

outsec1{" data_for_core0"

} > true_private_1;}

}

Freescale PowerPoint Template - NXP

Documents

Transcript of Freescale PowerPoint Template - NXP