Groups



Login

NDK



DSP

The SI-C667x product line is based on Texas Instruments Keystone Hardware and Software modules. TI's documents and resources are highly recommended for users to fully understand the architecture and utilization of the SI-C667xDSP board. Below is a breakdown of C667x key NDK features and links to learn how to use them.


Software

Main

 BIOS_start();  

The "after main()" startup sequence is governed by SYS/BIOS and is initiated by an explicit call to the BIOS_start() function at the end of the application's main() function. The SYS/BIOS startup sequence that run when BIOS_start() is called is as follows: 1. Startup Functions. Run the user-supplied "startup functions" (see BIOS.startupFxns). If the system supports Timers, all statically created timers are initialized at this point using their static configuration. If a timer was configured to start "automatically," it is started here. 2. Enable Hardware Interrupts. 3. Enable Software Interrupts. If the system supports software interrupts (Swis) (see BIOS.swiEnabled), then the SYS/BIOS startup sequence enables Swis at this point. 4. Task Startup. If the system supports Tasks (see BIOS.taskEnabled), then task scheduling begins here. If there are no statically or dynamically created Tasks in the system, then execution proceeds directly to the idle loop

Threads (Startup, HWI, SWI, Task and Idle)

Startup

 Startup.lastFxns.$add('&EVM_init');  : Last in a list of functions called after module startup
 var tskNdkStackTest  		=   Task.create("&StackTest");
 tskNdkStackTest.stackSize  	= 	0x2000;
 tskNdkStackTest.priority    = 	0x6;

Tasks represent independent threads of control that conceptually execute functions in parallel within a single C program; in reality, concurrency is achieved by switching the processor from one task to another.

When you create a task, it is provided with its own run-time stack, used for storing local variables as well as for further nesting of function calls. Each stack must be large enough to handle normal subroutine calls and one task preemption context. A task preemption context is the context that gets saved when one task preempts another as a result of an interrupt thread readying a higher-priority task. All tasks executing within a single program share a common set of global variables, accessed according to the standard rules of scope defined for C functions.

Each task is in one of five modes of execution at any point in time: running, ready, blocked, terminated, or inactive. By design, there is always one (and only one) task currently running, even if it is only the idle task managed internally by Task. The current task can be suspended from execution by calling certain Task functions, as well as functions provided by other modules like the Semaphore or Event Modules. The current task can also terminate its own execution. In either case, the processor is switched to the highest priority task that is ready to run.

You can assign numeric priorities to tasks. Tasks are readied for execution in strict priority order; tasks of the same priority are scheduled on a first-come, first-served basis. The priority of the currently running task is never lower than the priority of any ready task. Conversely, the running task is preempted and re-scheduled for execution whenever there exists some ready task of higher priority.

Idle

 var Idle = xdc.useModule('ti.sysbios.knl.Idle');
 Idle.idleFxns[0] = "&hBeatFxn";

The Idle module is used to specify a list of functions to be called when no other tasks are running in the system. If tasking is enabled (ie BIOS.taskEnabled = true), then the Task module will create an "Idle task" with the lowest possible priority. When no other tasks are running, this idle task runs in an infinite loop, calling the list of functions specified by the Idle module. If tasking is disabled (ie BIOS.taskEnabled = false), then the idle functions are called in an infinite loop within the BIOS_start function called within main().

The different thread types main differences outlined below:

  • HWI has the highest priority and is associated with hardware interrupts; can preempt SWI, Task and idle, and cannot be preempted by other threads.
  • SWI has second highest priority and is associated with software interrupts; can preempt Task and idle, and won't be preempted by Task and idle.
  • Task has second lowest priority and is not associated with interrupts; will be scheduled by SYS/BIOS when there is no active HWI or SWI running. Task threads also have peer priorities.
  • Idle has the lowest priority, would only run when there is no active HWI, SWI, or Task.

For more programming details, please refer to the SYS/BIOS User's Guide:


TI NDK

