This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ethernet driver - receiving packets doesn't work (conclusion)


Gary Thomas wrote:
Tom Malcolmson wrote:
Hi.

I'm new to eCos - we are trying to move away from a proprietary OS, and
I'm having basic problems with my Ethernet driver.

I'm using an eCos 2.0 snapshot from September 2006 on an ARM platform
with the standard FreeBSD stack.

Sending packets from an eCos app, thru my driver works fine, but eCos
doesn't seem to do anything with the packets that I deliver up to it:
they never back up to the application.  For DHCP for instance, I see the
DHCP request come out of my system, and I see a DHCP offer from the
server go back into my system.  I can see from debug prints in the
generic ethernet driver that it has correctly received the DHCP offer,
but the offer never gets back to the app.  I have tried apps other then
DHCP.

Now, I should expain that there is no actual ethernet hardware, so no
ethernet interrupts, etc.  My guide for writing the driver has been the
eCos reference manual, chapter 46:
http://ecos.sourceware.org/docs-2.0/ref/io-eth-drv-generic1.html
But I skip some steps since I don`t have a DSR.  When I have a packet
for the net stack, I just call (sc->funs->eth_drv->recv)() with the
number of bytes needed.  eCos calls my receive function which puts the
packet into the sg list.  From debug output I can see that the generic
driver code (eth_drv.c) has corrrectly received my packet and presumably
calls ether_input.

A couple other thing.  Loopback tests work.  I don`t have any debugging
capability.

I believe that the next step for me would be to insert print statements
in if_ethersubr.c.

For the network stack, you need to at least pretend that you
get interrupts and call the DSR. The driver normally calls
into the network stack at DSR time and the stack's input
processing thread is what eventually calls your handler
to fetch the packet, etc. I don't think it will work without
this interaction.
Thanks Andrew and Gary for your responses.

I changed my implementation as above. This did not solve my problem, but it did lead me to the solution. With this new implementation I found that my driver_deliver function was not getting called, and that this was because the net stack threads weren't getting scheduled. The priorities of some of my threads were too high. So, lowering CYGPKG_NET_THREAD_PRIORITY solved my problem.

Tom.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]