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 <unistd.h>
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

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
www.paultobias.com

"Ken Ryan" <newsryan@leesburg-geeks.org> wrote in message 
news:4657B037.1010500@leesburg-geeks.org...
> 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).
...
./ppc405_0/include/sleep.h:32: error: conflicting types for `sleep'
...

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:
> 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
> www.paultobias.com
> 
> "Ken Ryan" <newsryan@leesburg-geeks.org> wrote in message 
> news:4657B037.1010500@leesburg-geeks.org...
>> 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).
> ...
> ./ppc405_0/include/sleep.h:32: error: conflicting types for `sleep'
> ...
> 

On 28 mai, 00:35, Ken Ryan <newsr...@leesburg-geeks.org> wrote:
> 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

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

Patrick Dubois wrote:
> On 28 mai, 00:35, Ken Ryan <newsr...@leesburg-geeks.org> wrote:
>> 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
> 
> 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?

Yes, that's it.

> 
> 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?

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.

> 
> 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.

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


ken

On Jun 6, 10:08 pm, Ken Ryan <newsr...@leesburg-geeks.org> wrote:
> Xilinx should be ashamed of themselves, but after the xilnet
> disaster I doubt they are.

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

> 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?
> 

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

Patrick Dubois wrote:
> 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.

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

On 7 juin, 21:29, Ken Ryan <newsr...@leesburg-geeks.org> wrote:
> PatrickDuboiswrote:
> > 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.
>
> 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

Hehe, thanks for sharing your experience :-)