The TI-RTOS Networking or TI NDK (Network Development Kit) combines dual mode IPv4/IPv6 stack with some network applications, and is not included with CCS. Therefore, the TI NDK must be separately downloaded; for more details and documentation, please refer to the TI web page:

Please note that NDK interfaces NETCP directly and does not utilize the PA; which is to say that the hardware stack will filter some of the incoming packets while the NDK software stack will filter out rest of the packets. The PA provides better performance but requires a steeper learning curve. As such if used and properly configured, the PA will increase performance since unnecessary packets will be filtered out on the hardware level. However, the NDK provides a simpler interface allowing the user to easily port Host side socket code to the DSP side.

According to TI:
TI provides both NDK and PA LLD. The application can either use NDK or PA LLD with a network stack provided by the customer. If you choose to use the NDK, your application should interface with the NDK only, i.e. invoking NDK APIs for all data traffic. If you choose to use the PA LLD, you need to write your own network stack to interface with the PA LLD and other low layer software stacks such as CPPI and QMSS LLDs.

TI & SI PDK

TI PDK (Platform Development Kit) is a package that provides the foundational drivers and software to enable the device, and is included with CCS. From a software development perspective, the SI-C667xDSP board has differences with the TI EVM and therefore SI provides a customized TI PDK package for its users. To use the SI PDK and create projects with CCS, the following steps must be performed:

  1. Copy everything inside DSPApplications/pdk folder into $ti_installtion\pdk_C6678_1_1_2_6\packages\ folder (the path is usually C:\ti\pdk_C6678_1_1_2_6\packages\).
  2. Open CCS and click 'File Tab->Import'.
  3. Choose 'Existing CCS Eclipse Projects', then 'Next'.
  4. Select 'Search-Directory', and browse to the path where the project is copied into.
  5. Select 'platform_lib_evmc6678l'; do NOT select 'Copy Project Into Workspace'.
  6. Select 'Finish'.
  7. Build the project under the 'Release Configuration'.
  8. From here on out and in order to build a SYS/BIOS project for the SI-C667xDSP board, right click the project name inside CCS and select 'Properties'.
  9. Go to the 'RTSC' tab.
  10. In the 'Platform' drop-down menu, select 'ti.platforms.evm6678'.
  11. Once the platform is selected, initialization should be done on the DSP side via the EVM_Init function before running any DSP programs. Please refer to the EVM_init function inside the Sample_Ethernet project for the platform initialization code. Please note that platform initialization should only be run once in applications where programs may be running in multiple cores. The initialization code should therefore be first called in one core and then the other subsequent cores should wait for the initialization to finish execution before proceeding to BIOS_start().

TI Software Libraries

TI provides some really useful C6x software libraries for use on the C667x. The Mathlib in particular is a well optimized and useful library. Please refer to the TI web page:


SI DSP Demos

SI provides several DSP demo projects, and are designed to work in conjunction with their corresponding Host side demo projects.

Sample_DSP_C667x
This project contains a simple heartbeat loop and some basic arithmetic commands. To use this project, open HostExampleApp and use option '1' to load the precompiled 'sample.out' binary file to the DSP, then use option 'm' for the interactive display.

Sample_Ethernet
This project contains a simple TCP echo server running on the DSP side. It demonstrates initialization and utilization of the TI Keystone Ethernet interface. Please note that the SI PDK is required along with any Ethernet projects that run on the SI-C667xDSP board; refer to the PDK section for additional details. The workflow for this project is listed below:

  1. EVM_init is called. It initializes the hardware platform and writes correct configuration values into key hardware registers, such as the PLL and Ethernet. Refer to the pdk section for more details about this phase.
  2. main is called. It only serves to call the BIOS_start function.
  3. TaskMain is called. After BIOS_start is called, the SYS/BIOS will start its thread scheduler. TaskMain is called as it's the only registered thread in this project. The first half of TaskMain provides a sample configuration of the Ethernet interface hardware modules, and includes the QMSS, CPPI and PA. For more details on these aforementioned modules, please refer to the Ethernet section. The second half of TaskMain provides a sample configuration of TI NDK stack, and includes setting up the DHCP and the recv/send buffer limit for TCP/UDP. At the end of the function, NC_NetStart will be called, and the NDK will start processing all the configurations.
  4. After configuration is processed and an actual IP is bonded with the program, NetworkIPAddr will be called. Inside this function, TaskCreate is called to start running the TCP echo server thread. Please note TaskCreate is a wrapper function from NDK and is equivalent to creating a task with SYS/BIOS.
  5. ServerThread is called. The TCP echo server code will be running.

