* [ECOS] Building error on CVS checkout sources @ 2007-09-14 5:37 ariga masahiro 2007-09-14 8:22 ` [ECOS] " Andrew Lunn 0 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-09-14 5:37 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [ECOS] Re: Building error on CVS checkout sources 2007-09-14 5:37 [ECOS] Building error on CVS checkout sources ariga masahiro @ 2007-09-14 8:22 ` Andrew Lunn 2007-09-14 9:38 ` [ECOS] Virtual Vector Configuration Stefan Sommerfeld 2007-10-15 5:59 ` [ECOS] What functions should I call in ethernet drv ? ariga masahiro 0 siblings, 2 replies; 40+ messages in thread From: Andrew Lunn @ 2007-09-14 8:22 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [ECOS] Virtual Vector Configuration 2007-09-14 8:22 ` [ECOS] " Andrew Lunn @ 2007-09-14 9:38 ` Stefan Sommerfeld 2007-09-14 10:17 ` Nick Garnett 2007-10-15 5:59 ` [ECOS] What functions should I call in ethernet drv ? ariga masahiro 1 sibling, 1 reply; 40+ messages in thread From: Stefan Sommerfeld @ 2007-09-14 9:38 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Virtual Vector Configuration 2007-09-14 9:38 ` [ECOS] Virtual Vector Configuration Stefan Sommerfeld @ 2007-09-14 10:17 ` Nick Garnett 0 siblings, 0 replies; 40+ messages in thread From: Nick Garnett @ 2007-09-14 10:17 UTC (permalink / raw) To: Stefan Sommerfeld; +Cc: ecos-discuss "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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [ECOS] What functions should I call in ethernet drv ? 2007-09-14 8:22 ` [ECOS] " Andrew Lunn 2007-09-14 9:38 ` [ECOS] Virtual Vector Configuration Stefan Sommerfeld @ 2007-10-15 5:59 ` ariga masahiro 2007-10-15 11:20 ` Gary Thomas 1 sibling, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-10-15 5:59 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-15 5:59 ` [ECOS] What functions should I call in ethernet drv ? ariga masahiro @ 2007-10-15 11:20 ` Gary Thomas 2007-10-16 3:04 ` ariga masahiro 0 siblings, 1 reply; 40+ messages in thread From: Gary Thomas @ 2007-10-15 11:20 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-15 11:20 ` Gary Thomas @ 2007-10-16 3:04 ` ariga masahiro 2007-10-16 11:08 ` Gary Thomas 0 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-10-16 3:04 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-16 3:04 ` ariga masahiro @ 2007-10-16 11:08 ` Gary Thomas 2007-10-17 7:41 ` ariga masahiro 2007-10-17 8:45 ` [ECOS] What functions should I call in ethernet drv ? ariga masahiro 0 siblings, 2 replies; 40+ messages in thread From: Gary Thomas @ 2007-10-16 11:08 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-16 11:08 ` Gary Thomas @ 2007-10-17 7:41 ` ariga masahiro 2007-10-17 11:32 ` Gary Thomas 2007-10-17 8:45 ` [ECOS] What functions should I call in ethernet drv ? ariga masahiro 1 sibling, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-10-17 7:41 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-17 7:41 ` ariga masahiro @ 2007-10-17 11:32 ` Gary Thomas 2007-10-18 7:17 ` ariga masahiro [not found] ` <000c01c81151$9add59c0$1c0110ac@ariga> 0 siblings, 2 replies; 40+ messages in thread From: Gary Thomas @ 2007-10-17 11:32 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-17 11:32 ` Gary Thomas @ 2007-10-18 7:17 ` ariga masahiro [not found] ` <000c01c81151$9add59c0$1c0110ac@ariga> 1 sibling, 0 replies; 40+ messages in thread From: ariga masahiro @ 2007-10-18 7:17 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <000c01c81151$9add59c0$1c0110ac@ariga>]
* Re: [ECOS] What functions should I call in ethernet drv ? [not found] ` <000c01c81151$9add59c0$1c0110ac@ariga> @ 2007-10-18 11:12 ` Gary Thomas 2007-10-19 4:56 ` ariga masahiro 0 siblings, 1 reply; 40+ messages in thread From: Gary Thomas @ 2007-10-18 11:12 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-18 11:12 ` Gary Thomas @ 2007-10-19 4:56 ` ariga masahiro 2007-10-19 9:55 ` Gary Thomas 0 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-10-19 4:56 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-19 4:56 ` ariga masahiro @ 2007-10-19 9:55 ` Gary Thomas 2007-10-20 6:19 ` ariga masahiro 2007-10-23 8:23 ` ariga masahiro 0 siblings, 2 replies; 40+ messages in thread From: Gary Thomas @ 2007-10-19 9:55 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-19 9:55 ` Gary Thomas @ 2007-10-20 6:19 ` ariga masahiro 2007-10-23 8:23 ` ariga masahiro 1 sibling, 0 replies; 40+ messages in thread From: ariga masahiro @ 2007-10-20 6:19 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-19 9:55 ` Gary Thomas 2007-10-20 6:19 ` ariga masahiro @ 2007-10-23 8:23 ` ariga masahiro 2007-10-23 8:27 ` Alok Singh 1 sibling, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-10-23 8:23 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [ECOS] What functions should I call in ethernet drv ? 2007-10-23 8:23 ` ariga masahiro @ 2007-10-23 8:27 ` Alok Singh 2007-10-23 9:05 ` ariga masahiro 2007-10-25 2:05 ` ariga masahiro 0 siblings, 2 replies; 40+ messages in thread From: Alok Singh @ 2007-10-23 8:27 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-23 8:27 ` Alok Singh @ 2007-10-23 9:05 ` ariga masahiro 2007-10-25 2:05 ` ariga masahiro 1 sibling, 0 replies; 40+ messages in thread From: ariga masahiro @ 2007-10-23 9:05 UTC (permalink / raw) To: Alok Singh; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-23 8:27 ` Alok Singh 2007-10-23 9:05 ` ariga masahiro @ 2007-10-25 2:05 ` ariga masahiro 2007-10-30 2:41 ` [ECOS] Can't Connect,TCP CHECKSUM INCORRECT ariga masahiro 1 sibling, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-10-25 2:05 UTC (permalink / raw) To: Gary Thomas, Alok Singh; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-10-25 2:05 ` ariga masahiro @ 2007-10-30 2:41 ` ariga masahiro 2007-10-30 3:02 ` Andrew Lunn ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: ariga masahiro @ 2007-10-30 2:41 UTC (permalink / raw) To: Gary Thomas, Alok Singh; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-10-30 2:41 ` [ECOS] Can't Connect,TCP CHECKSUM INCORRECT ariga masahiro @ 2007-10-30 3:02 ` Andrew Lunn 2007-10-30 4:17 ` [ECOS] " Grant Edwards 2007-11-06 7:14 ` [ECOS] " ariga masahiro 2 siblings, 0 replies; 40+ messages in thread From: Andrew Lunn @ 2007-10-30 3:02 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [ECOS] Re: Can't Connect,TCP CHECKSUM INCORRECT 2007-10-30 2:41 ` [ECOS] Can't Connect,TCP CHECKSUM INCORRECT ariga masahiro 2007-10-30 3:02 ` Andrew Lunn @ 2007-10-30 4:17 ` Grant Edwards 2007-10-30 8:51 ` Alok Singh 2007-11-06 7:14 ` [ECOS] " ariga masahiro 2 siblings, 1 reply; 40+ messages in thread From: Grant Edwards @ 2007-10-30 4:17 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [ECOS] Re: Can't Connect,TCP CHECKSUM INCORRECT 2007-10-30 4:17 ` [ECOS] " Grant Edwards @ 2007-10-30 8:51 ` Alok Singh 0 siblings, 0 replies; 40+ messages in thread From: Alok Singh @ 2007-10-30 8:51 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-10-30 2:41 ` [ECOS] Can't Connect,TCP CHECKSUM INCORRECT ariga masahiro 2007-10-30 3:02 ` Andrew Lunn 2007-10-30 4:17 ` [ECOS] " Grant Edwards @ 2007-11-06 7:14 ` ariga masahiro 2007-11-06 7:58 ` Alok Singh 2 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-11-06 7:14 UTC (permalink / raw) To: Andrew Lunn, Alok Singh, Gary Thomas; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-06 7:14 ` [ECOS] " ariga masahiro @ 2007-11-06 7:58 ` Alok Singh 2007-11-06 8:30 ` ariga masahiro 0 siblings, 1 reply; 40+ messages in thread From: Alok Singh @ 2007-11-06 7:58 UTC (permalink / raw) To: ariga masahiro, Andrew Lunn, Gary Thomas; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-06 7:58 ` Alok Singh @ 2007-11-06 8:30 ` ariga masahiro 2007-11-06 8:35 ` Andrew Lunn 0 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-11-06 8:30 UTC (permalink / raw) To: Alok Singh, Andrew Lunn, Gary Thomas; +Cc: ecos-discuss >>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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-06 8:30 ` ariga masahiro @ 2007-11-06 8:35 ` Andrew Lunn 2007-11-06 23:47 ` ariga masahiro 2008-01-07 1:36 ` [ECOS] Wrongfully compiled code ariga masahiro 0 siblings, 2 replies; 40+ messages in thread From: Andrew Lunn @ 2007-11-06 8:35 UTC (permalink / raw) To: ariga masahiro; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-06 8:35 ` Andrew Lunn @ 2007-11-06 23:47 ` ariga masahiro 2007-11-07 1:05 ` ariga masahiro 2008-01-07 1:36 ` [ECOS] Wrongfully compiled code ariga masahiro 1 sibling, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-11-06 23:47 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-06 23:47 ` ariga masahiro @ 2007-11-07 1:05 ` ariga masahiro 2007-11-07 7:15 ` ariga masahiro 0 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-11-07 1:05 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-07 1:05 ` ariga masahiro @ 2007-11-07 7:15 ` ariga masahiro 2007-11-07 8:24 ` ariga masahiro 0 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-11-07 7:15 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-07 7:15 ` ariga masahiro @ 2007-11-07 8:24 ` ariga masahiro 2007-11-07 11:55 ` Alok Singh 2007-11-08 1:56 ` ariga masahiro 0 siblings, 2 replies; 40+ messages in thread From: ariga masahiro @ 2007-11-07 8:24 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-07 8:24 ` ariga masahiro @ 2007-11-07 11:55 ` Alok Singh 2007-11-08 1:56 ` ariga masahiro 1 sibling, 0 replies; 40+ messages in thread From: Alok Singh @ 2007-11-07 11:55 UTC (permalink / raw) To: ariga masahiro, Gary Thomas, Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-07 8:24 ` ariga masahiro 2007-11-07 11:55 ` Alok Singh @ 2007-11-08 1:56 ` ariga masahiro 2007-11-08 8:23 ` ariga masahiro 2007-11-08 9:13 ` Alok Singh 1 sibling, 2 replies; 40+ messages in thread From: ariga masahiro @ 2007-11-08 1:56 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-08 1:56 ` ariga masahiro @ 2007-11-08 8:23 ` ariga masahiro 2007-11-09 1:25 ` ariga masahiro 2007-11-08 9:13 ` Alok Singh 1 sibling, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-11-08 8:23 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-08 8:23 ` ariga masahiro @ 2007-11-09 1:25 ` ariga masahiro 2007-11-13 1:13 ` ariga masahiro 0 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-11-09 1:25 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-09 1:25 ` ariga masahiro @ 2007-11-13 1:13 ` ariga masahiro 2007-11-16 7:40 ` ariga masahiro 0 siblings, 1 reply; 40+ messages in thread From: ariga masahiro @ 2007-11-13 1:13 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-13 1:13 ` ariga masahiro @ 2007-11-16 7:40 ` ariga masahiro 0 siblings, 0 replies; 40+ messages in thread From: ariga masahiro @ 2007-11-16 7:40 UTC (permalink / raw) To: Gary Thomas, Alok Singh, Andrew Lunn; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* RE: [ECOS] Can't Connect,TCP CHECKSUM INCORRECT 2007-11-08 1:56 ` ariga masahiro 2007-11-08 8:23 ` ariga masahiro @ 2007-11-08 9:13 ` Alok Singh 1 sibling, 0 replies; 40+ messages in thread From: Alok Singh @ 2007-11-08 9:13 UTC (permalink / raw) To: ariga masahiro, Gary Thomas, Andrew Lunn; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [ECOS] Wrongfully compiled code 2007-11-06 8:35 ` Andrew Lunn 2007-11-06 23:47 ` ariga masahiro @ 2008-01-07 1:36 ` ariga masahiro 1 sibling, 0 replies; 40+ messages in thread From: ariga masahiro @ 2008-01-07 1:36 UTC (permalink / raw) To: ecos-discuss 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [ECOS] What functions should I call in ethernet drv ? 2007-10-16 11:08 ` Gary Thomas 2007-10-17 7:41 ` ariga masahiro @ 2007-10-17 8:45 ` ariga masahiro 1 sibling, 0 replies; 40+ messages in thread From: ariga masahiro @ 2007-10-17 8:45 UTC (permalink / raw) To: Gary Thomas; +Cc: ecos-discuss [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2008-01-07 1:36 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-09-14 5:37 [ECOS] Building error on CVS checkout sources ariga masahiro 2007-09-14 8:22 ` [ECOS] " Andrew Lunn 2007-09-14 9:38 ` [ECOS] Virtual Vector Configuration Stefan Sommerfeld 2007-09-14 10:17 ` Nick Garnett 2007-10-15 5:59 ` [ECOS] What functions should I call in ethernet drv ? ariga masahiro 2007-10-15 11:20 ` Gary Thomas 2007-10-16 3:04 ` ariga masahiro 2007-10-16 11:08 ` Gary Thomas 2007-10-17 7:41 ` ariga masahiro 2007-10-17 11:32 ` Gary Thomas 2007-10-18 7:17 ` ariga masahiro [not found] ` <000c01c81151$9add59c0$1c0110ac@ariga> 2007-10-18 11:12 ` Gary Thomas 2007-10-19 4:56 ` ariga masahiro 2007-10-19 9:55 ` Gary Thomas 2007-10-20 6:19 ` ariga masahiro 2007-10-23 8:23 ` ariga masahiro 2007-10-23 8:27 ` Alok Singh 2007-10-23 9:05 ` ariga masahiro 2007-10-25 2:05 ` ariga masahiro 2007-10-30 2:41 ` [ECOS] Can't Connect,TCP CHECKSUM INCORRECT ariga masahiro 2007-10-30 3:02 ` Andrew Lunn 2007-10-30 4:17 ` [ECOS] " Grant Edwards 2007-10-30 8:51 ` Alok Singh 2007-11-06 7:14 ` [ECOS] " ariga masahiro 2007-11-06 7:58 ` Alok Singh 2007-11-06 8:30 ` ariga masahiro 2007-11-06 8:35 ` Andrew Lunn 2007-11-06 23:47 ` ariga masahiro 2007-11-07 1:05 ` ariga masahiro 2007-11-07 7:15 ` ariga masahiro 2007-11-07 8:24 ` ariga masahiro 2007-11-07 11:55 ` Alok Singh 2007-11-08 1:56 ` ariga masahiro 2007-11-08 8:23 ` ariga masahiro 2007-11-09 1:25 ` ariga masahiro 2007-11-13 1:13 ` ariga masahiro 2007-11-16 7:40 ` ariga masahiro 2007-11-08 9:13 ` Alok Singh 2008-01-07 1:36 ` [ECOS] Wrongfully compiled code ariga masahiro 2007-10-17 8:45 ` [ECOS] What functions should I call in ethernet drv ? ariga masahiro
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).