Re: [ECOS] Perhaps an easy one on ethernet MAC chips

[Nick Garnett <nickg at ecoscentric dot com>]

Chuck McManis <ecos@mcmanis.com> writes:

> So the read descriptors are defined with some flags, a length, a
> pointer to the data buffer, and a pointer to the next descriptor.
> 
> When the descriptor goes from being NIC_OWNED to being HOST_OWNED
> (because the NIC put some data in it) the len now contains the actual
> length of the packet received.
> 
> Before it had a packet in there, what should length be set to?
>

To the size of the buffer it point to I expect, 1544.

> I noticed that _BUF_SIZE is hard coded to 1544 bytes. That's a pretty
> standard 1500 byte MTU with 44 bytes of framing wrapped around it. The
> length field is capable of representing up to 2047 bytes, and there
> are flags to say the buffer is only part of the story. (multiple
> buffers could have parts of packets in them). So how does the MAC know
> how much buffer space it has to work with?

I don't know specifically how the rhine device works, but usually the
MAC just fills receive buffers with data from a packet one after the
other and sets a bit in the last buffer of a packet. If there are not
enough buffers in the chain it reports an overrun.

In eCos drivers (and I suspect the drivers for most other operating
systems) we set the buffer size to be larger than any expected
ethernet packet, so we have one packet to one buffer. It just makes
life a lot easier.


-- 
Nick Garnett                                          eCos Kernel Architect
http://www.ecoscentric.com                     The eCos and RedBoot experts
Besuchen Sie uns vom 14.-16.02.06 auf der Embedded World 2006, Stand 11-222
Visit us at Embedded World 2006, NÃrnberg, Germany, 14-16 Feb, Stand 11-222


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