TODO

h1. PDK

Modifications to the TI C6678 EVM PDK to operate with our hardware.

{{TOC}}

h2. platform.c

h3. EMAC Port Selection

When the PDK builds its configuration descriptors for the EMAC ports, it determines how to enumerate the ports based on an enum _emac_port_mode_. This enum tells the constructor functions what mode the port should be configured to. There are two emac ports on the C6678 and they are represented by the 0 and 1 types specified in the _emac_port_mode_ enum.

The array 'emac_port_mode' is defined in platform.c.

⚠ <pre> /* This structure holds information about the EMAC port on the platform */

  1. pragma DATA_SECTION(emac_port_mode,"platform_lib");

PLATFORM_EMAC_PORT_MODE emac_port_mode[PLATFORM_MAX_EMAC_PORT_NUM] = {

    PLATFORM_EMAC_PORT_MODE_PHY,     //Port 0
    PLATFORM_EMAC_PORT_MODE_NONE     //Port 1

}; Note: Our PHY is on Port 0. The EVM board uses Port 1. ⚠ </pre>

The enum type _PLATFORM_EMAC_PORT_MODE_ is defined in platform.h.

⚠ <pre> /**

 * @brief Indicates the EMAC port mode
 *
 */

typedef enum {

    PLATFORM_EMAC_PORT_MODE_NONE,
    /**<EMAC port not used */
    PLATFORM_EMAC_PORT_MODE_PHY,
    /**<EMAC port connected to a PHY */
    PLATFORM_EMAC_PORT_MODE_AMC,
    /**<EMAC port connected to the backplane AMC chassis */
    PLATFORM_EMAC_PORT_MODE_MAX
    /**<End of port mode */

} PLATFORM_EMAC_PORT_MODE;

⚠ &lt;/pre&gt;

h3. platform_init

h4. PASS PLL

The function will test various config flags( arg passed to platform_init(platform_init_flags, ...)) to see which systems on the chip need to be configured. The first test is to configure the PLLs. We do not need to set the Main PLL as that is done through the I2C boot, but we do need to setup the PASS PLL. The relevant code can be moved outside the PLL configure check to force the PASS PLL configuration. The following is the required PASS PLL configuration code:

Note: This is located in platform_init(...) inside platform.c

⚠ &lt;pre&gt;

            status = SetPaPllConfig();
            if (status != CSL_SOK) {
                platform_errno = PLATFORM_ERRNO_PLL_SETUP;
                return ( (Platform_STATUS) Platform_EFAIL);
            }

⚠ &lt;/pre&gt;

The function _SetPaPllConfig_ is defined in evmc6678.c and by default uses the configuration settings for a PASS CLK of 100 Mhz. Our board's boot configuration disables the input PASSCLK and switches the PASS Clock source selection multiplexer to use the CORECLK input.

This clock is used to clock the NetCP which requires a 350 Mhz clock. The PASSPLL has an automatic divide by 2 and there is an additional divide by 3 before the input to the NetCP.

Note: 'DNUM' value in this function should refer to core 0 so that this is only run if coe zero is running this code.

h4. PowerUpDomains

This function is defined in evmc6678.c and enables various system domains through the PCS (Power Sleep Controller). At this time it is not necessary to power up the EMIF4 or the EMIF25/SPI. The relevant lines of code should be commented out.

