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

[Tom Malcolmson <Tom@Malcolmson.com>]

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