EDK9.1: XTemac + LwIP + Xilkernel + unistd.h = possible?

Hello all!

Has anyone had success using LwIP along with some of the xilkernel functions in a system that is based on the PPC and hard Trimode Ethernet MAC?

I keep running into a problem where the xtemac driver pulls in some xilinx header files that collide with unistd.h (pulled in by e.g. pthread.h).

make -f system.make echo_program started...

powerpc-eabi-gcc -O2 echo/src/socket.c -o echo/executable.elf \ -Wl,-T -Wl,echo_linker_script.ld -g

-I./ppc405_0/include/ -L./ ppc405_0/lib/ \ -lxilkernel -llwip4

In file included from /home/tools/EDK_9.1/gnu/powerpc-eabi/lin/bin/../lib/gcc/po werpc-eabi/4.1.1/../../../../powerpc-eabi/include/unistd.h:4, from echo/src/socket.c:62: /home/tools/EDK_9.1/gnu/powerpc-eabi/lin/bin/../lib/gcc/powerpc-eabi/4.1.1/../.. /../../powerpc-eabi/include/sys/unistd.h:144: error: conflicting types for ?sleep? ./ppc405_0/include/sleep.h:32: error: previous declaration of ?sleep? was here

alternately:

make -f system.make echo_program started... In file included from ./ppc405_0/include/xenv_none.h:60, from ./ppc405_0/include/xenv.h:73, from ./ppc405_0/include/xtemac.h:490, from echo/src/socket.c:61: ./ppc405_0/include/sleep.h:32: error: conflicting types for `sleep' /home/tools/EDK_9.1/gnu/powerpc-eabi/lin/bin/../lib/gcc/powerpc-eabi/4.1.1/../../../../powerpc-eabi/include/sys/unistd.h:144: error: previous declaration of `sleep' was here

The above examples were generated by taking the example project ml403_ppc_lwip_temac_fifo_91i.zip, building it as-is (well, after fixing the absolute pathnames in the system.xmp). I then opened the "echo" application and edited its source file echo/src/socket.c. I added the line #include either between the Xilinx headers and lwip headers (first case) or before all other headers (second case).

I'm looking to use both lwip and the functions in xilkernel (set thread priority and mutexes). Unfortunately, the headers needed for the functions in xilkernel pull in unistd.h.

Note that similar example designs which use xemac (opb_ethernet), such as xapp434, work fine with and without unistd.h.

I opened a webcase with Xilinx, unfortunately it's the start of a long weekend so it'll be at least three days before I can get a response. So I thought I'd try my luck here.

Thanks in advance for any help or suggestions!

ken

Reply to
Ken Ryan
Loading thread data ...

I had a similar problem developing an LWIP raw api program. Commenting out the definition of sleep() in the EDK source tree fixed it. I also wondered how the other applications managed to get around this.

Paul

formatting link

