[ECOS] Building error on CVS checkout sources

[ECOS] Building error on CVS checkout sources

[ariga masahiro]

Hi,

When I used other network than my com's
I succeeded to download newsources from CVS repository.
Maybe it was caused by my com's server limitation.

I am sorry for having bothered you.

First of all I tried to build from checkouted sources before anything 
changes.
I believe "A good beginning makes a good ending."

But I encountered next Building error.(Bad omen)

So before I tamper with anything I would like you to make my brain clear.

I made /ecoscvs under /opt and changed
ECOS_REPOSITORY environment variable like next.
ECOS_REPOSITORY=/opt/ecoscvs/ecos/packages ; export ECOS_REPOSITORY

Please enlighten me why next error happened although anything changed.
I put on last part of Building log below.

I each time started up configtool.exe and made save directory.
I usesd Template for Target "Hitach SE77x9 board" and "old_net".
I tried "net" Template too but resulted into the same error.

--"old_net" Buildin error
make[1]: Leaving directory 
`/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_build/io/fileio/current'
make -r -C net/common/current build
make[1]: Entering directory 
`/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_build/net/common/current'
sh-elf-gcc -c  -I/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_install/include 
 -I/opt/ecoscvs/ecos/packages/net/common/current -I/opt/ecoscvs/ecos/packages/net/common/current/src 
 -I/opt/ecoscvs/ecos/packages/net/common/current/tests -I. -I/opt/ecoscvs/ecos/packages/net/common/current/src/ 
 -finline-limit=7000 -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
 -Wundef  -ggdb -O2 -ffunction-sections -fdata-sections  -fno-exceptions   -D_KERNEL 
 -D__ECOS -D__INSIDE_NET -Wp,-MD,src/inet_addr.tmp -o 
src/net_common_inet_addr.o 
/opt/ecoscvs/ecos/packages/net/common/current/src/inet_addr.c
sh-elf-gcc -c  -I/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_install/include 
 -I/opt/ecoscvs/ecos/packages/net/common/current -I/opt/ecoscvs/ecos/packages/net/common/current/src 
 -I/opt/ecoscvs/ecos/packages/net/common/current/tests -I. -I/opt/ecoscvs/ecos/packages/net/common/current/src/ 
 -finline-limit=7000 -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
 -Wundef  -ggdb -O2 -ffunction-sections -fdata-sections  -fno-exceptions   -D_KERNEL 
 -D__ECOS -D__INSIDE_NET -Wp,-MD,src/inet_ntoa.tmp -o 
src/net_common_inet_ntoa.o 
/opt/ecoscvs/ecos/packages/net/common/current/src/inet_ntoa.c
sh-elf-gcc -c  -I/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_install/include 
 -I/opt/ecoscvs/ecos/packages/net/common/current -I/opt/ecoscvs/ecos/packages/net/common/current/src 
 -I/opt/ecoscvs/ecos/packages/net/common/current/tests -I. -I/opt/ecoscvs/ecos/packages/net/common/current/src/ 
 -finline-limit=7000 -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
 -Wundef  -ggdb -O2 -ffunction-sections -fdata-sections  -fno-exceptions   -D_KERNEL 
 -D__ECOS -D__INSIDE_NET -Wp,-MD,src/inet_ntop.tmp -o 
src/net_common_inet_ntop.o 
/opt/ecoscvs/ecos/packages/net/common/current/src/inet_ntop.c
sh-elf-gcc -c  -I/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_install/include 
 -I/opt/ecoscvs/ecos/packages/net/common/current -I/opt/ecoscvs/ecos/packages/net/common/current/src 
 -I/opt/ecoscvs/ecos/packages/net/common/current/tests -I. -I/opt/ecoscvs/ecos/packages/net/common/current/src/ 
 -finline-limit=7000 -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
 -Wundef  -ggdb -O2 -ffunction-sections -fdata-sections  -fno-exceptions   -D_KERNEL 
 -D__ECOS -D__INSIDE_NET -Wp,-MD,src/inet_pton.tmp -o 
src/net_common_inet_pton.o 
/opt/ecoscvs/ecos/packages/net/common/current/src/inet_pton.c
sh-elf-gcc -c  -I/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_install/include 
 -I/opt/ecoscvs/ecos/packages/net/common/current -I/opt/ecoscvs/ecos/packages/net/common/current/src 
 -I/opt/ecoscvs/ecos/packages/net/common/current/tests -I. -I/opt/ecoscvs/ecos/packages/net/common/current/src/ 
 -finline-limit=7000 -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
 -Wundef  -ggdb -O2 -ffunction-sections -fdata-sections  -fno-exceptions   -D_KERNEL 
 -D__ECOS -D__INSIDE_NET -Wp,-MD,src/bootp_support.tmp -o 
src/net_common_bootp_support.o 
/opt/ecoscvs/ecos/packages/net/common/current/src/bootp_support.c
sh-elf-gcc -c  -I/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_install/include 
 -I/opt/ecoscvs/ecos/packages/net/common/current -I/opt/ecoscvs/ecos/packages/net/common/current/src 
 -I/opt/ecoscvs/ecos/packages/net/common/current/tests -I. -I/opt/ecoscvs/ecos/packages/net/common/current/src/ 
 -finline-limit=7000 -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
 -Wundef  -ggdb -O2 -ffunction-sections -fdata-sections  -fno-exceptions   -D_KERNEL 
 -D__ECOS -D__INSIDE_NET -Wp,-MD,src/dhcp_support.tmp -o 
src/net_common_dhcp_support.o 
/opt/ecoscvs/ecos/packages/net/common/current/src/dhcp_support.c
sh-elf-gcc -c  -I/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_install/include 
 -I/opt/ecoscvs/ecos/packages/net/common/current -I/opt/ecoscvs/ecos/packages/net/common/current/src 
 -I/opt/ecoscvs/ecos/packages/net/common/current/tests -I. -I/opt/ecoscvs/ecos/packages/net/common/current/src/ 
 -finline-limit=7000 -ml -m3 -Wall -Wpointer-arith -Wstrict-prototypes -Winline 
 -Wundef  -ggdb -O2 -ffunction-sections -fdata-sections  -fno-exceptions   -D_KERNEL 
 -D__ECOS -D__INSIDE_NET -Wp,-MD,src/dhcp_prot.tmp -o 
src/net_common_dhcp_prot.o 
/opt/ecoscvs/ecos/packages/net/common/current/src/dhcp_prot.c
make[1]: Leaving directory 
`/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_build/net/common/current'
/opt/ecoscvs/ecos/packages/net/common/current/src/dhcp_prot.c: In function 
`do_dhcp':
make: Leaving directory 
`/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_build'
/opt/ecoscvs/ecos/packages/net/common/current/src/dhcp_prot.c:1375: internal 
error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[1]: *** [src/dhcp_prot.o.d] Error 1
make: *** [build] Error 2

Please make my brain clear.

Masahiro Ariga


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

[ECOS] Re: Building error on CVS checkout sources

[Andrew Lunn]

> I usesd Template for Target "Hitach SE77x9 board" and "old_net".
> I tried "net" Template too but resulted into the same error.

...

> `/ecos-c/cygwin/home/LINK/ecoscvs-old_net/untitled1_build'
> /opt/ecoscvs/ecos/packages/net/common/current/src/dhcp_prot.c:1375: 
> internal error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

lunn@londo:~/eCos/work$ rm -fr *
lunn@londo:~/eCos/work$ ecosconfig new se77x9 net
U CYGPKG_HAL_SH_7709A, new inferred value 0
U CYGPKG_HAL_SH_7709S, new inferred value 1
U CYGPRI_HAL_SH_SH77X9_SUPERIO, new inferred value 1
U CYGHWR_HAL_SH_IRQ_USE_IRQLVL, new inferred value 1
U CYGBLD_ISO_STRUCTTIMEVAL_HEADER, new inferred value <cyg/posix/sys/time.h>
U CYGBLD_ISO_FNMATCH_HEADER, new inferred value <cyg/fileio/fnmatch.h>
lunn@londo:~/eCos/work$ ecosconfig tree
lunn@londo:~/eCos/work$ make -s
headers finished
build finished

So it builds for me.

What version of gcc are you using? I have:

lunn@londo:~/eCos/work$ sh-elf-gcc -v
Reading specs from /opt/ecos/gnutools/sh-elf/bin/../lib/gcc-lib/sh-elf/3.2.1/specs
Configured with: /home/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/x86_linux_lsb1_3/tar_bz2/source/gcc-3.2.1/configure --target=sh-elf --prefix=/home/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/x86_linux_lsb1_3/tar_bz2/opt/ecos/gnutools/sh-elf --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=/home/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/x86_linux_lsb1_3/tar_bz2/opt/ecos/gnutools/sh-elf/sh-elf/include
Thread model: single
gcc version 3.2.1

    Andrew

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

[ECOS] Virtual Vector Configuration

[Stefan Sommerfeld]

Hello,

I'm searching for the right eCos configuration to replace all virtual 
vector functions from the bootloader with the one's from a loaded 
application. Especially the exception code must be replace.