⚠ &lt;pre&gt; void PowerUpDomains (void) {

    ...

    /* Enable the clocks for PASS modules */
    //CSL_PSC_setModuleNextState (CSL_PSC_LPSC_EMIF4F, PSC_MODSTATE_ENABLE);
    //CSL_PSC_setModuleNextState (CSL_PSC_LPSC_EMIF25_SPI,  PSC_MODSTATE_ENABLE);

    ....

} Note: PowerUpDomains(void) can be found in evmc6678.c ⚠ &lt;/pre&gt;

h4. PHY Config

The PHY Config flag should be set and this will cause the PHYs to be configured. The PHY configuration function _Init_SGMII_ takes as its argument the MDC/MDIO address of the device to configure. Our Marvell 88E1111 is presently wired to address/port 0x0.

Note: This can be found in platform_init(...) inside of platform.c In the examples EVM_init() sets the Phy config flag(p_flags->phy) and calls platform_init(flags, ...) ⚠ &lt;pre&gt;

    if (p_flags->phy)     //<--phy config flag
    {
        configSerdes();
   	 mNotify(0x61);
        Init_SGMII(0);    //<--we use macPortNum = 0
        //Init_SGMII(1);
    }

⚠ &lt;/pre&gt;

h3. NOTE: Revisit _Init_SGMII()_ and the need for modifications if needed

h2. evmc6678_phy.c

h3. configSerdes()

Change the SERDES PLL multiplier and divider settings to match the input reference clock SRIOSGMIICLK input.

In the Gigabit Ethernet (GbE) Switch Subsystem User Guide there is a table on page 3-82 that shows the available PLL multiply options. There is an automatic divide by two on the PLL output and the final output frequency needs to be 1.25 Ghz. So the PLL multiplier and divider settings for the SRIOSGMIICLK input clock should result in an output frequency of 2.5 Ghz which will then be divided by two.

For 312.5 Mhz *Multiply by 8 uses 0x41

⚠ &lt;pre&gt; CSL_BootCfgSetSGMIIConfigPLL (0x00000041);⚠ &lt;/pre&gt;

For 250 Mhz *We use 250 Mhz so we multiply by 10

⚠ &lt;pre&gt; CSL_BootCfgSetSGMIIConfigPLL (0x00000051);⚠ &lt;/pre&gt;

h2. TODO

1. Verify _Init_SGMII()_ sections need for changes or not. 2. Write function to convert binary as hex and assign to array.

h2. Random

1. Encountered a build error: Two resources of the same name: /blah/blah/blah generated by different tools tool1: C6000 Compiler tool2: C6000 Compiler

Only seemed to disappear once I cleaned all project without rebuilding at the same time. Until then builds would only show this error in a pop up but not the output window. All binaries created would fail when loaded After I did a clean all, then build platform, and finally a build of my project did my binary work on the new system -Perhaps a clean with build is not a full clean

2. The webpage uses a mixture of generated web pages and a pre-existing default.htm file to create the webpage

TODO Pt2

h1. NDK

{{TOC}}

h2. Notes

h3. Getting started

h4. Set up network services:

THIS MUST BE THE ABSOLUTE FIRST THING DONE IN AN APPLICATION before using the stack!!

    int NC_SystemOpen( NC_PRIORITY_LOW, NC_OPMODE_INTERRUPT );

NETCTRL is used to initialize the stack and maintain services. To accomplish this, it makes use of the configuration manager provided in the NETTOOLS library. Note that the configuration definitions and structures defined here are specific to NETCTRL, not CONFIG.

// First: Initialize the run-time environment _extern int NC_SystemOpen( int Priority, int OpMode );

h4. Create and build the system configuration from scratch.

I have yet to see this is documentation but the example follows with:

  • Create a new configuration

_extern HANDLE CfgNew();

  • Add a configuration entry to a configuration.

_extern int CfgAddEntry( HANDLE hCfg, uint Tag, uint Item, uint Mode, int Size, UINT8 *pData, HANDLE *phCfgEntry );

  • There are additional calls and initializations but these seem to be the core calls to initialize various services(http, tcp, udp)

See "int StackTest()"

h4. Start the network using the supplied configuration

