Problems with Raw Ethernet

Mitch,

My apologies for the lack of response on this post.  Are you still stuck on this issue or have you gotten past it?

Steve

We are still stuck.  An answer finally came in on another thread, i appreciate the answer, and it is perhaps a start.  the answer is from mcore, there is a similar function in omapl138 with less documentation and examples. i have no idea yet, whether it applies to c6748. i also do not know yet, whether i can use this level of api directly and dispense with the high level startnetwork stuff etc., and not have to do a lot of things explicity like powering up the phy and setting up interrupts, or whether i am supposed to integrate these call into the program at a higher level.  Surely there will be more questions, and so far it looks like there is only source code or a list of calls to work it out from.  So far we have a total of about three weeks delay on what should be a trivial task

I hesitate to be perhaps a bit un-politic, but i think the following needs to be said.  The difficutlies in documentation, the obscurity created by the ide and tools, and the occasional glitch in getting help, all add up to such project risk that it makes it difficult to explain to management why we chose to use a TI DSP.

Mitch,

I apologize about the frustrations you've been experiencing.

Would you be able to zip up your entire built project and attach it to this post?

I also have to give you a heads up ... this weekend is a holiday weekend, but I'll be glad to help you after.

Steve

I would be be happy to zip up the project and send it to you by email. Even though it is basically only cribbed from helloworld, I am a little uncomfortable with positing it to a public forum.

Here is the zipped project.  It is supposed to echo whatever it gets as a raw packet.  The target application would be built up from that starting point, if only it would work.  In the deployed system, this will be an internal communication mechanism for control and data transfer between custom boards connected by cross-over cables.

The incoming packets may have zeroes in the mac header and the ethernet type field might be set to anything, even 0x800..

7633.preprocessor.zip

Thank you

Please see previous email for the zip of the project.

The project as zipped, is actually just a starting point for the project. A command switch would go in place of the simple echo that is there now.

In the interim, with no other options, i started doing some more digging.

The first thing i found is that, as described in one of the documents, NIMUReceivePacket(), in nimu.c, does indeed filter pacekts based on ether type before it passes them to any raw socket. The ether type in our app can be random.  Is there any way around this filtering within the API?

The second part of the problem is that in our app, we can have zero filled or random mac addresses.  EMAC_setReceiveFilter() looks promising, but after looking and searching through documents and examples and source code, i still have not found how to use it in a socket program. Perhaps it can drop into one of the EMAC call backs in the helloworld example?

Thank you for helping.

Mitch,

I've been looking at your issue and I've got the benchmark app that we had made a long time ago, which uses raw sockets, to work with the latest NDK, etc.

It's designed to run on 2 different OMAPL138 boards, though.  Do you have two separate boards that you could try this out on?

I also noticed that in your code, you're calling 'getsendcbuff()' and then saw that our raw socket benchmark doesn't call that.

In the attached, you should be able to load and run.  Each program will hard code an EMAC address and use DHCP to obtain an IP address.

If you run the "testee" first, it sets up a receiver task that waits to receive data on a raw socket.

Then, run the "tester" on a different board, and it will send data on a raw socket to the testee.

Let me know if this helps you...

Steve

8345.ndk_rawEth.zip

We have two evm units and presumably the benchmark would work  as you described.  The evm units both have mac addresses, the packets will have their mac headers set accordingly and they are guaranteed not to use 0x800 as an ether type.  Unfortunately, our production system doesn't meet those criteria.

How do you modify the benchmark to put the interfaces in promiscous mode?

I am guessing that we can figure out how to remove the ether type filtering, Perhaps just  copy the nimu.c file into the project and hack it up?

On the send call,  we have never gotten so far as to actually receive a raw packet, so the send has never come up.  i would be delighted if i was so far a long as to be debugging the zero copy send.  We will need it in the app though.

Steve,

Thank you for working on the app and sending it to us.

i will try to put the peices together to try your app tomorrow. 

i think i will have to set up a second computer to host ccs and run the second evm. 

it will be good to see something work.

Mitch

It does not build.  Here is the error output:

js: "C:/Program Files/Texas Instruments/xdctools_3_20_08_88/include/utils.tci", line 582: Error: Can't find import file: '../common/noncopyTCPtestee.tci' (not found along 'C:\Projects\DSP_Preprocessor\testee\Debug/../;C:/Program Files/Texas Instruments/bios_5_41_10_36/packages;C:/Program Files/Texas Instruments/nsp_1_00_00_09/packages/ti/ndk/benchmarks/common/thrload;C:/Program Files/Texas Instruments/nsp_1_00_00_09/packages/ti/ndk/benchmarks/nonCopyTCP/testee/common;C:/Program Files/Texas Instruments/ndk_2_20_03_24/packages/ti/ndk/inc/tci;;C:\Program Files\Texas Instruments\xdctools_3_20_08_88/include;C:\Program Files\Texas Instruments\xdctools_3_20_08_88/packages')