My problem is that the MIPS fpu exception code has some bugs (I'll do a 
patch soon), but the code is inside the redboot (it's in the flash). I 
don't want to exchange the bootloaders on many systems and another point 
would be that the code from flash runs slighly slower than from ram. I saw 
the option "initialize whole of virtual vector table" in the configtool, 
but I'm not sure if this will also initilize the exception functions. 
Another problem with it would be that I need the version vector from 
bootloader, which tells my information about the hardware.

Any suggestion what would be the right way?

Bye.... 


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

Re: [ECOS] Virtual Vector Configuration

[Nick Garnett]

"Stefan Sommerfeld" <sommerfeld@mikrom.de> writes:

> Hello,
> 
> I'm searching for the right eCos configuration to replace all virtual
> vector functions from the bootloader with the one's from a loaded
> application. Especially the exception code must be replace.
> 
> My problem is that the MIPS fpu exception code has some bugs (I'll do
> a patch soon), but the code is inside the redboot (it's in the
> flash). I don't want to exchange the bootloaders on many systems and
> another point would be that the code from flash runs slighly slower
> than from ram. I saw the option "initialize whole of virtual vector
> table" in the configtool, but I'm not sure if this will also initilize
> the exception functions. Another problem with it would be that I need
> the version vector from bootloader, which tells my information about
> the hardware.
> 
> Any suggestion what would be the right way?

What you want to do has nothing to do with the virtual vector
table. Instead you need to update the VSR table with a pointer to the
default exception VSR in your executable rather than the one in
RedBoot. You should be able to do this in C from your
hal_platform_init() routine. Something like:

    hal_vsr_table[CYGNUM_HAL_VECTOR_FPE] = __default_exception_vsr;

Add appropriate #includes and extern declarations to keep the compiler
happy.


-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


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

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

[ariga masahiro]

Hello,

I am in a complete predicament,please help me.

I am testing SMSC LAN91C111 ethernet driver using nc_test_slave/master
and managed to make it run,correctly say,I succeeded to receive ARP from 
host.

But I discovered that in ether_input and ether_output functions in 
if_ethersubr.c file,
ng_ether_input_p and ng_ether_output_p pointers are both NULL,and passed out 
function calls.

\packages\net\bsd_tcpip\current\src\sys\net\if_ethersubr.c
ether_input(ifp, eh, m)
 /* Handle ng_ether(4) processing, if any */
 if (ng_ether_input_p != NULL) {
  (*ng_ether_input_p)(ifp, &m, eh);
  if (m == NULL)
   return;
 }

ether_output(ifp, m, dst, rt0)
 /* Handle ng_ether(4) processing, if any */
 if (ng_ether_output_p != NULL) {
  if ((error = (*ng_ether_output_p)(ifp, &m)) != 0) {
bad:   if (m != NULL)
    m_freem(m);
   return (error);
  }
  if (m == NULL)
   return (0);
 }

I encountered the same problem in ether_ifattach in the same file
where ng_ether_attach_p were NULL and passed out function call.
But at that time I found next function fulfill need,
so I inserted pointer assignment before function call like below.

packages\net\bsd_tcpip\current\src\sys\net\if.c
if_attach(ifp)

ether_ifattach(ifp, bpf)
    ng_ether_attach_p = if_attach;  // inserted
   if (ng_ether_attach_p != NULL)
      (*ng_ether_attach_p)(ifp);

I hope I was right.

But this time I can't find suitable functions in ether_input and 
ether_output.
It is crestfallen to select every functions.Is there any way to select 
correctly ?

Or rather,since I configured to use LAN91C111 driver specifically,
it is unreasonable to choose each functions manually.
There ought be the way to initialize cyg_ pointers in param.h.

Please let me know how to initialize cyg_ pointers so I could use LAN91C111 
driver properly.

I need your help urgently.

Masahiro Ariga


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

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

[Gary Thomas]

ariga masahiro wrote:
> Hello,
>
> I am in a complete predicament,please help me.
>
> I am testing SMSC LAN91C111 ethernet driver using nc_test_slave/master
> and managed to make it run,correctly say,I succeeded to receive ARP
> from host.
>
> But I discovered that in ether_input and ether_output functions in
> if_ethersubr.c file,
> ng_ether_input_p and ng_ether_output_p pointers are both NULL,and
> passed out function calls.
>
> \packages\net\bsd_tcpip\current\src\sys\net\if_ethersubr.c
> ether_input(ifp, eh, m)
> /* Handle ng_ether(4) processing, if any */
> if (ng_ether_input_p != NULL) {
>  (*ng_ether_input_p)(ifp, &m, eh);
>  if (m == NULL)
>   return;
> }
>
> ether_output(ifp, m, dst, rt0)
> /* Handle ng_ether(4) processing, if any */
> if (ng_ether_output_p != NULL) {
>  if ((error = (*ng_ether_output_p)(ifp, &m)) != 0) {
> bad:   if (m != NULL)
>    m_freem(m);
>   return (error);
>  }
>  if (m == NULL)
>   return (0);
> }
>
> I encountered the same problem in ether_ifattach in the same file
> where ng_ether_attach_p were NULL and passed out function call.
> But at that time I found next function fulfill need,
> so I inserted pointer assignment before function call like below.
>
> packages\net\bsd_tcpip\current\src\sys\net\if.c
> if_attach(ifp)
>
> ether_ifattach(ifp, bpf)
>    ng_ether_attach_p = if_attach;  // inserted
>   if (ng_ether_attach_p != NULL)
>      (*ng_ether_attach_p)(ifp);
>
> I hope I was right.
>
> But this time I can't find suitable functions in ether_input and
> ether_output.
> It is crestfallen to select every functions.Is there any way to select
> correctly ?
>
> Or rather,since I configured to use LAN91C111 driver specifically,
> it is unreasonable to choose each functions manually.
> There ought be the way to initialize cyg_ pointers in param.h.
>
> Please let me know how to initialize cyg_ pointers so I could use
> LAN91C111 driver properly.
You should not need to be messing with *any* of this.  The lanC91xx
driver is known to work,
as is, on a number of platforms.

I assume that this is for a new platform/port?  Did you follow the model
of how other platforms
are using this device?

-- 
------------------------------------------------------------
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

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

[ariga masahiro]

Hello Gary and others,

Gary,thank you very much for your reply.
You know,it is relieving to know that my mail are looked at.

I am desperately looking over my coding from begining to end.
But so far I cannot pinpoint the cause.

You know,since I do not know the intricacies of eCos,
(e.g. what is related to what)
it is very hard to search suspicious points.

This is very hard to say,but
I previously posted mails to describe as closely as possible my target's 
ported parts.
title:[ECOS] Not working lan91cxx_sc drv

Could I be bold enough to ask you to look at them ?
I mostly appreciate if you could suggest any suspicious points.
Or if you could think of any checking points,please let me know.

I heartly welcom any reply of you.

Thanks in advance.

Masahiro Ariga


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

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

[Gary Thomas]

ariga masahiro wrote:
> Hello Gary and others,
> 
> Gary,thank you very much for your reply.
> You know,it is relieving to know that my mail are looked at.
> 
> I am desperately looking over my coding from begining to end.
> But so far I cannot pinpoint the cause.
> 
> You know,since I do not know the intricacies of eCos,
> (e.g. what is related to what)
> it is very hard to search suspicious points.
> 
> This is very hard to say,but
> I previously posted mails to describe as closely as possible my target's
> ported parts.
> title:[ECOS] Not working lan91cxx_sc drv
> 
> Could I be bold enough to ask you to look at them ?
> I mostly appreciate if you could suggest any suspicious points.
> Or if you could think of any checking points,please let me know.

Send the files (exact - not the pseudo-code segments
that you've previously posted or even patches) to
ecos-patches@ecos.sourceware.org.  Pack them up (just the network
driver) as a tar file.  I'll give them a look and comment.

For example, if you were using the "innovator" target, you
would send the contents of the .../devs/eth/arm/innovator
directory.


-- 
------------------------------------------------------------
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

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

[ariga masahiro]

Hello Gary and others,

Sorry I missed 10/16/2007 20:08 mail,
I will prepare tar file and send you soon.

Before that,
Some points became cleared and also arose other question
and I rely on your suggestion.

I think the trouble is not my amendment or coding,rather how I 'use' eCos 
application.
Let me explain.

I debugged on the next premise.

[premise]
 There are no assingments to function 
pointers(e.g.ng_ether_attach_p,ng_ether_input_p) in coding,
so their inside values(=function addresses) are settled at the time of 
loading binary into RAM.
They are initially defined in 
\packages\net\bsd_tcpip\current\include\sys\param.h like next
#define ng_ether_attach_p cyg_ng_ether_attach_p
.

On the above premise I decided to check on sampled
 Hitachi SE77x9 Template that I used as protocol to develop my target 
template.
Source is CVS current version ,so it must work correctly.
I just only amended memory layout as same as my target template.

I built 'RAM' Start Mode and linked to nc_test_slave test.
I loaded elf file on RAM using ICE,and dumped memory addresses.

Result was just as same as my template.

--from memory map
 COMMON         0x000000008c0c0208       0x18 
/ecos-c/cygwin/home/LINK/ecoscvs_se-net-SE7709-2/untitled_install/lib/libtarget.a(net_bsd_tcpip_if_ethersubr.o)
                                          0x0 (size before relaxing)
                0x000000008c0c0208                _cyg_ng_ether_input_p
                0x000000008c0c020c                _cyg_ng_ether_detach_p
                0x000000008c0c0210 
_sysctl__net_link_ether_children
                0x000000008c0c0214                _cyg_ng_ether_attach_p
                0x000000008c0c0218                _cyg_ng_ether_output_p
                0x000000008c0c021c 
_cyg_ng_ether_input_orphan_p
 COMMON         0x000000008c0c0220       0xe8 
/ecos-c/cygwin/home/LINK/ecoscvs_se-net-SE7709-2/untitled_install/lib/libtarget.a(net_bsd_tcpip_if_loop.o)

and memory dump after loading.
URAM  8C0C0214  cyg_ng_ether_attach_p        00 00 00 00 00 00 00 00 
........
URAM  8C0C021C  cyg_ng_ether_input_orphan_p  00 00 00 00 00 00 00 00 
........
URAM  8C0C0224  cyg_loif+4                   00 00 00 00 00 00 00 00 
........
URAM  8C0C022C  cyg_loif+c                   00 00 00 00 00 00 00 00 
........
URAM  8C0C0234  cyg_loif+14                  00 00 00 00 00 00 00 00 
........
URAM  8C0C023C  cyg_loif+1c                  00 00 00 00 00 00 00 00 
........
URAM  8C0C0244  cyg_loif+24                  00 00 00 00 00 00 00 00 
........
URAM  8C0C024C  cyg_loif+2c                  00 00 00 00 00 00 00 00 
........
URAM  8C0C0254  cyg_loif+34                  00 00 00 00 00 00 00 00 
........
URAM  8C0C025C  cyg_loif+3c                  00 00 00 00 00 00 00 00 
........
URAM  8C0C0264  cyg_loif+44                  00 00 00 00 00 00 00 00 
........
URAM  8C0C026C  cyg_loif+4c                  00 00 00 00 00 00 00 00 
........
URAM  8C0C0274  cyg_loif+54                  00 00 00 00 00 00 00 00 
........
URAM  8C0C027C  cyg_loif+5c                  00 00 00 00 00 00 00 00 
........

I put on my target's memory layout files.
\packages\hal\sh\inserter\current\include\pkgconf\mlt_sh_sh77x9_inserter_ram.ldi
--- begin
#include <cyg/infra/cyg_type.inc>

MEMORY
{
    ram : ORIGIN = 0x8c000000, LENGTH = 0x4000000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_vectors (ram, 0x8c010000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x1), LMA_EQ_VMA)
    SECTION_data (ram, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_bss (ram, ALIGN (0x10), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}
--- end

\packages\hal\sh\inserter\current\include\pkgconf\mlt_sh_sh77x9_inserter_ram.h
--- begin
#ifndef __ASSEMBLER__
#include <cyg/infra/cyg_type.h>
#include <stddef.h>

#endif
#define CYGMEM_REGION_ram (0x8c000000)
#define CYGMEM_REGION_ram_SIZE (0x4000000)
#define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R | CYGMEM_REGION_ATTR_W)
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__heap1) [];
#endif
#define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
#define CYGMEM_SECTION_heap1_SIZE (0x90000000 - (size_t) CYG_LABEL_NAME 
(__heap1))
#ifndef __ASSEMBLER__
extern char CYG_LABEL_NAME (__pci_window) [];
#endif
--- end

and application makefile
--- begin
export PREFIX := 
/ecos-c/cygwin/home/LINK/ecoscvs_l_net_20071015/unnamed2_install

export COMMAND_PREFIX := sh-elf-
export CC := $(COMMAND_PREFIX)gcc
export OBJCOPY := $(COMMAND_PREFIX)objcopy
export HOST := CYGWIN
export AR := $(COMMAND_PREFIX)ar

XCC = sh-elf-gcc

## Build flags.
CFLAGS = -g -Wall -I$(PREFIX)/include -ffunction-sections -fdata-sections
LDFLAGS 
= -nostartfiles -L$(PREFIX)/lib -Wl,--gc-sections -Wl,--Map -Wl,nc_test_slave.map
LIBS = -Ttarget.ld -nostdlib
LD  = $(XCC)

## Build rules.
all: nc_test_slave

nc_test_slave.o: nc_test_slave.c
 $(XCC) -c -o $*.o $(CFLAGS) $<

nc_test_slave: nc_test_slave.o
 $(LD) $(LDFLAGS) -o $@ $@.o $(LIBS)

clean:
 -rm -f nc_test_slave.exe nc_test_slave.o nc_test_slave.map
--- end

From above result I suppose I must do 'something' to make LAN91C111 driver 
work,
or my environments lack somthing ?

If you could elicit any conclusion from above accounts
please enligten me.

I look foward to any suggestion.

Thank you in advance.

Sincerely,

 Masahiro Ariga


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

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

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Hello Gary and others,

I made tar file so send you.

As I said in my last mail I used SE77x9 template as my protocol.
And as makink LAN91c111 instatiating file(devs_eth_inserter.inl)
I refered to \arm\sa11x0\flexanet.

I mostly appreciate your help.

Thank you very much.

Sincerely,
 Masahiro Ariga

[-- Attachment #2: mytarget.tar --]
[-- Type: application/x-tar, Size: 40960 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

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

[Gary Thomas]

ariga masahiro wrote:
> Hello Gary and others,
> 
> Sorry I missed 10/16/2007 20:08 mail,
> I will prepare tar file and send you soon.
> 
> Before that,
> Some points became cleared and also arose other question
> and I rely on your suggestion.
> 
> I think the trouble is not my amendment or coding,rather how I 'use'
> eCos application.
> Let me explain.
> 
> I debugged on the next premise.
> 
> [premise]
> There are no assingments to function
> pointers(e.g.ng_ether_attach_p,ng_ether_input_p) in coding,
> so their inside values(=function addresses) are settled at the time of
> loading binary into RAM.
> They are initially defined in
> \packages\net\bsd_tcpip\current\include\sys\param.h like next
> #define ng_ether_attach_p cyg_ng_ether_attach_p
> .
> 
> On the above premise I decided to check on sampled
> Hitachi SE77x9 Template that I used as protocol to develop my target
> template.
> Source is CVS current version ,so it must work correctly.
> I just only amended memory layout as same as my target template.
> 
> I built 'RAM' Start Mode and linked to nc_test_slave test.
> I loaded elf file on RAM using ICE,and dumped memory addresses.
> 
> Result was just as same as my template.
> 
> --from memory map
> COMMON         0x000000008c0c0208       0x18
> /ecos-c/cygwin/home/LINK/ecoscvs_se-net-SE7709-2/untitled_install/lib/libtarget.a(net_bsd_tcpip_if_ethersubr.o)
> 
>                                          0x0 (size before relaxing)
>                0x000000008c0c0208                _cyg_ng_ether_input_p
>                0x000000008c0c020c                _cyg_ng_ether_detach_p
>                0x000000008c0c0210 _sysctl__net_link_ether_children
>                0x000000008c0c0214                _cyg_ng_ether_attach_p
>                0x000000008c0c0218                _cyg_ng_ether_output_p
>                0x000000008c0c021c _cyg_ng_ether_input_orphan_p
> COMMON         0x000000008c0c0220       0xe8
> /ecos-c/cygwin/home/LINK/ecoscvs_se-net-SE7709-2/untitled_install/lib/libtarget.a(net_bsd_tcpip_if_loop.o)
> 
> 
> and memory dump after loading.
> URAM  8C0C0214  cyg_ng_ether_attach_p        00 00 00 00 00 00 00 00
> ........
> URAM  8C0C021C  cyg_ng_ether_input_orphan_p  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C0224  cyg_loif+4                   00 00 00 00 00 00 00 00
> ........
> URAM  8C0C022C  cyg_loif+c                   00 00 00 00 00 00 00 00
> ........
> URAM  8C0C0234  cyg_loif+14                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C023C  cyg_loif+1c                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C0244  cyg_loif+24                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C024C  cyg_loif+2c                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C0254  cyg_loif+34                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C025C  cyg_loif+3c                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C0264  cyg_loif+44                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C026C  cyg_loif+4c                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C0274  cyg_loif+54                  00 00 00 00 00 00 00 00
> ........
> URAM  8C0C027C  cyg_loif+5c                  00 00 00 00 00 00 00 00
> ........
> 
> I put on my target's memory layout files.
> \packages\hal\sh\inserter\current\include\pkgconf\mlt_sh_sh77x9_inserter_ram.ldi
> 
> --- begin
> #include <cyg/infra/cyg_type.inc>
> 
> MEMORY
> {
>    ram : ORIGIN = 0x8c000000, LENGTH = 0x4000000
> }
> 
> SECTIONS
> {
>    SECTIONS_BEGIN
>    SECTION_vectors (ram, 0x8c010000, LMA_EQ_VMA)
>    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
>    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
>    SECTION_rodata1 (ram, ALIGN (0x8), LMA_EQ_VMA)
>    SECTION_rodata (ram, ALIGN (0x8), LMA_EQ_VMA)
>    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
>    SECTION_gcc_except_table (ram, ALIGN (0x1), LMA_EQ_VMA)
>    SECTION_data (ram, ALIGN (0x8), LMA_EQ_VMA)
>    SECTION_bss (ram, ALIGN (0x10), LMA_EQ_VMA)
>    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
>    SECTIONS_END
> }
> --- end
> 
> \packages\hal\sh\inserter\current\include\pkgconf\mlt_sh_sh77x9_inserter_ram.h
> 
> --- begin
> #ifndef __ASSEMBLER__
> #include <cyg/infra/cyg_type.h>
> #include <stddef.h>
> 
> #endif
> #define CYGMEM_REGION_ram (0x8c000000)
> #define CYGMEM_REGION_ram_SIZE (0x4000000)
> #define CYGMEM_REGION_ram_ATTR (CYGMEM_REGION_ATTR_R |
> CYGMEM_REGION_ATTR_W)
> #ifndef __ASSEMBLER__
> extern char CYG_LABEL_NAME (__heap1) [];
> #endif
> #define CYGMEM_SECTION_heap1 (CYG_LABEL_NAME (__heap1))
> #define CYGMEM_SECTION_heap1_SIZE (0x90000000 - (size_t) CYG_LABEL_NAME
> (__heap1))
> #ifndef __ASSEMBLER__
> extern char CYG_LABEL_NAME (__pci_window) [];
> #endif
> --- end
> 
> and application makefile
> --- begin
> export PREFIX :=
> /ecos-c/cygwin/home/LINK/ecoscvs_l_net_20071015/unnamed2_install
> 
> export COMMAND_PREFIX := sh-elf-
> export CC := $(COMMAND_PREFIX)gcc
> export OBJCOPY := $(COMMAND_PREFIX)objcopy
> export HOST := CYGWIN
> export AR := $(COMMAND_PREFIX)ar
> 
> XCC = sh-elf-gcc
> 
> ## Build flags.
> CFLAGS = -g -Wall -I$(PREFIX)/include -ffunction-sections -fdata-sections
> LDFLAGS = -nostartfiles -L$(PREFIX)/lib -Wl,--gc-sections -Wl,--Map
> -Wl,nc_test_slave.map
> LIBS = -Ttarget.ld -nostdlib
> LD  = $(XCC)
> 
> ## Build rules.
> all: nc_test_slave
> 
> nc_test_slave.o: nc_test_slave.c
> $(XCC) -c -o $*.o $(CFLAGS) $<
> 
> nc_test_slave: nc_test_slave.o
> $(LD) $(LDFLAGS) -o $@ $@.o $(LIBS)
> 
> clean:
> -rm -f nc_test_slave.exe nc_test_slave.o nc_test_slave.map
> --- end
> 
>> From above result I suppose I must do 'something' to make LAN91C111
>> driver 
> work,
> or my environments lack somthing ?
> 
> If you could elicit any conclusion from above accounts
> please enligten me.
> 
> I look foward to any suggestion.

Firstly, the fact that cyg_ng_ether_input_p is NULL is not important.
This is just an [optional] hook function for handling NetGraph protocol events.

Have you traced the actual ethernet driver ?
  (.../devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c )

I'd start by setting DEBUG=0xFF (manually, you have to edit that file).
This will turn on lots of messages and should guide you as to why the
driver is not working.

Note: the upper layers of the network code (and indeed most of the
drivers) are well proven - you probably don't need to be hunting
there for bugs, at least not the "out of the starting block" kind
that you have.  Stick to the actual driver :-)

-- 
------------------------------------------------------------
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

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

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]

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);
}

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 gzip file of it,would you please check it.

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.

And -gdwarf-22 is for making it readable for ICE(PalmICE).

I look forward your reply.

Thank you in advance.

Masahiro Ariga