_extern int NC_NetStart( HANDLE hCfg, void (*NetStart)(), void (*NetStop)(), void (*NetIP)(IPN,uint,uint) );

  • NetIP: This function is called whenever an IP address binding is added or removed from the system.

Example) static void NetworkIPAddr( IPN IPAddr, uint IfIdx, uint fAdd )

  • Within here I created an echo server by creating a task

_extern HANDLE TaskCreate( void(*pFun)(), char *Name, int Priority, uint StackSize, UINT32 Arg1, UINT32 Arg2, UINT32 Arg3 );

  • Within the function run in the task you must first Allocate the file environment for this task
    fdOpenSession( TaskSelf() );
  • Within the task function standard calls exist
    socket(), send(), bind(), listen, ...
  • To end the task: This task is killed by the system - here, we block
    TaskBlock( TaskSelf() );

h4. Destroy a configuration

_extern void CfgFree( HANDLE hCfg );

h4. Close down the run-time environment

_extern void NC_SystemClose();

h3. NC_NetStart - netctrl.c

If you are not using XGCONF, your application must call the NETCTRL function NC_NetStart() to invoke the network scheduler after the configuration is loaded. Besides the handle to the configuration, this function takes three additional callback pointer parameters; a pointer to a Start callback function, a Stop function, and a IP Address Event function. The first two are run once and are pretty self-explanatory. The latter is run every time an IP Address is given.

Summary: NC_NetStart() handles network requests and is run in a loop so that you may reboot it if you choose. The function does not exit unless you reboot or stop it(error can cause a stop too).

_llTimerInit() - associates some event with a timer initialized to zero - Purpose: ?? _llUserLedInit() - EVM specific - Initialize LED driver _llSerialInit() - Initialize CPLD(appears to handle their external interrupts), associate EXTINT7 with a handler Also sets default contol alues for serial devices. Not sure how the two are related. _llPacketInit() - DOES NOTHING(casts event handle as void) but claims to open packet driver and enumerate devices NIMUInit - Initialize Network Interface Management Unit Core stack - Initialzes the EMAC and software interface VLANInit - init vlan usule in core stack(ensure enough spce for NIMU header) IPv6Init - Init IPv6 Stack if used Save Network Open, Close, IP Address pointers - create loacal servers(tasks), kill them , and print message for new connections ExecOpen() - Sero out udp, tcp, ipv6, raw, stat structures NS_BootTask - Install service provider callbacks and boots user tasks ( OS, IP, Service, IpNet, Route) NetScheduler - STart running the stack and only exit when nethalt to clean up all previous calls

 - check for stack related eventts, timer, ethernet, and serial
 - polls events and handles them

LOOK HERE:

3.2.5.1 The NETCTRL Task Thread If you are not using XGCONF, your application must create a Task thread that contains a call to ND_NetStart(), which in turn runs the network scheduler function. The NSP example applications provide this thread. SPRU523H–May 2001–Revised February 2012 Configuring the NDK with C Code (without XGCONF) This Task thread (called the scheduler thread) is the thread in which nearly all the NETCTRL activity takes place. This thread acts as the program’s entry-point and performs initialization actions. Later, it becomes the NETCTRL scheduler thread. Therefore, control of this thread is not returned to the caller until the stack has been shut down.

h2. NDK User Guide

h3. The STACK Library

The STACK library is the main TCP/IP networking stack. It contains everything from the sockets layer at the top to the Ethernet and Point-to-point protocol (PPP) layers at the bottom. The library is compiled to make use of the SYS/BIOS operating system, and does not need to be ported when moved from one platform to another. Several builds of the library are included in the NDK. The STACK libraries are provided in the <NDK_INSTALL_DIR>\packages\ti h3. NETTOOL Libraries

The Network Tools (NETTOOL) function library contains all the sockets-based network services supplied with the NDK, plus a few additional tools designed to aid in the development of network applications.

h3. OS and MiniPrintf Libraries

