public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] EDOSK-2674 ethernet drivers -TCP problem
@ 2003-11-19 14:06 Uwe Kindler
  2003-11-29 13:48 ` [ECOS] " Yoshinori Sato
  0 siblings, 1 reply; 5+ messages in thread
From: Uwe Kindler @ 2003-11-19 14:06 UTC (permalink / raw)
  To: ecos-discuss; +Cc: ysato

Hello,

i buildet the Redboot image for the EDOSK-2674 platform including
ethernetdrivers for the onboard SMSC LAN91C96 chip.
The ping command works fine an so I tried to connect GDB via Remote/TCP. But
the connection does not work. In the gdb console is printed: Ignorig packet
error and continuing.

When I analyze the net traffic with Packetyzer and follow the TCP stream, i
can see the following:

RedBoot>0+$Hc-1#09RedBoot>0$Hc-1#09RedBoot>0RedBoot>0$Hc-1#09RedBoot>0RedBoo
t>0$Hc-1#09RedBoot>0$Hc-1#09RedBoot>0RedBoot>0RedBoot>0-$Hc-1#09-RedBoot>0Re
dBoot>0-RedBoot>0-+$qC#b4RedBoot>0RedBoot>0.....

From the EDOSK-board is only the "RedBoot>0" part.

When I look into the TCP part of the "RedBoot>0" packet then the ckecksum is
wrong

tcp.checksum = Checksum: 0x442d (incorrect, should be 0x342d)

Is there a bug within the TCP part of the Redboot stand alone stack or does
it look like a bug within
the ethernet device driver or did i missed a configuration option?

Regards, Uwe





-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ECOS] Re: EDOSK-2674 ethernet drivers -TCP problem
  2003-11-19 14:06 [ECOS] EDOSK-2674 ethernet drivers -TCP problem Uwe Kindler
@ 2003-11-29 13:48 ` Yoshinori Sato
  2003-12-05  8:54   ` Andrew Lunn
  0 siblings, 1 reply; 5+ messages in thread
From: Yoshinori Sato @ 2003-11-29 13:48 UTC (permalink / raw)
  To: Uwe Kindler; +Cc: ecos-discuss

At Wed, 19 Nov 2003 15:06:12 +0100 (CET),
Uwe Kindler wrote:
> 
> Hello,
> 
> i buildet the Redboot image for the EDOSK-2674 platform including
> ethernetdrivers for the onboard SMSC LAN91C96 chip.
> The ping command works fine an so I tried to connect GDB via Remote/TCP. But
> the connection does not work. In the gdb console is printed: Ignorig packet
> error and continuing.
> 
> When I analyze the net traffic with Packetyzer and follow the TCP stream, i
> can see the following:
> 
> RedBoot>0+$Hc-1#09RedBoot>0$Hc-1#09RedBoot>0RedBoot>0$Hc-1#09RedBoot>0RedBoo
> t>0$Hc-1#09RedBoot>0$Hc-1#09RedBoot>0RedBoot>0RedBoot>0-$Hc-1#09-RedBoot>0Re
> dBoot>0-RedBoot>0-+$qC#b4RedBoot>0RedBoot>0.....
> 
> From the EDOSK-board is only the "RedBoot>0" part.
> 
> When I look into the TCP part of the "RedBoot>0" packet then the ckecksum is
> wrong
> 
> tcp.checksum = Checksum: 0x442d (incorrect, should be 0x342d)
> 
> Is there a bug within the TCP part of the Redboot stand alone stack or does
> it look like a bug within
> the ethernet device driver or did i missed a configuration option?
> 
> Regards, Uwe
> 

Bug in smsc91cxx driver.
Send odd length packet to last byte broken.

Fix patch (sorry adhoc).

Index: packages/devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c
===================================================================
RCS file: /cvsroot/ecos-h8/ecos/packages/devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c,v
retrieving revision 1.3
diff -u -r1.3 if_lan91cxx.c
--- packages/devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c	22 May 2003 12:45:22 -0000	1.3
+++ packages/devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c	29 Nov 2003 13:42:54 -0000
@@ -794,7 +794,7 @@
     // Prepare header:
     put_data(sc, CYG_CPU_TO_LE16(0));        // reserve space for status word
     // packet length (includes status, byte-count and control shorts)
-    put_data(sc, CYG_CPU_TO_LE16(0x7FE & (plen + 6)) ); // Always even, always < 15xx(dec)
+    put_data(sc, CYG_CPU_TO_LE16(0x7FE & (plen + 6 + 1)) ); // Always even, always < 15xx(dec)
 
     // Put data into buffer
     for (i = 0;  i < sg_len;  i++) {
@@ -803,7 +803,7 @@
 
         CYG_ASSERT(0 == (len & 1) || (i == (sg_len-1)), "odd length");
         CYG_ASSERT( sdata, "No sg data pointer here" );
-        while(len >= sizeof(*sdata)) {
+        while(len > 0) {
             put_data(sc, *sdata++);
             len -= sizeof(*sdata);
         }

-- 
Yoshinori Sato
<ysato@users.sourceforge.jp>

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Re: EDOSK-2674 ethernet drivers -TCP problem
  2003-11-29 13:48 ` [ECOS] " Yoshinori Sato