[-- Attachment #2: teraterm_output.gz --]
[-- Type: application/x-gzip, Size: 6580 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

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

[Gary Thomas]

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

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

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]

Hello Gary and others,

Gary,
thanks for your help, I think I came close to the root of the trouble.(I 
hope)

I discovered(to the truth,I dicovered previously) received data upsidedown.
Please refer to 809-line in last-sent output log

8C05ECEC: FF FF FF FF FF FF 15 00  6D C5 F0 23 06 08        |........m..#.. 
|

Whereas host sends.
0000  ff ff ff ff ff ff 00 15  c5 6d 23 f0 08 06 00 01   ........ .m#.....
0010  08 00 06 04 00 01 00 15  c5 6d 23 f0 ac 10 01 1c   ........ .m#.....
0020  00 00 00 00 00 00 ac 10  01 1c                     ........ ..

ARP command should be 08 06.

(I am very sorry if it deliberately display them in little endian form.)

I thought I could amend this and I amended(I thought) like next in
\packages\devs\eth\smsc\lan91cxx\current\src\if_lan91cxx.c.
(I risk of appearing stupid but I henestly tell what I did.)
cyg_uint8 get_data_byte(struct eth_drv_sc *sc)
{
    //20070919
    int sf;

    cyg_uint8 c;
    struct lan91cxx_priv_data *cpd =
        (struct lan91cxx_priv_data *)sc->driver_private;

//    //20070919
//    db_printf("cpd->data_pos=%d rxd_t=%d\n",cpd->data_pos,sizeof(rxd_t));

    if( cpd->data_pos == sizeof(rxd_t) )
    {
        cpd->data_buf = get_data(sc);
        cpd->data_pos = 0;
        //20070919
        sf = 1;
    }
    //20070919 begin
    else{
        sf = 0;
  }
    //20070919 end

    //20070919 begin
//ORG    c = (cpd->data_buf>>(cpd->data_pos*8))&0xFF;
    c = (cpd->data_buf>>(sf*8))&0xFF;

//    //20070919
//    db_printf("cpd->data_buf=%x c=%x\n",cpd->data_buf,c);

    cpd->data_pos++;

    return c;

}

After that I ran and stored output log(I send gzip file).
To my astonishment,I found RxEvent errored.
Please refer to 795-line.
RxEvent - bad rx: stat: 0x7f40, len: 0x41fa

Apparantly I wrongly concocted.
I am still tracing source but I haven't found smart answer.
Even if I thought I could have corrected it myself,
I worries that my bad coding affects anywhere else.

Please teach me how to best amend this behaviour.
(I am afraid this time also I am missing target.)

I honestly hope this breaks the stagnation.

I would appreciate your reply.
Thanks in advance.

Masahiro Ariga

[-- Attachment #2: afterchangedlog.txt.gz --]
[-- Type: application/x-gzip, Size: 2626 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

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

[Gary Thomas]

ariga masahiro wrote:
> Hello Gary and others,
> 
> Gary,
> thanks for your help, I think I came close to the root of the trouble.(I
> hope)
> 
> I discovered(to the truth,I dicovered previously) received data upsidedown.
> Please refer to 809-line in last-sent output log
> 
> 8C05ECEC: FF FF FF FF FF FF 15 00  6D C5 F0 23 06 08       
> |........m..#.. |
> 
> Whereas host sends.
> 0000  ff ff ff ff ff ff 00 15  c5 6d 23 f0 08 06 00 01   ........ .m#.....
> 0010  08 00 06 04 00 01 00 15  c5 6d 23 f0 ac 10 01 1c   ........ .m#.....
> 0020  00 00 00 00 00 00 ac 10  01 1c                     ........ ..
> 
> ARP command should be 08 06.
> 
> (I am very sorry if it deliberately display them in little endian form.)
> 
> I thought I could amend this and I amended(I thought) like next in
> \packages\devs\eth\smsc\lan91cxx\current\src\if_lan91cxx.c.
> (I risk of appearing stupid but I henestly tell what I did.)
> cyg_uint8 get_data_byte(struct eth_drv_sc *sc)
> {
>    //20070919
>    int sf;
> 
>    cyg_uint8 c;
>    struct lan91cxx_priv_data *cpd =
>        (struct lan91cxx_priv_data *)sc->driver_private;
> 
> //    //20070919
> //    db_printf("cpd->data_pos=%d rxd_t=%d\n",cpd->data_pos,sizeof(rxd_t));
> 
>    if( cpd->data_pos == sizeof(rxd_t) )
>    {
>        cpd->data_buf = get_data(sc);
>        cpd->data_pos = 0;
>        //20070919
>        sf = 1;
>    }
>    //20070919 begin
>    else{
>        sf = 0;
>  }
>    //20070919 end
> 
>    //20070919 begin
> //ORG    c = (cpd->data_buf>>(cpd->data_pos*8))&0xFF;
>    c = (cpd->data_buf>>(sf*8))&0xFF;
> 
> //    //20070919
> //    db_printf("cpd->data_buf=%x c=%x\n",cpd->data_buf,c);
> 
>    cpd->data_pos++;
> 
>    return c;
> 
> }
> 
> After that I ran and stored output log(I send gzip file).
> To my astonishment,I found RxEvent errored.
> Please refer to 795-line.
> RxEvent - bad rx: stat: 0x7f40, len: 0x41fa
> 
> Apparantly I wrongly concocted.
> I am still tracing source but I haven't found smart answer.
> Even if I thought I could have corrected it myself,
> I worries that my bad coding affects anywhere else.
> 
> Please teach me how to best amend this behaviour.
> (I am afraid this time also I am missing target.)
> 
> I honestly hope this breaks the stagnation.
> 
> I would appreciate your reply.
> Thanks in advance.
> 
> Masahiro Ariga

You should not have to change the driver.  The differences in
endian-ness are handled by the macros CYG_CPU_TO_LE16() and
CYG_LE16_TO_CPU().  Make sure that your HAL defines them
correctly.


-- 
------------------------------------------------------------
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

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

[ariga masahiro]

Hello Gary and others,

> Gray wrote:
> You should not have to change the driver.  The differences in
> endian-ness are handled by the macros CYG_CPU_TO_LE16() and
> CYG_LE16_TO_CPU().  Make sure that your HAL defines them
> correctly.

The received data are reserved into data buffer in lan91cxx_recv's
line 1230 - line 1235
lan91cxx_recv()
      1230:         if (data) {
      1231:             while( clen > 0 ) {
      1232:                 *data++ = get_data_byte(sc);
      1233:                 clen--;
      1234:             }
      1235:         }

-->
cyg_uint8 get_data_byte(struct eth_drv_sc *sc)
{
    cyg_uint8 c;
    struct lan91cxx_priv_data *cpd =
        (struct lan91cxx_priv_data *)sc->driver_private;

    if( cpd->data_pos == sizeof(rxd_t) )
    {
        cpd->data_buf = get_data(sc);
        cpd->data_pos = 0;
    }

    c = (cpd->data_buf>>(cpd->data_pos*8))&0xFF;
    cpd->data_pos++;

    return c;

}

-->
get_data(struct eth_drv_sc *sc)
{
    rxd_t val;
    struct lan91cxx_priv_data *cpd =
        (struct lan91cxx_priv_data *)sc->driver_private;

#ifdef LAN91CXX_32BIT_RX
    HAL_READ_UINT32(cpd->base+((LAN91CXX_DATA_HIGH & 0x7) << cpd->addrsh), 
val);
#else
     HAL_READ_UINT16(cpd->base+((LAN91CXX_DATA & 0x7) << cpd->addrsh), val);
 #endif

 #if DEBUG & 2
     diag_printf("read data 0x%x\n", val);
 #endif
     return val;
 }

-->
#define HAL_READ_UINT16( _register_, _value_ )                  \
    CYG_MACRO_START                                             \
    ((_value_) = *((volatile CYG_WORD16 *)(_register_)));       \
    CYG_MACRO_END

As you can see CYG_CPU_TO_LE16() and CYG_LE16_TO_CPU() are never used,
and it is impossible to reserve data in BigEndian form without change.

Maybe at the time of interpriting ARP-request, reading data exchangedly ?
I tried to find where ARP-request is parsed and interpreted,but couldn't 
find where it is.

I checked that ISR,DSR are called(although I'm not sure they are called 
right time)
so I suppose that if ARP-request is correctly interpreted and ARP-reply is 
made and sent out,
it will work.

I sincerely ask your favor.
Would you please let me know next few questions ?
1.I would like to know where ARP-request is parsed and interpreted,
  entry function name, and if possible line numbers.

2.After ARP-request is recognised, by what sequence lan91cxx_send is called.

3.Where ARP-reply packet is made ?
  entry function name, and if possible line numbers.

I look forward to your reply.
Thank you in advance.

Masahiro Ariga



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

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

[ariga masahiro]

Hello Gary and others,

I have learned ARP operation.
I've got "TCP/IP illustrated vol2" by W.Richard Stevens.

I have traced to ARP interpreting point.
First I breaked lan91cxx_recv() when received ARP packet,
and next breaked if_ethersubr.c's ether_input(ifp, eh, m) function.
And I traced into ether_demux().

ether_demux(ifp, eh, m)
       594:     switch (ether_type) {
       595: #ifdef INET
       596:     case ETHERTYPE_IP:
       597:         if (ipflow_fastforward(m))
       598:             return;
       599:         schednetisr(NETISR_IP);
       600:         inq = &ipintrq;
       601:         break;
       602:
       603:     case ETHERTYPE_ARP:
       604:         if (ifp->if_flags & IFF_NOARP) {
       605:             /* Discard packet if ARP is disabled on interface */
       606:             m_freem(m);
       607:             return;
       608:         }
       609:         schednetisr(NETISR_ARP);
       610:         inq = &arpintrq;
       611:         break;

and I found ether_type==0x0608,so couldn't recognize ARP.

I concluded entering data in little Endian is wrong,
so as a makeshift I amended source next.

First I concocted get_data_byte(struct eth_drv_sc *sc)
to get data exchangedly like I previously sent the coding.

And I alse concocted in cyg_uint16 get_data_short like below
to echange data.

      1079: cyg_uint16 get_data_short(struct eth_drv_sc *sc)
      1080: {
      1081:     cyg_uint16 val;
      1082:
      1083:     val = get_data_byte(sc);
      1084:     //val |= get_data_byte(sc)<<8;
                val = val<<8 | get_data_byte(sc);  --I concocted to reverse 
data.
      1085:
      1086:     return CYG_LE16_TO_CPU(val);
      1087: }

I know it's bad coding but as I said this is a makeshift and
I expect your best amended source.(on condition I was right)

Anyway I could continue debugging.

After that I confirmed that following interrrupt,
it entered in if_ether.c's arpintr().

Then I traced into in_arpinput(m), and
according to the book,here send ARP-reply.
My expectancy reached high.

But alas,in in_arpinput(m)
didn't go to the point of sending packet.

The reason was, in first part of coding,
       529: in_arpinput(m)
       530:     struct mbuf *m;
       531: {
       532:     register struct ether_arp *ea;
       533:     register struct arpcom *ac = (struct arpcom 
*)m->m_pkthdr.rcvif;
       534:     struct ether_header *eh;
       535:     struct iso88025_header *th = (struct iso88025_header *)0;
       536:     register struct llinfo_arp *la = 0;
       537:     register struct rtentry *rt;
       538:     struct in_ifaddr *ia, *maybe_ia = 0;
       539:     struct sockaddr_dl *sdl;
       540:     struct sockaddr sa;
       541:     struct in_addr isaddr, itaddr, myaddr;
       542:     int op, rif_len;
       543:
       544:     if (m->m_len < sizeof(struct ether_arp) &&
       545:         (m = m_pullup(m, sizeof(struct ether_arp))) == NULL) {
       546:         log(LOG_ERR, "in_arp: runt packet -- m_pullup 
failed\n");
       547:         return;
       548:     }
       549:
       550:     ea = mtod(m, struct ether_arp *);
       551:     op = ntohs(ea->arp_op);
       552:     (void)memcpy(&isaddr, ea->arp_spa, sizeof (isaddr));
       553:     (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr));
       554:     for (ia = in_ifaddrhead.tqh_first; ia; ia = 
ia->ia_link.tqe_next) {
       555:         /*
       556:          * For a bridge, we want to check the address 
irrespective
       557:          * of the receive interface. (This will change slightly
       558:          * when we have clusters of interfaces).
       559:          */
       560: #ifdef BRIDGE
       561: #define BRIDGE_TEST (do_bridge)
       562: #else
       563: #define BRIDGE_TEST (0) /* cc will optimise the test away */
       564: #endif
       565:         if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) {
       566:             maybe_ia = ia;
       567:             if ((itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) 
||
       568:                  (isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)) 
{
       569:                 break;
       570:             }
       571:         }
       572:     }
       573:     if (maybe_ia == 0) {
       574:         m_freem(m);
       575:         return;
       576:     }
       577:     myaddr = ia ? ia->ia_addr.sin_addr : 
maybe_ia->ia_addr.sin_addr;  --ia,ª00

at 554 line,there was nothing in_ifaddrhead.tqh_first,
and at 577, ia became 00000000.

Here,Gary, I sincerely ask your opinion.
The trouble is there is nothing in in_ifaddrhead.tqh_first,
do you have any idea what caused this mishappening ?

I expect your any hints whatever.

Thanks in advance.

Masahiro Ariga



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

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

[Alok Singh]

Ariga,
Can you send us the dump of IP packet also (not ARP) on your system? We want to make sure that you are seeing the problem only with Arp packet. Send 64 bytes starting with Ethernet header.

-Alok

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of ariga masahiro
Sent: Tuesday, October 23, 2007 1:53 PM
To: Gary Thomas
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] What functions should I call in ethernet drv ?

Hello Gary and others,

I have learned ARP operation.
I've got "TCP/IP illustrated vol2" by W.Richard Stevens.

I have traced to ARP interpreting point.
First I breaked lan91cxx_recv() when received ARP packet,
and next breaked if_ethersubr.c's ether_input(ifp, eh, m) function.
And I traced into ether_demux().

ether_demux(ifp, eh, m)
       594:     switch (ether_type) {
       595: #ifdef INET
       596:     case ETHERTYPE_IP:
       597:         if (ipflow_fastforward(m))
       598:             return;
       599:         schednetisr(NETISR_IP);
       600:         inq = &ipintrq;
       601:         break;
       602:
       603:     case ETHERTYPE_ARP:
       604:         if (ifp->if_flags & IFF_NOARP) {
       605:             /* Discard packet if ARP is disabled on interface */
       606:             m_freem(m);
       607:             return;
       608:         }
       609:         schednetisr(NETISR_ARP);
       610:         inq = &arpintrq;
       611:         break;

and I found ether_type==0x0608,so couldn't recognize ARP.

I concluded entering data in little Endian is wrong,
so as a makeshift I amended source next.

First I concocted get_data_byte(struct eth_drv_sc *sc)
to get data exchangedly like I previously sent the coding.

And I alse concocted in cyg_uint16 get_data_short like below
to echange data.

      1079: cyg_uint16 get_data_short(struct eth_drv_sc *sc)
      1080: {
      1081:     cyg_uint16 val;
      1082:
      1083:     val = get_data_byte(sc);
      1084:     //val |= get_data_byte(sc)<<8;
                val = val<<8 | get_data_byte(sc);  --I concocted to reverse 
data.
      1085:
      1086:     return CYG_LE16_TO_CPU(val);
      1087: }

I know it's bad coding but as I said this is a makeshift and
I expect your best amended source.(on condition I was right)

Anyway I could continue debugging.

After that I confirmed that following interrrupt,
it entered in if_ether.c's arpintr().

Then I traced into in_arpinput(m), and
according to the book,here send ARP-reply.
My expectancy reached high.

But alas,in in_arpinput(m)
didn't go to the point of sending packet.

The reason was, in first part of coding,
       529: in_arpinput(m)
       530:     struct mbuf *m;
       531: {
       532:     register struct ether_arp *ea;
       533:     register struct arpcom *ac = (struct arpcom 
*)m->m_pkthdr.rcvif;
       534:     struct ether_header *eh;
       535:     struct iso88025_header *th = (struct iso88025_header *)0;
       536:     register struct llinfo_arp *la = 0;
       537:     register struct rtentry *rt;
       538:     struct in_ifaddr *ia, *maybe_ia = 0;
       539:     struct sockaddr_dl *sdl;
       540:     struct sockaddr sa;
       541:     struct in_addr isaddr, itaddr, myaddr;
       542:     int op, rif_len;
       543:
       544:     if (m->m_len < sizeof(struct ether_arp) &&
       545:         (m = m_pullup(m, sizeof(struct ether_arp))) == NULL) {
       546:         log(LOG_ERR, "in_arp: runt packet -- m_pullup 
failed\n");
       547:         return;
       548:     }
       549:
       550:     ea = mtod(m, struct ether_arp *);
       551:     op = ntohs(ea->arp_op);
       552:     (void)memcpy(&isaddr, ea->arp_spa, sizeof (isaddr));
       553:     (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr));
       554:     for (ia = in_ifaddrhead.tqh_first; ia; ia = 
ia->ia_link.tqe_next) {
       555:         /*
       556:          * For a bridge, we want to check the address 
irrespective
       557:          * of the receive interface. (This will change slightly
       558:          * when we have clusters of interfaces).
       559:          */
       560: #ifdef BRIDGE
       561: #define BRIDGE_TEST (do_bridge)
       562: #else
       563: #define BRIDGE_TEST (0) /* cc will optimise the test away */
       564: #endif
       565:         if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) {
       566:             maybe_ia = ia;
       567:             if ((itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) 
||
       568:                  (isaddr.s_addr == ia->ia_addr.sin_addr.s_addr)) 
{
       569:                 break;
       570:             }
       571:         }
       572:     }
       573:     if (maybe_ia == 0) {
       574:         m_freem(m);
       575:         return;
       576:     }
       577:     myaddr = ia ? ia->ia_addr.sin_addr : 
maybe_ia->ia_addr.sin_addr;  --ia,ª00

at 554 line,there was nothing in_ifaddrhead.tqh_first,
and at 577, ia became 00000000.

Here,Gary, I sincerely ask your opinion.
The trouble is there is nothing in in_ifaddrhead.tqh_first,
do you have any idea what caused this mishappening ?

I expect your any hints whatever.

Thanks in advance.

Masahiro Ariga



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




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

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

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 5886 bytes --]

Hello sir,

I send target's output log file.
This is after I chnged coding.

I also send Etherreal file from host.
I am sorry I don't know how to change text.

Are they suitable for your request ?

Masahiro Ariga

----- Original Message ----- 
From: "Alok Singh" <alok.singh@broadcom.com>
To: "ariga masahiro" <ariga@link-lab.co.jp>
Cc: <ecos-discuss@ecos.sourceware.org>
Sent: Tuesday, October 23, 2007 5:27 PM
Subject: RE: [ECOS] What functions should I call in ethernet drv ?


Ariga,
Can you send us the dump of IP packet also (not ARP) on your system? We want 
to make sure that you are seeing the problem only with Arp packet. Send 64 
bytes starting with Ethernet header.

-Alok

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org 
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of ariga masahiro
Sent: Tuesday, October 23, 2007 1:53 PM
To: Gary Thomas
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] What functions should I call in ethernet drv ?

Hello Gary and others,

I have learned ARP operation.
I've got "TCP/IP illustrated vol2" by W.Richard Stevens.

I have traced to ARP interpreting point.
First I breaked lan91cxx_recv() when received ARP packet,
and next breaked if_ethersubr.c's ether_input(ifp, eh, m) function.
And I traced into ether_demux().

ether_demux(ifp, eh, m)
       594:     switch (ether_type) {
       595: #ifdef INET
       596:     case ETHERTYPE_IP:
       597:         if (ipflow_fastforward(m))
       598:             return;
       599:         schednetisr(NETISR_IP);
       600:         inq = &ipintrq;
       601:         break;
       602:
       603:     case ETHERTYPE_ARP:
       604:         if (ifp->if_flags & IFF_NOARP) {
       605:             /* Discard packet if ARP is disabled on interface */
       606:             m_freem(m);
       607:             return;
       608:         }
       609:         schednetisr(NETISR_ARP);
       610:         inq = &arpintrq;
       611:         break;

and I found ether_type==0x0608,so couldn't recognize ARP.

I concluded entering data in little Endian is wrong,
so as a makeshift I amended source next.

First I concocted get_data_byte(struct eth_drv_sc *sc)
to get data exchangedly like I previously sent the coding.

And I alse concocted in cyg_uint16 get_data_short like below
to echange data.

      1079: cyg_uint16 get_data_short(struct eth_drv_sc *sc)
      1080: {
      1081:     cyg_uint16 val;
      1082:
      1083:     val = get_data_byte(sc);
      1084:     //val |= get_data_byte(sc)<<8;
                val = val<<8 | get_data_byte(sc);  --I concocted to reverse
data.
      1085:
      1086:     return CYG_LE16_TO_CPU(val);
      1087: }

I know it's bad coding but as I said this is a makeshift and
I expect your best amended source.(on condition I was right)

Anyway I could continue debugging.

After that I confirmed that following interrrupt,
it entered in if_ether.c's arpintr().

Then I traced into in_arpinput(m), and
according to the book,here send ARP-reply.
My expectancy reached high.

But alas,in in_arpinput(m)
didn't go to the point of sending packet.

The reason was, in first part of coding,
       529: in_arpinput(m)
       530:     struct mbuf *m;
       531: {
       532:     register struct ether_arp *ea;
       533:     register struct arpcom *ac = (struct arpcom
*)m->m_pkthdr.rcvif;
       534:     struct ether_header *eh;
       535:     struct iso88025_header *th = (struct iso88025_header *)0;
       536:     register struct llinfo_arp *la = 0;
       537:     register struct rtentry *rt;
       538:     struct in_ifaddr *ia, *maybe_ia = 0;
       539:     struct sockaddr_dl *sdl;
       540:     struct sockaddr sa;
       541:     struct in_addr isaddr, itaddr, myaddr;
       542:     int op, rif_len;
       543:
       544:     if (m->m_len < sizeof(struct ether_arp) &&
       545:         (m = m_pullup(m, sizeof(struct ether_arp))) == NULL) {
       546:         log(LOG_ERR, "in_arp: runt packet -- m_pullup
failed\n");
       547:         return;
       548:     }
       549:
       550:     ea = mtod(m, struct ether_arp *);
       551:     op = ntohs(ea->arp_op);
       552:     (void)memcpy(&isaddr, ea->arp_spa, sizeof (isaddr));
       553:     (void)memcpy(&itaddr, ea->arp_tpa, sizeof (itaddr));
       554:     for (ia = in_ifaddrhead.tqh_first; ia; ia =
ia->ia_link.tqe_next) {
       555:         /*
       556:          * For a bridge, we want to check the address
irrespective
       557:          * of the receive interface. (This will change slightly
       558:          * when we have clusters of interfaces).
       559:          */
       560: #ifdef BRIDGE
       561: #define BRIDGE_TEST (do_bridge)
       562: #else
       563: #define BRIDGE_TEST (0) /* cc will optimise the test away */
       564: #endif
       565:         if ((BRIDGE_TEST) || (ia->ia_ifp == &ac->ac_if)) {
       566:             maybe_ia = ia;
       567:             if ((itaddr.s_addr == ia->ia_addr.sin_addr.s_addr)
||
       568:                  (isaddr.s_addr == ia->ia_addr.sin_addr.s_addr))
{
       569:                 break;
       570:             }
       571:         }
       572:     }
       573:     if (maybe_ia == 0) {
       574:         m_freem(m);
       575:         return;
       576:     }
       577:     myaddr = ia ? ia->ia_addr.sin_addr :
maybe_ia->ia_addr.sin_addr;  --ia,ª00

at 554 line,there was nothing in_ifaddrhead.tqh_first,
and at 577, ia became 00000000.

Here,Gary, I sincerely ask your opinion.
The trouble is there is nothing in in_ifaddrhead.tqh_first,
do you have any idea what caused this mishappening ?

I expect your any hints whatever.

Thanks in advance.

Masahiro Ariga



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




[-- Attachment #2: MyFlashIDis422f9019.txt.gz --]
[-- Type: application/x-gzip, Size: 2457 bytes --]

[-- Attachment #3: thisishost --]
[-- Type: application/octet-stream, Size: 1567 bytes --]

[-- Attachment #4: Type: text/plain, Size: 148 bytes --]

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

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

[ariga masahiro]

Hello Gary and others,

First of all,I should apologize that our company's target board was hardware 
wired to
retreive data in BigEndian.
According to our hardware designer,it is a little bit out of normality.

I should have known earlier but I thought it normal to retreive data in 
BigEndian,
and he was out of contact.I heartly apologize you.

Anyway, I made it to execute lan91c111 driver properly.
Althogh not yet completing testing,at least I succeeded to
exchange packets between host and target.

I heartly thank you all,and especially for Gary,
without his precise comments I could not have succeeded to make it.

Thank you million times all of you !

Masahiro Ariga




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

[ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 5975 bytes --]

Hello,

I am the same person who sent the mailing list titled
"What functions should I call in ethernet drv ?".
At that time I was helped by your advices.
I was very much obliged.

I am sorry to say that I am encountered another trouble
and I ask you again your help.

Since then I continued to test transmission between host and target.
host(Client)  : 172.16.1.28  : nc_test_master
target(Server): 172.16.1.200 : nc_test_slave

UDP packets look like correctly transmitted between both terminals.

But when host tries to connect to target in TCP,
always happens connection error(timeout).
Below is host's output on cygwin shell.

$ ./nc_test_master.exe 172.16.1.200
Start Network Characterization - MASTER
================== No load, master at 100% ========================
Start TCP echo [64,10240] - no delays
Can't connect to slave: Connection refused
Can't connect to slave: Connection refused
Can't connect to slave: Connection refused

I sent also Etherreal packets captutre log file(text-gz format).
\TCP-checksum-log\DEBUG-00-prescale-20\EtherReal-log-txt\etherreal-TCP-2.txt
DEBUG=00,CYGHWR_HAL_SH_RTC_PRESCALE=20(CYGNUM_HAL_RTC_PERIOD=14745)
From here on,I refer to this file as er.txt.

When host send SYN packet to target(er.txt,line 89),
target tried to reply SYN-ACK but resulted [CHECKSUM INCORRECT].
Target's TCP packets almost always [CHECKSUM INCORRECT].
I also noticed Seq, Ack,and Win numbers all suspicious.
When Ack-number looks proper,CHECKSUM INCORRECT not occurs, but never 
connected.

I traced TCP checksum routine,and I am not sure they are correct.
I set break at 735 line in tcp_output() function in
packages\net\bsd_tcpip\current\src\sys\netinet\tcp_output.c

       730: #endif /* INET6 */
       731:       {
       732:     m->m_pkthdr.csum_flags = CSUM_TCP;
       733:     m->m_pkthdr.csum_data = offsetof(struct tcphdr, th_sum);
       734:     if (len + optlen)
       735:         th->th_sum = in_addword(th->th_sum,
       736:             htons((u_short)(optlen + len)));
Then jumped to
packages\net\bsd_tcpip\current\src\sys\netinet\in_cksum.c(200): 
in_addword(u_short a, u_short b)

       199: u_short
       200: in_addword(u_short a, u_short b)
       201: {
       202:     u_int32_t sum = a + b;
       203:
       204:     ADDCARRY(sum);
       205:     return (sum);
       206: }

ADDCARRY is defined as below in in_cksum.c(76)

#define ADDCARRY(x)  (x > 65535 ? x -= 65535 : x)

Now this looks not doing one's complement sum for me.
Is this really correct function ?

Whereas in case of UDP checksum,
I set break at 735 line in udp_output() function in
packages\net\bsd_tcpip\current\src\sys\netinet\udp_usrreq.c(662)
udp_usrreq.c
       662: udp_output(inp, m, addr, control, p)

       731:     /*
       732:      * Set up checksum and output datagram.
       733:      */
       734:     if (udpcksum) {
       735:             ui->ui_sum = in_pseudo(ui->ui_src.s_addr, 
ui->ui_dst.s_addr,
       736:             htons((u_short)len + sizeof(struct udphdr) + 
IPPROTO_UDP));
       737:         m->m_pkthdr.csum_flags = CSUM_UDP;
       738:         m->m_pkthdr.csum_data = offsetof(struct udphdr, uh_sum);
       739:     } else {
       740:         ui->ui_sum = 0;
       741:     }

And jumped to
       208: u_short
       209: in_pseudo(u_int32_t a, u_int32_t b, u_int32_t c)
       210: {
       211:     u_int64_t sum;
       212:     union q_util q_util;
       213:     union l_util l_util;
       214:
       215:     sum = (u_int64_t) a + b + c;
       216:     REDUCE16;
       217:     return (sum);
       218: }

#define REDUCE16         \
    {           \
 q_util.q = sum;         \
 l_util.l = q_util.s[0] + q_util.s[1] + q_util.s[2] + q_util.s[3]; \
 sum = l_util.s[0] + l_util.s[1];      \
 ADDCARRY(sum);         \
    }

This looks like doing one's complement sum for me.

As Gary suggested,I checked hearbeat.
I changed CYGHWR_HAL_SH_RTC_PRESCALE from default 4 to 20 and
now,CYGNUM_HAL_RTC_PERIOD=14745,

cdl_option CYGNUM_HAL_RTC_PERIOD {
    # Flavor: data
    # No user value, uncomment the following line to provide one.
    # user_value 14745
    # value_source default
    # Default value: 
CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/CYGNUM_HAL_RTC_DENOMINATOR / 
CYGHWR_HAL_SH_RTC_PRESCALE
    #     CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED == 29491200
    #     CYGNUM_HAL_RTC_DENOMINATOR == 100
    #     CYGHWR_HAL_SH_RTC_PRESCALE == 20
    #   --> 14745
};
but nothing changed.

Our most serious concern is, my concoction in driver source to accommodate 
to target's hardware pecuriality
is affecting those misbehaviour.
As I said in last mail, our company's target board was hardware wired to
retreive data in BigEndian.

I concocted in \packages\devs\eth\smsc\lan91cxx\current\src\if_lan91cxx.c.
cyg_uint8 get_data_byte(struct eth_drv_sc *sc)
{
    //20070919
    int sf;

    cyg_uint8 c;
    struct lan91cxx_priv_data *cpd =
        (struct lan91cxx_priv_data *)sc->driver_private;

    if( cpd->data_pos == sizeof(rxd_t) )
    {
        cpd->data_buf = get_data(sc);
        cpd->data_pos = 0;
        //20070919
        sf = 1;
    }
    //20070919 begin
    else{
        sf = 0;
  }
    //20070919 end

    //20070919 begin
//ORG    c = (cpd->data_buf>>(cpd->data_pos*8))&0xFF;
    c = (cpd->data_buf>>(sf*8))&0xFF;

    cpd->data_pos++;

    return c;
}
cyg_uint16 get_data_short(struct eth_drv_sc *sc)
{
    cyg_uint16 val;

    val = get_data_byte(sc);
//20071023
    //ORG val |= get_data_byte(sc)<<8;
    val = val<<8 | get_data_byte(sc);

    return CYG_LE16_TO_CPU(val);
}

I also send together target's serial log when I setted DEBUF=FF.
But if CYGNUM_HAL_RTC_PERIOD=14745 then happend time_out error at 
intialization(watchdog),
so I changed CYGHWR_HAL_SH_RTC_PRESCALE=4(CYGNUM_HAL_RTC_PERIOD=73728).
C:\cygwin\home\TCP-checksum-log\DEBUG-FF-prescale-4\Teraterm\MyFlashIDis422f9019.txt

I am perplexed what is happening,please help me.
Thanks in advance.

Masahiro Ariga 

[-- Attachment #2: TCP-checksum-log.tar.gz --]
[-- Type: application/x-gzip, Size: 13404 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[Andrew Lunn]

On Tue, Oct 30, 2007 at 11:41:48AM +0900, ariga masahiro wrote:
> Hello,
>
> I am the same person who sent the mailing list titled
> "What functions should I call in ethernet drv ?".
> At that time I was helped by your advices.
> I was very much obliged.
>
> I am sorry to say that I am encountered another trouble
> and I ask you again your help.
>
> Since then I continued to test transmission between host and target.
> host(Client)  : 172.16.1.28  : nc_test_master
> target(Server): 172.16.1.200 : nc_test_slave
>
> UDP packets look like correctly transmitted between both terminals.
>
> But when host tries to connect to target in TCP,
> always happens connection error(timeout).
> Below is host's output on cygwin shell.
>
> $ ./nc_test_master.exe 172.16.1.200
> Start Network Characterization - MASTER
> ================== No load, master at 100% ========================
> Start TCP echo [64,10240] - no delays
> Can't connect to slave: Connection refused
> Can't connect to slave: Connection refused
> Can't connect to slave: Connection refused
>
> I sent also Etherreal packets captutre log file(text-gz format).
> \TCP-checksum-log\DEBUG-00-prescale-20\EtherReal-log-txt\etherreal-TCP-2.txt
> DEBUG=00,CYGHWR_HAL_SH_RTC_PRESCALE=20(CYGNUM_HAL_RTC_PERIOD=14745)
>> From here on,I refer to this file as er.txt.
>
> When host send SYN packet to target(er.txt,line 89),
> target tried to reply SYN-ACK but resulted [CHECKSUM INCORRECT].
> Target's TCP packets almost always [CHECKSUM INCORRECT].
> I also noticed Seq, Ack,and Win numbers all suspicious.
> When Ack-number looks proper,CHECKSUM INCORRECT not occurs, but never 
> connected.
>
> I traced TCP checksum routine,and I am not sure they are correct.
> I set break at 735 line in tcp_output() function in
> packages\net\bsd_tcpip\current\src\sys\netinet\tcp_output.c
>
>       730: #endif /* INET6 */
>       731:       {
>       732:     m->m_pkthdr.csum_flags = CSUM_TCP;
>       733:     m->m_pkthdr.csum_data = offsetof(struct tcphdr, th_sum);
>       734:     if (len + optlen)
>       735:         th->th_sum = in_addword(th->th_sum,
>       736:             htons((u_short)(optlen + len)));
> Then jumped to
> packages\net\bsd_tcpip\current\src\sys\netinet\in_cksum.c(200): 
> in_addword(u_short a, u_short b)
>
>       199: u_short
>       200: in_addword(u_short a, u_short b)
>       201: {
>       202:     u_int32_t sum = a + b;
>       203:
>       204:     ADDCARRY(sum);
>       205:     return (sum);
>       206: }
>
> ADDCARRY is defined as below in in_cksum.c(76)
>
> #define ADDCARRY(x)  (x > 65535 ? x -= 65535 : x)
>
> Now this looks not doing one's complement sum for me.
> Is this really correct function ?

Something to consider. This code works for many people on lots of
differ net hardware, big endian and little endian. This is also taken
directly from FreeBSD which has many more uses than eCos. So it is
very unlikely to be a bug in something like this.

It is much more likely you have a configuration problem for your
hardware or a bug in your new code for the hardware dependant part of
the device driver.

> Our most serious concern is, my concoction in driver source to accommodate 
> to target's hardware pecuriality
> is affecting those misbehaviour.
> As I said in last mail, our company's target board was hardware wired to
> retreive data in BigEndian.

What is probably a better idea is to get your hardware engineer to fix
your board so the ethernet device is using the correct
endianness. This should not be too hard, maybe replace a pull up
resister with a patch wire to ground etc...

         Andrew


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

[ECOS] Re: Can't Connect,TCP CHECKSUM INCORRECT

[Grant Edwards]

On 2007-10-30, ariga masahiro <ariga@link-lab.co.jp> wrote:

> I traced TCP checksum routine,and I am not sure they are correct.

Oh please.

The BSD IP checksum routines have been used in hundreds of
different OSes and network stacks for _decades_.  They're
probably some of the most scrutinized routines on the planet.
They've been tested, examined, reviewed, and tuned by hundreds
of different people.

They are correct.

They are the de-fact _definition_ of what an IP checksum is.
They are the gold standard, the platinum sphere, the be-all and
end-all of IP checksum routines.

It took me _weeks_ of blood, sweat, and tears (not to mention
help from some other people far smarter than I) to come up with
an ARM assembly language routine that could match the
C-language BSD IP checksum routines in execution time.

The BSD routines work for everbody on the flippin' planet
except you, and you think your code is OK, and the BSD routines
are broken?  [Damn, to be young again...]

There's something wrong with your code.  

Really.

Trust me.

One thing you learn after a decade or two is that it's not the
compiler, it's not the library code, it's not the processor,
it's not the linker, it's _your_ code that's broken.  

Except for that one time out of a thousand when it isn't.

But this isn't one of those times.

-- 
Grant Edwards                   grante             Yow!  BARBARA STANWYCK
                                  at               makes me nervous!!
                               visi.com            


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

RE: [ECOS] Re: Can't Connect,TCP CHECKSUM INCORRECT

[Alok Singh]

Please also make sure that you have "CYGPKG_HAL_MIPS_MSBFIRST" set for
your big-endian target. And it will be better to remove all the code
changes you made while debugging the ARP issue earlier.  

-Alok

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Grant
Edwards
Sent: Tuesday, October 30, 2007 9:47 AM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] Re: Can't Connect,TCP CHECKSUM INCORRECT

On 2007-10-30, ariga masahiro <ariga@link-lab.co.jp> wrote:

> I traced TCP checksum routine,and I am not sure they are correct.

Oh please.

The BSD IP checksum routines have been used in hundreds of
different OSes and network stacks for _decades_.  They're
probably some of the most scrutinized routines on the planet.
They've been tested, examined, reviewed, and tuned by hundreds
of different people.

They are correct.

They are the de-fact _definition_ of what an IP checksum is.
They are the gold standard, the platinum sphere, the be-all and
end-all of IP checksum routines.

It took me _weeks_ of blood, sweat, and tears (not to mention
help from some other people far smarter than I) to come up with
an ARM assembly language routine that could match the
C-language BSD IP checksum routines in execution time.

The BSD routines work for everbody on the flippin' planet
except you, and you think your code is OK, and the BSD routines
are broken?  [Damn, to be young again...]

There's something wrong with your code.  

Really.

Trust me.

One thing you learn after a decade or two is that it's not the
compiler, it's not the library code, it's not the processor,
it's not the linker, it's _your_ code that's broken.  

Except for that one time out of a thousand when it isn't.

But this isn't one of those times.

-- 
Grant Edwards                   grante             Yow!  BARBARA
STANWYCK
                                  at               makes me nervous!!
                               visi.com            


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




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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 4406 bytes --]

Hello,

We have held argumental conference.
Our board is hardware wired in DATA BUS in order
to retrieve DATA from MAC in Big Endian form like below.

Normal DATA BUS connection
  SH        SMSC(MAC)
D15 <------> D15
 |            |
D08 <------> D08
D07 <------> D07
 |            |
D00 <------> D00

Our Board DATA BUS connection
  SH        SMSC(MAC)
D15 <------> D07
 |            |
D08 <------> D00
D07 <------> D15
 |            |
D00 <------> D08

I know you will be surprised as much as I did.
The trouble is, our company have had already achievements
with this design.Our executives are reluctant to change hardware,
and I am too weak to change company's decision.
After quarrelsome debate, it concluded that my current problem
is not concerned with Endian issue.They doubt my configuration.

So I beseech you to help me again.
I sum up my trouble.
After exchanged commands in UDP,
host begins to TCP Connect and send SYN packet
to our target.Target receives SYN packet and tries to
send back SYN-ACK but that packet becomes Malformed packet.
SYN-ACK packet is never recieved by host.
Please refer to Ethereal txt log file I sent before.

I captured TCP connection between Windows PCs,
and compared SYN - SYNACK packets between Windows PCs log and host-target 
log,
and I noticed there are some incomprehensible points.

Below is from Ethereal Capture log

Windows<-->Windows  -- no problem
PC-client[172.16.1.28]<-->PC-server[172.16.1.21]
[172.16.1.28]-->[172.16.1.21]
SYN-Packet
00 10 a4 8a 8a ce 00 15  c5 6d 23 f0 08 00 45 00
00 30 30 b8 40 00 80 06  6f be ac 10 01 1c ac 10
01 15 04 c5 04 21 33 5d  c7 c1 00 00 00 00 70 02
ff ff 24 c9 00 00 02 04  05 b4 01 01 04 02
[172.16.1.21]-->[172.16.1.28]
SYN-ACK-Packet
00 15 c5 6d 23 f0 00 10  a4 8a 8a ce 08 00 45 00
00 30 16 2a 40 00 80 06  8a 4c ac 10 01 15 ac 10
01 1c 04 21 04 c5 20 08  8f 1b 33 5d c7 c2 70 12
44 70 31 24 00 00 02 04  05 b4 01 01 04 02
=========================================================
cygwin<-->eCos  -- SYN-ACK [CHECKSUM INCORRECT][Malformed packet]
host-client[172.16.1.28]<-->target-server[172.16.1.200]
[172.16.1.28]-->[172.16.1.200]
SYN-Packet
00 40 31 08 01 00 00 15  c5 6d 23 f0 08 00 45 00
00 30 35 81 40 00 80 06  6a 42 ac 10 01 1c ac 10
01 c8 05 1e 22 42 a6 39  a9 dc 00 00 00 00 70 02
ff ff b0 a4 00 00 02 04  05 b4 01 01 04 02
[172.16.1.200]-->[172.16.1.28]
SYN-ACK-Packet
00 15 c5 6d 23 f0 00 40  31 08 01 00 08 00 45 00
00 28 00 02 40 00 40 06  df c9 ac 10 01 c8 ac 10
01 1c 22 42 05 1e 17 7a  85 37 a6 39 a9 dd 60 12
44 70 ec 30 00 00 00 00  00 00 00 00

My incomprehensible points are,
about Target's SYN-ACK-Packet,
1. paket length in IP header(=0028 line-2,colum-1,2) indicates
   length from top of IP header(line-1,colum-15) to last of packet,
   but 0028(=40d) counts to line-4,colum-6,there are 6 bytes surplus.
2. data offset bits(=6 line-3,colum-15) indicates there are 4*6=24bytes
   from top of TCP header(line-3,colum-3) to last of packet.
   But 24 counts to line-4,colum-10,there are 2 bytes surplus.
   And there is a contradiction between paket length in IP header and TCP 
data offset bits.
3. option part of SYN packet(00 00 02 04  05 b4 01 01 04 02) changed to (00 
00 00 00  00 00 00 00)
   in Target's SYN-ACK-Packet.

Please, could you enlighten me what is cause of this phenomenon ?

By the way,I calculated checksum mannually and confirmed they are all 
correct.

I only changed coding in retrieving data in BigEndian as I reported to you.
I think others are resolved by Macros of bigendian.

Currently when building, Resolve conflicts dialog appears like below.

Resolve conflicts
Item                  Conflict    Property
CYGPKG_POSIX_CLOCKS   Unsatisfied Requires 
CYGBLD_ISO_STRUCTTIMEVAL_HEADER=="<cyg/posix/sys/time.h>"
CYGPKG_FILEIO_FNMATCH Unsatisfied Requires 
CYGBLD_ISO_FNMATCH__HEADER=="<cyg/fileio/fnmatch.h>"
Proposed Solutions:
Item                               Value
x CYGBLD_ISO_FNMATCH__HEADER       Enabled,<cyg/fileio/fnmatch.h>
x CYGBLD_ISO_STRUCTTIMEVAL_HEADER  Enabled,<cyg/posix/sys/time.h>

I also send ecc file.
Suspicious option is CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE.
Now CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE is false
Must I make it true ?

I am checking myself options,
but it is like searching diamond among Pacific Oceans' sands.
Could you give me atleast any hints whatsoever ?

I look forward for your reply.
Thanks in advance.

Masahiro Ariga

[-- Attachment #2: untitled.ecc.gz --]
[-- Type: application/x-gzip, Size: 89736 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

RE: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[Alok Singh]

Ariga,

>>I only changed coding in retrieving data in BigEndian as I reported to
>>you.
>> I think others are resolved by Macros of bigendian.

Can you let us know what code you changed to retrieve data in
Big-endian?

-Alok

-----Original Message-----
From: ariga masahiro [mailto:ariga@link-lab.co.jp] 
Sent: Tuesday, November 06, 2007 12:44 PM
To: Andrew Lunn; Alok Singh; Gary Thomas
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

Hello,

We have held argumental conference.
Our board is hardware wired in DATA BUS in order
to retrieve DATA from MAC in Big Endian form like below.

Normal DATA BUS connection
  SH        SMSC(MAC)
D15 <------> D15
 |            |
D08 <------> D08
D07 <------> D07
 |            |
D00 <------> D00

Our Board DATA BUS connection
  SH        SMSC(MAC)
D15 <------> D07
 |            |
D08 <------> D00
D07 <------> D15
 |            |
D00 <------> D08

I know you will be surprised as much as I did.
The trouble is, our company have had already achievements
with this design.Our executives are reluctant to change hardware,
and I am too weak to change company's decision.
After quarrelsome debate, it concluded that my current problem
is not concerned with Endian issue.They doubt my configuration.

So I beseech you to help me again.
I sum up my trouble.
After exchanged commands in UDP,
host begins to TCP Connect and send SYN packet
to our target.Target receives SYN packet and tries to
send back SYN-ACK but that packet becomes Malformed packet.
SYN-ACK packet is never recieved by host.
Please refer to Ethereal txt log file I sent before.

I captured TCP connection between Windows PCs,
and compared SYN - SYNACK packets between Windows PCs log and
host-target 
log,
and I noticed there are some incomprehensible points.

Below is from Ethereal Capture log

Windows<-->Windows  -- no problem
PC-client[172.16.1.28]<-->PC-server[172.16.1.21]
[172.16.1.28]-->[172.16.1.21]
SYN-Packet
00 10 a4 8a 8a ce 00 15  c5 6d 23 f0 08 00 45 00
00 30 30 b8 40 00 80 06  6f be ac 10 01 1c ac 10
01 15 04 c5 04 21 33 5d  c7 c1 00 00 00 00 70 02
ff ff 24 c9 00 00 02 04  05 b4 01 01 04 02
[172.16.1.21]-->[172.16.1.28]
SYN-ACK-Packet
00 15 c5 6d 23 f0 00 10  a4 8a 8a ce 08 00 45 00
00 30 16 2a 40 00 80 06  8a 4c ac 10 01 15 ac 10
01 1c 04 21 04 c5 20 08  8f 1b 33 5d c7 c2 70 12
44 70 31 24 00 00 02 04  05 b4 01 01 04 02
=========================================================
cygwin<-->eCos  -- SYN-ACK [CHECKSUM INCORRECT][Malformed packet]
host-client[172.16.1.28]<-->target-server[172.16.1.200]
[172.16.1.28]-->[172.16.1.200]
SYN-Packet
00 40 31 08 01 00 00 15  c5 6d 23 f0 08 00 45 00
00 30 35 81 40 00 80 06  6a 42 ac 10 01 1c ac 10
01 c8 05 1e 22 42 a6 39  a9 dc 00 00 00 00 70 02
ff ff b0 a4 00 00 02 04  05 b4 01 01 04 02
[172.16.1.200]-->[172.16.1.28]
SYN-ACK-Packet
00 15 c5 6d 23 f0 00 40  31 08 01 00 08 00 45 00
00 28 00 02 40 00 40 06  df c9 ac 10 01 c8 ac 10
01 1c 22 42 05 1e 17 7a  85 37 a6 39 a9 dd 60 12
44 70 ec 30 00 00 00 00  00 00 00 00

My incomprehensible points are,
about Target's SYN-ACK-Packet,
1. paket length in IP header(=0028 line-2,colum-1,2) indicates
   length from top of IP header(line-1,colum-15) to last of packet,
   but 0028(=40d) counts to line-4,colum-6,there are 6 bytes surplus.
2. data offset bits(=6 line-3,colum-15) indicates there are 4*6=24bytes
   from top of TCP header(line-3,colum-3) to last of packet.
   But 24 counts to line-4,colum-10,there are 2 bytes surplus.
   And there is a contradiction between paket length in IP header and
TCP 
data offset bits.
3. option part of SYN packet(00 00 02 04  05 b4 01 01 04 02) changed to
(00 
00 00 00  00 00 00 00)
   in Target's SYN-ACK-Packet.

Please, could you enlighten me what is cause of this phenomenon ?

By the way,I calculated checksum mannually and confirmed they are all 
correct.

I only changed coding in retrieving data in BigEndian as I reported to
you.
I think others are resolved by Macros of bigendian.

Currently when building, Resolve conflicts dialog appears like below.

Resolve conflicts
Item                  Conflict    Property
CYGPKG_POSIX_CLOCKS   Unsatisfied Requires 
CYGBLD_ISO_STRUCTTIMEVAL_HEADER=="<cyg/posix/sys/time.h>"
CYGPKG_FILEIO_FNMATCH Unsatisfied Requires 
CYGBLD_ISO_FNMATCH__HEADER=="<cyg/fileio/fnmatch.h>"
Proposed Solutions:
Item                               Value
x CYGBLD_ISO_FNMATCH__HEADER       Enabled,<cyg/fileio/fnmatch.h>
x CYGBLD_ISO_STRUCTTIMEVAL_HEADER  Enabled,<cyg/posix/sys/time.h>

I also send ecc file.
Suspicious option is CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE.
Now CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE is false
Must I make it true ?

I am checking myself options,
but it is like searching diamond among Pacific Oceans' sands.
Could you give me atleast any hints whatsoever ?

I look forward for your reply.
Thanks in advance.

Masahiro Ariga


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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

>>I only changed coding in retrieving data in BigEndian as I reported to
>>you.
>> I think others are resolved by Macros of bigendian.

Can you let us know what code you changed to retrieve data in
Big-endian?

Only next two functions. 
\packages\devs\eth\smsc\lan91cxx\current\src\if_lan91cxx.c
cyg_uint8 get_data_byte(struct eth_drv_sc *sc)
{
    //20070919
    int sf;

    cyg_uint8 c;
    struct lan91cxx_priv_data *cpd =
        (struct lan91cxx_priv_data *)sc->driver_private;

//    //20070919
//    db_printf("cpd->data_pos=%d rxd_t=%d\n",cpd->data_pos,sizeof(rxd_t));

    if( cpd->data_pos == sizeof(rxd_t) )
    {
        cpd->data_buf = get_data(sc);
        cpd->data_pos = 0;
        //20070919
        sf = 1;
    }
    //20070919 begin
    else{
        sf = 0;
  }
    //20070919 end

    //20070919 begin
//ORG    c = (cpd->data_buf>>(cpd->data_pos*8))&0xFF;
    c = (cpd->data_buf>>(sf*8))&0xFF;

//    //20070919
//    db_printf("cpd->data_buf=%x c=%x\n",cpd->data_buf,c);

    cpd->data_pos++;
    
    return c;

}

cyg_uint16 get_data_short(struct eth_drv_sc *sc)
{
    cyg_uint16 val;

    val = get_data_byte(sc);
//20071023
    // val |= get_data_byte(sc)<<8;
    val = val<<8 | get_data_byte(sc);
    
    return CYG_LE16_TO_CPU(val);
}


-----Original Message-----
From: ariga masahiro [mailto:ariga@link-lab.co.jp] 
Sent: Tuesday, November 06, 2007 12:44 PM
To: Andrew Lunn; Alok Singh; Gary Thomas
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

Hello,

We have held argumental conference.
Our board is hardware wired in DATA BUS in order
to retrieve DATA from MAC in Big Endian form like below.

Normal DATA BUS connection
  SH        SMSC(MAC)
D15 <------> D15
 |            |
D08 <------> D08
D07 <------> D07
 |            |
D00 <------> D00

Our Board DATA BUS connection
  SH        SMSC(MAC)
D15 <------> D07
 |            |
D08 <------> D00
D07 <------> D15
 |            |
D00 <------> D08

I know you will be surprised as much as I did.
The trouble is, our company have had already achievements
with this design.Our executives are reluctant to change hardware,
and I am too weak to change company's decision.
After quarrelsome debate, it concluded that my current problem
is not concerned with Endian issue.They doubt my configuration.

So I beseech you to help me again.
I sum up my trouble.
After exchanged commands in UDP,
host begins to TCP Connect and send SYN packet
to our target.Target receives SYN packet and tries to
send back SYN-ACK but that packet becomes Malformed packet.
SYN-ACK packet is never recieved by host.
Please refer to Ethereal txt log file I sent before.

I captured TCP connection between Windows PCs,
and compared SYN - SYNACK packets between Windows PCs log and
host-target 
log,
and I noticed there are some incomprehensible points.

Below is from Ethereal Capture log

Windows<-->Windows  -- no problem
PC-client[172.16.1.28]<-->PC-server[172.16.1.21]
[172.16.1.28]-->[172.16.1.21]
SYN-Packet
00 10 a4 8a 8a ce 00 15  c5 6d 23 f0 08 00 45 00
00 30 30 b8 40 00 80 06  6f be ac 10 01 1c ac 10
01 15 04 c5 04 21 33 5d  c7 c1 00 00 00 00 70 02
ff ff 24 c9 00 00 02 04  05 b4 01 01 04 02
[172.16.1.21]-->[172.16.1.28]
SYN-ACK-Packet
00 15 c5 6d 23 f0 00 10  a4 8a 8a ce 08 00 45 00
00 30 16 2a 40 00 80 06  8a 4c ac 10 01 15 ac 10
01 1c 04 21 04 c5 20 08  8f 1b 33 5d c7 c2 70 12
44 70 31 24 00 00 02 04  05 b4 01 01 04 02
=========================================================
cygwin<-->eCos  -- SYN-ACK [CHECKSUM INCORRECT][Malformed packet]
host-client[172.16.1.28]<-->target-server[172.16.1.200]
[172.16.1.28]-->[172.16.1.200]
SYN-Packet
00 40 31 08 01 00 00 15  c5 6d 23 f0 08 00 45 00
00 30 35 81 40 00 80 06  6a 42 ac 10 01 1c ac 10
01 c8 05 1e 22 42 a6 39  a9 dc 00 00 00 00 70 02
ff ff b0 a4 00 00 02 04  05 b4 01 01 04 02
[172.16.1.200]-->[172.16.1.28]
SYN-ACK-Packet
00 15 c5 6d 23 f0 00 40  31 08 01 00 08 00 45 00
00 28 00 02 40 00 40 06  df c9 ac 10 01 c8 ac 10
01 1c 22 42 05 1e 17 7a  85 37 a6 39 a9 dd 60 12
44 70 ec 30 00 00 00 00  00 00 00 00

My incomprehensible points are,
about Target's SYN-ACK-Packet,
1. paket length in IP header(=0028 line-2,colum-1,2) indicates
   length from top of IP header(line-1,colum-15) to last of packet,
   but 0028(=40d) counts to line-4,colum-6,there are 6 bytes surplus.
2. data offset bits(=6 line-3,colum-15) indicates there are 4*6=24bytes
   from top of TCP header(line-3,colum-3) to last of packet.
   But 24 counts to line-4,colum-10,there are 2 bytes surplus.
   And there is a contradiction between paket length in IP header and
TCP 
data offset bits.
3. option part of SYN packet(00 00 02 04  05 b4 01 01 04 02) changed to
(00 
00 00 00  00 00 00 00)
   in Target's SYN-ACK-Packet.

Please, could you enlighten me what is cause of this phenomenon ?

By the way,I calculated checksum mannually and confirmed they are all 
correct.

I only changed coding in retrieving data in BigEndian as I reported to
you.
I think others are resolved by Macros of bigendian.

Currently when building, Resolve conflicts dialog appears like below.

Resolve conflicts
Item                  Conflict    Property
CYGPKG_POSIX_CLOCKS   Unsatisfied Requires 
CYGBLD_ISO_STRUCTTIMEVAL_HEADER=="<cyg/posix/sys/time.h>"
CYGPKG_FILEIO_FNMATCH Unsatisfied Requires 
CYGBLD_ISO_FNMATCH__HEADER=="<cyg/fileio/fnmatch.h>"
Proposed Solutions:
Item                               Value
x CYGBLD_ISO_FNMATCH__HEADER       Enabled,<cyg/fileio/fnmatch.h>
x CYGBLD_ISO_STRUCTTIMEVAL_HEADER  Enabled,<cyg/posix/sys/time.h>

I also send ecc file.
Suspicious option is CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE.
Now CYGSEM_KERNEL_SCHED_TIMESLICE_ENABLE is false
Must I make it true ?

I am checking myself options,
but it is like searching diamond among Pacific Oceans' sands.
Could you give me atleast any hints whatsoever ?

I look forward for your reply.
Thanks in advance.

Masahiro Ariga



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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[Andrew Lunn]

On Tue, Nov 06, 2007 at 05:30:26PM +0900, ariga masahiro wrote:
>
>>> I only changed coding in retrieving data in BigEndian as I reported to
>>> you.
>>> I think others are resolved by Macros of bigendian.
>
> Can you let us know what code you changed to retrieve data in
> Big-endian?
>
> Only next two functions. 

This is nearly impossible to read.

Please send a unified diff which you generate using the command diff. 

       Andrew

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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

Hello,

I am very sorry.

I am not  familiar using  command diff.
So I send again.
As I said I changed next two functions in 
\packages\devs\eth\smsc\lan91cxx\current\src\if_lan91cxx.c

cyg_uint8 get_data_byte(struct eth_drv_sc *sc)
{
    //20070919
    int sf;

    cyg_uint8 c;
    struct lan91cxx_priv_data *cpd =
        (struct lan91cxx_priv_data *)sc->driver_private;

    if( cpd->data_pos == sizeof(rxd_t) )
    {
        cpd->data_buf = get_data(sc);
        cpd->data_pos = 0;
        //20070919
        sf = 1;
    }
    //20070919 begin
    else{
        sf = 0;
  }
    //20070919 end

    //20070919 begin
//ORG    c = (cpd->data_buf>>(cpd->data_pos*8))&0xFF;
    c = (cpd->data_buf>>(sf*8))&0xFF;

    cpd->data_pos++;
    
    return c;
}

cyg_uint16 get_data_short(struct eth_drv_sc *sc)
{
    cyg_uint16 val;

    val = get_data_byte(sc);
//20071023
    // val |= get_data_byte(sc)<<8;
    val = val<<8 | get_data_byte(sc);
    
    return CYG_LE16_TO_CPU(val);
}

Masahiro Ariga


> On Tue, Nov 06, 2007 at 05:30:26PM +0900, ariga masahiro wrote:
>>
>>>> I only changed coding in retrieving data in BigEndian as I reported to
>>>> you.
>>>> I think others are resolved by Macros of bigendian.
>>
>> Can you let us know what code you changed to retrieve data in
>> Big-endian?
>>
>> Only next two functions. 
> 
> This is nearly impossible to read.
> 
> Please send a unified diff which you generate using the command diff. 
> 
>       Andrew
>

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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Hello,

I have learned diff command.

I made diffs file from 
CVS current version
if_lan91cxx.c
and my if_lan91cxx.c.

To retrieve my version
$ patch [CVS current version]if_lan91cxx.c diffs

I tested and confirmed.

For fear of mishap,I send also CVS current version if_lan91cxx.c.

Masahiro Ariga



[-- Attachment #2: difffile.tar.gz --]
[-- Type: application/x-gzip, Size: 12631 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

Hello,

I again  recorded serial log file as DEBUG=0xff and prescale=4.
I also recorded Ethereal log at that time.

Although I previously sent log in my first mail,
for your information I send them.

As for prescale=4,please refer to my first mail.

I mostly appreciate your help.

Masahiro Ariga

[-- Attachment #2: serial-ethereal-log.tar.gz --]
[-- Type: application/x-gzip, Size: 10443 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

Hello,

I am terribly sorry.
Previously sent serial  log and Ethereal log are suspicious,
maybe mismatching .

I send again renewally recorded files.
Please refer to these files.

I am ashamed.

Masahiro Ariga

----- Original Message ----- 
From: "ariga masahiro" <ariga@link-lab.co.jp>
To: "Gary Thomas" <gary@mlbassoc.com>; "Alok Singh" 
<alok.singh@broadcom.com>; "Andrew Lunn" <andrew@lunn.ch>
Cc: <ecos-discuss@ecos.sourceware.org>
Sent: Wednesday, November 07, 2007 4:15 PM
Subject: Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT


> Hello,
>
> I again  recorded serial log file as DEBUG=0xff and prescale=4.
> I also recorded Ethereal log at that time.
>
> Although I previously sent log in my first mail,
> for your information I send them.
>
> As for prescale=4,please refer to my first mail.
>
> I mostly appreciate your help.
>
> Masahiro Ariga
>


--------------------------------------------------------------------------------


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

[-- Attachment #2: seria-eth-log-2.tar.gz --]
[-- Type: application/x-gzip, Size: 10834 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

RE: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[Alok Singh]

Ariga,
It will better if you remove all your little/big endian hacks. Or Take a
fresh view. And take care of the following - 

1) CYGPKG_HAL_MIPS_MSBFIRST  - should be defined, (and not
CYGPKG_HAL_MIPS_LSBFIRST)

2) # define CYG_BYTEORDER as CYG_MSBFIRST (and not as CYG_LSBFIRST). It
should be decided based on option 1) actually.


Plz try it out.


-Alok

-----Original Message-----
From: ariga masahiro [mailto:ariga@link-lab.co.jp] 
Sent: Wednesday, November 07, 2007 1:55 PM
To: Gary Thomas; Alok Singh; Andrew Lunn
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

Hello,

I am terribly sorry.
Previously sent serial  log and Ethereal log are suspicious,
maybe mismatching .

I send again renewally recorded files.
Please refer to these files.

I am ashamed.

Masahiro Ariga

----- Original Message ----- 
From: "ariga masahiro" <ariga@link-lab.co.jp>
To: "Gary Thomas" <gary@mlbassoc.com>; "Alok Singh" 
<alok.singh@broadcom.com>; "Andrew Lunn" <andrew@lunn.ch>
Cc: <ecos-discuss@ecos.sourceware.org>
Sent: Wednesday, November 07, 2007 4:15 PM
Subject: Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT


> Hello,
>
> I again  recorded serial log file as DEBUG=0xff and prescale=4.
> I also recorded Ethereal log at that time.
>
> Although I previously sent log in my first mail,
> for your information I send them.
>
> As for prescale=4,please refer to my first mail.
>
> I mostly appreciate your help.
>
> Masahiro Ariga
>


------------------------------------------------------------------------
--------


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


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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 3451 bytes --]

Hello,

Alok,thank you very much for your reply.

Alok wrote
> It will better if you remove all your little/big endian hacks. Or Take a
> fresh view. And take care of the following -

I checked two parameters you suggest,but I was encountered next questions 
for each.
Please allow my ignorance and teach me how to settle it.

About,
> 1) CYGPKG_HAL_MIPS_MSBFIRST  - should be defined, (and not
> CYGPKG_HAL_MIPS_LSBFIRST)
My target uses SH7709S.
CYGPKG_HAL_MIPS_MSBFIRST is included next cdl files,
packages\hal\mips\idt32334\current\cdl\hal_mips_idt32334.cdl(68): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\mips32\current\cdl\hal_mips_mips32.cdl(96):     cdl_option 
CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\rm7000\var\current\cdl\hal_mips_rm7000.cdl(118): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\tx39\current\cdl\hal_mips_tx39.cdl(78):         cdl_option 
CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\tx49\current\cdl\hal_mips_tx49.cdl(119): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\upd985xx\current\cdl\hal_mips_upd985xx.cdl(201): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\vrc4373\current\cdl\hal_mips_vr4300_vrc4373.cdl(82): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
but my target never uses above cdl file.
My target's configuration is like next in ecos.db.
target inserter {
        alias       { "Hitachi inserter board" }
        packages    { CYGPKG_HAL_SH
                      CYGPKG_HAL_SH_SH3
                      CYGPKG_HAL_SH_SH77X9_inserter
                      CYGPKG_IO_FLASH
                      CYGPKG_DEVS_FLASH_SH_inserter
                      CYGPKG_DEVS_FLASH_AMD_AM29XXXXX
                      CYGPKG_DEVS_ETH_SMSC_LAN91CXX
                      CYGPKG_DEVS_ETH_SH_INSERTER
                      CYGPKG_IO_ETH_DRIVERS
                      CYGPKG_IO_SERIAL_SH_inserter
                      CYGPKG_IO_SERIAL_SH_SCIF
        }
        description "
           The inserter target provides the packages needed to run
           eCos on a Hitachi Solution Engine 77x9 board."
}
Please tell me where and how to include CYGPKG_HAL_MIPS_MSBFIRST.
I send my ecos.db for reference.

About,
> 2) # define CYG_BYTEORDER as CYG_MSBFIRST (and not as CYG_LSBFIRST). It
> should be decided based on option 1) actually.
CYG_BYTEORDER is defined as below in 
packages\hal\sh\arch\current\include\basetype.h(60)
#ifdef __LITTLE_ENDIAN__
# define CYG_BYTEORDER          CYG_LSBFIRST // Little endian
#else
# define CYG_BYTEORDER          CYG_MSBFIRST // Big endian
#endif

__LITTLE_ENDIAN__ are defined in next files.
packages\hal\common\current\include\hal_stub.h(100):
#if (CYG_BYTEORDER==CYG_LSBFIRST)
# if !defined(__LITTLE_ENDIAN__)
#  define __LITTLE_ENDIAN__
# endif
# if !defined(_LITTLE_ENDIAN)
#  define _LITTLE_ENDIAN
# endif
#endif

packages\redboot\current\include\net\net.h(86):
#if (CYG_BYTEORDER == CYG_LSBFIRST)
#ifndef __LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__
#endif
extern unsigned long  ntohl(unsigned long x);
extern unsigned short ntohs(unsigned short x);
#else
#define ntohl(x) (x)
#define ntohs(x) (x)
#endif

I think redboot program space is differnt so I could exclude it.
The question is, between basetype.h and hal_stub.h which is included first ?
I never defined __LITTLE_ENDIAN__, so I thought even right now,
# define CYG_BYTEORDER          CYG_MSBFIRST // Big endian
Isn't it?

I look forward your reply.
Thanks in advance.

Masahiro Ariga

[-- Attachment #2: ecos.db.gz --]
[-- Type: application/x-gzip, Size: 33997 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

Hello,

Please read this mail with next consent.
I never doubt anything of eCos source code.
I just like to find out suffering points because of hardware oddity and
my bad concoction.I beseech you to help me find that suffering points.
And I mail this if my discovery have any merit for you to pinpoint that
suffering points.I am not good at TCP/IP.My opinion is greatly loaded
with conjectures.

I traced tcp_output function.
It looks to me, at tcp_output's next points, append option part.
line 688-691
 if (optlen) {
  bcopy(opt, th + 1, optlen);
  th->th_off = (sizeof (struct tcphdr) + optlen) >> 2;
 }
Although peer sent 8 bytes option,optlen was 4.

Also it looks to me, in generating SYN-ACK packet, at next switch sentence,
case (TH_SYN|TH_ACK) context should be executed.
But it all passed out these block, never entered if sentence(line 445) 
block.
At that time tp->t_flags was 0xA1,flags was 0x12.

line 445-510
  /*
  * Send `CC-family' options if our side wants to use them (TF_REQ_CC),
  * options are allowed (!TF_NOOPT) and it's not a RST.
   */
  if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC &&
       (flags & TH_RST) == 0) {
  switch (flags & (TH_SYN|TH_ACK)) {
  /*
   * This is a normal ACK, send CC if we received CC before
   * from our peer.
   */
  case TH_ACK:
   if (!(tp->t_flags & TF_RCVD_CC))
    break;
   /*FALLTHROUGH*/

  /*
   * We can only get here in T/TCP's SYN_SENT* state, when
   * we're a sending a non-SYN segment without waiting for
   * the ACK of our SYN.  A check above assures that we only
   * do this if our peer understands T/TCP.
   */
  case 0:
   opt[optlen++] = TCPOPT_NOP;
   opt[optlen++] = TCPOPT_NOP;
   opt[optlen++] = TCPOPT_CC;
   opt[optlen++] = TCPOLEN_CC;
   *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);

   optlen += 4;
   break;

  /*
   * This is our initial SYN, check whether we have to use
   * CC or CC.new.
   */
  case TH_SYN:
   opt[optlen++] = TCPOPT_NOP;
   opt[optlen++] = TCPOPT_NOP;
   opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
      TCPOPT_CCNEW : TCPOPT_CC;
   opt[optlen++] = TCPOLEN_CC;
   *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
    optlen += 4;
   break;

  /*
   * This is a SYN,ACK; send CC and CC.echo if we received
   * CC from our peer.
   */
  case (TH_SYN|TH_ACK):
   if (tp->t_flags & TF_RCVD_CC) {
    opt[optlen++] = TCPOPT_NOP;
    opt[optlen++] = TCPOPT_NOP;
    opt[optlen++] = TCPOPT_CC;
    opt[optlen++] = TCPOLEN_CC;
    *(u_int32_t *)&opt[optlen] =
     htonl(tp->cc_send);
    optlen += 4;
    opt[optlen++] = TCPOPT_NOP;
    opt[optlen++] = TCPOPT_NOP;
    opt[optlen++] = TCPOPT_CCECHO;
    opt[optlen++] = TCPOLEN_CC;
    *(u_int32_t *)&opt[optlen] =
     htonl(tp->cc_recv);
    optlen += 4;
   }
   break;
  }
  }

Possibly I am wrong,anyway I inform you on the risk of showing ignarance.

I sincerely beseech your help.

Masahiro Ariga



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

RE: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[Alok Singh]

Ariga,
Can you send your generated ecc file?

-Alok

-----Original Message-----
From: ariga masahiro [mailto:ariga@link-lab.co.jp] 
Sent: Thursday, November 08, 2007 7:26 AM
To: Gary Thomas; Alok Singh; Andrew Lunn
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

Hello,

Alok,thank you very much for your reply.

Alok wrote
> It will better if you remove all your little/big endian hacks. Or Take
a
> fresh view. And take care of the following -

I checked two parameters you suggest,but I was encountered next
questions 
for each.
Please allow my ignorance and teach me how to settle it.

About,
> 1) CYGPKG_HAL_MIPS_MSBFIRST  - should be defined, (and not
> CYGPKG_HAL_MIPS_LSBFIRST)
My target uses SH7709S.
CYGPKG_HAL_MIPS_MSBFIRST is included next cdl files,
packages\hal\mips\idt32334\current\cdl\hal_mips_idt32334.cdl(68): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\mips32\current\cdl\hal_mips_mips32.cdl(96):
cdl_option 
CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\rm7000\var\current\cdl\hal_mips_rm7000.cdl(118): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\tx39\current\cdl\hal_mips_tx39.cdl(78):
cdl_option 
CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\tx49\current\cdl\hal_mips_tx49.cdl(119): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\upd985xx\current\cdl\hal_mips_upd985xx.cdl(201): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
packages\hal\mips\vrc4373\current\cdl\hal_mips_vr4300_vrc4373.cdl(82): 
cdl_option CYGPKG_HAL_MIPS_MSBFIRST {
but my target never uses above cdl file.
My target's configuration is like next in ecos.db.
target inserter {
        alias       { "Hitachi inserter board" }
        packages    { CYGPKG_HAL_SH
                      CYGPKG_HAL_SH_SH3
                      CYGPKG_HAL_SH_SH77X9_inserter
                      CYGPKG_IO_FLASH
                      CYGPKG_DEVS_FLASH_SH_inserter
                      CYGPKG_DEVS_FLASH_AMD_AM29XXXXX
                      CYGPKG_DEVS_ETH_SMSC_LAN91CXX
                      CYGPKG_DEVS_ETH_SH_INSERTER
                      CYGPKG_IO_ETH_DRIVERS
                      CYGPKG_IO_SERIAL_SH_inserter
                      CYGPKG_IO_SERIAL_SH_SCIF
        }
        description "
           The inserter target provides the packages needed to run
           eCos on a Hitachi Solution Engine 77x9 board."
}
Please tell me where and how to include CYGPKG_HAL_MIPS_MSBFIRST.
I send my ecos.db for reference.

About,
> 2) # define CYG_BYTEORDER as CYG_MSBFIRST (and not as CYG_LSBFIRST).
It
> should be decided based on option 1) actually.
CYG_BYTEORDER is defined as below in 
packages\hal\sh\arch\current\include\basetype.h(60)
#ifdef __LITTLE_ENDIAN__
# define CYG_BYTEORDER          CYG_LSBFIRST // Little endian
#else
# define CYG_BYTEORDER          CYG_MSBFIRST // Big endian
#endif

__LITTLE_ENDIAN__ are defined in next files.
packages\hal\common\current\include\hal_stub.h(100):
#if (CYG_BYTEORDER==CYG_LSBFIRST)
# if !defined(__LITTLE_ENDIAN__)
#  define __LITTLE_ENDIAN__
# endif
# if !defined(_LITTLE_ENDIAN)
#  define _LITTLE_ENDIAN
# endif
#endif

packages\redboot\current\include\net\net.h(86):
#if (CYG_BYTEORDER == CYG_LSBFIRST)
#ifndef __LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__
#endif
extern unsigned long  ntohl(unsigned long x);
extern unsigned short ntohs(unsigned short x);
#else
#define ntohl(x) (x)
#define ntohs(x) (x)
#endif

I think redboot program space is differnt so I could exclude it.
The question is, between basetype.h and hal_stub.h which is included
first ?
I never defined __LITTLE_ENDIAN__, so I thought even right now,
# define CYG_BYTEORDER          CYG_MSBFIRST // Big endian
Isn't it?

I look forward your reply.
Thanks in advance.

Masahiro Ariga


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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

Hello Alok and others,

Thank you for attending my problem.
I  send ecc compressed file.

By the way,I cannot generate reply mail from Alok's mail.
I mean normally when I try to reply mail 
> is prepended to top of previous sentence.
But  when I tried to reply Alok's mail
no > is prepended.
And when I added my sentense and sent mail,
receiver couldn't read my sentence.
I am compelled to write reply mail for Alok  in repliable mail template.
So my reply mail is ommitted previous mail log.
Sorry for inconvieniance.

Masahiro Ariga

[-- Attachment #2: unnamed2.ecc.gz --]
[-- Type: application/x-gzip, Size: 89736 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

Hello,

I setted break point at ether_demux()'s 599 line in if_ethersubr.c and 
dumped mbuf data
when received SYN packet from host and was confirmed its content is just as 
same as
Ethereal captured data and also mh_len is correct.

ether_demux(ifp, eh, m)  596-601 lines
 case ETHERTYPE_IP:
  if (ipflow_fastforward(m))
   return;
      schednetisr(NETISR_IP);
  inq = &ipintrq;
  break;

Ethereal captured SYN-packet
host[172.16.1.28]-->target[172.16.1.200] TCP SYN packet
0000   00 40 31 08 01 00 00 15 c5 6d 23 f0 08 00 45 00
0010   00 30 09 fb 40 00 80 06 95 c8 ac 10 01 1c ac 10
0020   01 c8 04 d2 22 42 10 7d 2c a0 00 00 00 00 70 02
0030   ff ff c3 e9 00 00 02 04 05 b4 01 01 04 02

mbuf dumped data
{m_hdr={mh_next=*00000000,mh_nextpkt=*00000000,mh_data=*8C092EAC,mh_len=0x30,mh_type=0x1,mh_flags=0x2},
8C092EAC  45 00 00 30 09 FB 40 00
8C092EB4  80 06 95 C8 AC 10 01 1C
8C092EBC  AC 10 01 C8 04 D2 22 42
8C092EC4  10 7D 2C A0 00 00 00 00
8C092ECC  70 02 FF FF C3 E9 00 00
8C092ED4  02 04 05 B4 01 01 04 02
8C092EDC  00 40 31 08 01 00 08 06
8C092EE4  00 01 08 00 06 04 00 01

Also I setted break point at eth_drv_send()'s line 748 in eth_drv.c.
and dumped sg_list in which sending packet is reserved.
This is just before jumping to lan91cxx_send().

eth_drv.c
eth_drv_send(struct ifnet *ifp)
       746:         // Tell hardware to send this packet
       747:         if ( sg_len )
break  748:             (sc->funs->send)(sc, sg_list, sg_len, total_len, 
(unsigned long)m0);

sg_list
[0] = {buf=0x8C0928AE,len=0x36}
[1] = {buf=0x8,len=0x8C0816B4}
[2] = {buf=0x0,len=0x8C081248}
8C0928AE  00 15 C5 6D 23 F0 00 40
8C0928B6  31 08 01 00 08 00 45 00
8C0928BE  00 28 00 02 40 00 40 06
8C0928C6  DF C9 AC 10 01 C8 AC 10
8C0928CE  01 1C 22 42 05 3F 11 0E
8C0928D6  A5 2E 78 6A D4 5B 60 12
8C0928DE  44 70 D5 D5 00 00 02 04
8C0928E6  05 B4 00 00 00 00 00 00

And I confirmed that already at this point IP packet 
length(line-3,column-1,2) is contradicting
with TCP data-offset(line-6,column-7). Both lengths too short.

Thus I think it proves that my current trouble(=SYN-ACK becomes Malformed 
Packet)
is not concerned with hardware byte swapping.(at least directry)
I think it is caused by something else.

I beseech you to consider again without attention to hardware byte swapping.

I re-post my trouble or question from 11/6/2007 mail.
> After exchanged commands in UDP,
> host begins to TCP Connect and send SYN packet
> to our target.Target receives SYN packet and tries to
> send back SYN-ACK but that packet becomes Malformed packet.
> SYN-ACK packet is never recieved by host.
> Please refer to Ethereal txt log file I sent before.
>
> I captured TCP connection between Windows PCs,
> and compared SYN - SYNACK packets between Windows PCs log and
> host-target
> log,
> and I noticed there are some incomprehensible points.
>
> Below is from Ethereal Capture log
>
> Windows<-->Windows  -- no problem
> PC-client[172.16.1.28]<-->PC-server[172.16.1.21]
> [172.16.1.28]-->[172.16.1.21]
> SYN-Packet
> 00 10 a4 8a 8a ce 00 15  c5 6d 23 f0 08 00 45 00
> 00 30 30 b8 40 00 80 06  6f be ac 10 01 1c ac 10
> 01 15 04 c5 04 21 33 5d  c7 c1 00 00 00 00 70 02
> ff ff 24 c9 00 00 02 04  05 b4 01 01 04 02
> [172.16.1.21]-->[172.16.1.28]
> SYN-ACK-Packet
> 00 15 c5 6d 23 f0 00 10  a4 8a 8a ce 08 00 45 00
> 00 30 16 2a 40 00 80 06  8a 4c ac 10 01 15 ac 10
> 01 1c 04 21 04 c5 20 08  8f 1b 33 5d c7 c2 70 12
> 44 70 31 24 00 00 02 04  05 b4 01 01 04 02
> =========================================================
> cygwin<-->eCos  -- SYN-ACK [CHECKSUM INCORRECT][Malformed packet]
> host-client[172.16.1.28]<-->target-server[172.16.1.200]
> [172.16.1.28]-->[172.16.1.200]
> SYN-Packet
> 00 40 31 08 01 00 00 15  c5 6d 23 f0 08 00 45 00
> 00 30 35 81 40 00 80 06  6a 42 ac 10 01 1c ac 10
> 01 c8 05 1e 22 42 a6 39  a9 dc 00 00 00 00 70 02
> ff ff b0 a4 00 00 02 04  05 b4 01 01 04 02
> [172.16.1.200]-->[172.16.1.28]
> SYN-ACK-Packet
> 00 15 c5 6d 23 f0 00 40  31 08 01 00 08 00 45 00
> 00 28 00 02 40 00 40 06  df c9 ac 10 01 c8 ac 10
> 01 1c 22 42 05 1e 17 7a  85 37 a6 39 a9 dd 60 12
> 44 70 ec 30 00 00 00 00  00 00 00 00
>
> My incomprehensible points are,
> about Target's SYN-ACK-Packet,
> 1. paket length in IP header(=0028 line-2,colum-1,2) indicates
>   length from top of IP header(line-1,colum-15) to last of packet,
>   but 0028(=40d) counts to line-4,colum-6,there are 6 bytes surplus.
> 2. data offset bits(=6 line-3,colum-15) indicates there are 4*6=24bytes
>   from top of TCP header(line-3,colum-3) to last of packet.
>   But 24 counts to line-4,colum-10,there are 2 bytes surplus.
>   And there is a contradiction between paket length in IP header and
> TCP
> data offset bits.
> 3. option part of SYN packet(00 00 02 04  05 b4 01 01 04 02) changed to
> (00
> 00 00 00  00 00 00 00)
>   in Target's SYN-ACK-Packet.
>
> Please, could you enlighten me what is cause of this phenomenon ?
>
> By the way,I calculated checksum mannually and confirmed they are all
> correct.
>
> I only changed coding in retrieving data in BigEndian as I reported to
> you.
> I think others are resolved by Macros of bigendian.
>
> Currently when building, Resolve conflicts dialog appears like below.
>
> Resolve conflicts
> Item                  Conflict    Property
> CYGPKG_POSIX_CLOCKS   Unsatisfied Requires
> CYGBLD_ISO_STRUCTTIMEVAL_HEADER=="<cyg/posix/sys/time.h>"
> CYGPKG_FILEIO_FNMATCH Unsatisfied Requires
> CYGBLD_ISO_FNMATCH__HEADER=="<cyg/fileio/fnmatch.h>"
> Proposed Solutions:
> Item                               Value
> x CYGBLD_ISO_FNMATCH__HEADER       Enabled,<cyg/fileio/fnmatch.h>
> x CYGBLD_ISO_STRUCTTIMEVAL_HEADER  Enabled,<cyg/posix/sys/time.h>
>

I think at least my next observation is connected with my problem.
This is from 11/08/2007 mail.
> I traced tcp_output function.
> It looks to me, at tcp_output's next points, append option part.

> line 688-691
> if (optlen) {
>  bcopy(opt, th + 1, optlen);
>  th->th_off = (sizeof (struct tcphdr) + optlen) >> 2;
> }

> Although peer sent 8 bytes option,optlen was 4.
>
> Also it looks to me, in generating SYN-ACK packet, at next switch 
> sentence,
> case (TH_SYN|TH_ACK) context should be executed.
> But it all passed out these block, never entered if sentence(line 445)
> block.
> At that time tp->t_flags was 0xA1,flags was 0x12.
>
> line 445-510
>  /*
>  * Send `CC-family' options if our side wants to use them (TF_REQ_CC),
>  * options are allowed (!TF_NOOPT) and it's not a RST.
>   */
>  if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC &&
>       (flags & TH_RST) == 0) {
>  switch (flags & (TH_SYN|TH_ACK)) {
>  /*
>   * This is a normal ACK, send CC if we received CC before
>   * from our peer.
>   */
>  case TH_ACK:
>   if (!(tp->t_flags & TF_RCVD_CC))
>    break;
>   /*FALLTHROUGH*/
>
>  /*
>   * We can only get here in T/TCP's SYN_SENT* state, when
>   * we're a sending a non-SYN segment without waiting for
>   * the ACK of our SYN.  A check above assures that we only
>   * do this if our peer understands T/TCP.
>   */
>  case 0:
>   opt[optlen++] = TCPOPT_NOP;
>   opt[optlen++] = TCPOPT_NOP;
>   opt[optlen++] = TCPOPT_CC;
>   opt[optlen++] = TCPOLEN_CC;
>   *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
>
>   optlen += 4;
>   break;
>
>  /*
>   * This is our initial SYN, check whether we have to use
>   * CC or CC.new.
>   */
>  case TH_SYN:
>   opt[optlen++] = TCPOPT_NOP;
>   opt[optlen++] = TCPOPT_NOP;
>   opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
>      TCPOPT_CCNEW : TCPOPT_CC;
>   opt[optlen++] = TCPOLEN_CC;
>   *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
>    optlen += 4;
>   break;
>
>  /*
>   * This is a SYN,ACK; send CC and CC.echo if we received
>   * CC from our peer.
>   */
>  case (TH_SYN|TH_ACK):
>   if (tp->t_flags & TF_RCVD_CC) {
>    opt[optlen++] = TCPOPT_NOP;
>    opt[optlen++] = TCPOPT_NOP;
>    opt[optlen++] = TCPOPT_CC;
>    opt[optlen++] = TCPOLEN_CC;
>    *(u_int32_t *)&opt[optlen] =
>     htonl(tp->cc_send);
>    optlen += 4;
>    opt[optlen++] = TCPOPT_NOP;
>    opt[optlen++] = TCPOPT_NOP;
>    opt[optlen++] = TCPOPT_CCECHO;
>    opt[optlen++] = TCPOLEN_CC;
>    *(u_int32_t *)&opt[optlen] =
>     htonl(tp->cc_recv);
>    optlen += 4;
>   }
>   break;
>  }
>  }

Please help me to resolve problem.
Thank you in advance.




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

Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT

[ariga masahiro]

[-- Attachment #1: Type: text/plain, Size: 10788 bytes --]

Hello,

Since last mail I studied TCP/IP stack source,
and I concluded that for problem of length becoming uncorrect
when making SYN-ACK packet,only possible cause is tp->t_flags
is become un-correct value in tcp_input() for generating SYN-ACK packet.
Of cource I know it's caused by my wrong coding or my cofiguration.
But I beseech you to help me discover the cause of it.

As I said in previous mail, tp->t_flags was 0xA1 when jumped tcp_output at 
2345 line in tcp_input.c.
tcp_input()
      2342: #endif
      2343:     m_freem(m);
      2344:     tp->t_flags |= TF_ACKNOW;
      2345:     (void) tcp_output(tp);

Is this value is correct for sending SYN-ACK packet to host.
Would you please let me know correct value.

If by any chance, this is uncorrect would you enligten me
what do you think cause of malfunction ?

When I searched tp->t_flags topics in mailing list,
I found next topic titled "Re: SYN problem with new TCP/IP stack".
In Sun, 12 Feb 2006 mail Mr.Grant Edwards wrote next sentences.

> So, the ACK that's required by the TCP RFC is never sent (the
> SYN packet is just ignored).  So, the host just sits there and
> sends SYNs. Then the host's owner gets annoyed and calls
> customer support, yadda yadda, and here were are.

> Adding the following code immediately after the drop: label at
> line 2398 fixes the problem.

>                if (tp->t_flags & TF_ACKNOW)
>                        (void)tcp_output(tp);

I checked my tcp_input.c(CVS current version),it does not include above 
code.
To be on the safe side,I send my tcp_input.c version,would you please check
it is updated to include above operation ?

One more question:
I still not checked auto_negotiation,but is there any chance tp->t_flags 
becomes bad value
when auto_negotiation mal-functioed ?

I most earnetly beseech you to help me.
Thank you in advance.

Masahiro Ariga

----- Original Message ----- 
From: "ariga masahiro" <ariga@link-lab.co.jp>
To: "Gary Thomas" <gary@mlbassoc.com>; "Alok Singh" 
<alok.singh@broadcom.com>; "Andrew Lunn" <andrew@lunn.ch>
Cc: <ecos-discuss@ecos.sourceware.org>
Sent: Tuesday, November 13, 2007 10:13 AM
Subject: Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT


> Hello,
>
> I setted break point at ether_demux()'s 599 line in if_ethersubr.c and 
> dumped mbuf data
> when received SYN packet from host and was confirmed its content is just 
> as same as
> Ethereal captured data and also mh_len is correct.
>
> ether_demux(ifp, eh, m)  596-601 lines
> case ETHERTYPE_IP:
>  if (ipflow_fastforward(m))
>   return;
>      schednetisr(NETISR_IP);
>  inq = &ipintrq;
>  break;
>
> Ethereal captured SYN-packet
> host[172.16.1.28]-->target[172.16.1.200] TCP SYN packet
> 0000   00 40 31 08 01 00 00 15 c5 6d 23 f0 08 00 45 00
> 0010   00 30 09 fb 40 00 80 06 95 c8 ac 10 01 1c ac 10
> 0020   01 c8 04 d2 22 42 10 7d 2c a0 00 00 00 00 70 02
> 0030   ff ff c3 e9 00 00 02 04 05 b4 01 01 04 02
>
> mbuf dumped data
> {m_hdr={mh_next=*00000000,mh_nextpkt=*00000000,mh_data=*8C092EAC,mh_len=0x30,mh_type=0x1,mh_flags=0x2},
> 8C092EAC  45 00 00 30 09 FB 40 00
> 8C092EB4  80 06 95 C8 AC 10 01 1C
> 8C092EBC  AC 10 01 C8 04 D2 22 42
> 8C092EC4  10 7D 2C A0 00 00 00 00
> 8C092ECC  70 02 FF FF C3 E9 00 00
> 8C092ED4  02 04 05 B4 01 01 04 02
> 8C092EDC  00 40 31 08 01 00 08 06
> 8C092EE4  00 01 08 00 06 04 00 01
>
> Also I setted break point at eth_drv_send()'s line 748 in eth_drv.c.
> and dumped sg_list in which sending packet is reserved.
> This is just before jumping to lan91cxx_send().
>
> eth_drv.c
> eth_drv_send(struct ifnet *ifp)
>       746:         // Tell hardware to send this packet
>       747:         if ( sg_len )
> break  748:             (sc->funs->send)(sc, sg_list, sg_len, total_len, 
> (unsigned long)m0);
>
> sg_list
> [0] = {buf=0x8C0928AE,len=0x36}
> [1] = {buf=0x8,len=0x8C0816B4}
> [2] = {buf=0x0,len=0x8C081248}
> 8C0928AE  00 15 C5 6D 23 F0 00 40
> 8C0928B6  31 08 01 00 08 00 45 00
> 8C0928BE  00 28 00 02 40 00 40 06
> 8C0928C6  DF C9 AC 10 01 C8 AC 10
> 8C0928CE  01 1C 22 42 05 3F 11 0E
> 8C0928D6  A5 2E 78 6A D4 5B 60 12
> 8C0928DE  44 70 D5 D5 00 00 02 04
> 8C0928E6  05 B4 00 00 00 00 00 00
>
> And I confirmed that already at this point IP packet 
> length(line-3,column-1,2) is contradicting
> with TCP data-offset(line-6,column-7). Both lengths too short.
>
> Thus I think it proves that my current trouble(=SYN-ACK becomes Malformed 
> Packet)
> is not concerned with hardware byte swapping.(at least directry)
> I think it is caused by something else.
>
> I beseech you to consider again without attention to hardware byte 
> swapping.
>
> I re-post my trouble or question from 11/6/2007 mail.
>> After exchanged commands in UDP,
>> host begins to TCP Connect and send SYN packet
>> to our target.Target receives SYN packet and tries to
>> send back SYN-ACK but that packet becomes Malformed packet.
>> SYN-ACK packet is never recieved by host.
>> Please refer to Ethereal txt log file I sent before.
>>
>> I captured TCP connection between Windows PCs,
>> and compared SYN - SYNACK packets between Windows PCs log and
>> host-target
>> log,
>> and I noticed there are some incomprehensible points.
>>
>> Below is from Ethereal Capture log
>>
>> Windows<-->Windows  -- no problem
>> PC-client[172.16.1.28]<-->PC-server[172.16.1.21]
>> [172.16.1.28]-->[172.16.1.21]
>> SYN-Packet
>> 00 10 a4 8a 8a ce 00 15  c5 6d 23 f0 08 00 45 00
>> 00 30 30 b8 40 00 80 06  6f be ac 10 01 1c ac 10
>> 01 15 04 c5 04 21 33 5d  c7 c1 00 00 00 00 70 02
>> ff ff 24 c9 00 00 02 04  05 b4 01 01 04 02
>> [172.16.1.21]-->[172.16.1.28]
>> SYN-ACK-Packet
>> 00 15 c5 6d 23 f0 00 10  a4 8a 8a ce 08 00 45 00
>> 00 30 16 2a 40 00 80 06  8a 4c ac 10 01 15 ac 10
>> 01 1c 04 21 04 c5 20 08  8f 1b 33 5d c7 c2 70 12
>> 44 70 31 24 00 00 02 04  05 b4 01 01 04 02
>> =========================================================
>> cygwin<-->eCos  -- SYN-ACK [CHECKSUM INCORRECT][Malformed packet]
>> host-client[172.16.1.28]<-->target-server[172.16.1.200]
>> [172.16.1.28]-->[172.16.1.200]
>> SYN-Packet
>> 00 40 31 08 01 00 00 15  c5 6d 23 f0 08 00 45 00
>> 00 30 35 81 40 00 80 06  6a 42 ac 10 01 1c ac 10
>> 01 c8 05 1e 22 42 a6 39  a9 dc 00 00 00 00 70 02
>> ff ff b0 a4 00 00 02 04  05 b4 01 01 04 02
>> [172.16.1.200]-->[172.16.1.28]
>> SYN-ACK-Packet
>> 00 15 c5 6d 23 f0 00 40  31 08 01 00 08 00 45 00
>> 00 28 00 02 40 00 40 06  df c9 ac 10 01 c8 ac 10
>> 01 1c 22 42 05 1e 17 7a  85 37 a6 39 a9 dd 60 12
>> 44 70 ec 30 00 00 00 00  00 00 00 00
>>
>> My incomprehensible points are,
>> about Target's SYN-ACK-Packet,
>> 1. paket length in IP header(=0028 line-2,colum-1,2) indicates
>>   length from top of IP header(line-1,colum-15) to last of packet,
>>   but 0028(=40d) counts to line-4,colum-6,there are 6 bytes surplus.
>> 2. data offset bits(=6 line-3,colum-15) indicates there are 4*6=24bytes
>>   from top of TCP header(line-3,colum-3) to last of packet.
>>   But 24 counts to line-4,colum-10,there are 2 bytes surplus.
>>   And there is a contradiction between paket length in IP header and
>> TCP
>> data offset bits.
>> 3. option part of SYN packet(00 00 02 04  05 b4 01 01 04 02) changed to
>> (00
>> 00 00 00  00 00 00 00)
>>   in Target's SYN-ACK-Packet.
>>
>> Please, could you enlighten me what is cause of this phenomenon ?
>>
>> By the way,I calculated checksum mannually and confirmed they are all
>> correct.
>>
>> I only changed coding in retrieving data in BigEndian as I reported to
>> you.
>> I think others are resolved by Macros of bigendian.
>>
>> Currently when building, Resolve conflicts dialog appears like below.
>>
>> Resolve conflicts
>> Item                  Conflict    Property
>> CYGPKG_POSIX_CLOCKS   Unsatisfied Requires
>> CYGBLD_ISO_STRUCTTIMEVAL_HEADER=="<cyg/posix/sys/time.h>"
>> CYGPKG_FILEIO_FNMATCH Unsatisfied Requires
>> CYGBLD_ISO_FNMATCH__HEADER=="<cyg/fileio/fnmatch.h>"
>> Proposed Solutions:
>> Item                               Value
>> x CYGBLD_ISO_FNMATCH__HEADER       Enabled,<cyg/fileio/fnmatch.h>
>> x CYGBLD_ISO_STRUCTTIMEVAL_HEADER  Enabled,<cyg/posix/sys/time.h>
>>
>
> I think at least my next observation is connected with my problem.
> This is from 11/08/2007 mail.
>> I traced tcp_output function.
>> It looks to me, at tcp_output's next points, append option part.
>
>> line 688-691
>> if (optlen) {
>>  bcopy(opt, th + 1, optlen);
>>  th->th_off = (sizeof (struct tcphdr) + optlen) >> 2;
>> }
>
>> Although peer sent 8 bytes option,optlen was 4.
>>
>> Also it looks to me, in generating SYN-ACK packet, at next switch 
>> sentence,
>> case (TH_SYN|TH_ACK) context should be executed.
>> But it all passed out these block, never entered if sentence(line 445)
>> block.
>> At that time tp->t_flags was 0xA1,flags was 0x12.
>>
>> line 445-510
>>  /*
>>  * Send `CC-family' options if our side wants to use them (TF_REQ_CC),
>>  * options are allowed (!TF_NOOPT) and it's not a RST.
>>   */
>>  if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC &&
>>       (flags & TH_RST) == 0) {
>>  switch (flags & (TH_SYN|TH_ACK)) {
>>  /*
>>   * This is a normal ACK, send CC if we received CC before
>>   * from our peer.
>>   */
>>  case TH_ACK:
>>   if (!(tp->t_flags & TF_RCVD_CC))
>>    break;
>>   /*FALLTHROUGH*/
>>
>>  /*
>>   * We can only get here in T/TCP's SYN_SENT* state, when
>>   * we're a sending a non-SYN segment without waiting for
>>   * the ACK of our SYN.  A check above assures that we only
>>   * do this if our peer understands T/TCP.
>>   */
>>  case 0:
>>   opt[optlen++] = TCPOPT_NOP;
>>   opt[optlen++] = TCPOPT_NOP;
>>   opt[optlen++] = TCPOPT_CC;
>>   opt[optlen++] = TCPOLEN_CC;
>>   *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
>>
>>   optlen += 4;
>>   break;
>>
>>  /*
>>   * This is our initial SYN, check whether we have to use
>>   * CC or CC.new.
>>   */
>>  case TH_SYN:
>>   opt[optlen++] = TCPOPT_NOP;
>>   opt[optlen++] = TCPOPT_NOP;
>>   opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
>>      TCPOPT_CCNEW : TCPOPT_CC;
>>   opt[optlen++] = TCPOLEN_CC;
>>   *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
>>    optlen += 4;
>>   break;
>>
>>  /*
>>   * This is a SYN,ACK; send CC and CC.echo if we received
>>   * CC from our peer.
>>   */
>>  case (TH_SYN|TH_ACK):
>>   if (tp->t_flags & TF_RCVD_CC) {
>>    opt[optlen++] = TCPOPT_NOP;
>>    opt[optlen++] = TCPOPT_NOP;
>>    opt[optlen++] = TCPOPT_CC;
>>    opt[optlen++] = TCPOLEN_CC;
>>    *(u_int32_t *)&opt[optlen] =
>>     htonl(tp->cc_send);
>>    optlen += 4;
>>    opt[optlen++] = TCPOPT_NOP;
>>    opt[optlen++] = TCPOPT_NOP;
>>    opt[optlen++] = TCPOPT_CCECHO;
>>    opt[optlen++] = TCPOLEN_CC;
>>    *(u_int32_t *)&opt[optlen] =
>>     htonl(tp->cc_recv);
>>    optlen += 4;
>>   }
>>   break;
>>  }
>>  }
>
> Please help me to resolve problem.
> Thank you in advance.

[-- Attachment #2: tcp_input.c.gz --]
[-- Type: application/x-gzip, Size: 26065 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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

[ECOS] Wrongfully compiled code

[ariga masahiro]

Hello,
Happy New Year.

I am encountered next phenomenon and I am very in deep trouble.
It happens when sending back TCP SYN-ACK packet to peer,
and it happens in 
packages\net\bsd_tcpip\current\src\sys\netinet\tcp_output.c
tcp_output()function.

I attach C source code,and corresponding mixed source code below.
Please refer to them.

I traced source code using ICE. (numbers are source line numbers)
First,on line 398 hdrlen becomes 0x28.And optlen becomes 4 on line 408.
Althoug it should execute
       512:     hdrlen += optlen;
but looks it passed in C code trace.

And on line
|      643:         m->m_len = hdrlen;      -- hdrlen is still 0x28
hdrlen is 0x28,although it should be 0x2c.

I could have traced same part in mixed source mode,and I discovered it was 
wrongfully compiled.
I explain in detail after the source code.
Below are C code source and corresponding mixed source(from 445 line onward 
in C source).
-- tcp_output() C source code
       383: send:
       384:     /*
       385:      * Before ESTABLISHED, force sending of initial options
       386:      * unless TCP set not to do any options.
       387:      * NOTE: we assume that the IP/TCP header plus TCP options
       388:      * always fit in a single mbuf, leaving room for a maximum
       389:      * link header, i.e.
       390:      *  max_linkhdr + sizeof (struct tcpiphdr) + optlen <= 
MCLBYTES
       391:      */
       392:     optlen = 0;
       393: #ifdef INET6
       394:     if (isipv6)
       395:         hdrlen = sizeof (struct ip6_hdr) + sizeof (struct 
tcphdr);
       396:     else
       397: #endif
->     398:     hdrlen = sizeof (struct tcpiphdr);   -- here hdrlen becomes 
0x28
|      399:     if (flags & TH_SYN) {
|      400:         tp->snd_nxt = tp->iss;
|      401:         if ((tp->t_flags & TF_NOOPT) == 0) {
       402:             u_short mss;
       403:
|      404:             opt[0] = TCPOPT_MAXSEG;
|      405:             opt[1] = TCPOLEN_MAXSEG;
|      406:             mss = htons((u_short) tcp_mssopt(tp));
|      407:             (void)memcpy(opt + 2, &mss, sizeof(mss));
|      408:             optlen = TCPOLEN_MAXSEG;
       409:
|      410:             if ((tp->t_flags & TF_REQ_SCALE) &&  --428,É"n,Ô
       411:                 ((flags & TH_ACK) == 0 ||
       412:                 (tp->t_flags & TF_RCVD_SCALE))) {
       413:                 *((u_int32_t *)(opt + optlen)) = htonl(
       414:                     TCPOPT_NOP << 24 |
       415:                     TCPOPT_WINDOW << 16 |
       416:                     TCPOLEN_WINDOW << 8 |
       417:                     tp->request_r_scale);
       418:                 optlen += 4;
       419:             }
       420:         }
       421:     }
       422:
       423:     /*
       424:      * Send a timestamp and echo-reply if this is a SYN and our 
side
       425:      * wants to use timestamps (TF_REQ_TSTMP is set) or both our 
side
       426:      * and our peer have sent timestamps in our SYN's.
       427:      */
->     428:     if ((tp->t_flags & (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP 
&&
       429:         (flags & TH_RST) == 0 &&
       430:         ((flags & TH_ACK) == 0 ||
       431:          (tp->t_flags & TF_RCVD_TSTMP))) {
       432:         u_int32_t *lp = (u_int32_t *)(opt + optlen);
       433:
       434:         /* Form timestamp option as shown in appendix A of RFC 
1323. */
       435:         *lp++ = htonl(TCPOPT_TSTAMP_HDR);
       436:         *lp++ = htonl(ticks);
       437:         *lp   = htonl(tp->ts_recent);
       438:         optlen += TCPOLEN_TSTAMP_APPA;
       439:     }
       440:
       441:     /*
       442:      * Send `CC-family' options if our side wants to use them 
(TF_REQ_CC),
       443:      * options are allowed (!TF_NOOPT) and it's not a RST.
       444:      */
->     445:     if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC &&
       446:          (flags & TH_RST) == 0) {
       447:         switch (flags & (TH_SYN|TH_ACK)) {
       448:         /*
       449:          * This is a normal ACK, send CC if we received CC 
before
       450:          * from our peer.
       451:          */
       452:         case TH_ACK:
       453:             if (!(tp->t_flags & TF_RCVD_CC))
       454:                 break;
       455:             /*FALLTHROUGH*/
       456:
       457:         /*
       458:          * We can only get here in T/TCP's SYN_SENT* state, when
       459:          * we're a sending a non-SYN segment without waiting for
       460:          * the ACK of our SYN.  A check above assures that we 
only
       461:          * do this if our peer understands T/TCP.
       462:          */
       463:         case 0:
       464:             opt[optlen++] = TCPOPT_NOP;
       465:             opt[optlen++] = TCPOPT_NOP;
       466:             opt[optlen++] = TCPOPT_CC;
       467:             opt[optlen++] = TCPOLEN_CC;
       468:             *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
       469:
       470:             optlen += 4;
       471:             break;
       472:
       473:         /*
       474:          * This is our initial SYN, check whether we have to use
       475:          * CC or CC.new.
       476:          */
       477:         case TH_SYN:
       478:             opt[optlen++] = TCPOPT_NOP;
       479:             opt[optlen++] = TCPOPT_NOP;
       480:             opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
       481:                         TCPOPT_CCNEW : TCPOPT_CC;
       482:             opt[optlen++] = TCPOLEN_CC;
       483:             *(u_int32_t *)&opt[optlen] = htonl(tp->cc_send);
       484:             optlen += 4;
       485:             break;
       486:
       487:         /*
       488:          * This is a SYN,ACK; send CC and CC.echo if we received
       489:          * CC from our peer.
       490:          */
       491:         case (TH_SYN|TH_ACK):
       492:             if (tp->t_flags & TF_RCVD_CC) {
       493:                 opt[optlen++] = TCPOPT_NOP;
       494:                 opt[optlen++] = TCPOPT_NOP;
       495:                 opt[optlen++] = TCPOPT_CC;
       496:                 opt[optlen++] = TCPOLEN_CC;
       497:                 *(u_int32_t *)&opt[optlen] =
       498:                     htonl(tp->cc_send);
       499:                 optlen += 4;
       500:                 opt[optlen++] = TCPOPT_NOP;
       501:                 opt[optlen++] = TCPOPT_NOP;
       502:                 opt[optlen++] = TCPOPT_CCECHO;
       503:                 opt[optlen++] = TCPOLEN_CC;
       504:                 *(u_int32_t *)&opt[optlen] =
       505:                     htonl(tp->cc_recv);
       506:                 optlen += 4;
       507:             }
       508:             break;
       509:         }
       510:     }
       511:
       512:     hdrlen += optlen;

and try to convert m->m_len,
->     642:         m->m_data += max_linkhdr;
|      643:         m->m_len = hdrlen;        -- hdrlen is still 0x28

--- Mix source code corresponding to C code
tcp_output.c (445):    if ((tp->t_flags & (TF_REQ_CC|TF_NOOPT)) == TF_REQ_CC 
&&
            8C048BA4            51AA      MOV.L      @(28,R10 tp ),R1
            8C048BA6            9214      MOV.W      8C048BD2,R2
            8C048BA8            2129      AND        R2,R1
            8C048BAA            72F8      ADD        #F8,R2
            8C048BAC            3120      CMP/EQ     R2,R1
            8C048BAE            8F51      BF/S 
4              ->1
            8C048BB0            60D3      MOV        R13 flags ,R0
            8C048BB2            C904      AND        #4,R0
            8C048BB4            2008      TST        R0,R0
            8C048BB6            8F4D      BF/S       8C048C54
            8C048BB8            E212      MOV        #12,R2
tcp_output.c (447):        switch (flags & (TH_SYN|TH_ACK)) {
            8C048BBA            22D9      AND        R13 flags ,R2
            8C048BBC            E112      MOV        #12,R1
            8C048BBE            3216      CMP/HI     R1,R2
            8C048BC0            8948      BT         8C048C54
            8C048BC2            C70A      MOVA       8C048BEC,R0
            8C048BC4            322C      ADD        R2,R2
            8C048BC6            012D      MOV.W      @(R0,R2),R1
            8C048BC8            0123      BRAF       R1
            8C048BCA            0009      NOP
            8C048BCC            00AC      MOV.B      @(R0,R10 tp ),R0
            8C048BCE            0080      ???
            8C048BD0            0100      ???
            8C048BD2            2008      TST        R0,R0
            8C048BD4            8C02      ???
            8C048BD6            9D60      MOV.W      8C048C9A,R13 flags
            8C048BD8            8C04      ???
            8C048BDA            94A0      MOV.W      8C048D1E,R4
            8C048BDC            8C04      ???
            8C048BDE            8600      ???
            8C048BE0            0103      BSRF       R1
            8C048BE2            0300      ???
            8C048BE4            0101      ???
            8C048BE6            080A      STS        MACH,R8 error
            8C048BE8            8C02      ???
            8C048BEA            8BF0      BF         8C048BCE
            8C048BEC            005C      MOV.B      @(R0,R5),R0
            8C048BEE            0124      MOV.B      R2,@(R0,R1)
            8C048BF0            0094      MOV.B      R9,@(R0,R0)
            8C048BF2            0124      MOV.B      R2,@(R0,R1)
            8C048BF4            0124      MOV.B      R2,@(R0,R1)
            8C048BF6            0124      MOV.B      R2,@(R0,R1)
            8C048BF8            0124      MOV.B      R2,@(R0,R1)
            8C048BFA            0124      MOV.B      R2,@(R0,R1)
            8C048BFC            0124      MOV.B      R2,@(R0,R1)
            8C048BFE            0124      MOV.B      R2,@(R0,R1)
            8C048C00            0124      MOV.B      R2,@(R0,R1)
            8C048C02            0124      MOV.B      R2,@(R0,R1)
            8C048C04            0124      MOV.B      R2,@(R0,R1)
            8C048C06            0124      MOV.B      R2,@(R0,R1)
            8C048C08            0124      MOV.B      R2,@(R0,R1)
            8C048C0A            0124      MOV.B      R2,@(R0,R1)
            8C048C0C            0054      MOV.B      R5,@(R0,R0)
            8C048C0E            0124      MOV.B      R2,@(R0,R1)
            8C048C10            00D4      MOV.B      R13 flags ,@(R0,R0)
            8C048C12            0009      NOP
            8C048C14            0009      NOP
            8C048C16            0009      NOP
            8C048C18            0009      NOP
            8C048C1A            0009      NOP
            8C048C1C            0009      NOP
            8C048C1E            0009      NOP
tcp_output.c (453):            if (!(tp->t_flags & TF_RCVD_CC))
            8C048C20            52AA      MOV.L      @(28,R10 tp ),R2
            8C048C22            91B2      MOV.W      8C048D8A,R1
            8C048C24            2218      TST        R1,R2
            8C048C26            8963      BT         8C048CF0
tcp_output.c (464):            opt[optlen++] = TCPOPT_NOP;
            8C048C28            E101      MOV        #1,R1
            8C048C2A            E048      MOV        #48,R0
            8C048C2C            00EE      MOV.L      @(R0,R14),R0
            8C048C2E            0E14      MOV.B      R1,@(R0,R14)
            8C048C30            7001      ADD        #1,R0
            8C048C32            E240      MOV        #40,R2
            8C048C34            32EC      ADD        R14,R2
tcp_output.c (465):            opt[optlen++] = TCPOPT_NOP;
            8C048C36            0E14      MOV.B      R1,@(R0,R14)
            8C048C38            7001      ADD        #1,R0
tcp_output.c (466):            opt[optlen++] = TCPOPT_CC;
            8C048C3A            E10B      MOV        #B,R1
            8C048C3C            0E14      MOV.B      R1,@(R0,R14)
            8C048C3E            7001      ADD        #1,R0
tcp_output.c (467):            opt[optlen++] = TCPOLEN_CC;
            8C048C40            E106      MOV        #6,R1
            8C048C42            0E14      MOV.B      R1,@(R0,R14)
            8C048C44            7001      ADD        #1,R0
            8C048C46            1202      MOV.L      R0,@(8,R2)
tcp_output.c (468):            *(u_int32_t *)&opt[optlen] = 
htonl(tp->cc_send);
            8C048C48            90A0      MOV.W      8C048D8C,R0
            8C048C4A            01AE      MOV.L      @(R0,R10 tp ),R1
            8C048C4C            5022      MOV.L      @(8,R2),R0
            8C048C4E            0E16      MOV.L      R1,@(R0,R14)
tcp_output.c (470):            optlen += 4;
            8C048C50            7004      ADD        #4,R0
            8C048C52            1202      MOV.L      R0,@(8,R2)
->1         8C048C54            A04D      BRA        8C048CF2   ->2
tcp_output.c (471):            break;
            8C048C56            E740      MOV        #40,R7
            8C048C58            0009      NOP
            8C048C5A            0009      NOP
            8C048C5C            0009      NOP
            8C048C5E            0009      NOP
tcp_output.c (478):            opt[optlen++] = TCPOPT_NOP;
            8C048C60            E101      MOV        #1,R1
            8C048C62            E048      MOV        #48,R0
            8C048C64            00EE      MOV.L      @(R0,R14),R0
            8C048C66            0E14      MOV.B      R1,@(R0,R14)
            8C048C68            7001      ADD        #1,R0
tcp_output.c (479):            opt[optlen++] = TCPOPT_NOP;
            8C048C6A            0E14      MOV.B      R1,@(R0,R14)
            8C048C6C            7001      ADD        #1,R0
tcp_output.c (480):            opt[optlen++] = tp->t_flags & TF_SENDCCNEW ?
            8C048C6E            6303      MOV        R0,R3 ipoptlen
            8C048C70            33EC      ADD        R14,R3 ipoptlen
            8C048C72            7001      ADD        #1,R0
            8C048C74            52AA      MOV.L      @(28,R10 tp ),R2
            8C048C76            D146      MOV.L      8C048D90,R1
            8C048C78            2218      TST        R1,R2
            8C048C7A            0129      MOVT       R1
            8C048C7C            611B      NEG        R1,R1
            8C048C7E            710C      ADD        #C,R1
            8C048C80            2310      MOV.B      R1,@R3 ipoptlen
tcp_output.c (482):            opt[optlen++] = TCPOLEN_CC;
            8C048C82            E106      MOV        #6,R1
            8C048C84            0E14      MOV.B      R1,@(R0,R14)
            8C048C86            7001      ADD        #1,R0
            8C048C88            E640      MOV        #40,R6
            8C048C8A            36EC      ADD        R14,R6
            8C048C8C            1602      MOV.L      R0,@(8,R6)
tcp_output.c (483):            *(u_int32_t *)&opt[optlen] = 
htonl(tp->cc_send);
            8C048C8E            907D      MOV.W      8C048D8C,R0
            8C048C90            01AE      MOV.L      @(R0,R10 tp ),R1
            8C048C92            A029      BRA        8C048CE8
tcp_output.c (485):            break;
            8C048C94            5062      MOV.L      @(8,R6),R0
            8C048C96            0009      NOP
            8C048C98            0009      NOP
            8C048C9A            0009      NOP
            8C048C9C            0009      NOP
            8C048C9E            0009      NOP
tcp_output.c (492):            if (tp->t_flags & TF_RCVD_CC) {
            8C048CA0            52AA      MOV.L      @(28,R10 tp ),R2
            8C048CA2            9172      MOV.W      8C048D8A,R1
            8C048CA4            2218      TST        R1,R2
            8C048CA6            8D24      BT/S       8C048CF2
            8C048CA8            E740      MOV        #40,R7
tcp_output.c (493):                opt[optlen++] = TCPOPT_NOP;
            8C048CAA            E201      MOV        #1,R2
            8C048CAC            E048      MOV        #48,R0
            8C048CAE            00EE      MOV.L      @(R0,R14),R0
            8C048CB0            0E24      MOV.B      R2,@(R0,R14)
            8C048CB2            7001      ADD        #1,R0
tcp_output.c (494):                opt[optlen++] = TCPOPT_NOP;
            8C048CB4            0E24      MOV.B      R2,@(R0,R14)
            8C048CB6            7001      ADD        #1,R0
tcp_output.c (495):                opt[optlen++] = TCPOPT_CC;
            8C048CB8            E10B      MOV        #B,R1
            8C048CBA            0E14      MOV.B      R1,@(R0,R14)
            8C048CBC            7001      ADD        #1,R0
            8C048CBE            E640      MOV        #40,R6
            8C048CC0            36EC      ADD        R14,R6
tcp_output.c (496):                opt[optlen++] = TCPOLEN_CC;
            8C048CC2            E706      MOV        #6,R7
            8C048CC4            0E74      MOV.B      R7,@(R0,R14)
            8C048CC6            7001      ADD        #1,R0
tcp_output.c (497):                *(u_int32_t *)&opt[optlen] =
            8C048CC8            9160      MOV.W      8C048D8C,R1
            8C048CCA            63A3      MOV        R10 tp ,R3 ipoptlen
            8C048CCC            331C      ADD        R1,R3 ipoptlen
            8C048CCE            5130      MOV.L      @(0,R3 ipoptlen ),R1
            8C048CD0            0E16      MOV.L      R1,@(R0,R14)
tcp_output.c (499):                optlen += 4;
            8C048CD2            7004      ADD        #4,R0
tcp_output.c (500):                opt[optlen++] = TCPOPT_NOP;
            8C048CD4            0E24      MOV.B      R2,@(R0,R14)
            8C048CD6            7001      ADD        #1,R0
tcp_output.c (501):                opt[optlen++] = TCPOPT_NOP;
            8C048CD8            0E24      MOV.B      R2,@(R0,R14)
            8C048CDA            7001      ADD        #1,R0
tcp_output.c (502):                opt[optlen++] = TCPOPT_CCECHO;
            8C048CDC            E10D      MOV        #D,R1
            8C048CDE            0E14      MOV.B      R1,@(R0,R14)
            8C048CE0            7001      ADD        #1,R0
tcp_output.c (503):                opt[optlen++] = TCPOLEN_CC;
            8C048CE2            0E74      MOV.B      R7,@(R0,R14)
            8C048CE4            7001      ADD        #1,R0
tcp_output.c (504):                *(u_int32_t *)&opt[optlen] =
            8C048CE6            5131      MOV.L      @(4,R3 ipoptlen ),R1
            8C048CE8            0E16      MOV.L      R1,@(R0,R14)
tcp_output.c (506):                optlen += 4;
            8C048CEA            7004      ADD        #4,R0
            8C048CEC            1602      MOV.L      R0,@(8,R6)
            8C048CEE            0009      NOP
tcp_output.c (512):    hdrlen += optlen;
            8C048CF0            E740      MOV        #40,R7
->2         8C048CF2            37EC      ADD        R14,R7
            8C048CF4            5073      MOV.L      @(C,R7),R0
            8C048CF6            5772      MOV.L      @(8,R7),R7
            8C048CF8            307C      ADD        R7,R0
            8C048CFA            1703      MOV.L      R0,@(C,R7)
tcp_output.c (520):    if (tp->t_inpcb->inp_options) {
            8C048CFC            51A8      MOV.L      @(20,R10 tp ),R1
            8C048CFE            9046      MOV.W      8C048D8E,R0
            8C048D00            011E      MOV.L      @(R0,R1),R1
            8C048D02            2118      TST        R1,R1
            8C048D04            8904      BT         8C048D10
            8C048D06            5113      MOV.L      @(C,R1),R1
tcp_output.c (521):        ipoptlen = tp->t_inpcb->inp_options->m_len -

In detail.
Like I said,at line-445 hdrlen is 0x28,and optlen is 4.
After that it jump to address 8C048CF2(->2).

About @(disp:4,Rn) assembler operation,next is from SH assembler manual,
"The effective address is Rn plus a 4-bit displacement
(disp). The value of disp is zero-extended, and
remains the same for a byte operation, is doubled for
a word operation, and is quadrupled for a longword
operation."

When jumped to 8C048CF2, R14=8c081458,R7=00000040.
Added,R7 becomes 8c081498.
After executing (MOV.L  @(C,R7),R0),R0 becomes 0x28.
But here it acts qeerly,according to manual,0x28 should be retrieved
from 8c081498+c*4=8c0814c8, but really it was retreived from 8c0814a4.
It looks there's no extension according to operand size.But this is minor 
point.
Anyway,after executing next line(MOV.L      @(8,R7),R7),R7 becomes 4.
By (ADD R7,R0),R0 becomes 0x2c,this is expected value for hdrlen.
But,by (MOV.L R0,@(C,R7)),content of R0 is reserved into 0x00000010.(really 
it can't be written).
Content of hdrlen(8c0814a4) remains 0x28.

I executed without ICE but resulted in IP packet size being 0x28,although it 
should be 0x2c.

I am perplexed why this phenomenon happens.
Please enlighten me what do you think causes this mishappening.

My target CPU is SH7709S.
I am developing on Cygwin environment.
I checked sh-elf-gcc version and it was version 3.2.1.

$ sh-elf-gcc -v
Reading specs from 
/opt/ecos/gnutools/sh-elf/bin/../lib/gcc-lib/sh-elf/3.2.1/spe
cs
Configured with: 
/local/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/cygwin/tar_b
z2/source/gcc-3.2.1/configure --target=sh-elf --prefix=/local/demonweb/tools/eco
s-gnutools-v1.4/r2/sh-elf/cygwin/tar_bz2/opt/ecos/gnutools/sh-elf --enable-langu
ages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=/loc
al/demonweb/tools/ecos-gnutools-v1.4/r2/sh-elf/cygwin/tar_bz2/opt/ecos/gnutools/
sh-elf/sh-elf/include
Thread model: single
gcc version 3.2.1

My compile option is same as CVS downloaded version for se77x9,
        cdl_option CYGBLD_GLOBAL_CFLAGS {
            display "Global compiler flags"
            flavor  data
            no_define
            default_value { CYGHWR_HAL_SH_BIGENDIAN ? 
"-D_KERNEL -D__ECOS -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" }
            description   "
                This option controls the global compiler flags which
                are used to compile all packages by
                default. Individual packages may define
                options which override these global flags."
        }

        cdl_option CYGBLD_GLOBAL_LDFLAGS {
            display "Global linker flags"
            flavor  data
            no_define
            default_value { CYGHWR_HAL_SH_BIGENDIAN ? 
"-mb -m3 -ggdb -nostdlib -Wl,--gc-sections -Wl,-static" : 
"-ml -m3 -ggdb -nostdlib -Wl,--gc-sections -Wl,-static" }
            description   "
                This option controls the global linker flags. Individual
                packages may define options which override these global 
flags."
        }

CYGHWR_HAL_SH_BIGENDIAN is valid.

My ICE works on Windows so I would like to develop on Cygwin environment.

I bessech you to help me.
Thanks in advance.

Masahiro Ariga



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