These libraries form a thin adaptation layer that maps some abstracted OS function calls to SYS/BIOS function calls. This adaptation layer allows the SYS/BIOS system programmer to tune the NDK system to any OS based on SYS/BIOS. This includes Task thread management, memory allocation, packet buffer management, printing, logging, critical sectioning, cache coherency, interrupt management and jumbo packet buffer management.

h3. HAL Libraries

The HAL libraries contain files that interface the hardware peripherals to the NDK. These include timers, LED indicators, Ethernet devices, and serial ports.

h3. NETCTRL Libraries

The NETCTRL or Network Control library can be considered the center of the stack. It controls the interaction between the TCP/IP and the outside world. Of all the stack modules, it is the most important to the operation of the NDK.

h2. Previous NDK Wiki Entry

file:///C:/ti/pdk_C6678_1_1_0_3/packages/ti/platform/docs/platform/platform_library_user_guide.html

Adding NDK support is a pain. Documentation lacks any useful information. Need to find and download the ndk, nsp, pdk(c6678 specific). Unzip these in the ti installation directory.

Then I added the 'Global' Module to SYS/BIOS. This creates lots of errors. Online w\instructions will tell you libraries are missing. Lies. You need to include source code files. Currently I'm trying platform_osal.c and resourcemgr.c. At this point I'm not sure where I got them but they do exist in the ti installation. Either the ndk, nsp, or pdk. Now your project should compile but will no longer run properly. To get the hbeat going again I added the HeapMem mosule. Created an instance called systemHeap with size 131072.

Then I modified the Memory module to use systemHeap as the default Heap instance!

ti.sysbios.heaps.HeapMem.Instance#1 4096

removed this from memory Managment module after adding Heap Memory instance Systemheap and making it much larger)

Current progress:

Call to this function fails. Unfortunately this function doesn't seem to even return with an error. Instead it never returns. Possibly the wrong one is being used but I don't see how it's linked in yet pform_status = platform_init(&sFlags, &sConfig);

Header file for definition C:\ti\pdk_C6678_1_0_0_21\packages\ti\platform

C:\ti\pdk_C6678_1_0_0_21\packages\ti\platform\evmc6678l\platform_lib\src C:\ti\pdk_C6678_1_0_0_21\packages\ti\platform\simc6678\platform_lib\src

When you delete a project in eclipse you get asked if you also want to delete the folder contents. If not, the project folder remains in the workspace folder. You can re-add it with File->Import and then choose General->Existing Project into Workspace.

The library to be included is pdk_C####_#_#_#_#/packages/ti/platform/evmc6678l/platform_lib/lib/debug or release/ti.platform.evm6678l.ae66; Application needs to include the CSL library as well. If you are a RTSC project you can include the CSL libraries in your CFG file by using the following statement: var Csl = xdc.useModule('ti.csl.Settings');. If your are not a RTSC project see the pdk_C####_#_#_#_#/packages/ti/csl/lib directory for the list of libraries to include. You will need the *.ae66 for little endian and *.ae66e for big endian. The library is re-buildable as a CCSv5 project. Just import from the platform_lib directory as an existing CCS project.

Requires newer compiler: https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm#C6000

To get the NDK stuff moving forward I have: 1) Added the bare minimum module from the SYS BIOS (General) 2) This required adding paramets to the cfg file:

 // Load the CSL package 

var Csl = xdc.useModule('ti.csl.Settings'); // Load the CPPI package var Cppi = xdc.loadPackage('ti.drv.cppi'); // Load the QMSS package var Qmss = xdc.loadPackage('ti.drv.qmss'); // Load the PA package var Pa = xdc.useModule('ti.drv.pa.Settings');

 // Load the Platform/NDK Transport packages 

var PlatformLib = xdc.loadPackage('ti.platform.evmc6678l'); var NdkTransport = xdc.loadPackage('ti.transport.ndk');

Some section mapping may need to be done to allow the compilation to fit in memory

These also tie in with the platform library and source files: 3) Added source files from the client_evmc6678l example project: Source code and project files are here: C:\ti\mcsdk_2_01_00_03\examples\ndk\client