gmake: *** [evmboardcfg.cmd] Error 1

gmake: Target `all' not remade because of errors.

Mitch,

I had to hard code some paths in the project on my end to get it to build, so it has some paths that are specific to my PC.  I was hoping you'd just be able to load and run the existing exes.

To rebuild, you need to update the paths in the project settings so they match what's on your machine.

The file should be located here (that's where it is for me), so this is the one you'll need to change:

C:/Program Files/Texas Instruments/nsp_1_00_00_09/packages/ti/ndk/benchmarks/nonCopyTCP/testee/common

You should modify the paths in the build settings of the project of "Tconf" (see below screen) to match what you've got on your system.  You'll probably also need to do the same for the compiler and linker include paths. Give this a shot and let me know how it goes

There is no "common" directory in the zip file (8345.ndk_rawEth.zip), and there is "no nonCopyTCP" directory.

Here is a directory list after unzipping it into the specified location:

pwd

/cygdrive/c/Program Files/Texas Instruments/nsp_1_00_00_09/packages/ti/ndk

-rwx------+ 1 Mitch Nelson None 1448815 2011-04-29 11:20 8345.ndk_rawEth.zip

8345.ndk_rawEth/tester/:
total 53
-rwx------+ 1 Mitch Nelson None  2925 2011-04-28 18:27 udpHello.c
-rwx------+ 1 Mitch Nelson None  1618 2011-04-28 18:27 thrload_config_cpuload.c
-rwx------+ 1 Mitch Nelson None 10365 2011-04-28 18:27 thrload.c
-rwx------+ 1 Mitch Nelson None 17995 2011-04-28 18:27 nonCopyTCPtester.c
-rwx------+ 1 Mitch Nelson None    84 2011-04-28 18:27 evminit.c
-rwx------+ 1 Mitch Nelson None  1675 2011-04-28 18:27 evmboard.tcf
-rwx------+ 1 Mitch Nelson None  6647 2011-04-28 18:27 emacHooks.c
drwx------+ 1 Mitch Nelson None     0 2011-04-29 13:40 Debug

8345.ndk_rawEth/testee/:
total 57
-rwx------+ 1 Mitch Nelson None  2925 2011-04-28 18:27 udpHello.c
-rwx------+ 1 Mitch Nelson None  1618 2011-04-28 18:27 thrload_config_cpuload.c
-rwx------+ 1 Mitch Nelson None 10365 2011-04-28 18:27 thrload.c
-rwx------+ 1 Mitch Nelson None 16978 2011-04-28 18:27 nonCopyTCPtestee.c
-rwx------+ 1 Mitch Nelson None  1014 2011-04-28 18:27 nonCopyTCPTestee.tci
-rwx------+ 1 Mitch Nelson None    84 2011-04-28 18:27 evminit.c
-rwx------+ 1 Mitch Nelson None  1675 2011-04-28 18:27 evmboard.tcf
-rwx------+ 1 Mitch Nelson None  6647 2011-04-28 18:27 emacHooks.c
drwx------+ 1 Mitch Nelson None     0 2011-04-29 13:40 Debug

8345.ndk_rawEth:
total 0
drwx------+ 1 Mitch Nelson None 0 2011-04-29 13:40 tester
drwx------+ 1 Mitch Nelson None 0 2011-04-29 13:40 testee

Mitch,

Whoops, that's because those benchmarks aren't part of the NSP product!

Please find the attached and unzip it into your NSP installation here:

<install location>\nsp_1_00_00_09\packages\ti\ndk

I think this should be everything you need, but let me know either way.

2248.benchmarks.zip

Steve

It didn't work, but maybe i didn't do it correctly.   Here is waht i did:

1) unzip the file 2248.benchmarks.zip   to  C:\Program Files\Texas Instruments\nsp_1_00_00_09\packages\ti\ndk

2) open CCS4 with my current default workspace   C:\Projects\DSP_Preprocessor

3) Try to import existing CCS/CCE Eclipse project.  In the dialog box, browse to the directory and even each subdriectory - fails to recognize that the project is there.

4) Try to import as a legacy CCSv3.3 project,  this time it finds all four projects from the benchmarks subdirectory.

5) Try to build it, if fails to build.  here are the errors

**** Build of configuration Custom for project nonCopyTCPTestee ****

C:\Program Files\Texas Instruments\ccsv4\utils\gmake\gmake -k all

'Building file: ../evmboard.tcf'

'Invoking: TConf Script Compiler'

"C:/Program Files/Texas Instruments/xdctools_3_20_08_88/tconf" -b -Dconfig.importPath="C:/Program Files/Texas Instruments/bios_5_41_10_36/packages;C:/Program Files/Texas Instruments/ndk_2_20_03_24/packages/ti/ndk/inc/tci;C:/Program Files/Texas Instruments/ndk_2_20_03_24/packages/ti/ndk/benchmarks/common/thrload;" "../evmboard.tcf"

I still was not able to get it to build, and of course if it doesn't build there is not much i can do with it.  But thank you.

While waiting for help on the above,  I tried some hacks on the network stack.   the following adds an ioctl to set promiscouse mode.  it is not tested very much yet.

H8547.preprocessor.rev2.zipere is what i came up with so far.

Mitch,

Did you already have a project called "tester" or "testee" in your workspace?  If a project with the same name already exists, then Eclipse won't import it (it won't show up as you described).  Also, the CCSv3 .pjt files were there by accident, you want the CCSv4 one.

If not, can you try importing a different way?  You should choose "import existing CCS/Eclipse Project" (NOT the CCSv3 project)" then you'll see the following screen, but can you choose "select archive file"?  Then browse to the zip that I sent you.

Here's a screen shot:

Then you should see the projects appear.  It should look like this after you browse to and choose the zip file:

Mitch,

I think I've made things too confusing by sending 2 different zip files, especially since in the 2nd one I posted I accidentally left some CCSv3 *.pjt project files in there.

I've updated the original zip file I attached. This has the CCSv4 projects and a lot of files just copied locally to the project directory.

One initial criteria is that the projects use the variable "NDK_INSTALL_DIR".  You would need to define this as a Windows environment variable and set it to where your NDK 2.20.X installation is at.  For example, on my machine it's defined as follows:

echo %ndk_install_dir%
C:\Program Files\Texas Instruments\ndk_2_20_03_24

So, the steps you should follow are:

1. Close down CCSv4

2. Define NDK_INSTALL_DIR = C:\Program Files\Texas Instruments\ndk_2_20_03_24\ndk_2_20_03_24

(or where ever you've installed that on your machine)

3. download the attached zip file: 7217.ndk_rawEth02.zip

4. open CCSv4, go to the "C/C++" view

5. Project -> import existing CCS/CCE Eclipse Project

6. Select "archive file"  (as shown in screen shots of previous post) and point it to the zip file from step 4

7. This should import the 2 apps into Eclipse.

8. Rebuild them, or load the existing executables (I think they should work for you)

Steve

Steve,

The project builds, loads, and runs.   However,   NO DATA IS TRANSMITTED OR RECEIVED from the tester to the testee (nor vice versa).

The test articles are two of the eval boards from Logic PD with  C6748 SOM installed.

The  two boards are connected by an RJ-45 crossover cable (yellow, "store bought", and tested and known to be good).

The testee is loaded and the tester is loaded, each on their repsective systems.

The testee is started, and then the tester is started.

The printout from the tester is listed below.  Notice that it gets to the service status DHCPC fault, and then nothing else appears.  The printout from the testee does the same thing.  I am wondering, should this be able to work for our setup with a direct wire between two units?

Thank you

Mitch

Non Copy TCP Tester Benchmark

Using default MAC address

Using MAC Address: 00-08-ee-03-14-79

MAC Address = 00-08-ee-03-14-79

EMAC should be up and running

EMAC has been started successfully

Registeration of the EMAC Successful

Service Status: DHCPC : Enabled : : 000

Service Status: DHCPC : Enabled : Running : 000

Link Status: 100Mb/s Full Duplex on PHY 0

Service Status: DHCPC : Enabled : Fault : 002

Mitch,

The test programs are configured to get a dynamic IP address using DHCP.  Can you hook each board up to your network (or to a router) so that they get their IP addresses?

Thanks,

Steve

I can do that, for purpose of testing the tester-testee pair.   But of course, that's very different what will be in our system.

Congratulations (or mazel tov, if you like).

The testee received all of the data, and the rate is 15328 kb/s at a CPU load of 1%

that's great.

So now...

How do we strip out all of the unneeded (and undesired) services and configure it so that we can connect the boards directly to each other?

{presumably we need to strip out the services also to reduce the image?).

See my post above,  the testee received the data at 1% cpu load.  that's good.

BUT,  i just noticed the tester reports a 99% CPU load.  that's not good.  is there no dma in this?  or is it perhaps not a zero copy send?

I experienced the same problem when trying out the client example project, where recvnc() never return when trying to receive raw ethernet, but with mcsdk_2_00_00_11.

Turns out the socket needs to be set a timeout.

Hope this is useful for others.

Chiang