* Re: [ECOS] TCP/IP Stack for eCos @ 1999-05-04 13:51 ` Jay Lepreau 1999-05-04 17:06 ` Fred Fierling 1999-05-05 1:54 ` [ECOS] " Fernando D. Mato Mira 0 siblings, 2 replies; 52+ messages in thread From: Jay Lepreau @ 1999-05-04 13:51 UTC (permalink / raw) To: Fred Fierling; +Cc: ecos-discuss, oskit > It probably would take very little effort to get the OSKit's TCP/IP > stack working in eCos, [...] Do you know if it's a zero copy stack? Yes, I believe it is but can't swear to it. It's FreeBSD's implementation with our wrapping code and environment. Aside: In Sec 5 of the SOSP paper on our site there's a discussion of a networking example (ttcp) which might be enlightening in a general way. In that particular example an extra copy is incurred on the outgoing path because BSD's scatter/gather `mbufs' in the protocol component have to be copied into linear `skbuffs' in the (unchanged) Linux driver component. That is an artifact of the mismatch and would not apply if you allowed yourself to change the Linux drivers or provided other drivers. (For maintenance and philosophical reasons, we generally avoid changing foreign "encapsulated" code in the OSKit.) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] TCP/IP Stack for eCos 1999-05-04 13:51 ` [ECOS] TCP/IP Stack for eCos Jay Lepreau @ 1999-05-04 17:06 ` Fred Fierling 1999-05-04 17:43 ` Brendan Simon 1999-05-05 5:15 ` [ECOS] " Bart Veer 1999-05-05 1:54 ` [ECOS] " Fernando D. Mato Mira 1 sibling, 2 replies; 52+ messages in thread From: Fred Fierling @ 1999-05-04 17:06 UTC (permalink / raw) To: ecos-discuss Jay Lepreau wrote: > > It probably would take very little effort to get the OSKit's TCP/IP > > stack working in eCos, [...] I assume it's written in C? It occurs to me that since eCos is written in C++ that it may be an idea to write its TCP/IP stack in C++ as well. Thoughts? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] TCP/IP Stack for eCos 1999-05-04 17:06 ` Fred Fierling @ 1999-05-04 17:43 ` Brendan Simon 1999-05-05 5:15 ` [ECOS] " Bart Veer 1 sibling, 0 replies; 52+ messages in thread From: Brendan Simon @ 1999-05-04 17:43 UTC (permalink / raw) To: egcs; +Cc: ecos-discuss It depends who is going to maintain the networking stack. It probably makes sense to maintain some C++ wrapper classes to an existing and maintained IP stack (eg. FreeBSD, Linux, etc). Brendan Simon. Fred Fierling wrote: > Jay Lepreau wrote: > > > > It probably would take very little effort to get the OSKit's TCP/IP > > > stack working in eCos, [...] > > I assume it's written in C? > > It occurs to me that since eCos is written in C++ that it may be > an idea to write its TCP/IP stack in C++ as well. Thoughts? ^ permalink raw reply [flat|nested] 52+ messages in thread
* [ECOS] Re: TCP/IP Stack for eCos 1999-05-04 17:06 ` Fred Fierling 1999-05-04 17:43 ` Brendan Simon @ 1999-05-05 5:15 ` Bart Veer 1 sibling, 0 replies; 52+ messages in thread From: Bart Veer @ 1999-05-05 5:15 UTC (permalink / raw) To: fff; +Cc: ecos-discuss >>>>> "Fred" == Fred Fierling <fff@microplex.com> writes: >> > It probably would take very little effort to get the OSKit's TCP/IP >> > stack working in eCos, [...] Fred> I assume it's written in C? Fred> It occurs to me that since eCos is written in C++ that it Fred> may be an idea to write its TCP/IP stack in C++ as well. Fred> Thoughts? If somebody were to write a completely new TCP/IP stack for eCos then C++ would be a reasonable choice of language - or rather a subset of the language, some parts such as exception handling involve rather major code size overheads which are usually unacceptable in embedded systems. In practice I am not sure there is much justification for writing yet another TCP/IP stack, there are plenty of them out there already. Bart Veer // eCos net maintainer ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] TCP/IP Stack for eCos 1999-05-04 13:51 ` [ECOS] TCP/IP Stack for eCos Jay Lepreau 1999-05-04 17:06 ` Fred Fierling @ 1999-05-05 1:54 ` Fernando D. Mato Mira 1 sibling, 0 replies; 52+ messages in thread From: Fernando D. Mato Mira @ 1999-05-05 1:54 UTC (permalink / raw) To: ecos-discuss At 05:06 PM 5/4/99 -0700, you wrote: >Jay Lepreau wrote: > >> > It probably would take very little effort to get the OSKit's TCP/IP >> > stack working in eCos, [...] > >I assume it's written in C? > >It occurs to me that since eCos is written in C++ that it may be >an idea to write its TCP/IP stack in C++ as well. Thoughts? No. Even if there was egcs support for Analog Devices and TI DSPs at least, egcs is not like Green Hills EC++ where you can span the continuum between EC++ and C++ by switching on/off features. Most of our projects run on raw hardware because a kernel is not needed, even if there're multiple tasks running (eg: network, infrared in/out, audio in/out, video in, keyboard, display, `stuff'). Fernando D. Mato Mira Real-Time SW Engineering & Networking Advanced Systems Engineering Division CSEM - Centre Suisse d'Electronique et de Microtechnique Jaquet-Droz 1 Email: matomira AT acm DOT org CH-2007 Neuchatel Phone: +41 (32) 720-5157 Switzerland FAX: +41 (32) 720-5720 http://www.csem.ch/ http://www.vrai.com/ http://ligwww.epfl.ch/matomira.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <"Wed,>]
[parent not found: <5>]
[parent not found: <Jul>]
[parent not found: <2000>]
[parent not found: <11:39:46>]
[parent not found: <+0200>]
[parent not found: <"Mon,>]
[parent not found: <09>]
* [ECOS] Connecting gdb to AEB @ 2000-07-05 2:40 ` Andreas.Karlsson 2000-07-05 2:53 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: Andreas.Karlsson @ 2000-07-05 2:40 UTC (permalink / raw) To: ecos-discuss Hi! While following the "Getting Started with eCos" you shall connect to the board using these gdb commands. (gdb) set remotebaud 38400 (gdb) set mips-force-32bit-saved-gpregs (gdb) target remote COM1 This set mips.. command, should I replace it? Entering the command I get: (gdb) set mips-force-32bit-saved-gpregs Error: No symbol table is loaded. Use the "file" command. /Andreas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Connecting gdb to AEB 2000-07-05 2:40 ` [ECOS] Connecting gdb to AEB Andreas.Karlsson @ 2000-07-05 2:53 ` Jesper Skov 2000-07-05 3:12 ` Robert Erskine 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2000-07-05 2:53 UTC (permalink / raw) To: Andreas.Karlsson; +Cc: ecos-discuss, roberte >>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes: Andreas> Hi! While following the "Getting Started with eCos" you Andreas> shall connect to the board using these gdb commands. Andreas> (gdb) set remotebaud 38400 (gdb) set Andreas> mips-force-32bit-saved-gpregs (gdb) target remote COM1 Ignore that command. It's a documentation bug [Robert, this has been fixed, hasn't it?] Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Connecting gdb to AEB 2000-07-05 2:53 ` Jesper Skov @ 2000-07-05 3:12 ` Robert Erskine 0 siblings, 0 replies; 52+ messages in thread From: Robert Erskine @ 2000-07-05 3:12 UTC (permalink / raw) To: Jesper Skov, Andreas.Karlsson; +Cc: ecos-discuss, roberte At 11:52 AM 7/5/00 +0200, Jesper Skov wrote: >>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes: > >Andreas> Hi! While following the "Getting Started with eCos" you >Andreas> shall connect to the board using these gdb commands. > >Andreas> (gdb) set remotebaud 38400 (gdb) set >Andreas> mips-force-32bit-saved-gpregs (gdb) target remote COM1 > >Ignore that command. It's a documentation bug [Robert, this has been >fixed, hasn't it?] That line appears in 1.3.1 and 1.3.2 (arm). Robert ^ permalink raw reply [flat|nested] 52+ messages in thread
* [ECOS] GDB Download on i386 target hangs @ 2000-10-05 12:33 ` Christian Plessl 2000-10-06 5:15 ` Nick Garnett 0 siblings, 1 reply; 52+ messages in thread From: Christian Plessl @ 2000-10-05 12:33 UTC (permalink / raw) To: ecos-discuss Hi everybody I managed building a (hopefully) working ECOS kernel. Im able to start it using a bootdisk. When looking at the output of COM1: I see the typical cryptic GBD debug protocol. Up to here, everything seems to work ok. When starting GBD or Insight, I'm able to connect to the target, I can even view the registers. But if I try to download an 'application' say one of the HAL tests for instance 'cache' the download stops after sending about 3kB of data! My development system is running Mandrake Linux 7.2 and I'm using the latest ECOS sources from CVS. Does anybody have an idea, why the download immediately stops after downloading some 2-3k of data? Thanks for your help. Chris ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-05 12:33 ` [ECOS] GDB Download on i386 target hangs Christian Plessl @ 2000-10-06 5:15 ` Nick Garnett 2000-10-07 0:55 ` Christian Plessl 0 siblings, 1 reply; 52+ messages in thread From: Nick Garnett @ 2000-10-06 5:15 UTC (permalink / raw) To: ecos-discuss Christian Plessl <cplessl@ee.ethz.ch> writes: > Hi everybody > > I managed building a (hopefully) working ECOS kernel. Im able to start it > using a bootdisk. When looking at the output of COM1: I see the typical > cryptic GBD debug protocol. Up to here, everything seems to work ok. > > When starting GBD or Insight, I'm able to connect to the target, I can even > view the registers. But if I try to download an 'application' say one of > the HAL tests for instance 'cache' the download stops after sending about > 3kB of data! > > My development system is running Mandrake Linux 7.2 and I'm using the > latest ECOS sources from CVS. > > Does anybody have an idea, why the download immediately stops after > downloading some 2-3k of data? > > Thanks for your help. > Have you built the test programs in a separate build tree from the floppy monitor? If not, then it is very easy to get cross-contamination and, for example, end up with you executables being linked to the same memory locations as the monitor. The symptoms you describe are consistent with the monitor being overwritten by the download. -- Nick Garnett, eCos Kernel Architect Red Hat, Cambridge, UK ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-06 5:15 ` Nick Garnett @ 2000-10-07 0:55 ` Christian Plessl 2000-10-09 6:40 ` Nick Garnett 0 siblings, 1 reply; 52+ messages in thread From: Christian Plessl @ 2000-10-07 0:55 UTC (permalink / raw) To: ecos-discuss; +Cc: Nick Garnett Hi Nick and others >Have you built the test programs in a separate build tree from the >floppy monitor? If not, then it is very easy to get >cross-contamination and, for example, end up with you executables being >linked to the same memory locations as the monitor. The symptoms you >describe are consistent with the monitor being overwritten by the >download. Thanks a lot. You guessed right. Now I've built the tests in a different directory, using a i386 target configuration without stubs (is this right?). Now I'm able to download the excecutables. But immediately after the download, when I start the program on the target, I get an SIGILL on the target: GDB Warning: Program received signal SIGILL, Illegal instruction 0x3270 in ?? () at /usr/local/pack/ecoscvs/ecos/packages/services/memalloc /common/current/src/dlmalloc.cxx:1257 It's alway the same address, where the debugger claims to find a illegal instruction. But if I try to disassemble the code at this address in gdb, gdb complains: (gdb) disassemble 0x3270 Error: No function contains specified address. When looking at the symboltable of the elf binary using nm, there is no code located at 3270. I'm somewhat confused and have the following questions: a) Do I have to activate gdb stubs for my application? b) Whats the matter with this error in dlmalloc? Do I need additional configuration for my dynamic allocatable memory on the heap? A suggestion: Unfortunately there is AFAIK no FAQ on ECOS on i386, but when reading the mailing list, I get the impression, that a lot of people do have some trouble, when starting devolopment with the ECOS on i386. What about collecting these questions and answers in a FAQ. Chris ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-07 0:55 ` Christian Plessl @ 2000-10-09 6:40 ` Nick Garnett 2000-10-09 12:50 ` Christian Plessl 0 siblings, 1 reply; 52+ messages in thread From: Nick Garnett @ 2000-10-09 6:40 UTC (permalink / raw) To: Christian Plessl; +Cc: ecos-discuss Christian Plessl <cplessl@ee.ethz.ch> writes: > Hi Nick and others > > >Have you built the test programs in a separate build tree from the > >floppy monitor? If not, then it is very easy to get > >cross-contamination and, for example, end up with you executables being > >linked to the same memory locations as the monitor. The symptoms you > >describe are consistent with the monitor being overwritten by the > >download. > > Thanks a lot. You guessed right. Now I've built the tests in a different > directory, using a i386 target configuration without stubs (is this right?). > Probably not, see later. > Now I'm able to download the excecutables. But immediately after the > download, when I start the program on the target, I get an SIGILL on the > target: > > GDB Warning: > > Program received signal SIGILL, Illegal instruction > 0x3270 in ?? () at /usr/local/pack/ecoscvs/ecos/packages/services/memalloc > /common/current/src/dlmalloc.cxx:1257 What program are you actually running? Do any of the standard test programs run? Do not take too much notice of what GDB says the location is here. It is confused by the address being outside it's known range and is making a guess. > > It's alway the same address, where the debugger claims to find a illegal > instruction. But if I try to disassemble the code at this address in gdb, > gdb complains: > > (gdb) disassemble 0x3270 > Error: No function contains specified address. > Try "x/1i 0x3270". On my machine this gives 0x3270: fild (%edx) which looks like it is halfway through an instruction in the stub monitor. > When looking at the symboltable of the elf binary using nm, there is no > code located at 3270. > > I'm somewhat confused and have the following questions: > > a) Do I have to activate gdb stubs for my application? You have to have GDB stubs included in the executable, there is not sufficient support in the monitor for it to work. This should happen by default, unless you have changed the configuration in any way. Initially, just build the default RAM startup configuration without changing anything, and make sure that something like the kernel tm_basic test works. > b) Whats the matter with this error in dlmalloc? Do I need additional > configuration for my dynamic allocatable memory on the heap? > As I said above, the problem is (probably) not in dlmalloc, that's just GDB's guess at where it is. > > A suggestion: Unfortunately there is AFAIK no FAQ on ECOS on i386, but when > reading the mailing list, I get the impression, that a lot of people do > have some trouble, when starting devolopment with the ECOS on i386. What > about collecting these questions and answers in a FAQ. > That would be a good idea. -- Nick Garnett, eCos Kernel Architect Red Hat, Cambridge, UK ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-09 6:40 ` Nick Garnett @ 2000-10-09 12:50 ` Christian Plessl 2000-10-10 2:46 ` Nick Garnett ` (2 more replies) 0 siblings, 3 replies; 52+ messages in thread From: Christian Plessl @ 2000-10-09 12:50 UTC (permalink / raw) To: ecos-discuss >What program are you actually running? Do any of the standard test >programs run? Do not take too much notice of what GDB says the >location is here. It is confused by the address being outside it's >known range and is making a guess. > >Try "x/1i 0x3270". On my machine this gives > >0x3270: fild (%edx) > >which looks like it is halfway through an instruction in the stub >monitor. Unfortunately, I still have troubles downlaoding. I tried to run many kernel tests, but there is always the same problem. I captured my attempt to run the tm_basicthe test: I configured ecos in a new directory, using the commands ecosconfig new pc ecosconfig check ecosconfig tree make make tests then, chdir to the install/kernel/test directory .. [cplessl@pluto tests]$ i386-elf-gdb -nw tm_basic GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=i386-elf"... (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 0x334e in ?? () at /usr/local/pack/ecos-cvs/ecos/packages/services/memalloc/common/current/src/dlmalloc.cxx:1257 1257 return chunk2mem(victim); (gdb) load Loading section .text, size 0xc118 lma 0x10000 Loading section .rodata, size 0xdfd lma 0x1c118 Loading section .data, size 0x288 lma 0x1cf18 Start address 0x10000 , load size 53661 Transfer rate: 20442 bits/sec, 76 bytes/write. (gdb) continue Continuing. Program received signal SIGILL, Illegal instruction. 0x3273 in ?? () at /usr/local/pack/ecos-cvs/ecos/packages/services/memalloc/common/current/src/dlmalloc.cxx:1257 1257 return chunk2mem(victim); (gdb) x/1i 0x3273 0x3273: (bad) As you see, It seems as if at location 0x3273 was no valid instruction.. Does anybody have an idea how to solve this problem? -- Christian Plessl, Loorenstr. 20, 5443 Niederrohrdorf Tel, Fax: 056 496 41 73 email: cplessl@ee.ethz.ch ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-09 12:50 ` Christian Plessl @ 2000-10-10 2:46 ` Nick Garnett 2000-10-10 3:49 ` Jesper Skov [not found] ` <5.0.0.25.0.20001010121538.009f5e30@imap.ee.ethz.ch> 2 siblings, 0 replies; 52+ messages in thread From: Nick Garnett @ 2000-10-10 2:46 UTC (permalink / raw) To: Christian Plessl; +Cc: ecos-discuss Christian Plessl <cplessl@ee.ethz.ch> writes: > Unfortunately, I still have troubles downlaoding. > I tried to run many kernel tests, but there is always the same problem. > > I captured my attempt to run the tm_basicthe test: > <snip> Up to this point it all looks OK, I duplicated it here and got similar results. But when I continue, the program runs as expected. > > As you see, It seems as if at location 0x3273 was no valid instruction.. > > Does anybody have an idea how to solve this problem? > I think the thing to do is to send me a copy of your tm_basic executable so I can try running it here and see what happens for myself. Send it direct to me, don't include the list, either MIME or UUCP encoding should work. I'm beginning to suspect either a hardware or a toolchain problem. -- Nick Garnett, eCos Kernel Architect Red Hat, Cambridge, UK ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-09 12:50 ` Christian Plessl 2000-10-10 2:46 ` Nick Garnett @ 2000-10-10 3:49 ` Jesper Skov [not found] ` <5.0.0.25.0.20001010121538.009f5e30@imap.ee.ethz.ch> 2 siblings, 0 replies; 52+ messages in thread From: Jesper Skov @ 2000-10-10 3:49 UTC (permalink / raw) To: Christian Plessl; +Cc: ecos-discuss >>>>> "Christian" == Christian Plessl <cplessl@ee.ethz.ch> writes: Christian> (gdb) load Loading section .text, size 0xc118 lma 0x10000 Christian> Loading section .rodata, size 0xdfd lma 0x1c118 Loading Christian> section .data, size 0x288 lma 0x1cf18 Start address 0x10000 Christian> , load size 53661 Transfer rate: 20442 bits/sec, 76 Christian> bytes/write. Christian> As you see, It seems as if at location 0x3273 was no valid Christian> instruction.. Christian> Does anybody have an idea how to solve this problem? Yes, do the download, breakpoint 0x10000 and run. Then step your way through the code using 'si'. Before you start stepping, do: (gdb) disp /i $pc Happy huntin' :) Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <5.0.0.25.0.20001010121538.009f5e30@imap.ee.ethz.ch>]
[parent not found: <wwg8zrwkiht.fsf@balti.cygnus>]
* Re: [ECOS] GDB Download on i386 target hangs [not found] ` <wwg8zrwkiht.fsf@balti.cygnus> @ 2000-10-10 7:28 ` Christian Plessl 2000-10-10 7:58 ` Nick Garnett 0 siblings, 1 reply; 52+ messages in thread From: Christian Plessl @ 2000-10-10 7:28 UTC (permalink / raw) To: ecos-discuss; +Cc: Nick Garnett >Well, I just ran it and it worked perfectly. Excerpt below: [..snip..] hmm, now I'm really confused. At least my toolchain is set up right. Maybe it's really a hardware problem. I'will check on an other pc. >So, it looks like a hardware problem. What exactly is your hardware >setup? One thought is that the tools by default probably build for a >Pentium class machine. You may need to add a compiler option if you >are running on a 386 or 486. Currently I'm running on a Pentium-I 166 (no MMX), 64Mb EDO-RAM, Type Digital Celebris GL-5166ST. Since a have some other boxes around, I will try to run it on another PC. My target system will probably be a 486 single board computer. What compiler switches would this require? Could it be, that my made a configuration mistake, when building the bootdisk? Here my commands: ecosconfig new pc stubs ecosconfig tree make Should be ok, right? Chris -- Christian Plessl <cplessl@ee.ethz.ch> ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-10 7:28 ` Christian Plessl @ 2000-10-10 7:58 ` Nick Garnett 2000-10-11 7:11 ` Christian Plessl 0 siblings, 1 reply; 52+ messages in thread From: Nick Garnett @ 2000-10-10 7:58 UTC (permalink / raw) To: Christian Plessl; +Cc: ecos-discuss Christian Plessl <cplessl@ee.ethz.ch> writes: > >Well, I just ran it and it worked perfectly. Excerpt below: [..snip..] > > hmm, now I'm really confused. At least my toolchain is set up right. Maybe > it's really a hardware problem. I'will check on an other pc. Yes, that's the next obvious step. > > >So, it looks like a hardware problem. What exactly is your hardware > >setup? One thought is that the tools by default probably build for a > >Pentium class machine. You may need to add a compiler option if you > >are running on a 386 or 486. > > Currently I'm running on a Pentium-I 166 (no MMX), 64Mb EDO-RAM, Type > Digital Celebris GL-5166ST. Since a have some other boxes around, I will > try to run it on another PC. > That hardware should be fine. If you have other makes of PC around, try one of those. > > My target system will probably be a 486 single board computer. > What compiler switches would this require? > I'm not entirely sure, and it may not even be necessary if my reading of the documentation is correct. Take a look at the GCC docs for the i386 specific stuff. Adding "-march=i486" to the compile flags should be safe, however. > > Could it be, that my made a configuration mistake, when building the bootdisk? > > Here my commands: > > ecosconfig new pc stubs > ecosconfig tree > make > > Should be ok, right? > Yep, that's correct. The fact that you can download the executable shows that this has been built correctly. If you are still having problems with other PCs, perhaps the next step is for me to send you an executable I built here, and seen whether that runs for you. -- Nick Garnett, eCos Kernel Architect Red Hat, Cambridge, UK ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-10 7:58 ` Nick Garnett @ 2000-10-11 7:11 ` Christian Plessl 2000-10-11 7:20 ` Nick Garnett 0 siblings, 1 reply; 52+ messages in thread From: Christian Plessl @ 2000-10-11 7:11 UTC (permalink / raw) To: ecos-discuss; +Cc: Nick Garnett >If you are still having problems with other PCs, perhaps the next step >is for me to send you an executable I built here, and seen whether >that runs for you. You wont belive it, my troubles disappeared. A friend emailed me a i386 ecos bootsector and it worked. hmm, then I tried to copy my own bootsector on the floppy and it worked as well! The solution: I used another floppy. My first floppy seems to be somewhat broken! I cannot imagine how this can happen, but obviously, the floppydisk is damaged in that way, that ecos with stubs can start and download an executable, but after this it crashes! Lesson learned: never trust a floppy disk ;) Thanks to Nick and Jesper for their help. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-11 7:11 ` Christian Plessl @ 2000-10-11 7:20 ` Nick Garnett 2000-10-12 0:45 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: Nick Garnett @ 2000-10-11 7:20 UTC (permalink / raw) To: Christian Plessl; +Cc: ecos-discuss Christian Plessl <cplessl@ee.ethz.ch> writes: > >If you are still having problems with other PCs, perhaps the next step > >is for me to send you an executable I built here, and seen whether > >that runs for you. > > You wont belive it, my troubles disappeared. A friend emailed me a i386 > ecos bootsector and it worked. hmm, then I tried to copy my own bootsector > on the floppy and it worked as well! The solution: I used another floppy. > My first floppy seems to be somewhat broken! I cannot imagine how this can > happen, but obviously, the floppydisk is damaged in that way, that ecos > with stubs can start and download an executable, but after this it crashes! > Lesson learned: never trust a floppy disk ;) This sounds really wierd. Maybe a strangely formatted floppy? > > Thanks to Nick and Jesper for their help. > No problem, glad you're on your way at last. -- Nick Garnett, eCos Kernel Architect Red Hat, Cambridge, UK ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] GDB Download on i386 target hangs 2000-10-11 7:20 ` Nick Garnett @ 2000-10-12 0:45 ` Jesper Skov 0 siblings, 0 replies; 52+ messages in thread From: Jesper Skov @ 2000-10-12 0:45 UTC (permalink / raw) To: Nick Garnett; +Cc: Christian Plessl, ecos-discuss >>>>> "Nick" == Nick Garnett <nickg@cygnus.co.uk> writes: >> is damaged in that way, that ecos with stubs can start and download >> an executable, but after this it crashes! Lesson learned: never >> trust a floppy disk ;) Nick> This sounds really wierd. Maybe a strangely formatted floppy? Or just a bad sector in the right (wrong) place. I've never understood why, in the PC world, it appears to be a defacto standard _not_ to write-verify floppies. Incredible for a media with such a high failure rate. <rant> Now, when I was a lad and used Amiga DOS, written data was always verified. Yes, it was slower, but one could be fairly confident the floppy actually contained the intended data whenever it was going to be used. I took a lot of flak from PC friends using DOS which wrote data to floppies much faster (verify disabled per default in DOS, but could be enabled). At the time I didn't (unfortunately) grill them about failure rates - my own experience is that the more important the data, and the longer it travels from the source, the greater the chance it'll be toast on arrival. </rant> Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <11:11:19>]
[parent not found: <+0100>]
[parent not found: <Jesper>]
* [ECOS] forwarded message from Peter Graf @ 2000-11-17 2:11 ` Jesper Skov 2000-11-19 23:43 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2000-11-17 2:11 UTC (permalink / raw) To: ecos-discuss To : Jesper Skov <jskov at redhat dot com> Subject : Re: [ECOS] Hitachi SH7709 Serial drivers From : pg-itk at t-online dot de (Peter Graf) Date : Fri, 17 Nov 2000 10:57:21 +0100 References : <pg-itk@t-online.de's message of "Thu, 12 Oct 2000 16:17:54 +0200"><3.0.5.32.20001012161754.008f0560@pop.btx.dtag.de> Hi Jesper, thanks for your help with the Hitachi SH7709A serial drivers. One thing I forgot to report is that the eCos bitrate computation doesn't work correctly under all conditions. For 20 MHz all works well. The table below shows the values computed by hand and the values computed by eCos. Peripheral Clock = 20 MHz: Bitrate [bit/s] n N min. error N eCos error eCos 4800 0 129 0,16% 129 0,16% 9600 0 64 0,16% 64 0,16% 14400 0 42 0,94% 42 0,94% 19200 0 32 -1,36% 31 1,73% 38400 0 15 1,73% 15 1,73% 57600 0 10 -1,36% 9 8,51% 115200 0 4 8,51% 4 8,51% 230400 0 2 -9,58% 1 35,63% For 22 MHz eg. 38400 baud doesn't work reliably under eCos. The table below shows the correct values and the values computed by eCos. (BTW 22 MHz peripheral clock is very useful because it allows low bitrate errors up to 230 kBaud.) Peripheral Clock = 22 MHz: Bitrate [bit/s] n N min. error N error eCos 9600 0 71 -0,54% 70 0,87% 14400 0 47 -0,54% 46 1,58% 19200 0 35 -0,54% 34 2,31% 38400 0 17 -0,54% 16 5,32% 57600 0 11 -0,54% 10 8,51% 115200 0 5 -0,54% 4 19,36% 230400 0 2 -0,54% 1 49,20% I have only worked around by using a fixed table. A parametric macro without the rounding problems seems tricky, if you want to avoid computation at runtime. Peter ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] forwarded message from Peter Graf 2000-11-17 2:11 ` [ECOS] forwarded message from Peter Graf Jesper Skov @ 2000-11-19 23:43 ` Jesper Skov 2000-11-20 5:36 ` [ECOS] Hitachi SH7709A problems Peter Graf 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2000-11-19 23:43 UTC (permalink / raw) To: ecos-discuss Peter> I have only worked around by using a fixed table. A parametric Peter> macro without the rounding problems seems tricky, if you want Peter> to avoid computation at runtime. This is a better solution, IMO. Jesper Index: sh3/current/ChangeLog =================================================================== RCS file: /local/cvsfiles/ecc/ecc/hal/sh/sh3/current/ChangeLog,v retrieving revision 1.2 diff -u -5 -r1.2 ChangeLog --- sh3/current/ChangeLog 2000/11/10 07:33:37 1.2 +++ sh3/current/ChangeLog 2000/11/20 07:40:41 @@ -1,5 +1,9 @@ +2000-11-20 Jesper Skov <jskov@redhat.com> + + * include/mod_regs_ser.h (CYGARC_SCBRR_N): Reduce rounding error. + 2000-11-10 Jesper Skov <jskov@redhat.com> * src/var_misc.c: Add spaces around ... used in ranges. 2000-11-01 Jesper Skov <jskov@redhat.com> Index: sh3/current/include/mod_regs_ser.h =================================================================== RCS file: /local/cvsfiles/ecc/ecc/hal/sh/sh3/current/include/mod_regs_ser.h,v retrieving revision 1.1 diff -u -5 -r1.1 mod_regs_ser.h --- sh3/current/include/mod_regs_ser.h 2000/11/01 10:00:35 1.1 +++ sh3/current/include/mod_regs_ser.h 2000/11/20 07:38:49 @@ -108,20 +108,24 @@ #define CYGARC_SCBRR_PRESCALE(_b_) \ ((((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/1/(_b_))-1)<256) ? 1 : \ (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/4/(_b_))-1)<256) ? 4 : \ (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/16/(_b_))-1)<256) ? 16 : 64) +// Add half the divisor to reduce rounding errors to .5 +#define CYGARC_SCBRR_ROUNDING(_b_) \ + 16*CYGARC_SCBRR_PRESCALE(_b_)*(_b_) + // These two macros provide the static values we need to stuff into the // registers. #define CYGARC_SCBRR_CKSx(_b_) \ ((1 == CYGARC_SCBRR_PRESCALE(_b_)) ? 0 : \ (4 == CYGARC_SCBRR_PRESCALE(_b_)) ? 1 : \ (16 == CYGARC_SCBRR_PRESCALE(_b_)) ? 2 : 3) #define CYGARC_SCBRR_N(_b_) \ (((_b_) < 4800) ? 0 : \ ((_b_) > 115200) ? 0 : \ - ((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/CYGARC_SCBRR_PRESCALE(_b_)/(_b_))-1)) + (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED+CYGARC_SCBRR_ROUNDING(_b_))/32/CYGARC_SCBRR_PRESCALE(_b_)/(_b_))-1)) //++++++ Module IRDA +++++++++++++++++++++++++++++++++++++++++++++++++++++++ #ifdef CYGARC_SH_MOD_IRDA Index: sh4/current/ChangeLog =================================================================== RCS file: /local/cvsfiles/ecc/ecc/hal/sh/sh4/current/ChangeLog,v retrieving revision 1.3 diff -u -5 -r1.3 ChangeLog --- sh4/current/ChangeLog 2000/11/09 11:23:04 1.3 +++ sh4/current/ChangeLog 2000/11/20 07:41:38 @@ -1,5 +1,9 @@ +2000-11-20 Jesper Skov <jskov@redhat.com> + + * include/mod_regs_ser.h (CYGARC_SCBRR_N): Reduce rounding error. + 2000-11-09 Jesper Skov <jskov@redhat.com> * include/mod_regs_ubc.h: Correct definitions. * include/mod_7750.h (CYGARC_SH_MOD_UBC): Defined. Index: sh4/current/include/mod_regs_ser.h =================================================================== RCS file: /local/cvsfiles/ecc/ecc/hal/sh/sh4/current/include/mod_regs_ser.h,v retrieving revision 1.1 diff -u -5 -r1.1 mod_regs_ser.h --- sh4/current/include/mod_regs_ser.h 2000/11/01 10:00:37 1.1 +++ sh4/current/include/mod_regs_ser.h 2000/11/20 07:41:09 @@ -105,20 +105,24 @@ #define CYGARC_SCBRR_PRESCALE(_b_) \ ((((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/1/(_b_))-1)<256) ? 1 : \ (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/4/(_b_))-1)<256) ? 4 : \ (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/16/(_b_))-1)<256) ? 16 : 64) +// Add half the divisor to reduce rounding errors to .5 +#define CYGARC_SCBRR_ROUNDING(_b_) \ + 16*CYGARC_SCBRR_PRESCALE(_b_)*(_b_) + // These two macros provide the static values we need to stuff into the // registers. #define CYGARC_SCBRR_CKSx(_b_) \ ((1 == CYGARC_SCBRR_PRESCALE(_b_)) ? 0 : \ (4 == CYGARC_SCBRR_PRESCALE(_b_)) ? 1 : \ (16 == CYGARC_SCBRR_PRESCALE(_b_)) ? 2 : 3) #define CYGARC_SCBRR_N(_b_) \ (((_b_) < 4800) ? 0 : \ ((_b_) > 115200) ? 0 : \ - ((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED/32/CYGARC_SCBRR_PRESCALE(_b_)/(_b_))-1)) + (((CYGHWR_HAL_SH_ONCHIP_PERIPHERAL_SPEED+CYGARC_SCBRR_ROUNDING(_b_))/32/CYGARC_SCBRR_PRESCALE(_b_)/(_b_))-1)) //++++++ Module IRDA +++++++++++++++++++++++++++++++++++++++++++++++++++++++ #ifdef CYGARC_SH_MOD_IRDA ^ permalink raw reply [flat|nested] 52+ messages in thread
* [ECOS] Hitachi SH7709A problems 2000-11-19 23:43 ` Jesper Skov @ 2000-11-20 5:36 ` Peter Graf 2000-11-20 6:58 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: Peter Graf @ 2000-11-20 5:36 UTC (permalink / raw) To: ecos-discuss Jesper wrote: [baudrate errors] >Peter> I have only worked around by using a fixed table. A parametric >Peter> macro without the rounding problems seems tricky, if you want >Peter> to avoid computation at runtime. > >This is a better solution, IMO. [New macro definition] Yes it is, thanks very much! At the moment I am struggling with two serious problems on the SH7709A target: 1. When I use the GDB stub compiled from the latest CVS sources, I can only set one breakpoint. If I remove it and set the next and so on, everything works fine. If I don't remove all old breakpoints before continuing, the target keeps on running and ignores further breakpoint(s). An older stub, compiled from sources probably around August, works fine. Could be related to the use of the UBC, but I haven't been able to figure out. 2. ROMs compiled in ROMRAM startup mode don't work anymore, although the pure ROM versions work. The ROMRAM feature has also worked fine using earlier sources. Has anyone else exprienced the same? Thanks. Peter ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Hitachi SH7709A problems 2000-11-20 5:36 ` [ECOS] Hitachi SH7709A problems Peter Graf @ 2000-11-20 6:58 ` Jesper Skov 2000-11-20 7:20 ` Peter Graf 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2000-11-20 6:58 UTC (permalink / raw) To: Peter Graf; +Cc: ecos-discuss >>>>> "Peter" == Peter Graf <pg-itk@t-online.de> writes: Peter> Jesper wrote: [baudrate errors] Peter> I have only worked around by using a fixed table. A parametric Peter> macro without the rounding problems seems tricky, if you want Peter> to avoid computation at runtime. >> This is a better solution, IMO. Peter> [New macro definition] Peter> Yes it is, thanks very much! Good. Peter> At the moment I am struggling with two serious problems on the Peter> SH7709A target: Peter> 1. When I use the GDB stub compiled from the latest CVS Peter> sources, I can only set one breakpoint. If I remove it and set Peter> the next and so on, everything works fine. If I don't remove Peter> all old breakpoints before continuing, the target keeps on Peter> running and ignores further breakpoint(s). An older stub, Peter> compiled from sources probably around August, works fine. Could Peter> be related to the use of the UBC, but I haven't been able to Peter> figure out. Hm, no clue. Maybe because you use a new(er) version of GDB which uses stub breakpoints, which I believe were added to the stub recently by Drew. Only, I don't think they should affect the HALs unless they claim to support it somehow. I haven't looked at it. In mod_7709a.h you can comment out the UBC definition, and the stub will fall back to the old way of single-stepping. But that should be the only effect. I can't think of any reason breakpoints should be involved. Your target is indeed a 7709A, right? The UBCs differ between the various CPU models. Peter> 2. ROMs compiled in ROMRAM startup mode don't work anymore, Peter> although the pure ROM versions work. The ROMRAM feature has Peter> also worked fine using earlier sources. I may have broken something when the code was split into variant HALs. I probably won't have time to look at it until next year though - so if it's something you need working ASAP, you are probably best of (a) figuring out why it fails on your own, or (b) revert to the older codebase. Sorry. Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Hitachi SH7709A problems 2000-11-20 6:58 ` Jesper Skov @ 2000-11-20 7:20 ` Peter Graf 2001-01-03 2:48 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: Peter Graf @ 2000-11-20 7:20 UTC (permalink / raw) To: ecos-discuss At 15:58 20.11.00 +0100, Jesper Skov wrote: >Peter> 1. When I use the GDB stub compiled from the latest CVS >Peter> sources, I can only set one breakpoint. If I remove it and set >Peter> the next and so on, everything works fine. If I don't remove >Peter> all old breakpoints before continuing, the target keeps on >Peter> running and ignores further breakpoint(s). An older stub, >Peter> compiled from sources probably around August, works fine. Could >Peter> be related to the use of the UBC, but I haven't been able to >Peter> figure out. > >Hm, no clue. Maybe because you use a new(er) version of GDB which uses >stub breakpoints, which I believe were added to the stub recently by >Drew. Only, I don't think they should affect the HALs unless they >claim to support it somehow. I haven't looked at it. > >In mod_7709a.h you can comment out the UBC definition, and the stub >will fall back to the old way of single-stepping. But that should be >the only effect. I can't think of any reason breakpoints should be >involved. Since single-stepping also doesn't seem work anymore, I will try removing the UBC definition, thanks for the hint. >Your target is indeed a 7709A, right? Exactly. >Peter> 2. ROMs compiled in ROMRAM startup mode don't work anymore, >Peter> although the pure ROM versions work. The ROMRAM feature has >Peter> also worked fine using earlier sources. > >I may have broken something when the code was split into variant >HALs. I probably won't have time to look at it until next year though >- so if it's something you need working ASAP, you are probably best of >(a) figuring out why it fails on your own, or (b) revert to the older >codebase. Sorry. I've already started (a), but debugging by burning Flashroms is quite tough. I'll let you know if I find something. Thanks Peter ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Hitachi SH7709A problems 2000-11-20 7:20 ` Peter Graf @ 2001-01-03 2:48 ` Jesper Skov 2001-01-12 3:45 ` Peter Graf 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2001-01-03 2:48 UTC (permalink / raw) To: Peter Graf; +Cc: ecos-discuss >>>>> "Peter" == Peter Graf <pg-itk@t-online.de> writes: Peter> 2. ROMs compiled in ROMRAM startup mode don't work anymore, Peter> although the pure ROM versions work. The ROMRAM feature has Peter> also worked fine using earlier sources. >> I may have broken something when the code was split into variant >> HALs. I probably won't have time to look at it until next year >> though - so if it's something you need working ASAP, you are >> probably best of (a) figuring out why it fails on your own, or (b) >> revert to the older codebase. Sorry. Peter> I've already started (a), but debugging by burning Flashroms is Peter> quite tough. I'll let you know if I find something. Did you find the problem? It was the initial jump instruction at the image entry address. It was fixed in late December in the CVS tree. Cheers, Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Hitachi SH7709A problems 2001-01-03 2:48 ` Jesper Skov @ 2001-01-12 3:45 ` Peter Graf 0 siblings, 0 replies; 52+ messages in thread From: Peter Graf @ 2001-01-12 3:45 UTC (permalink / raw) To: ecos-discuss Hi Jesper, sorry for the late reply, have been away from office for some time. >Peter> 2. ROMs compiled in ROMRAM startup mode don't work anymore, >Peter> although the pure ROM versions work. The ROMRAM feature has >Peter> also worked fine using earlier sources. >>> I may have broken something when the code was split into variant >>> HALs. I probably won't have time to look at it until next year >>> though - so if it's something you need working ASAP, you are >>> probably best of (a) figuring out why it fails on your own, or (b) >>> revert to the older codebase. Sorry. > >Peter> I've already started (a), but debugging by burning Flashroms is >Peter> quite tough. I'll let you know if I find something. > >Did you find the problem? It was the initial jump instruction at the >image entry address. It was fixed in late December in the CVS tree. Thank you very much for fixing the ROMRAM problem. But no I didn't find it, seems I've looked at the wrong places. I gave up the "ROMRAM" target. I started writing flash drivers and using Redboot instead. Which I have now running (using a serial port) on our hardware. I load a "RAM" binary from FIS, which is a good replacement for "ROMRAM" (and more :-)). Pretty feature to be able to use the same code for debugging in RAM and for the production version loaded from flash. All the best Peter ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <20:29:19>]
[parent not found: <+0900>]
* [ECOS] Help me !!, Hello world on out target @ 2000-11-20 3:28 ` °ÃÃç¿ë 2000-11-20 3:43 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: ðÃÂÃÂçÿë @ 2000-11-20 3:28 UTC (permalink / raw) To: ecos-discuss Hi All! I am porting eCos on our target which is simmilar with CMA230. Now, I am working with ecos-1.3.1 (net-release, 27-03-2000). I was building and testing GDB stubs ROM. Downloading is OK, but RAM application is not executed. CPU core of our target is ARM7 and support FIQ. But IRQ is not supported. Is there anything to change in HAL for FIQ ? While downloading, Is GDB Stub ROM operated by polled or interrupt ? Thanks a lot ! ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Help me !!, Hello world on out target 2000-11-20 3:28 ` [ECOS] Help me !!, Hello world on out target °ÃÃç¿ë @ 2000-11-20 3:43 ` Jesper Skov 2000-11-20 5:54 ` Lewin A.R.W. Edwards 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2000-11-20 3:43 UTC (permalink / raw) To: ðÃÂÃÂçÿë Cc: ecos-discuss [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 925 bytes --] >>>>> "°ÃÃç¿ë" == °ÃÃç¿ë <koh@bdtel.com> writes: °ÃÃç¿ë> Hi All! I am porting eCos on our target which is simmilar °ÃÃç¿ë> with CMA230. Now, I am working with ecos-1.3.1 (net-release, °ÃÃç¿ë> 27-03-2000). I was building and testing GDB stubs ROM. You should use the CVS tree instead. 1.3.1 is way old now. °ÃÃç¿ë> Downloading is OK, but RAM application is not executed. CPU °ÃÃç¿ë> core of our target is ARM7 and support FIQ. But IRQ is not °ÃÃç¿ë> supported. Is there anything to change in HAL for FIQ ? Yes. I can't tell you what off hand though. But I'm sure you'll need to change some things. °ÃÃç¿ë> While downloading, Is GDB Stub ROM operated by polled or °ÃÃç¿ë> interrupt ? Thanks a lot ! Polled mode only. Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Help me !!, Hello world on out target 2000-11-20 3:43 ` Jesper Skov @ 2000-11-20 5:54 ` Lewin A.R.W. Edwards 2000-11-20 6:43 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: Lewin A.R.W. Edwards @ 2000-11-20 5:54 UTC (permalink / raw) To: ecos-discuss [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 758 bytes --] >°ÃÃç¿ë> with CMA230. Now, I am working with ecos-1.3.1 (net-release, > >You should use the CVS tree instead. 1.3.1 is way old now. I'm using 1.3.1 too (and can't get the TCP/IP stuff installed). Will a CVS checkout of today give the complete OS including TCP/IP stack or is the networking stuff in a different repository? Also, is it possible to build the Win32-hosted graphical administration tool for the latest eCos version? I like that tool very much. Lewin A.R.W. Edwards (Embedded Engineer) Got any Commodore 16 or VIC-20 hardware, cartridges, tapes? Visit http://www.larwe.com/vintage/ ================================================ Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Help me !!, Hello world on out target 2000-11-20 5:54 ` Lewin A.R.W. Edwards @ 2000-11-20 6:43 ` Jesper Skov 2000-11-21 22:00 ` Jonathan Larmour 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2000-11-20 6:43 UTC (permalink / raw) To: Lewin A.R.W. Edwards; +Cc: ecos-discuss >>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes: >> =B0=ED=C0=E7=BF=EB> with CMA230. Now, I am working with >> ecos-1.3.1= Lewin> (net-release, >> You should use the CVS tree instead. 1.3.1 is way old now. Lewin> I'm using 1.3.1 too (and can't get the TCP/IP stuff Lewin> installed). Will a CVS= =20 checkout of today give the complete Lewin> OS including TCP/IP stack or is the=20 networking stuff in a Lewin> different repository? I think it's all in the same repo now, but I must admit that I'm not 100% sure. Lewin> Also, is it possible to build the Win32-hosted graphical Lewin> administration=20 tool for the latest eCos version? I like that Lewin> tool very much. I believe a new version has been uploaded on sourceware somewhere that handles the new CDL stuff. Again, I'm not sure though. Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Help me !!, Hello world on out target 2000-11-20 6:43 ` Jesper Skov @ 2000-11-21 22:00 ` Jonathan Larmour 0 siblings, 0 replies; 52+ messages in thread From: Jonathan Larmour @ 2000-11-21 22:00 UTC (permalink / raw) To: Jesper Skov; +Cc: Lewin A.R.W. Edwards, ecos-discuss Jesper Skov wrote: > > >>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes: > > >> =B0=ED=C0=E7=BF=EB> with CMA230. Now, I am working with > >> ecos-1.3.1= > Lewin> (net-release, > >> You should use the CVS tree instead. 1.3.1 is way old now. > > Lewin> I'm using 1.3.1 too (and can't get the TCP/IP stuff > Lewin> installed). Will a CVS= =20 checkout of today give the complete > Lewin> OS including TCP/IP stack or is the=20 networking stuff in a > Lewin> different repository? > > I think it's all in the same repo now, but I must admit that I'm not > 100% sure. It is in the same repository but you have to use separate steps to get it. It's described at http://sources.redhat.com/anoncvs.html under "Optional networking support". > Lewin> Also, is it possible to build the Win32-hosted graphical > Lewin> administration=20 tool for the latest eCos version? I like that > Lewin> tool very much. > > I believe a new version has been uploaded on sourceware somewhere that > handles the new CDL stuff. Again, I'm not sure though. It has indeed. Again there's a link at http://sources.redhat.com/anoncvs.html Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <09:24:40>]
[parent not found: <-0500>]
* [ECOS] gdb/insight questions @ 2000-12-05 6:26 ` Lewin A.R.W. Edwards 2000-12-05 7:22 ` Jesper Skov 2000-12-05 20:15 ` Jonathan Larmour 0 siblings, 2 replies; 52+ messages in thread From: Lewin A.R.W. Edwards @ 2000-12-05 6:26 UTC (permalink / raw) To: ecos-discuss Well, practically everything works - I can compile apps, I can connect to the target board and I can load programs. I have a couple of gdb questions though. Q1: I don't understand where console I/O goes by default; I would have assumed to the gdb console but it seems not? My hello world app has a printf in it; by default, where does this output go? Can someone please verify to me that this is the right process: * compile * arm-elf-gdb -nw a.out * (gdb) set remotebaud 38400 * (gdb) target remote com1 * (gdb) load * (gdb) continue I also tried enabling serial port 2 and fprintfing a message to /dev/ttys2 or whatever it is, and I get my output message on the second port so the program is definitely running (yay!). Q2: (Relatively minor) I can only run command-line gdb, not insight. I even tried recompiling insight but when I run it I get an MB_ICONSTOP messagebox that says: Can't find a usable main.tcl in the following directories: C:/CYGWIN/TOOLS/share/gdbctl C:/CYGWIN/TOOLS/gdbtcl C:/CYGWIN/TOOLS/gdb/gdbtk/library C:/CYGWIN/TOOLS/gdb1.0/gdbtk/library C:/CYGWIN/TOOLS/share/gdbtcl/main.tcl: can't read "errMsg": no such variable can't read "errMsg": no such variable while executing "tk_messageBox -title Error -message "Could not find the lwidgets libraries. Got nameofexec: [info nameofexecutable] Error(s) were :\n$errMsg" -icon e..." invoked from within "if {![find_iwidgets_library]} { tk_messageBox.................... (lots more stuff). I can run native insight with no problems. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] gdb/insight questions 2000-12-05 6:26 ` [ECOS] gdb/insight questions Lewin A.R.W. Edwards @ 2000-12-05 7:22 ` Jesper Skov 2000-12-05 7:32 ` Lewin A.R.W. Edwards 2000-12-05 20:15 ` Jonathan Larmour 1 sibling, 1 reply; 52+ messages in thread From: Jesper Skov @ 2000-12-05 7:22 UTC (permalink / raw) To: Lewin A.R.W. Edwards; +Cc: ecos-discuss >>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes: Lewin> Well, practically everything works - I can compile apps, I can Lewin> connect to the target board and I can load programs. I have a Lewin> couple of gdb questions though. Lewin> Q1: I don't understand where console I/O goes by default; I Lewin> would have assumed to the gdb console but it seems not? My Lewin> hello world app has a printf in it; by default, where does this Lewin> output go? Can someone please verify to me that this is the Lewin> right process: It is. Problem is that GDB hides any output that is not in O-packet format. HAL diag will normally wrap ASCII output in O-packets, but raw serial output does not (for obvious reasons). If you need raw ASCII output via serial I suggest you just use that extra serial line. Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] gdb/insight questions 2000-12-05 7:22 ` Jesper Skov @ 2000-12-05 7:32 ` Lewin A.R.W. Edwards 0 siblings, 0 replies; 52+ messages in thread From: Lewin A.R.W. Edwards @ 2000-12-05 7:32 UTC (permalink / raw) To: Jesper Skov; +Cc: ecos-discuss Hi Jesper, >Lewin> Q1: I don't understand where console I/O goes by default; I >Lewin> would have assumed to the gdb console but it seems not? My > >If you need raw ASCII output via serial I suggest you just use that >extra serial line. OK, this is no problem. I was just puzzled when I got no "hello world" with printf. Thanks for the explanation. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] gdb/insight questions 2000-12-05 6:26 ` [ECOS] gdb/insight questions Lewin A.R.W. Edwards 2000-12-05 7:22 ` Jesper Skov @ 2000-12-05 20:15 ` Jonathan Larmour 2000-12-06 4:13 ` Lewin A.R.W. Edwards 1 sibling, 1 reply; 52+ messages in thread From: Jonathan Larmour @ 2000-12-05 20:15 UTC (permalink / raw) To: Lewin A.R.W. Edwards; +Cc: ecos-discuss, Jesper Skov "Lewin A.R.W. Edwards" wrote: > > Q1: I don't understand where console I/O goes by default; I would have > assumed to the gdb console but it seems not? My hello world app has a > printf in it; by default, where does this output go? Can someone please > verify to me that this is the right process: > > * compile > * arm-elf-gdb -nw a.out > * (gdb) set remotebaud 38400 > * (gdb) target remote com1 > * (gdb) load > * (gdb) continue Jesper then said "Problem is that GDB hides any output that is not in O-packet format. HAL diag will normally wrap ASCII output in O-packets, but raw serial output does not (for obvious reasons)." but isn't the problem above that printf() isn't working by default? Or has Lewin changed the configuration from the default to use haldiag, to serial drivers; or changed haldiag to output packets that aren't O-packetized. My point is that *by default* printf() should work and display output on GDB. > I also tried enabling serial port 2 and fprintfing a message to /dev/ttys2 > or whatever it is, and I get my output message on the second port so the > program is definitely running (yay!). > > Q2: (Relatively minor) I can only run command-line gdb, not insight. I even > tried recompiling insight but when I run it I get an MB_ICONSTOP messagebox > that says: > > Can't find a usable main.tcl in the following directories: > C:/CYGWIN/TOOLS/share/gdbctl C:/CYGWIN/TOOLS/gdbtcl > C:/CYGWIN/TOOLS/gdb/gdbtk/library C:/CYGWIN/TOOLS/gdb1.0/gdbtk/library > > C:/CYGWIN/TOOLS/share/gdbtcl/main.tcl: can't read "errMsg": no such variable > can't read "errMsg": no such variable > while executing "tk_messageBox -title Error -message "Could not find the > lwidgets libraries. Got nameofexec: [info nameofexecutable] > Error(s) were :\n$errMsg" -icon e..." > invoked from within > "if {![find_iwidgets_library]} { > tk_messageBox.................... > > (lots more stuff). I seem to recall this coming up before. Are you using Win98? See my earlier reply at http://sources.redhat.com/ml/ecos-discuss/2000-10/msg00137.html which recommends to upgrade both your cygwin and insight versions. [ I decided not to update the FAQ in the end because this isn't sufficiently frequent, and will be less so as time goes on. ] Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] gdb/insight questions 2000-12-05 20:15 ` Jonathan Larmour @ 2000-12-06 4:13 ` Lewin A.R.W. Edwards 0 siblings, 0 replies; 52+ messages in thread From: Lewin A.R.W. Edwards @ 2000-12-06 4:13 UTC (permalink / raw) To: Jonathan Larmour; +Cc: ecos-discuss Hi Jonathan, > > Q1: I don't understand where console I/O goes by default; I would have > > assumed to the gdb console but it seems not? My hello world app has a > >Jesper then said "Problem is that GDB hides any output that is not in > >but isn't the problem above that printf() isn't working by default? Or has >Lewin changed the configuration from the default to use haldiag, to serial Well, I did not change anything related to this THAT I KNOW OF, but I have since generated a new "from scratch" .ecc and now printf works like I expected. I guess my configuration was wrong or corrupt. BTW, the config tool seems to be quite unstable when saving .ecc files. It seems to be slightly more stable if one collapses all the controls in the left-hand pane before attempting to save the .ecc. > > Can't find a usable main.tcl in the following directories: > > C:/CYGWIN/TOOLS/share/gdbctl C:/CYGWIN/TOOLS/gdbtcl > > C:/CYGWIN/TOOLS/gdb/gdbtk/library C:/CYGWIN/TOOLS/gdb1.0/gdbtk/library > >I seem to recall this coming up before. Are you using Win98? See my earlier >reply at http://sources.redhat.com/ml/ecos-discuss/2000-10/msg00137.html >which recommends to upgrade both your cygwin and insight versions. Guilty as charged. If this is a known problem and not just my own personal ill karma then I will leave things as they are, I think, rather than trying to wrestle with the whole toolchain issue again. I might downgrade to regular non-insight gdb so I don't have to remember -nw all the time. === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [ECOS] gdb/insight questions @ 2000-12-05 22:43 ` Natarajan, Mekala (CTS) 2000-12-06 1:42 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: Natarajan, Mekala (CTS) @ 2000-12-05 22:43 UTC (permalink / raw) To: 'Jonathan Larmour'; +Cc: 'ecos-discuss@sourceware.cygnus.com' hi, i am using i386pc target. For me printf() is working fine and it is displaying output in GDB console.. -----Original Message----- From: Jonathan Larmour [ mailto:jlarmour@cygnus.co.uk ] Sent: Wednesday, December 06, 2000 9:45 AM To: Lewin A.R.W. Edwards Cc: ecos-discuss@sourceware.cygnus.com; Jesper Skov Subject: Re: [ECOS] gdb/insight questions "Lewin A.R.W. Edwards" wrote: > > Q1: I don't understand where console I/O goes by default; I would have > assumed to the gdb console but it seems not? My hello world app has a > printf in it; by default, where does this output go? Can someone please > verify to me that this is the right process: > > * compile > * arm-elf-gdb -nw a.out > * (gdb) set remotebaud 38400 > * (gdb) target remote com1 > * (gdb) load > * (gdb) continue Jesper then said "Problem is that GDB hides any output that is not in O-packet format. HAL diag will normally wrap ASCII output in O-packets, but raw serial output does not (for obvious reasons)." but isn't the problem above that printf() isn't working by default? Or has Lewin changed the configuration from the default to use haldiag, to serial drivers; or changed haldiag to output packets that aren't O-packetized. My point is that *by default* printf() should work and display output on GDB. > I also tried enabling serial port 2 and fprintfing a message to /dev/ttys2 > or whatever it is, and I get my output message on the second port so the > program is definitely running (yay!). > > Q2: (Relatively minor) I can only run command-line gdb, not insight. I even > tried recompiling insight but when I run it I get an MB_ICONSTOP messagebox > that says: > > Can't find a usable main.tcl in the following directories: > C:/CYGWIN/TOOLS/share/gdbctl C:/CYGWIN/TOOLS/gdbtcl > C:/CYGWIN/TOOLS/gdb/gdbtk/library C:/CYGWIN/TOOLS/gdb1.0/gdbtk/library > > C:/CYGWIN/TOOLS/share/gdbtcl/main.tcl: can't read "errMsg": no such variable > can't read "errMsg": no such variable > while executing "tk_messageBox -title Error -message "Could not find the > lwidgets libraries. Got nameofexec: [info nameofexecutable] > Error(s) were :\n$errMsg" -icon e..." > invoked from within > "if {![find_iwidgets_library]} { > tk_messageBox.................... > > (lots more stuff). I seem to recall this coming up before. Are you using Win98? See my earlier reply at http://sources.redhat.com/ml/ecos-discuss/2000-10/msg00137.html which recommends to upgrade both your cygwin and insight versions. [ I decided not to update the FAQ in the end because this isn't sufficiently frequent, and will be less so as time goes on. ] Jifl -- Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS Tel: +44 (1223) 728762 "Plan to be spontaneous tomorrow." || These opinions are all my own fault This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] gdb/insight questions 2000-12-05 22:43 ` Natarajan, Mekala (CTS) @ 2000-12-06 1:42 ` Jesper Skov 2000-12-06 4:47 ` Lewin A.R.W. Edwards 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2000-12-06 1:42 UTC (permalink / raw) To: Natarajan, Mekala (CTS) Cc: 'Jonathan Larmour', 'ecos-discuss@sourceware.cygnus.com' >>>>> "Natarajan," == Natarajan, Mekala (CTS) <NMekala@CHN.CTS-CORP.COM> writes: Natarajan,> hi, i am using i386pc target. For me printf() is working Natarajan,> fine and it is displaying output in GDB console.. Curiously, the behavior is different on different platforms/versions of GDB. jifl> Jesper then said "Problem is that GDB hides any output jifl> that is not in O-packet format. HAL diag will normally jifl> wrap ASCII output in O-packets, but raw serial output does jifl> not (for obvious reasons)." jifl> but isn't the problem above that printf() isn't working by jifl> default? Or has Lewin changed the configuration from the jifl> default to use haldiag, to serial drivers; or changed jifl> haldiag to output packets that aren't O-packetized. jifl> My point is that *by default* printf() should work and jifl> display output on GDB. Hm, you are right. Lewin, you can make sure by enabling remotedebug in GDB - that will show you if the incoming data is in raw or O-packet format. I'm not sure why it shouldn't be in O-packet format, unless you are writing to a raw device (fprintf? - do we actually have that?) Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] gdb/insight questions 2000-12-06 1:42 ` Jesper Skov @ 2000-12-06 4:47 ` Lewin A.R.W. Edwards 0 siblings, 0 replies; 52+ messages in thread From: Lewin A.R.W. Edwards @ 2000-12-06 4:47 UTC (permalink / raw) To: Jesper Skov, Natarajan, Mekala (CTS) Cc: 'Jonathan Larmour', 'ecos-discuss@sourceware.cygnus.com' >I'm not sure why it shouldn't be in O-packet format, unless you are >writing to a raw device (fprintf? - do we actually have that?) Yes, you have fprintf. Sssh, it is working fine for me, don't jinx it by saying it shouldn't work ;) === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* [ECOS] Really dumb newbie question @ 2001-01-10 16:42 Tim Noell 2001-01-10 17:48 ` Lewin A.R.W. Edwards 0 siblings, 1 reply; 52+ messages in thread From: Tim Noell @ 2001-01-10 16:42 UTC (permalink / raw) To: ecos-discuss Hi eCos Users: I'm new to eCos and new to this list. Please don't skewer me for my dumb newbie questions - I'll come up to speed fast enough ... I've searched the archives and not found anything on this, so here goes: I've just installed eCos v1.3.1 on my Windoze NT 4.0 machine. When I invoke the Configuration Tool I get the following error: "The ordinal 6880 could not be located in the dynamic link library MFC42.DLL" I get a similar error when I invoke the Package Administration Tool. Looks like I need a later version of MFC42.DLL - ? Which one? Where do I get it? BTW, do very many of you use the Windoze host? Most are on a Linux host, I'm guessing ... Sorry for the newbie-ness of my questions, and THANKS in advance! Tim // Tim Noell // Specialist, Business Printer Division // Lexmark International, Inc. // "Only dead fish go with the flow." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-10 16:42 [ECOS] Really dumb newbie question Tim Noell @ 2001-01-10 17:48 ` Lewin A.R.W. Edwards 2001-01-10 23:58 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: Lewin A.R.W. Edwards @ 2001-01-10 17:48 UTC (permalink / raw) To: Tim Noell; +Cc: ecos-discuss Hi Tim, >I've just installed eCos v1.3.1 on my Windoze NT 4.0 machine. When I >invoke the Configuration Tool I get the following error: >"The ordinal 6880 could not be located in the dynamic link library MFC42.DLL" I had this problem when I used a buggy installer - I think it was either OrCAD 9.1 or Eudora 4.3 - that overwrote my MFC42.DLL with an old one. Checking my hard drive I find several versions: OrCAD - 940,304 bytes, 06/30/98 07:33a WINDOWS\SYSTEM - 995,383 bytes 04/26/99 11:00p Sony HotBurn - 954,640 bytes 11/04/97 01:12a HP Network Printer - 995,383 bytes 08/19/99 06:26p I can email you the WINDOWS\SYSTEM copy if you want. >BTW, do very many of you use the Windoze host? Most are on a Linux host, I'm >guessing ... It is much, much, much more convenient to me to use Windows as my host, so I'll only move to Linux if it becomes absolutely necessary. Having said that, I will admit that if you can either do all your non-eCos work in it, or dedicate a PC to it, Linux is definitely the platform of choice. For me it boils down to which set of hoops I'd rather jump through, and the Windows-colored hoops blaze with a slightly cooler flame. I work much better when I can just close my laptop and take everything home with me. There are some gotchas in Windows and in particular you might find, as I have, that the GUI configuration tool is REALLY unstable on Windows, but since I spend much more than 99% of my time in a text editor and gdb, that isn't such a big issue. Just remember to make backup copies of your .ecc files before attempting any editing, since the config tool crashes very often (for me at least) when saving edits to an existing file. >Sorry for the newbie-ness of my questions, and THANKS in advance! My questions in this list are of the same caliber, so don't be ashamed ;) === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-10 17:48 ` Lewin A.R.W. Edwards @ 2001-01-10 23:58 ` Jesper Skov 2001-01-11 6:05 ` Lewin A.R.W. Edwards 0 siblings, 1 reply; 52+ messages in thread From: Jesper Skov @ 2001-01-10 23:58 UTC (permalink / raw) To: Lewin A.R.W. Edwards; +Cc: Tim Noell, ecos-discuss >>>>> "Lewin" == Lewin A R W Edwards <larwe@larwe.com> writes: Lewin> OrCAD - 940,304 bytes, 06/30/98 07:33a WINDOWS\SYSTEM - 995,383 Lewin> bytes 04/26/99 11:00p Sony HotBurn - 954,640 bytes 11/04/97 Lewin> 01:12a HP Network Printer - 995,383 bytes 08/19/99 06:26p Lewin> I can email you the WINDOWS\SYSTEM copy if you want. Probably wouldn't work as Tim's using NT4. Tim, have you installed the latest service pack? If not, do so, as it should (I imagine) update the DLL as well. Lewin> There are some gotchas in Windows and in particular you might Lewin> find, as I have, that the GUI configuration tool is REALLY Lewin> unstable on Windows, but since I spend much more than 99% of my Lewin> time in a text editor and gdb, that isn't such a big Lewin> issue. Just remember to make backup copies of your .ecc files Lewin> before attempting any editing, since the config tool crashes Lewin> very often (for me at least) when saving edits to an existing Lewin> file. The config tool is more stable on NT than on Windows9x/ME/suffix-of-the-day but even on NT it tends to bomb (for me anyway) after saving the same config 5-10 times. Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-10 23:58 ` Jesper Skov @ 2001-01-11 6:05 ` Lewin A.R.W. Edwards 2001-01-11 7:26 ` Gary Thomas 0 siblings, 1 reply; 52+ messages in thread From: Lewin A.R.W. Edwards @ 2001-01-11 6:05 UTC (permalink / raw) To: ecos-discuss >Lewin> OrCAD - 940,304 bytes, 06/30/98 07:33a WINDOWS\SYSTEM - 995,383 > >Lewin> I can email you the WINDOWS\SYSTEM copy if you want. > >Probably wouldn't work as Tim's using NT4. Well, a colleague has eCos's Windows host-end installed on an NT4 machine also, so I could give him the MFC42 from there. However I assumed that this file, or at least recent versions of it, cover both platforms, because I have programs that claim compatibility with both, and their install media have only one version of the file. >Lewin> before attempting any editing, since the config tool crashes >Lewin> very often (for me at least) when saving edits to an existing > >The config tool is more stable on NT than on >Windows9x/ME/suffix-of-the-day but even on NT it tends to bomb (for me >anyway) after saving the same config 5-10 times. I haven't noticed a great deal of difference between NT4, 98SE and Win2k. If I had time (how many times do I say that every day) I would investigate further. I have a gut feeling that the problem is related to the way the tree control is coded. How about recoding the config tool in Java? :) === Lewin A.R.W. Edwards (Embedded Engineer) Work: http://www.digi-frame.com/ Personal: http://www.zws.com/ and http://www.larwe.com/ "Und setzet ihr nicht das Leben ein, Nie wird euch das Leben gewonnen sein." ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-11 6:05 ` Lewin A.R.W. Edwards @ 2001-01-11 7:26 ` Gary Thomas 2001-01-11 7:41 ` Grant Edwards 2001-01-11 8:36 ` Sergei Organov 0 siblings, 2 replies; 52+ messages in thread From: Gary Thomas @ 2001-01-11 7:26 UTC (permalink / raw) To: Lewin A.R.W. Edwards; +Cc: ecos-discuss On 11-Jan-2001 Lewin A.R.W. Edwards wrote: > How about recoding the config tool in Java? :) > The ConfigTool _is_ being rewritten, due out probably by Summer '01. Sorry, no Java, just WxWindows (the most portable and flexible toolkit we could find), ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-11 7:26 ` Gary Thomas @ 2001-01-11 7:41 ` Grant Edwards 2001-01-11 7:51 ` Julian Smart 2001-01-11 7:56 ` Gary Thomas 2001-01-11 8:36 ` Sergei Organov 1 sibling, 2 replies; 52+ messages in thread From: Grant Edwards @ 2001-01-11 7:41 UTC (permalink / raw) To: Gary Thomas; +Cc: Lewin A.R.W. Edwards, ecos-discuss On Thu, Jan 11, 2001 at 08:24:28AM -0700, Gary Thomas wrote: > On 11-Jan-2001 Lewin A.R.W. Edwards wrote: > > How about recoding the config tool in Java? :) > > The ConfigTool _is_ being rewritten, due out probably by Summer '01. > > Sorry, no Java, just WxWindows (the most portable and flexible toolkit > we could find), Just curious: what language is being used? I've heard a lot of good things about the Python/WxWindows combo.. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-11 7:41 ` Grant Edwards @ 2001-01-11 7:51 ` Julian Smart 2001-01-11 8:01 ` Grant Edwards 2001-01-11 7:56 ` Gary Thomas 1 sibling, 1 reply; 52+ messages in thread From: Julian Smart @ 2001-01-11 7:51 UTC (permalink / raw) To: Grant Edwards, Gary Thomas; +Cc: ecos-discuss At 09:44 AM 1/11/01 -0600, you wrote: >Just curious: what language is being used? I've heard a lot of >good things about the Python/WxWindows combo.. I'm using C++; the main reasons behind this are that (a) Python would introduce another layer of complexity and possible configtool support issues; (b) I know C++ so I'll be more productive, and (c) since the original configtool was written in C++, quite a bit of code can be lifted with minimal translation. But yes, a lot of people rave about wxPython. The Linux (wxGTK) version is going well and it's starting to allow configuration viewing and editing. Although I'm a bit biassed towards wxWindows being its original author, I'm still pleasantly surprised at how good a job it does ;-) in large part due to Robert Roebling's excellent GTK+ port, together with his dialog editor. Regards, Julian -- Red Hat UK Ltd, Unit 200 Rustat House, 62 Clifton Road, Cambridge, UK. CB1 7EG Tel: +44 (1223) 271063 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-11 7:51 ` Julian Smart @ 2001-01-11 8:01 ` Grant Edwards 0 siblings, 0 replies; 52+ messages in thread From: Grant Edwards @ 2001-01-11 8:01 UTC (permalink / raw) To: Julian Smart; +Cc: Gary Thomas, ecos-discuss On Thu, Jan 11, 2001 at 03:57:32PM +0000, Julian Smart wrote: > >Just curious: what language is being used? I've heard a lot of > >good things about the Python/WxWindows combo.. > > I'm using C++; the main reasons behind this are that (a) Python > would introduce another layer of complexity and possible > configtool support issues; (b) I know C++ so I'll be more > productive, and (c) since the original configtool was written > in C++, quite a bit of code can be lifted with minimal > translation. But yes, a lot of people rave about wxPython. The other part of RedHat has always been pretty big into Python*, and I though maybe that had rubbed off on you guys. Even though most of the Linux boxes probably have Python, many don't don't have wxPython, so it would introduce another layer of installation/support hassles. * IIRC, the RH Linux installers were originally written in Python, rpm was originally in Python, some of the system configuration tools were in Python. -- Grant Edwards grante@visi.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-11 7:41 ` Grant Edwards 2001-01-11 7:51 ` Julian Smart @ 2001-01-11 7:56 ` Gary Thomas 1 sibling, 0 replies; 52+ messages in thread From: Gary Thomas @ 2001-01-11 7:56 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss, Lewin A.R.W. Edwards On 11-Jan-2001 Grant Edwards wrote: > On Thu, Jan 11, 2001 at 08:24:28AM -0700, Gary Thomas wrote: > >> On 11-Jan-2001 Lewin A.R.W. Edwards wrote: >> > How about recoding the config tool in Java? :) >> >> The ConfigTool _is_ being rewritten, due out probably by Summer '01. >> >> Sorry, no Java, just WxWindows (the most portable and flexible toolkit >> we could find), > > Just curious: what language is being used? I've heard a lot of > good things about the Python/WxWindows combo.. C/C++ AFAIK (since the libCDL is in C++). I agree about Python, being a member of the now extinct PSA, but that's yet another political battle ... ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Really dumb newbie question 2001-01-11 7:26 ` Gary Thomas 2001-01-11 7:41 ` Grant Edwards @ 2001-01-11 8:36 ` Sergei Organov 1 sibling, 0 replies; 52+ messages in thread From: Sergei Organov @ 2001-01-11 8:36 UTC (permalink / raw) To: ecos-discuss As CDL itself is Tcl, it seems to be more natural to code ConfigTool in Tcl/Tk than in Java/Python/whatever. Why to add third language to the picture? Gary Thomas <gthomas@redhat.com> writes: > On 11-Jan-2001 Lewin A.R.W. Edwards wrote: > > How about recoding the config tool in Java? :) > > > > The ConfigTool _is_ being rewritten, due out probably by Summer '01. > > Sorry, no Java, just WxWindows (the most portable and flexible toolkit > we could find), ^ permalink raw reply [flat|nested] 52+ messages in thread
* [ECOS] Help me !!, Hello world on out target @ 2000-11-16 17:25 KOHJY 2000-11-16 23:46 ` Jesper Skov 0 siblings, 1 reply; 52+ messages in thread From: KOHJY @ 2000-11-16 17:25 UTC (permalink / raw) To: ecos-discuss Hi All! I am porting eCos on our target which is similar with CMA230(ARM7), 1 timer and 2 Uart. I keep running into this problem while debugging with ecos gdb. When trying to execute an RAM application(Hello World program). Look at below. Downloading is OK. But RAM application not started ? (gdb)0x401440 in ?? () (gdb) load Loading section .rom_vectors, size 0x60 lma 0x8000 Loading section .text, size 0x4eb8 lma 0x8060 Loading section .rodata, size 0x228 lma 0xcf18 Loading section .data, size 0x2b4 lma 0xd140 Start address 0x8060 , load size 21492 Transfer rate: 21492 bits/sec, 298 bytes/write. (gdb) c Continuing. ..................... I don't know what happend ? Is GDB stub ROM wrong ? or eCos kernel building ? Thanks a lot ! ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [ECOS] Help me !!, Hello world on out target 2000-11-16 17:25 [ECOS] Help me !!, Hello world on out target KOHJY @ 2000-11-16 23:46 ` Jesper Skov 0 siblings, 0 replies; 52+ messages in thread From: Jesper Skov @ 2000-11-16 23:46 UTC (permalink / raw) To: KOHJY; +Cc: ecos-discuss >>>>> "KOHJY" == KOHJY <KOHJY@chollian.net> writes: KOHJY> Hi All! I am porting eCos on our target which is similar with KOHJY> CMA230(ARM7), 1 timer and 2 Uart. I keep running into this KOHJY> problem while debugging with ecos gdb. When trying to execute KOHJY> an RAM application(Hello World program). Look at below. KOHJY> Downloading is OK. But RAM application not started ? KOHJY> (gdb)0x401440 in ?? () (gdb) load Loading section .rom_vectors, KOHJY> size 0x60 lma 0x8000 Loading section .text, size 0x4eb8 lma KOHJY> 0x8060 Loading section .rodata, size 0x228 lma 0xcf18 Loading KOHJY> section .data, size 0x2b4 lma 0xd140 Start address 0x8060 , KOHJY> load size 21492 Transfer rate: 21492 bits/sec, 298 bytes/write. KOHJY> (gdb) c Continuing. .................... KOHJY> I don't know what happend ? Is GDB stub ROM wrong ? or eCos KOHJY> kernel building ? You obviously have a stub there, so I suggest you try to follow the flow of the code to see what is wrong. It's impossible to tell from the lack of output what is wrong. Jesper ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <Lewin>]
[parent not found: <A.R.W.>]
[parent not found: <Natarajan,>]
[parent not found: <Christian>]
end of thread, other threads:[~2001-01-12 3:45 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Fred> [not found] ` <Fierling's> [not found] ` <message> [not found] ` <of> [not found] ` <"Tue,> [not found] ` <05> [not found] ` <10> [not found] ` <Jan> [not found] ` <2001> [not found] ` <"Sat,> [not found] ` <07> [not found] ` <"Fri,> [not found] ` <17> [not found] ` <Tue,> [not found] ` <04> [not found] ` <May> [not found] ` <99> [not found] ` <12:35:31> [not found] ` <PDT> 1999-05-04 13:51 ` [ECOS] TCP/IP Stack for eCos Jay Lepreau 1999-05-04 17:06 ` Fred Fierling 1999-05-04 17:43 ` Brendan Simon 1999-05-05 5:15 ` [ECOS] " Bart Veer 1999-05-05 1:54 ` [ECOS] " Fernando D. Mato Mira [not found] ` <"Wed,> [not found] ` <5> [not found] ` <Jul> [not found] ` <2000> [not found] ` <11:39:46> [not found] ` <+0200> [not found] ` <"Mon,> [not found] ` <09> 2000-07-05 2:40 ` [ECOS] Connecting gdb to AEB Andreas.Karlsson 2000-07-05 2:53 ` Jesper Skov 2000-07-05 3:12 ` Robert Erskine 2000-10-05 12:33 ` [ECOS] GDB Download on i386 target hangs Christian Plessl 2000-10-06 5:15 ` Nick Garnett 2000-10-07 0:55 ` Christian Plessl 2000-10-09 6:40 ` Nick Garnett 2000-10-09 12:50 ` Christian Plessl 2000-10-10 2:46 ` Nick Garnett 2000-10-10 3:49 ` Jesper Skov [not found] ` <5.0.0.25.0.20001010121538.009f5e30@imap.ee.ethz.ch> [not found] ` <wwg8zrwkiht.fsf@balti.cygnus> 2000-10-10 7:28 ` Christian Plessl 2000-10-10 7:58 ` Nick Garnett 2000-10-11 7:11 ` Christian Plessl 2000-10-11 7:20 ` Nick Garnett 2000-10-12 0:45 ` Jesper Skov [not found] ` <11:11:19> [not found] ` <+0100> [not found] ` <Jesper> 2000-11-17 2:11 ` [ECOS] forwarded message from Peter Graf Jesper Skov 2000-11-19 23:43 ` Jesper Skov 2000-11-20 5:36 ` [ECOS] Hitachi SH7709A problems Peter Graf 2000-11-20 6:58 ` Jesper Skov 2000-11-20 7:20 ` Peter Graf 2001-01-03 2:48 ` Jesper Skov 2001-01-12 3:45 ` Peter Graf [not found] ` <20:29:19> [not found] ` <+0900> 2000-11-20 3:28 ` [ECOS] Help me !!, Hello world on out target °ÃÃç¿ë 2000-11-20 3:43 ` Jesper Skov 2000-11-20 5:54 ` Lewin A.R.W. Edwards 2000-11-20 6:43 ` Jesper Skov 2000-11-21 22:00 ` Jonathan Larmour [not found] ` <09:24:40> [not found] ` <-0500> 2000-12-05 6:26 ` [ECOS] gdb/insight questions Lewin A.R.W. Edwards 2000-12-05 7:22 ` Jesper Skov 2000-12-05 7:32 ` Lewin A.R.W. Edwards 2000-12-05 20:15 ` Jonathan Larmour 2000-12-06 4:13 ` Lewin A.R.W. Edwards 2000-12-05 22:43 ` Natarajan, Mekala (CTS) 2000-12-06 1:42 ` Jesper Skov 2000-12-06 4:47 ` Lewin A.R.W. Edwards 2001-01-10 16:42 [ECOS] Really dumb newbie question Tim Noell 2001-01-10 17:48 ` Lewin A.R.W. Edwards 2001-01-10 23:58 ` Jesper Skov 2001-01-11 6:05 ` Lewin A.R.W. Edwards 2001-01-11 7:26 ` Gary Thomas 2001-01-11 7:41 ` Grant Edwards 2001-01-11 7:51 ` Julian Smart 2001-01-11 8:01 ` Grant Edwards 2001-01-11 7:56 ` Gary Thomas 2001-01-11 8:36 ` Sergei Organov -- strict thread matches above, loose matches on Subject: below -- 2000-11-16 17:25 [ECOS] Help me !!, Hello world on out target KOHJY 2000-11-16 23:46 ` Jesper Skov [not found] <Lewin> [not found] ` <A.R.W.> [not found] <Natarajan,> [not found] <Christian>
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).