client.h client.c(I pulled source code from this file and integrated it with my own main as this is main for the example) platform.h platform_osal.c webpage.c webdata<dir>

  default.h
  dspchip.h
  logobar.h
  websample.h
  default.htm
  dspchip.gif
  logobar.gif
  sample.htm

4) The platform library needs to be modified: C:\ti\pdk_C6678_1_1_0_3\packages\ti\platform\evmc6678l\platform_lib

Import this project into your workspace. It may require a different compiler. Download and install it. At this point the project may physically exist in your workspace but not show up in the project list in CCS. Remedy this by selecting: File->Import->General->'Existing Projects in Workspace' and the project missing. I made a copy of the entire C:\ti\pdk_C6678_1_1_0_3 directory, and work on this one, rather than a copy of just the project directory because links will no longer work and resolving them was a proving to be a nuisance.

5) In the sample project I removed MCSDK PDK TMS32C6678 from the Properties->RTSC->Products and Repositories and replaced it with the copy I created above called: C:\ti\tim_C6678_1_1_0_3\packages Note that the original link doesn't require packages(my be done behind the scenes) but mine requires this extra directory guidance

6) Should be able to now build the platform library and then the sample project

  • In the platform library I have changed:

CSL_BootCfgSetSGMIIConfigPLL (0x00000051); //We use 250 Mz: 10x : Instead of -- 0x00000041 312.5 MHz: 8x Init_SGMII(0); instead of Port 1 (verify)

7)Added

CSL_SGMII_setAdvAbility (macPortNum, &sgmiiCfg); //Existing code in Init_SGMII()

//ADDED TIM W CSL_SGMII_disableAutoNegotiation (macPortNum);

8) Platform.c /* This structure holds information about the EMAC port on the platform */

  1. pragma DATA_SECTION(emac_port_mode,"platform_lib");

PLATFORM_EMAC_PORT_MODE emac_port_mode[PLATFORM_MAX_EMAC_PORT_NUM] = {

	PLATFORM_EMAC_PORT_MODE_PHY,
	PLATFORM_EMAC_PORT_MODE_NONE
    //PLATFORM_EMAC_PORT_MODE_AMC,
    //PLATFORM_EMAC_PORT_MODE_PHY

};

9) Added to platform_init()(normally part of pll flag calls but now forced):

        /* Set the PA_SS PLL */	//ADDED THIS
        status = SetPaPllConfig();
        if (status != CSL_SOK)
        {
            platform_errno = PLATFORM_ERRNO_PLL_SETUP;
            return ( (Platform_STATUS) Platform_EFAIL);
        }

10) In Init_SGMII() swapped the 'if (macPortNum)' sections 0->1 & 1-> 0

h3. The NETCTRL Task Thread

If you are not using XGCONF, your application must create a Task thread that contains a call to ND_NetStart(), which in turn runs the network scheduler function. The NSP example applications provide this thread. SPRU523H–May 2001–Revised February 2012 Network Application Development 51 Submit Documentation Feedback Copyright © 2001–2012, Texas Instruments Incorporated Configuring the NDK with C Code (without XGCONF) www.ti.com This Task thread (called the scheduler thread) is the thread in which nearly all the NETCTRL activity takes place. This thread acts as the program’s entry-point and performs initialization actions. Later, it becomes the NETCTRL scheduler thread. Therefore, control of this thread is not returned to the caller until the stack has been shut down. Application Tasks—network-oriented or otherwise—are not executed within this thread.

  • This makes sense but can't find evidence of this. Find out what they mean by "not using XGCONF" and "NSP example applications"

h2. NOTES

http://e2e.ti.com/support/embedded/bios/f/355/t/120158.aspx

This issue describes how to use one socket between two tasks. In the NDK, you must use a file descriptor. You must open a session and then share the session data.

TODO Pt 3

Add MDIO info.

Add random notes about rebuilding/ added libs

Bug fixed by removing .config folder: http://e2e.ti.com/support/embedded/tirtos/f/355/t/569964