[U-Boot-Users] Smc91c111 - extra bytes in receive buffer

[U-Boot-Users] Smc91c111 - extra bytes in receive buffer

[Earle Clubb]

I'm trying to get the smc91c111 driver running, but I'm having trouble when
reading received packets from the data register.  There always seem to be
extra bytes between the byte count and the destination address of the
received packet.  For example, here is the beginning of a received arp
request:

407f 0042 ffff ffff ffff 000a 407f 0042
ffff ffff ffff 000a 04d0 cd01 0806 0001
0800 0604 0001 000a 04d0 cd01 c0a8 0b01

As you can see, the status word, byte count, destination address, and the
first two bytes of the source address appear to be duplicated.  Usually the
data separating the first byte count from the second dest address is six
words, but it can vary.  Therefore, I'm not able to just trash the extra
words because I might trash part of the packet as well.

Any ideas on why this might be happening?

Another question: what do the bits in the status word for a receive mean?
I've looked through the data sheet and appnote96 and can't find any
definition of the bits.

Thanks for your help.


Earle Clubb

Software Engineer
Valcom, Inc.

E-mail: eclubb at valcom.com
Voice:  (540) 563-2000 x253
Fax:    (540) 362-9800

[U-Boot-Users] Smc91c111 - extra bytes in receive buffer

[Yasushi SHOJI]

At Thu, 20 May 2004 12:41:53 -0400,
Earle Clubb wrote:
> 
> I'm trying to get the smc91c111 driver running, but I'm having trouble when
> reading received packets from the data register.  There always seem to be
> extra bytes between the byte count and the destination address of the
> received packet.  For example, here is the beginning of a received arp
> request:
> 
> 407f 0042 ffff ffff ffff 000a 407f 0042
> ffff ffff ffff 000a 04d0 cd01 0806 0001
> 0800 0604 0001 000a 04d0 cd01 c0a8 0b01
> 
> As you can see, the status word, byte count, destination address, and the
> first two bytes of the source address appear to be duplicated.  Usually the
> data separating the first byte count from the second dest address is six
> words, but it can vary.  Therefore, I'm not able to just trash the extra
> words because I might trash part of the packet as well.

unless LAN91C111 is broken, you, or the protocol stack, can throw away
the broken packet.

what LAN91C111 does is to append two bytes (status word and byte
count) to the data received, so the extra 6 byte you are seeing
_should_ also be in the ethernet frame on the wire. and that frame is
broken. You should use some packet capture tool, ie ethereal, to see
the extra bytes are really on the wire or not.

> Any ideas on why this might be happening?
> 
> Another question: what do the bits in the status word for a receive mean?
> I've looked through the data sheet and appnote96 and can't find any
> definition of the bits.

you can find a section called "receive frame status word", in the data
sheet.

regards,
--
          yashi

X-IMail-SPAM-Phrase Re: [U-Boot-Users] Smc91c111 - extra bytes in receive buffer

[Earle Clubb]

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net 
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf 
> Of Yasushi SHOJI
> Sent: Friday, May 21, 2004 4:31 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: X-IMail-SPAM-Phrase Re: [U-Boot-Users] Smc91c111 - 
> extra bytes in receive buffer
> 
> 
> At Thu, 20 May 2004 12:41:53 -0400,
> Earle Clubb wrote:
> > 
> > I'm trying to get the smc91c111 driver running, but I'm 
> having trouble 
> > when reading received packets from the data register.  There always 
> > seem to be extra bytes between the byte count and the destination 
> > address of the received packet.  For example, here is the 
> beginning of 
> > a received arp
> > request:
> > 
> > 407f 0042 ffff ffff ffff 000a 407f 0042
> > ffff ffff ffff 000a 04d0 cd01 0806 0001
> > 0800 0604 0001 000a 04d0 cd01 c0a8 0b01
> > 
> > As you can see, the status word, byte count, destination 
> address, and 
> > the first two bytes of the source address appear to be duplicated.  
> > Usually the data separating the first byte count from the 
> second dest 
> > address is six words, but it can vary.  Therefore, I'm not able to 
> > just trash the extra words because I might trash part of 
> the packet as 
> > well.
> 
> unless LAN91C111 is broken, you, or the protocol stack, can 
> throw away the broken packet.

It turns out that I had the order wrong.  The first 12 (sometimes 10) bytes
are the extra bytes, then come the status and byte count words, then the
actual received data.  So in the above packet, the first 407f 0042 ffff ffff
ffff 000a sequence is junk, then the status word (407f), then the byte count
(0042), then the proper received data.  The first 12 bytes aren't always
duplicates of the following 12 bytes.  Sometimes it's 10 bytes of what
appears to be junk before the status word.  It appears to vary based on the
received packet type, but is always consistent for a given type.  I never
receive a packet of any type without the extra byte on the front.

> 
> what LAN91C111 does is to append two bytes (status word and byte
> count) to the data received, so the extra 6 byte you are 
> seeing _should_ also be in the ethernet frame on the wire. 
> and that frame is broken. You should use some packet capture 
> tool, ie ethereal, to see the extra bytes are really on the 
> wire or not.
> 

I've been using ethereal to sniff the packets and they're always correct.

> > Any ideas on why this might be happening?
> > 
> > Another question: what do the bits in the status word for a receive 
> > mean? I've looked through the data sheet and appnote96 and 
> can't find 
> > any definition of the bits.
> 
> you can find a section called "receive frame status word", in 
> the data sheet.
> 

Thanks...I found it.

Earle

> regards,
> --
>           yashi
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... 
> Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam 
> FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>