Re: [ECOS] What functions should I call in ethernet drv ?

[Gary Thomas <gary at mlbassoc dot com>]

ariga masahiro wrote:
> Hello Gary and others,
> 
> I was too much concerned of pointers' contents being NULL.
> I am ashamed.
> 
> I directed my attention toward if_lan91cxx.c.
> 
> I added my coding in if_lan91cxx.c,eth_drv.c,if_ethersubr.c,
> so I exchanged them with original CVS current sources.
> 
> Result was ng_ether_attach_p==NULL and passed out
> (*ng_ether_attach_p)(ifp),
> in next function as before.
> 
> ether_ifattach(ifp, bpf)
> register struct ifnet *ifp;
> int bpf;
> {
>     |
>     |
> if (ng_ether_attach_p != NULL)
>  (*ng_ether_attach_p)(ifp);
> }

You are still chasing the wrong rabbits :-(  None of the "ng_XXX" functions
are implemented, so indeed, these pointers will always be NULL on *every*
system.

> I setted DEBUG=0xFF and stored serial output log.
> Although I checked it I couldn't pinpoint suspicious point.
> I continue to check it.
> 
> As I send you tar file of it,would you please check it.

I looked at this and it looks like your network driver is working,
at least somewhat.  I see packets going out and coming back in,
so the basic network driver is functioning, along with interrupts.

It looks like you've configured the system to use fixed IP addresses?
Are you sure they are correct?  Most times, it's simpler to get started
using DHCP.

My guess is that your platform is having other troubles which are not
network related.  Have you verified other aspects of the kernel, by
running the various test programs?  I would not be surprised if your
system clock (heartbeat timer) is not working properly.

> Also,I remember one point I changed that I should tell you.
> Although I don't know it is related to right now problem.
> 
> I changed cdl_option CYGBLD_GLOBAL_CFLAGS to next
>           default_value { CYGHWR_HAL_SH_BIGENDIAN ? "-D_KERNEL -D__ECOS
> -gdwarf-22 -mb -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline
> -Wundef -Woverloaded-virtual -ggdb -O1 -ffunction-sections
> -fdata-sections -fno-rtti -fno-exceptions -fvtable-gc -finit-priority" :
> "-D_KERNEL -D__ECOS -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes
> -Winline -Wundef -Woverloaded-virtual -ggdb -O1 -ffunction-sections
> -fdata-sections  -fno-rtti -fno-exceptions -fvtable-gc -finit-priority" }
> from original.
> #original  default_value { CYGHWR_HAL_SH_BIGENDIAN ? "-mb -m3 -Wall
> -Wpointer-arith -Wstrict-prototypes -Winline -Wundef
> -Woverloaded-virtual -ggdb -O2 -ffunction-sections -fdata-sections
> -fno-rtti -fno-exceptions -fvtable-gc -finit-priority" : "-ml -m3 -Wall
> -Wpointer-arith -Wstrict-prototypes -Winline -Wundef
> -Woverloaded-virtual -ggdb -O2 -ffunction-sections -fdata-sections
> -fno-rtti -fno-exceptions -fvtable-gc -finit-priority" }
> 
> I changed optimization level from -O2 to -O1
> because when I built on cygwin as it was, there happend many
> Segmentation errors.
> I perused old mailing lists and found that there is bug in sh-elf-gcc,
> and on cygwin -O2 causes above errors whereas less than -O1 causes no
> error.
> So I changed to -O1.

An age-old problem with CygWin - completely reasonable to do.

Run the other system tests to verify that the rest of your system
is functioning properly.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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