@ 2003-12-05  8:54   ` Andrew Lunn
  2003-12-05 10:24     ` [ECOS] Re: STL support under eCos, what does it take? Giovanni Perbellini
  2003-12-05 14:52     ` [ECOS] Re: EDOSK-2674 ethernet drivers -TCP problem Uwe Kindler
  0 siblings, 2 replies; 5+ messages in thread
From: Andrew Lunn @ 2003-12-05  8:54 UTC (permalink / raw)
  To: Yoshinori Sato; +Cc: Uwe Kindler, ecos-discuss

Hi Yoshinori

> @@ -803,7 +803,7 @@
>  
>          CYG_ASSERT(0 == (len & 1) || (i == (sg_len-1)), "odd length");
>          CYG_ASSERT( sdata, "No sg data pointer here" );
> -        while(len >= sizeof(*sdata)) {
> +        while(len > 0) {
>              put_data(sc, *sdata++);
>              len -= sizeof(*sdata);
>          }
 
I don't know this chip at all, im just reading the code and deciding
if to commit your patch. sizeof(*sdata) is 2. The original code will
exist the loop when len == 0 or 1 and in these cases *sdata points to
the end of the packet, or the last byte. Your change means it will
exit when len == 0 or -1 and in these cases, *sdata points to the end
of the packet, or one byte after the end of the packet.

So when len is odd, the original code *sdate points to the last byte
and your code *sdata points to some junk after the end of the packet.
The code that follows is:

   control = 0;
    if ( 1 & plen ) {
        // Need to set ODD flag and insert the data
        unsigned char onebyte = *(unsigned char*)sdata;
        control = onebyte;
        control |= LAN91CXX_CONTROLBYTE_ODD;
    }

ie if we have an odd length packet, get the last byte at *sdata and
put it into a control word.

It looks to me your change causes random junk to be in the control
word.

Am i reading this wrong? 

   Thanks
        Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ECOS] Re: STL support under eCos, what does it take?
  2003-12-05  8:54   ` Andrew Lunn
@ 2003-12-05 10:24     ` Giovanni Perbellini
  2003-12-05 14:52     ` [ECOS] Re: EDOSK-2674 ethernet drivers -TCP problem Uwe Kindler
  1 sibling, 0 replies; 5+ messages in thread
From: Giovanni Perbellini @ 2003-12-05 10:24 UTC (permalink / raw)
  To: ecos-discuss


Bob,

I am trying to configure STLport-4.6 in order to use it in an eCos project.