... ./ppc405_0/include/sleep.h:32: error: conflicting types for `sleep' ...

Reply to
Paul Tobias

Thanks, you encouraged me to try that tack again. :-)

I commented out the bogus sleep() definition, and I had to drop a "#define LWIP_TIMEVAL_PRIVATE 0" to keep lwip away from struct timeval.

Next, to figure out why the Xilinx gdb quit giving me symbols... (yes I have -g -O0 in both the app and libraries...)

ken

Paul Tobias wrote:

Reply to
Ken Ryan

Thank you guys for sharing your experiences. I had the same problem and commented out this line in sleep.h. //void sleep(unsigned int seconds); Is it the line you were talking about?

I'm not sure where to do the fix however... Doing any modification to the EDK source tree is not portable accross computers. Doing the modification in the ppc405_0 folder will be lost during the next library rebuild. Is there a better way?

Another question while I'm at it, did you fix the problem about debug symbols? It indeed seems broken in EDK v9.1, even after 2 service packs.

Thanks.

Patrick

Reply to
Patrick Dubois

Yes, that's it.

Yes, that;s a problem. I haven't figured out a better way. As a stopgap I added that sleep.h to the list of include files for my application, as a reminder. Doesn't help for a command-line build though.

I'm seeking out another solution for the whole mess anyway. Evidently the xilinx-provided libc is only thread-safe for some functions, and they don't seem to have a list of which ones. So it's either wrap all the standard C library functions in mutexes or do my own libc port. Xilinx should be ashamed of themselves, but after the xilnet disaster I doubt they are.

Note sure I came across this one (or at least I don't recognize it)...

ken

Reply to
Ken Ryan

The software side of EDK is really disappointing to say the least. I sold the idea around here to use the Avnet FX12 mini-module as a nice solution to ethernet connectivity. I thought that there would be lots of working examples for it (as ethernet seems to be its biggest selling point). Wrong.

The Avnet ethernet examples all use lwIP in sockets mode and as we seem to discover, not everything is xilkernel friendly. Not only that, the ethernet examples using MPCM2 are not compatible with flash booting in EDK v9.1 (not an essential feature it seems?!). Gigabit reference design? It's using an expensive tcp/ip stack, so it's not very useful for most people.

It's very hard for me to explain to my boss why such a simple application (SPI-ethernet bridge) is taking forever to complete. I thought that the mini-module would be a nice integrated solution (as far as ethernet is concerned) like the Rabbit microcontroller is. Boy was I wrong on this one.

I'm starting to think that trying to make lwIP work in raw mode instead (despite the lack of driver support for the temac!) might be easier than dealing with all the xilkernel related issues. Or maybe I could go back to EDK v7.1 (!), Avnet has a reference design with lwIP v1.0 working in raw mode for that version... But what if I get a bug in the design, I'll probably be told by Xilinx to upgrade to v9.1.

Virtex-4 was released what, 2 years ago now? Come on software folks at Xilinx, it's about time to get a working tcp/ip solution (free) to use the hard temac without having to bother with xilkernel!! Is that too much to ask?

Patrick

Reply to
Patrick Dubois

This will be available in 9.2. A clean high performance lwip solution for both raw and socket modes for the TEMAC. The socket mode will still rely on xilkernel, but the issues will be fixed. We will also move to lwip v1.2.0.

-Siva

Reply to
Siva Velusamy

Hoboy, you stepped on a rant there. :-)

I initially procured the Avnet v2pro FF672 board with the comm3 module. I figured, how could I go wrong, there's an example design that does 90% of what I want to do - the only bit missing was a specialized gigabit serial link that I could adapt from a previous design.

I checked out the board, the example seemed to work OK, so I proceeded with my design. Then sometime later I connected the board to my company's intranet - instead of a private wire link. Wham, the TCP stack fell over, crashed the processor hard. This was my introduction to xilnet. Then I realize that EDK didn't support the 91C111 MAC that was on that board - I'd have to port an ethernet stack myself. The Avnet demo was a hacked-up port of xilnet with a very rudimentary driver, and completely useless for anything halfway realistic.

I actually started down the path of porting Linux to the board, when I discovered another problem. The comm3 module uses all 3.3V signaling to the FPGA. The FF672 board has a bank voltage select to support it. Unfortunately *some* of the I/Os come from a fixed 2.5v bank. So Avnet's stack was driving about a half-dozen 2.5v inputs with 3.3v levels. I considered switching to the comm2 module, but when I looked at the schematics I saw the same problem. Eventually I got hold of someone in the know at Avnet; turns out that was a known design bug, known for a long time (through two design generations!).

My mood wasn't helped by the complete and utter failure to get their SystemAce Module to work (I eventually gave up and tossed it in a drawer to rot).

Normally when one uses one of these development boards one is just fiddling with it or experimenting. Sometimes we want to embed it into a product, if it's appropriate. This was to go into some equipment with a fairly long expected lifetime, so I couldn't afford to have hardware I knew would eat itself. $4500 and six weeks down the drain. I turned the Avnet sales rep's ears around for that one. Avnet is great with the vast majority of what they do, but it'll be a long time before I consider another of their development boards for anything more sophisticated than fixing a short table leg.

Now I'm going through the process of finding all the other little surprises (I went to an ML405 board; much better piece of hardware thought it took me a while to port my rocketio design).

OK, I'll quit frothing now...

ken

Reply to
Ken Ryan

Hehe, thanks for sharing your experience :-)

Reply to
Patrick Dubois

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.