Questions:
1. in stl_user_config.h  there's a switch _STLP_NO_IOSTREAMS to enable for
no iostream support.
Is this what you used?
2. I could not find a switch for disabling the exceptions. Browsing through
code, however, I see
a _STLP_HAS_NO_EXCEPTIONS define. Did you just
added -D_STLP_HAS_NO_EXCEPTIONS
to your compile flags to disable the exceptions support?
3. would you share your .mak file? I would like to see how you linked the
ecos library headers (and
GCC headers?) since I am not sure I am doing it in the right way.

Thanks in advance.
Giovanni


****************************************************************************
*************
----- Original Message ----- 

Use STLPort,

configure it _not_ to use iostreams or exceptions. Works great for me.

Bob

On Wed, 2003-01-15 at 20:36, Barton Meeks wrote:
> Look back through this mailing list, it looked like
> support for C++ Standard Template Library may not have
> been too far off back in early 2002, before Red Hat
> lost interest (and personnel).
>
> How much effort would it take to provide support for
> STL for eCos? What needs to be done? It it work on
> eCos itself or the gnu tool chain?
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Re: EDOSK-2674 ethernet drivers -TCP problem
  2003-12-05  8:54   ` Andrew Lunn
  2003-12-05 10:24     ` [ECOS] Re: STL support under eCos, what does it take? Giovanni Perbellini
@ 2003-12-05 14:52     ` Uwe Kindler
  1 sibling, 0 replies; 5+ messages in thread
From: Uwe Kindler @ 2003-12-05 14:52 UTC (permalink / raw)
  To: ecos-discuss; +Cc: Andrew Lunn

Hello Andrew,

I found the problem within the driver and fixed it by myself - now the
driver works with EDOSK2674 board.
Yoshinori Satos patch does not work for me. Here is my patch for smsc91cxx
driver.

Uwe Kindler


--- if_lan91cxx.c 2003-11-18 22:05:34.000000000 +0100
+++ ../if_lan91cxx.c 2003-11-28 16:58:18.000000000 +0100
@@ -141,9 +141,8 @@
 static cyg_handle_t  lan91cxx_interrupt_handle;

 // This ISR is called when the ethernet interrupt occurs
-static int
-lan91cxx_isr(cyg_vector_t vector, cyg_addrword_t data
-             /* , HAL_SavedRegisters *regs */ )
+static int lan91cxx_isr(cyg_vector_t vector, cyg_addrword_t data)
+             /* , HAL_SavedRegisters *regs */
 {
     struct eth_drv_sc *sc = (struct eth_drv_sc *)data;
     struct lan91cxx_priv_data *cpd =
@@ -820,7 +819,7 @@
         control |= LAN91CXX_CONTROLBYTE_ODD;
     }
     control |= LAN91CXX_CONTROLBYTE_CRC; // Just in case...
-    put_data(sc, control);
+    put_data(sc, CYG_CPU_TO_LE16(control));

     // Enqueue the packet
     put_reg(sc, LAN91CXX_MMU_COMMAND, LAN91CXX_MMU_enq_packet);
@@ -1071,6 +1070,7 @@
     val = CYG_LE32_TO_CPU(val);
     plen = (val >> 16) - 6;
 #else
+    val = CYG_LE16_TO_CPU(val);
     plen = get_data(sc);
     plen = CYG_LE16_TO_CPU(plen) - 6;
 #endif
@@ -1111,6 +1111,8 @@
  val >>= 16;
  mlen -= 2;
     } else
+#else
+    val = CYG_LE16_TO_CPU(val);
 #endif
  cp = (unsigned char *)data;


> It looks to me your change causes random junk to be in the control
> word.
>
> Am i reading this wrong?
>
>    Thanks
>         Andrew
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-12-05 14:52 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-19 14:06 [ECOS] EDOSK-2674 ethernet drivers -TCP problem Uwe Kindler
2003-11-29 13:48 ` [ECOS] " Yoshinori Sato
2003-12-05  8:54   ` Andrew Lunn
2003-12-05 10:24     ` [ECOS] Re: STL support under eCos, what does it take? Giovanni Perbellini
2003-12-05 14:52     ` [ECOS] Re: EDOSK-2674 ethernet drivers -TCP problem Uwe Kindler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).