Re: [ECOS] small custom bootloader to start an app stored in flash
On 2014-10-21 02:27, Oleg Uzenkov wrote: Hello Everyone, I would like to make a small custom bootloader (not considering RedBoot) that would implement a simple function of checking a flag (some bytes in memory) and then jumping to one of the applications stored in internal flash. Something like this: internal flash memory: -- 0x0800 | bootloader | || -- |_| |flag || -- || || -- | app1 | || -- | app2 | || -- || || -- Basically, if flag is true then start app1 else start app2. I suppose bootloader would be a simple eCos app with ROM startup. Applications in flash probably should also be built for ROM startup. When the jump is made app's .data and .bss sections should be copied into RAM... Any ideas how to make a jump to start an app? May be some sample code showing how to do it in eCos? May be someone has done it already? I would appreciate any help on this. You've already mentioned the answer - RedBoot! RedBoot is just another eCos application which does all the things you are considering. I can understand not wanting to include RedBoot in your design (although it can be extremely useful, especially during development), but looking through the sources you'll find guidance on all the topics you are looking for. Good luck -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: select doesn't work on stdin?
On 2012-11-19 09:08, Ken Yee wrote: Gary Thomas wrote: Have you tried using a serial port (not the diagnostic console)? The problem with the diag port is that it is blocking which does not play nice with select() Unfortunately, we're out of serial ports on our system. We only have 3. 1 goes to a modem, 1 is used for board-board comms, and the 3rd is the console port which we have shared w/ the diag port (eCos forces you to assign the diag port to a serial port and you can't assign it to /dev/null). Not exactly true - you can use the serial driver (interrupt driven, etc) alongside the polled diag driver, at least for output. I've done it on many occasions and it works just fine. I can do ioctl w/ the FNONBIO flag to get it to run in non-blocking mode, but it only sees 1 in 18 characters (you hit the same key 17-18 times before one value gets to the read character function)-: -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: select doesn't work on stdin?
On 2012-11-15 14:16, Ken Yee wrote: I was about to put a bug in the ecos bug database and found this: http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968 From 2001??? Wow :-O I guess no one puts command shells on stdin/stdout in their embedded environments :-P Have you tried using a serial port (not the diagnostic console)? The problem with the diag port is that it is blocking which does not play nice with select() -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Linker Problem with Codesourcery lite arm-none-eabi 4.6.1
On 2012-03-04 05:58, Bob Brusa wrote: Hi the linker produces the following message: arm-none-eabi-g++ -LC:\ProjDAc\TDSsw\libs\tds_lib_2_install\lib -TC:\ProjDAc\TDSsw\libs\tds_lib_2_install\lib\target.ld -mcpu=arm7tdmi -Wl,--gc-sections -Wl,-static -nostdlib -mno-thumb-interwork -Xlinker -Map -Xlinker tds_4.Map -otds_4.elf usb_cdc.o tds_sym.o pa.o c:/programme/codesourcery/sourcery_codebench_lite_for_arm_eabi/bin/../lib/gcc/arm-none-eabi/4.6.1/../../../../arm-none-eabi/lib\libsupc++.a(vterminate.o): In function `__gnu_cxx::__verbose_terminate_handler()': vterminate.cc:(.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x184): undefined reference to `_impure_ptr' collect2: ld returned 1 exit status Build error occurred, build is stopped Time consumed: 3562 ms. Unfortunately, this diagnostics does not offer a clue on the source of the problem. Sure, somewhere in my source, but where and what? Does someone have a helpful advice? Thanks - Bob. Note: this has been discussed a lot in the archives... http://bit.ly/xpp3d4 -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] array index bug in tftp_server.c
On 2012-03-01 16:38, Grant Edwards wrote:
There appears to be an array index out-of-bounds problem in
tftp_server.c at line 691. At lines 661-666 there is a for loop that
leaves i with the value CYGNUM_NET_MAX_INET_PROTOS. Then at line 691,
'i' is used as a subscript in the experess 'server-s[i]'. The array
s contains CYGNUM_NET_MAX_INET_PROTOS elements, so the max legal
subscript is CYGNUM_NET_MAX_INET_PROTOS-1. But i is
CYGNUM_NET_MAX_INET_PROTOS at that point.
I have no clue what's going on in this particular code. The use of i
as a loop index inside an outer loop that also uses i as the loop
index seems like a mistake. I suspect that the loop at lines 661-666
should not be using i as the loop index.
647 for (i=0; i CYGNUM_NET_MAX_INET_PROTOS; i++) {
648 if (server-s[i] FD_ISSET(server-s[i],readfds)) {
649 recv_len = sizeof(data);
650 from_len = sizeof(from_addr);
651 data_len = recvfrom(server-s[i], hdr, recv_len, 0,
652 from_addr,from_len);
653 if ( data_len 0) {
654 diag_printf(TFTPD [%x]: can't read request\n, p);
655 } else {
656 #ifdef CYGSEM_NET_TFTPD_MULTITHREADED
657 // Close the socket and post on the semaphore some
658 // another thread can start listening for requests. This
659 // is not quite right. select could of returned with more
than
660 // one socket with data to read. Here we only deal with
one of them
661 for (i=0; i CYGNUM_NET_MAX_INET_PROTOS; i++) {
662 if (server-s[i]) {
663 close (server-s[i]);
664 server-s[i] = 0;
665 }
666 }
667 sem_post(server-port);
668 #endif
669 #ifndef CYGPKG_NET_TESTS_USE_RT_TEST_HARNESS
670 getnameinfo(from_addr,sizeof(from_addr), name,
sizeof(name),0,0,0);
671 diag_printf(TFTPD [%x]: received %x from %s\n, p,
672 ntohs(hdr-th_opcode), name);
673 #endif
674 switch (ntohs(hdr-th_opcode)) {
675 case WRQ:
676 tftpd_write_file(server, hdr,from_addr, from_len);
677 break;
678 case RRQ:
679 tftpd_read_file(server, hdr,from_addr, from_len);
680 break;
681 case ACK:
682 case DATA:
683 case ERROR:
684 // Ignore
685 break;
686 default:
687 getnameinfo(from_addr,sizeof(from_addr), name,
sizeof(name),0,0,0);
688 diag_printf(TFTPD [%x]: bogus request %x from %s\n, p,
689 ntohs(hdr-th_opcode),
690 name);
691
tftpd_send_error(server-s[i],hdr,TFTP_EBADOP,from_addr,from_len);
692 }
693
It looks like the loop variable 'i' is reused (incorrectly)
inside the #ifdef CYGSEM_NET_TFTPD_MULTITHREADED starting
on line 656. Change that to be a different variable and it
should fix it.
--
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
[ECOS] Re: [beagleboard] eCos Port on BeagleBoard-xM
On 2012-02-22 01:56, Swapnil Pimpale wrote: Hi all, Has eCos been ported to BeagleBoard-xM? Can somebody direct me to a source where I can find more How Tos regarding this? Not publicly - eCos is only available for Cortex-M3 based devices. There was some talk about other Cortex designs on the mailing list, but nothing has made it past that. You could check with eCosCentric. BTW, this question is much more suited for an eCos list (CC'd) as this list primarily covers Linux (and some Windows/CE) on the BeagleBoard. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Why is IPv6 in RedBoot not possible?
On 2012-01-23 16:44, Grant Edwards wrote: We're adding IPv6 support to our eCos-based products. The basic IPv6 support in the full-up application code is working fine (at least with static and link-local addressing). The next big question mark is RedBoot. I need to either add IPv6 support to RedBoot or make some basic changes to the way our product works (specifically how the application is updated in the field). Many years back Andrew Lunn stated that IPv6 support in RedBoot was not possibleP From: Andrew Lunnandrew.lunnat ascom.ch Subject: Re: hello..I have a problem about make redboot suport IPv6 Newsgroups: gmane.os.ecos.general Date: 2003-05-26 07:24:20 GMT (8 years, 34 weeks, 4 days, 16 hours and 12 minutes ago) No. Redboot has its own little TCP/IP stack. Have a look in packages/redboot/current/support/net/. This is a very simple IP stack, which is IPv4 only. IPv6 in redboot is not possible. My question is why? I realize it might be a fair amount of work to implement some sort of IPv6 support in RedBoot, but I'm wondering what would make it not possible. Adding IPv6 to RedBoot is not impossible, but it will require a large amount of work, certainly requiring changes to all the existing code as well as adding additional support. Andrew's not possible was most likely an expression of how involved this might be. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] removing all interrupts code and data from RedBoot image
On 2012-01-05 14:03, Elad Yosef wrote: Hi all, I'm short in RAM ROM for my Redboot run What I want to do is to eliminate all the interrupts code and data. In the hal_mon_init I'll register the exception handler to handle interrupts (it will halt CPU since no interrupt is expected...) Can someone give me points where to start? Since RedBoot doesn't use interrupts, you may not find much to save. What's your target architecture? Have you looked at a load map to see what might be cut, etc? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] ARM FIQ and nested interrupts
On 2011-10-14 11:52, Paul D. DeRocco wrote: From: Will Wagner We are looking at an application where we will need an FIQ to be able to interrupt an IRQ and I have been looking at support for this. It seems like there is no nested interrupt support for ARM and that FIQ support is very limited, in that it effectively turns it into an IRQ to be handled after current IRQ. Am I missing something here? Has anyone done any work to support the FIQ properly on ARM? Anyone able to comment on why it was done this way in the first place? I've always thought of FIQ as being for what you might call software DMA, where you have a really simple handler that just moves some data, and after some number of invocations invokes a real interrupt. For this paradigm, eCos doesn't need to participate in the FIQ mechanism at all: you manually install your own handler and unmask FIQ, and all works fine as long as you never do ANY OS calls in the handler. The way you signal the rest of eCos at the end of a series of FIQ calls is to force the generation of a regular IRQ, which in at least some ARM interrupt controllers can be done by manually setting the request bit for some channel that doesn't map to a used hardware interrupt input. I did this once on an ARM7TDMI, and it worked fine. This is the best use of FIQ on the ARM. As mentioned, I originally thought it could be used like IRQ via the normal eCos mechanisms. However, that is just too heavy for the sort of things FIQ is normally used for, so a very simple FIQ VSR is installed to do these quick and simple operations, like pseudo-DMA. Look at the MP3 player example in .../packages/hal/arm/edb7xxx/current/misc -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] eCos application offset for Redboot load
On 2011-08-08 17:25, gmail wrote: I am trying to build an eCos application (and the test suite) to load onto a board with a Redboot monitor. I've created an xxx_ram.ldi / .h for the board but don't know if I need to add in the offset in that file for the Redboot monitor or if that is done elsewhere. The monitor indicates: Platform: TS-7250 Board (ARM920T) Rev A Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. RAM: 0x-0x0200, [0x000530c0-0x01fdd000] available FLASH: 0x6000 - 0x6800, 1024 blocks of 0x0002 bytes each. Do I change the text base in the .ldi to something above 0x000530c0? Yes, e.g. 0x8 would be suitable. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: eCos Tool under Windows/cygwin How to invoke compiler, which is expecting windows style pathes
On 2011-08-05 09:40, Richard Rauch wrote: Unfortunately it is not a gcc based compiler. So when the compiler is not accepting forward slash, then it is no possibility to use with eCos config tool? Even if you get past this, you'll have other troubles - eCos uses a number of GCC extensions which your compiler probably does not support. Is this for a device which does not have GCC? (a rare beast!) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] eCos 3.0 and TS2750
On 2011-08-01 16:36, gmail wrote: Hi, I am starting a 'personal project' and would like to use eCos, and I am trying to get all of the pieces together. The board is from Technologic Systems (www.embeddedARM.com) and is the TS7250 w/ an ARM9 Cirrus Logic EP9302 on it. It comes with a redboot loader that loads their Linux port. I've got cygwin on an XP box and have installed eCos 3.0, but cannot find any package for the TS7250 or the ARM9-EP9302 processor. The s/w that came with the board appears to have the redboot source but I think it is a eCos 2.x version. Is there an existing package for this board or is there a way to 'import' it from the 2.x source? Thanks for any pointers in getting going in the right direction! This board is not part of the public tree. You should be able to get the original sources from Technologic Systems -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Problem with Redboot and Dollar Sign
On 07/07/2011 06:31 AM, Smith, Keith wrote: When I type a dollar sign, $, on the command line of RedBoot, RedBoot hangs. Is this a known problem or just a problem with my build of RedBoot? I noticed in redboot/src/io.c/_rb_gets_preloaded() that the $ used as a GDB lead-in. In my ROM version of RedBoot, Redboot just hangs. In my ROMRAM version of Redboot, I get a GDB dump. This is expected behaviour. You should be able to type $c#63 and RedBoot will carry on. If you really need to type $, try using \$ -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re-use RedBoot RAM segment in the application
On 07/03/2011 12:50 AM, Elad Yosef wrote: But My RedBoot code is running directly from the ROM. What you are saying is that when the application is calling UART write for example The code which runs is the RedBoot code from the ROM, which I agree about it. But all the parameters I think they are located on the calling Thread's stack, Am I wrong here? Even when RedBoot runs in ROM, there are static data which it uses (not everything can be kept on stacks). As I said below (top posting is evil BTW), if your application is built with CYGSEM_HAL_USE_ROM_MONITOR == 1, then you *will* need the data segment of RedBoot to remain intact. On Fri, Jul 1, 2011 at 3:38 PM, Gary Thomasg...@mlbassoc.com wrote: On 07/01/2011 06:28 AM, Elad Yosef wrote: Hi all, My Target is short with RAM and I want to use the RedBoot RAM in the application as well. Is it possible? it is a waste of RAM if not. It's only a waste if your application does not use RedBoot for runtime services. By default, your code will call functions in RedBoot for such things as console I/O, network debug support, GDB support, etc. You can only reuse RedBoot's RAM section if you are not using any of those (CYGSEM_HAL_USE_ROM_MONITOR == 0) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re-use RedBoot RAM segment in the application
On 07/01/2011 06:28 AM, Elad Yosef wrote: Hi all, My Target is short with RAM and I want to use the RedBoot RAM in the application as well. Is it possible? it is a waste of RAM if not. It's only a waste if your application does not use RedBoot for runtime services. By default, your code will call functions in RedBoot for such things as console I/O, network debug support, GDB support, etc. You can only reuse RedBoot's RAM section if you are not using any of those (CYGSEM_HAL_USE_ROM_MONITOR == 0) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] RedBoot Export Compliance
On 06/24/2011 08:50 AM, Keith McCready wrote: Greetings, I am about to release a product in which RedBoot is deployed. An internal audit has found that we do not have Export Compliance information regarding RedBoot. Does anyone happen to know if an ECCN has been assigned to RedBoot? That would be hard to do as there is no single RedBoot. Open Source projects like this require you to make such an application/assignment based on your particular environment. As far as it goes, I don't believe that there is anything in the core of RedBoot that would cause any problem (no encryption, etc) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] jffs2 problem
On 05/17/2011 12:15 PM, Eigil Krogh Sørensen wrote: Hi I'm writing code that uses jffs2 (for a Freescale i.MX25 board) and can't get it to work. In RedBoot I have created at fis image with name jffs2 w.: fis create -l 0x1024 fis list gives: Name FLASH addr Mem addrLength Entry point RedBoot 0x 0x 0x000C 0x FIS directory 0x000C 0x000C 0x0003F000 0x RedBoot config0x000FF000 0x000FF000 0x1000 0x perfTsts 0x0010 0x0010 0x0004 0x00100230 jffs2 0x0014 0x 0x0004 0x Then I have erased the FLASH w.: fis erase -f 0x0014 -l 0x0004 After that in eCos mount( /dev/flash/fis/jffs2, /, jffs2 ) works OK, and on the tty it writes Erase 0x0014: .. when the mount( /dev/flash/fis/jffs2, /, jffs2 ) instruction is run. But I can't create any files in / after that. The instruction open( jffs2tst, O_WRONLY|O_CREAT ) returns -1 (which originates from jffs2_reserve_space(.) that returnes because dirty = 0 and c-nospc_dirty_size = 264765). What am I doing wrong ? Is there anything I can do to solve the problem ? JFFS2 images need at least 2 empty erase blocks to function. Try creating the image with a larger length. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] AF_UNIX in ecos
On 05/14/2011 11:03 AM, ratheesh kannoth wrote: On Thu, May 12, 2011 at 5:16 PM, Daniel Morrisdani...@ecoscentric.com wrote: On Thu, May 12, 2011 at 04:44:24PM +0530, ratheesh kannoth wrote: eCos support AF_UNIX sockets ? Round cheeses roll? http://www.gerv.net/hacking/how-to-ask-good-questions/ Daniel %-- Daniel Morris - Sales Marketing Director eCosCentric - The eCos and RedBoot experts Tel: +44 1223 245 571 - i...@ecoscentric.com DDI: +44 1269 591 171 - dani...@ecoscentric.com Daniel, I did some experiment on AF_UNIX support in eCos. I have a strange prob. int s = socket(AF_LOCAL, SOCK_DGRAM, 0 ); sleep(120); int k = socket(AF_LOCAL, SOCK_DGRAM, 0 ); The first socket system call fails with errno 325( protocol not supported ). but second socket() call succeed . But, AF_INET socket is created without any error. http://www.ecoscentric.com/ecospro/doc.cgi/html/ref/net-common-tcpip-manpages-socket.html mentions support of AF_LOCAL. But in ecos-3.0, packages/net/snmp/lib/v3_0/src/snmp_api.c : 165 says no support for local sockets . If anybody has some clue, greatly appreciated. Local sockets, which are normally implemented using named pipes, are not supported in eCos. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] where I can find tm_basic test outputs?
On 05/10/2011 08:02 AM, Sergei Gavrikov wrote: On Tue, 10 May 2011, Richard Rauch wrote: Hi all, Are somewhere outputs from the tm_basic test available? Such test outputs from several platforms would be a good reference for comparing different microcontrollers, platforms or the quality of eCos portings. There are a few same outputs in Appendix B of eCos User Guide, take a look here: http://ecos.sourceware.org/docs-latest/user-guide/real-time-characterization.html Keep in mind that those results are more than 10 years old :-) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] measure the execution time of each thread
On 04/24/2011 04:22 PM, moktar_bouain wrote:
You don't want to modify that code, just look at how it computes time
at a nanosecond scale.
Look at the function show_time_in_us() which uses time values
based on the function HAL_CLOCK_READ() that reads the system timer
(whatever that may be) and calculates time to the most accurate
value available in the system. This is based on the raw clock
(often the hardware system clock) that's used to run the system
'tick' timer. On most systems, this value is accurate to micro-seconds,
sometimes even nano-seconds.
Hi Gary,
I found the function gettimeofday() which returns the time in us.
I create a simple application with eCos containing 1 thread,i like to
measure the
execution time(us) of the thread.
void taska(cyg_addrword_t data)
{
struct timeval tv1,tv2;
long long diff;
while(1)
{
gettimeofday (tv1, NULL);
cyg_mutex_lock(cliblock);
printf(TASKA \n);
cyg_mutex_unlock(cliblock);
cyg_thread_delay(2);
gettimeofday (tv2, NULL);
diff=(tv2.tv_sec-tv1.tv_sec) * 100 + (tv2.tv_usec-tv1.tv_usec);
printf(Time tv1 is %d\n,tv1.tv_usec);
printf(Time tv2 is %d\n,tv2.tv_usec);
printf(The diff is =%d usec\n,diff);
};
}
when i run this application in Tsim(simulator of Leon3):
Time tv1 is 286326803
Time tv2 is 286326801
The diff is -1 usec
Can you tell me what the fault in my program?
Looks like HAL_CLOCK_READ() isn't working on your hardware.
What's your target hardware? Is it part of the public eCos tree?
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] measure the execution time of each thread
On 04/23/2011 09:07 AM, moktar_bouain wrote: As I said before, look at how it's done in tm_basic.cxx I did, but I do not understand how to modify. Can you give me some details? You don't want to modify that code, just look at how it computes time at a nanosecond scale. Look at the function show_time_in_us() which uses time values based on the function HAL_CLOCK_READ() that reads the system timer (whatever that may be) and calculates time to the most accurate value available in the system. This is based on the raw clock (often the hardware system clock) that's used to run the system 'tick' timer. On most systems, this value is accurate to micro-seconds, sometimes even nano-seconds. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] measure the execution time of each thread
On 04/18/2011 05:32 PM, moktar_bouain wrote: Note that this technique is only accurate to the system tick time which is normally 10ms. If your thread runs for less time than this, you won't know. Look at the test program tm_basic.cxx for details on how to measure at a finer grain (without the overhead of decreasing the tick time). I use eCos for Sparc (Leon3 processor) with a 66 MHz. Means that the clock tick corresponds to 1.5×10-5ms(15ns). is it possible to measure the execution time of a thread?? That's not the clock tick that those functions are using, but the hardware instruction clock. The system clock is a periodic timer, used to measure time, that normally runs at 100Hz -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] measure the execution time of each thread
On 04/18/2011 04:00 PM, moktar_bouain wrote:
http://ecos.sourceware.org/docs-latest/ref/kernel-clocks.html
static cyg_tick_count_t run_time;
cyg_tick_count_t start, end, run_time;
while (1) {
start = cyg_current_time();
processing ...
end = cyg_current_time();
run_time = end - start;
}
Then you just need to convert ticks to time, based on the tick rate
for your platform.
Hi Mike,
Thank you for your reply.
I tried with your solution,but the value of run_time is always
constant.(run_time =1)
Note that this technique is only accurate to the system tick time
which is normally 10ms. If your thread runs for less time than this,
you won't know.
Look at the test program tm_basic.cxx for details on how to measure
at a finer grain (without the overhead of decreasing the tick time).
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Cannot open linker script file target.ld (Fedora 13)
for `headers'. make[1]: Leaving directory `/home/sc/ecos/ecos-work/st_build/language/c/libc/time/v3_0' make -r -C language/c/libm/v3_0 headers make[1]: Entering directory `/home/sc/ecos/ecos-work/st_build/language/c/libm/v3_0' make[1]: Nothing to be done for `headers'. make[1]: Leaving directory `/home/sc/ecos/ecos-work/st_build/language/c/libm/v3_0' make -r -C io/wallclock/v3_0 headers make[1]: Entering directory `/home/sc/ecos/ecos-work/st_build/io/wallclock/v3_0' make[1]: Nothing to be done for `headers'. make[1]: Leaving directory `/home/sc/ecos/ecos-work/st_build/io/wallclock/v3_0' make -r -C error/v3_0 headers make[1]: Entering directory `/home/sc/ecos/ecos-work/st_build/error/v3_0' make[1]: Nothing to be done for `headers'. make[1]: Leaving directory `/home/sc/ecos/ecos-work/st_build/error/v3_0' make -r -C hal/synth/arch/v3_0 headers make[1]: Entering directory `/home/sc/ecos/ecos-work/st_build/hal/synth/arch/v3_0' make[1]: Nothing to be done for `headers'. make[1]: Leaving directory `/home/sc/ecos/ecos-work/st_build/hal/synth/arch/v3_0' make -r -C hal/synth/i386linux/v3_0 headers make[1]: Entering directory `/home/sc/ecos/ecos-work/st_build/hal/synth/i386linux/v3_0' make[1]: Nothing to be done for `headers'. make[1]: Leaving directory `/home/sc/ecos/ecos-work/st_build/hal/synth/i386linux/v3_0' headers finished make -r -C services/memalloc/common/v3_0 heapgeninc.tcl make[1]: Entering directory `/home/sc/ecos/ecos-work/st_build/services/memalloc/common/v3_0' gcc -finline-limit=7000 -Wall -Wpointer-arith -Wundef -Woverloaded-virtual -Wno-write-strings -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -I/home/sc/ecos/ecos-work/st_install/include -I/home/sc/ecos/ecos-3.0/packages/services/memalloc/common/v3_0 -I/home/sc/ecos/ecos-3.0/packages/services/memalloc/common/v3_0/src -I/home/sc/ecos/ecos-3.0/packages/services/memalloc/common/v3_0/tests -I. -Wp,-MD,heapgen.tmp -E /home/sc/ecos/ecos-3.0/packages/services/memalloc/common/v3_0/src/heapgen.cpp -o heapgeninc.tcl make[1]: Leaving directory `/home/sc/ecos/ecos-work/st_build/services/memalloc/common/v3_0' /bin/sh: tclsh: command not found On Fedora 13, this is installed via the package tcl make -r -C services/memalloc/common/v3_0 heaps.cxx make[1]: *** [heaps.cxx] Error 127 make[1]: Entering directory `/home/sc/ecos/ecos-work/st_build/services/memalloc/common/v3_0' make: *** [build] Error 2 tclsh /home/sc/ecos/ecos-3.0/packages/services/memalloc/common/v3_0/src/heapgen.tcl /home/sc/ecos/ecos-work/st_install `pwd` make[1]: Leaving directory `/home/sc/ecos/ecos-work/st_build/services/memalloc/common/v3_0' make: Leaving directory `/home/sc/ecos/ecos-work/st_build' -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Cannot open linker script file target.ld (Fedora 13)
On 04/15/2011 04:31 PM, Ironicster wrote: Well if i search tcl in Add/remove Software i get a lot of hits. Should i install them all or is there a direct way? But regardless, like i said i used a config file that has worked before on Fedora 13, but it is looking for tclsh inside a folder specified in the config file, that will not be where the installation will put it... sudo yum install tcl -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] [Help] Running Apache on ecos
CC'd to the eCos discussion list for followup On 04/05/2011 03:09 AM, Ahmet ŞANSLI wrote: Hello there, Is there any web services we can run via ecos ? light apache or etc eCos does have a lightweight HTTP server as part of the mainline repository. Just search the archives for details. -- Please keep your replies on the mailing list(s) so that all may benefit. Private support is available under contract from various agents, including MLB Associates. Private email to me without a contract will be ignored. Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] eCos Test programs serial output format?
On 03/30/2011 08:26 AM, Richard Rauch wrote: Hi All, When running tests like tm-basic, there are log outputs to serial interface. Is this pure ASCII? Or do I need on host side a terminal emulation or something special? (e.g. when using Hyperterminal) It should be pure ASCII. Are you seeing something else? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: Why does sending multicast UDP require a gateway?
On 03/29/2011 05:09 PM, Grant Edwards wrote:
On 2011-03-29, Grant Edwardsgrant.b.edwa...@gmail.com wrote:
Somebody I work with has spent the last three days trying to send UDP
multicast packets using eCos and the FreeBSD network stack.
AFAICT, the FreeBSD stack will refuse to send a UDP multicast packet
unless it can find a valid route to the multicast destination IP
address with that IP _treated_as_a_unicast_address_.
The broken code is in sys/netinet/ip_output.c, and the error is
asserted at line 269:
123 ip_output(m0, opt, ro, flags, imo)
[...]
239 /*
240 * If routing to interface only,
241 * short circuit routing lookup.
242 */
243 #define ifatoia(ifa)((struct in_ifaddr *)(ifa))
244 #define sintosa(sin)((struct sockaddr *)(sin))
245 if (flags IP_ROUTETOIF) {
246 if ((ia = ifatoia(ifa_ifwithdstaddr(sintosa(dst ==
0
247 (ia = ifatoia(ifa_ifwithnet(sintosa(dst == 0) {
248 ipstat.ips_noroute++;
249 error = ENETUNREACH;
250 goto bad;
251 }
252 ifp = ia-ia_ifp;
253 ip-ip_ttl = 1;
254 isbroadcast = in_broadcast(dst-sin_addr, ifp);
255 } else {
256 /*
257 * If this is the case, we probably don't want to
allocate
258 * a protocol-cloned route since we didn't get one from
the
259 * ULP. This lets TCP do its thing, while not burdening
260 * forwarding or ICMP with the overhead of cloning a
route.
261 * Of course, we still want to do any cloning requested
by
262 * the link layer, as this is probably required in all
cases
263 * for correct operation (as it is for ARP).
264 */
265 if (ro-ro_rt == 0)
266 rtalloc_ign(ro, RTF_PRCLONING);
267 if (ro-ro_rt == 0) {
268 ipstat.ips_noroute++;
269 error = EHOSTUNREACH;
270 goto bad;
271 }
272 ia = ifatoia(ro-ro_rt-rt_ifa);
273 ifp = ro-ro_rt-rt_ifp;
274 ro-ro_rt-rt_use++;
275 if (ro-ro_rt-rt_flags RTF_GATEWAY)
276 dst = (struct sockaddr_in
*)ro-ro_rt-rt_gateway;
277 if (ro-ro_rt-rt_flags RTF_HOST)
278 isbroadcast = (ro-ro_rt-rt_flags
RTF_BROADCAST);
279 else
280 isbroadcast = in_broadcast(dst-sin_addr, ifp);
281 }
282 if (IN_MULTICAST(ntohl(ip-ip_dst.s_addr))) {
283 struct in_multi *inm;
284
285 m-m_flags |= M_MCAST;
286 /*
287 * IP destination address is multicast. Make sure dst
288 * still points to the address in ro. (It may have
been
289 * changed to point to a gateway address, above.)
290 */
As you can see, the output code rejects the packet for lack of a valid
route to the destination IP address before it checks to see if it's a
multicast IP address.
That doesn't look right to me...
If it's a multicast destination, shouldn't that short-circuit the
route-checking stuff?
The docs I can find are pretty clear: if it's a multicast IP
destination you ship it out to the corresponding multicast MAC
address. Period. No messing about with routes and gateway addresses.
I agree that this doesn't seem right. You might try looking at the
current BSD networking code to see if this has changed since I merged
the stack last - some *ten* years ago :-)
If you find a fix/work-around, send a patch!
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Any problem ?
On 03/25/2011 09:17 AM, ratheesh kannoth wrote:
Is there any prob with below code segment in eCos ?
{
fd_set rd_fds;
FD_ZERO(rd_fds);
while (1) {
timeout.tv_sec = 1;
timeout.tv_usec = 0;
if (select(0,rd_fds, NULL, NULL,timeout) 0) {
printf(\n Error \n);
sleep(1);
continue;
}
printf(\n Success \n);
}
}
Yes - the first parameter to select() is the number of open file
descriptors to check (fd in 0..N-1). Putting a zero there will
never yield any activity.
Typically, one puts the max # of open file descriptors or at
least the highest known open one + 1.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Any problem ?
On 03/25/2011 09:27 AM, ratheesh kannoth wrote:
On Fri, Mar 25, 2011 at 8:54 PM, Gary Thomasg...@mlbassoc.com wrote:
On 03/25/2011 09:17 AM, ratheesh kannoth wrote:
Is there any prob with below code segment in eCos ?
{
fd_set rd_fds;
FD_ZERO(rd_fds);
while (1) {
timeout.tv_sec = 1;
timeout.tv_usec = 0;
if (select(0,rd_fds, NULL, NULL,timeout)0) {
printf(\n Error \n);
sleep(1);
continue;
}
printf(\n Success \n);
}
}
Yes - the first parameter to select() is the number of open file
descriptors to check (fd in 0..N-1). Putting a zero there will
never yield any activity.
Typically, one puts the max # of open file descriptors or at
least the highest known open one + 1.
True. But it runs perfectly on eCos and linux. I facing some
problem, whenever i hit a key on keyboard in eCos. Is there connection
to this select system call here.
How are you connecting to the keyboard? If you are just using stdin,
the default will be the debug/console channel which is not interrupt
driven and select can't help you.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Any problem ?
On 03/25/2011 09:40 AM, ratheesh kannoth wrote:
On Fri, Mar 25, 2011 at 9:07 PM, Gary Thomasg...@mlbassoc.com wrote:
How are you connecting to the keyboard? If you are just using stdin,
the default will be the debug/console channel which is not interrupt
driven and select can't help you.
Top posting is evil, even if you move my quote :-(
I am new to eCos. Could you please explain a little more.
What file descriptor are you trying to select on and how did you open it?
Unless it's a device which supports interrupts and asynchronous operations,
select won't do a lot for you.
Also, you don't say what behaviour you are seeing, just asking if something
is wrong with this code snippet. What does it do? How would you expect it to
behave?
-Ratheesh
On 03/25/2011 09:27 AM, ratheesh kannoth wrote:
On Fri, Mar 25, 2011 at 8:54 PM, Gary Thomasg...@mlbassoc.comwrote:
On 03/25/2011 09:17 AM, ratheesh kannoth wrote:
Is there any prob with below code segment in eCos ?
{
fd_set rd_fds;
FD_ZERO(rd_fds);
while (1) {
timeout.tv_sec = 1;
timeout.tv_usec = 0;
if (select(0,rd_fds, NULL, NULL,timeout)
0) {
printf(\n Error \n);
sleep(1);
continue;
}
printf(\n Success \n);
}
}
Yes - the first parameter to select() is the number of open file
descriptors to check (fd in 0..N-1). Putting a zero there will
never yield any activity.
Typically, one puts the max # of open file descriptors or at
least the highest known open one + 1.
True. But it runs perfectly on eCos and linux. I facing some
problem, whenever i hit a key on keyboard in eCos. Is there connection
to this select system call here.
How are you connecting to the keyboard? If you are just using stdin,
the default will be the debug/console channel which is not interrupt
driven and select can't help you.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Development environment under Windows without cygwin?
On 03/23/2011 08:41 AM, Richard Rauch wrote: Hi All, Do anybody knows a way to work without cygwin natively on Windows? It seems, that cygwin is causing several problems on different windows environments. Is there a way to work without cygwin? Is the gnu compiler/linker toolchain available for windows? Which versions are comparable to the arm-eabi-gcc V4.3.2 ? Is it possible to run the eCos Config Tool without cygwin? If you want to avoid CygWin, run Linux in a VM. Better yet, just run Linux. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Redboot responds to ICMP echo when it shouldn't.
On 03/21/2011 02:21 PM, Grant Edwards wrote: While testing my rewrite of Redboot DHCP support, I've noticed that Redboots ping support is also broken. Redboot responds to ICMP echo requests that it shouldn't. Redboot will respond to ICMP echo requests _before_ it has received an IP address from the BOOTP/DHCP server. The destination IP address in the ICMP echo packet _does_not_match_ Redboot's IP address, but it responds anyway with a source IP address of 0.0.0.0. Is this behavior intentional? Not as far as I know. How are those packets even being received? Are they going to a broadcast address (IP or ESA)? Normally incoming packets are filtered by ESA by the network driver before they get pushed up the stack and processed. You might find that RedBoot replies to [some, maybe all] packets which somehow match it's ESA, but not IP address as well. If so, why? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: Redboot responds to ICMP echo when it shouldn't.
On 03/21/2011 02:36 PM, Grant Edwards wrote: On 2011-03-21, Gary Thomasg...@mlbassoc.com wrote: On 03/21/2011 02:21 PM, Grant Edwards wrote: While testing my rewrite of Redboot DHCP support, I've noticed that Redboots ping support is also broken. Redboot responds to ICMP echo requests that it shouldn't. Redboot will respond to ICMP echo requests _before_ it has received an IP address from the BOOTP/DHCP server. The destination IP address in the ICMP echo packet _does_not_match_ Redboot's IP address, but it responds anyway with a source IP address of 0.0.0.0. Is this behavior intentional? Not as far as I know. How are those packets even being received? The pinging host's ARP cache still has RedBoot's MAC address associated with the IP address bing pinged. Are they going to a broadcast address (IP or ESA)? Unicast Ethernet MAC, unicast IP. This is happening because of a stale ARP cache on your host. Normally incoming packets are filtered by ESA by the network driver before they get pushed up the stack and processed. Right. And then the IP layer should filter them by IP address, right? You might find that RedBoot replies to [some, maybe all] packets which somehow match it's ESA, but not IP address as well. That appears to be the case. I assumed that devices shouldn't respond to ICMP ping requests that don't match their IP address. Am I wrong? No, I think you are correct. The IP code may match if the local IP address is set to IPANY (i.e. 0.0.0.0). The DHCP server (which is sending the ICMP echo request before offering an IP address) appears to be ignoring the reply from IP address 0.0.0.0, but I can imagine somewhat contrived situations where it might cause problems. This seems to be a pretty rare condition, caused by a stale ARP cache. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: RedBoot DHCP failure due to race condition.
On 03/18/2011 02:39 AM, Tarmo Kuuse wrote: On 18.03.2011 01:18, Grant Edwards wrote: What I'm having problems with is the DHCP implementation in the Redboot bootloader. Redboot has it's own stripped-down polled-mode network stack and implementations of things like BOOTP/DHCP client, Telnet server, and TFTP client. Redboot's DHCP code started out as purely a BOOTP client, and it looks like when DHCP was added a few obscure failure modes were overlooked. Ok, I was not paying enough attention. Sorry. Yes, I remember seeing similar problems in RedBoot DHCP client over a year ago. It's not exactly production quality code (to put it mildly). Looking at some old stuff I see following major problems: 1. The race. Any received BOOTREPLY packages are copied into internal buffer before they are verified to be valid and destined to us. A BOOTREPLY package sent to somebody else will overwrite our current package. Lines 92-97 need to be moved 10 lines lower, after verification code. This may not fix all problems, but it should fix the race that you described. 2. The retry counter counts remaining retry attempts. I vaguely recall that it does not work. Mostly because it doesn't really care - line 232 always tops up the remaining retries counter even if the last attempt failed, causing a neverending loop. There used to be a similar assignment before 234 but I don't see it in current cvs. I have forgotten the details by now so don't take this as reliable information. Other, minor issues are: 3. DHCP transaction ID (XID) is not unique. If you start up multiple devices simultaneously, it will create a mess. 4. XID is not verified. It accepts any response it gets, as long as MAC address matches. Feel free to contribute production quality code to the project, rather than just moaning about it! -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] updated to new eCos version, asserts when first thread is resumed
On 03/14/2011 05:46 PM, Nathan French wrote: We just updated from eCos (pro) 2.0.91 to 3.0.9.1. What I'm seeing is that during cyg_user_start(), as soon as we create a thread and cyg_thread_resume() it the kernel asserts in Cyg_Scheduler_Implementation::add_thread(). The assert it is hitting is Idle thread vanished!!! but I believe it is due to the queue_map member of the scheduler not being initialized (it's a null pointer). I'm admittedly a little confused as to how exactly the kernel starts up and constructs the scheduler. After some googling I became confused about whether I needed to call cyg_scheduler_start() and if so, where. I tried calling this prior to resuming the thread but it failed in a very similar way (different assert, but same root cause). I don't believe there is anything wrong with our application code but thought perhaps we had been doing something wrong all along and the newer eCos version enforces something now... but I haven't found any evidence of that. Any ideas? Thanks in advance. eCos(pro) == ask eCosCentric This list is for help with the public version of eCos -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] GDB Issue on MPC837X
][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][#][8][0]Packet
received:
00
00
0x0 in __lshrdi3 (u=0, b=0)
(gdb)
(gdb) jump *0x10
Line 16 is not in `__lshrdi3'. Jump anyway? (y or n) y
Continuing at 0x10.
Sending packet: $P40=0010#72...[+]Ack
[$][O][K][#][9][a]Packet received: OK
Sending packet: $Hc0#db...[+]Ack
[$][O][K][#][9][a]Packet received: OK
Sending packet: $c#63...[+]Ack
[$][T][0][4][4][0][:][0][0][1][0][0][0][0][0][;][0][1][:][0][0][0][0][0][0][0][0][;][#][6][8]Packet
received: T0440:0010;01:;
Program received signal SIGILL, Illegal instruction.
0x10 in _stext () at include/exception:16
16 virtual ~exception () { }
Current language: auto; currently c++
(gdb)
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] GDB Issue on MPC837X
][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][
0]
[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
[0]
[0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][#][8][0]Packet
received:
000
000
00
0x0 in __lshrdi3 (u=0, b=0)
(gdb)
(gdb) jump *0x10
Line 16 is not in `__lshrdi3'. Jump anyway? (y or n) y
Continuing at 0x10.
Sending packet: $P40=0010#72...[+]Ack
[$][O][K][#][9][a]Packet received: OK
Sending packet: $Hc0#db...[+]Ack
[$][O][K][#][9][a]Packet received: OK
Sending packet: $c#63...[+]Ack
[$][T][0][4][4][0][:][0][0][1][0][0][0][0][0][;][0][1][:][0][0][0][0][0][0][0][0][;][#][6][8]Packet
received: T0440:0010;01:;
Program received signal SIGILL, Illegal instruction.
0x10 in _stext () at include/exception:16
16 virtual ~exception () { }
Current language: auto; currently c++
(gdb)
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Gary Thomas | Consulting for the
MLB Associates | Embedded world
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Newbie doubt about CYG... macros
On 02/13/2011 05:12 AM, Madhavi Manchala wrote: Hi All, I am new to the eCos. While looking at one of the eCos applications I am seeing lot of macros which are starts with CYG... I am viewing the application source in Cygwin Linux environment on Windows XP system. Here, my doubt is, is CYG represents the Cygwin Linux macros or eCos OS macros. I mean, are they defined in the Cygwin Linux OS or in eCos OS packages? The macros are look like #ifdef CYGPKG_KERNEL CYG_INTERRUPT_STATE #define CYG_ELF_MACHINE EM_386 #if defined(CYGPKG_HAL_ARM) #define CYG_ELF_MACHINE EM_ARM However, I heard a word like Cygnus' eCos. So, the macros which are starts with CYG are related to eCos OS but not related to Cygwin Linux. Am I correct? Sorry for asking such a simple question. But, I am looking into an eCos application in Cygwin linux environment. So, I am in a bit confusion about those macros. If anyone clarifies me, I am very happy. What does this mean? eCos runs on embedded hardware, not CygWin. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] using GDB without ROM Monitor
On 01/13/2011 08:22 AM, Christian Kraus wrote: Gary Thomas schrieb: On 01/12/2011 07:08 AM, Christian Kraus wrote: Hallo, We want to use the GDB Stub together with our application, we do not want to use the GDB/Redboot ROM Monitor and we want to debug only one thread. While we debugging this thread, the others threads should not suspended or stopped. The debugging should be done by GDB and Eclipse. We do not exactly know if this is posible with ecos with the GDB. Sorry, no. Once you are interacting via GDB, all else stops, interrupts, threads, etc. We are still using ecos 2.0 release. We using the STR912 microcontroller. We have porting the ecos to this Controller by ourselves. We have now include the GDB Stub support into the target. There was no error durring compilation. After flashing the binary the target printed out some chars on the serial debug port. That's the application telling you that it's ready to talk via the GDB protocol. Most likely, something like $O1234#99 which is an output string. Then we start to connect to the target with GDB. First it seems that it works, but we get SIGTRAP error, after that the Programm counter goes to 0 and after that nothing works any more. More details are required to help much more. Thank you very much for the fast reply. And the information you gave to us helps for the first moment. Here are more information about the problem. I think everything looks fine for the first moment, but we get some errors later: i get the following output after starting the target: +h$T0athread:0001;0f:fcc80a00;0d:cc5a0004;#dc then i try to set a GDB-Connection: C:\bw.vendor\G5\enip\.releasearm-none-eabi-gdb -b 115200 GNU gdb (CodeSourcery Sourcery G++ Lite 2007q3-53) 6.6.50.20070821-cvs Copyright (C) 2007 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-mingw32 --target=arm-none-eabi. For bug reporting instructions, please see: https://support.codesourcery.com/GNUToolchain/. (gdb) file enip.elf Reading symbols from C:\bw.vendor\G5\enip\.release/enip.elf...done. (gdb) target remote COM3 Remote debugging using COM3 0x000ac8fc in cyg_ether_ifattach (ifp=0x40008e8, bpf=value optimized out) at c:/bw.vendor/ecos-2.0/packages/net/bsd_tcpip/current/src/sys/net/if_ether subr.c:742 742 sdl = (struct sockaddr_dl *)ifa-ifa_addr; Current language: auto; currently c (gdb) c Continuing. [New Thread 1] after typing c in the console one more i get the following error: Program received signal SIGBUS, Bus error. cyg_ether_ifattach (ifp=0x40008e8, bpf=value optimized out) at c:/bw.vendor/ecos-2.0/packages/net/bsd_tcpip/current/src/sys/net/if_ether subr.c:744 744 sdl-sdl_alen = ifp-if_addrlen; (gdb) c Continuing. i checked the communication on the COM-Port. after i tried to connect the gdb with the target i get: Port A = GDB Port B = target [Port A] 01.01.1970 01:01:09 $q [Port B] 01.01.1970 01:01:09 $ [Port A] 01.01.1970 01:01:09 S [Port B] 01.01.1970 01:01:09 T [Port A] 01.01.1970 01:01:09 u [Port B] 01.01.1970 01:01:09 0 [Port A] 01.01.1970 01:01:09 p [Port B] 01.01.1970 01:01:09 a [Port A] 01.01.1970 01:01:09 p [Port B] 01.01.1970 01:01:09 t [Port A] 01.01.1970 01:01:09 o [Port B] 01.01.1970 01:01:09 h [Port A] 01.01.1970 01:01:09 r [Port B] 01.01.1970 01:01:09 r [Port A] 01.01.1970 01:01:09 t [Port B] 01.01.1970 01:01:09 e [Port A] 01.01.1970 01:01:09 e [Port B] 01.01.1970 01:01:09 a [Port A] 01.01.1970 01:01:09 d [Port B] 01.01.1970 01:01:09 d [Port A] 01.01.1970 01:01:09 # [Port B] 01.01.1970 01:01:09 : [Port A] 01.01.1970 01:01:09 3 [Port B] 01.01.1970 01:01:09 0 [Port A] 01.01.1970 01:01:09 7 [Port B] 01.01.1970 01:01:09 001;0f:fcc80a00;0d:cc5a0004;#dc$T0athread:00 [Port A] 01.01.1970 01:01:09 + [Port B] 01.01.1970 01:01:09 01;0f:fcc80a00;0d:cc5a0004;#dc [Port A] 01.01.1970 01:01:09 +$qSupported#37 [Port B] 01.01.1970 01:01:11 +$#00 [Port A] 01.01.1970 01:01:11 ++$Hc-1#09 [Port B] 01.01.1970 01:01:11 +$OK#9a [Port A] 01.01.1970 01:01:11 +$qC#b4 [Port B] 01.01.1970 01:01:11 +$QC0001#15 [Port A] 01.01.1970 01:01:11 +$qOffsets#4b [Port B] 01.01.1970 01:01:11 +$#00 [Port A] 01.01.1970 01:01:11 +$?#3f [Port B] 01.01.1970 01:01:11 +$S0a#e4 [Port A] 01.01.1970 01:01:11 +$Hg1#e0 [Port B] 01.01.1970 01:01:11 +$OK#9a [Port A] 01.01.1970 01:01:11 +$g#67 [Port B] 01.01.1970 01:01:11 +$b26a12a50100e83c0104e26a12a5e8080004d8080004246e0004d8080004fdff3004bcb200040600cc5a000454140a00fcc80a00#ee [Port A] 01.01.1970 01:01:11
Re: [ECOS] using GDB without ROM Monitor
On 01/12/2011 07:08 AM, Christian Kraus wrote: Hallo, We want to use the GDB Stub together with our application, we do not want to use the GDB/Redboot ROM Monitor and we want to debug only one thread. While we debugging this thread, the others threads should not suspended or stopped. The debugging should be done by GDB and Eclipse. We do not exactly know if this is posible with ecos with the GDB. Sorry, no. Once you are interacting via GDB, all else stops, interrupts, threads, etc. We are still using ecos 2.0 release. We using the STR912 microcontroller. We have porting the ecos to this Controller by ourselves. We have now include the GDB Stub support into the target. There was no error durring compilation. After flashing the binary the target printed out some chars on the serial debug port. That's the application telling you that it's ready to talk via the GDB protocol. Most likely, something like $O1234#99 which is an output string. Then we start to connect to the target with GDB. First it seems that it works, but we get SIGTRAP error, after that the Programm counter goes to 0 and after that nothing works any more. More details are required to help much more. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] [ecos-discuss] invalid ecos.db following cvs-update
On 12/01/2010 09:05 AM, Bob Brusa wrote: Hi under windows xp with cygwin, I entered the command cvs -z3 update -d -P It goes through without error messages, but I end up with an ecos.db-file that is refused by configtool. The file starts with a sequence of and also includes many cr (ASCII '\0x0a'). The usual header (comment-section at the beginning of the file) is missing. What went wrong and how can i fix this? This indicates you had a conflict in merging the changes to that file, most likely stemming from local changes to the file. The easiest thing would be to do something like this: % mv ecos.db ecos.db.BAD % cvs up ecos.db Then manually compare them and figure out how to merge your changes into the master. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: ARM Versatile 926EJ-S Board Support
On 08/26/2010 04:09 PM, Drasko DRASKOVIC wrote: On Thu, Aug 26, 2010 at 11:30 PM, Alex Schuilenburg al...@ecoscentric.com wrote: On 2010-08-22 09:25, John Dallaway wrote: Hi Drasko Drasko DRASKOVIC wrote: [...] ecosconfig new vpb926ejs redboot Unknown target vpb926ejs How to get support for this board ? Is it open-source or commercial ? It's a commercial port. To clarify, it is commercial open source (i.e. not FOSS) available from eCosCentric. -- Alex Schuilenburg That means that it can be obtained/downloaded ? No, it means you have to pay eCosCentric for it. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Purpose of CYGACC_CALL_IF_RESET?
On 08/18/2010 12:54 AM, Stuart Longland wrote: Hi, Does anyone happen to know what CYGACC_CALL_IF_RESET _actually_ does? Please don't say reset the device, because in my case, it doesn't... and I'm looking to find out why. The target board here is a Ka-Ro TX27 module (Freescale i.MX27), and I believe the RedBoot that it came with is based on eCos 2.0, but that's a guess. After adding some features to be able to manipulate an I²C EEPROM from within RedBoot and adjust the Linux kernel command line to suit, I've found that the reset command is broken, the device hangs instead. I have no JTAG, so must debug this by tracing through the code by hand, and inserting diag_printf's liberally. My understanding is that calling this function (or macro as the case may be), eventually leads to HAL_PLATFORM_RESET getting called... however it stops somewhere, indefinitely. I've tried tracing it, but I find it very hard to navigate the twists and turns of eCos' internals. I think I might have a much better idea as to what's going on if I could determine what the actual flow of execution is once this macro/function is called. Could someone enlighten me? Regards, Look at .../packages/hal/arm/mdbmx1/var/current/include/hal_var_ints.h #define HAL_PLATFORM_RESET() \ CYG_MACRO_START\ ((void(*)(void))0)(); /* hang here forever if reset fails */ \ CYG_MACRO_END This says that to reset the board, simply jump to location 0, which may or may not really do what you want. You'll have to figure out what magic can actually reset the board. Note: the code for this platform is not in the public repository, so you really should ask whomever delivered it to you for help as the eCos community in general will have no clue. I just happen to also have access to it. -- Please keep your replies on the mailing list(s) so that all may benefit. Private support is available under contract from various agents, including MLB Associates. Private email to me without a contract will be ignored. Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] HOW TO compile and include thirdparty libray.
On 08/06/2010 01:00 PM, Ramesh Chandra Satyavaram wrote: Hi, I am working on a project that uses the ECOS. We have a requirement with our customer. The Customer provides the compiled library and that should be linked with out application. I want to know the procedure on how to do this. We are using the ARM Based AT91SAM7XX micro controllers. We are using the arm-elf cross compilation tools. Should the customer also use the ECOS for compilation or is it enough to compile with arm-elf-gcc? Yes, they should build using the same toolchain and include tree (from your eCos kernel build tree) as you use to build the kernel. How to include the library with our application? Could any one help on this? Try looking at this example: http://www.mlbassoc.com/examples/build_httpd.html It shows how to build an eCos application using a separate library/module. This particular example is self contained, but it should show you how to do it with your customer's library. -- Please keep your replies on the mailing list(s) so that all may benefit. Private support is available under contract from various agents, including MLB Associates. Private email to me without a contract will be ignored. Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Ethernet PHY Device API
On 07/06/2010 01:07 PM, Mikhail Matusov wrote: Perhaps reset() is supposed to be used for initializing PHY itself. The ETH_PHY_REG_LEVEL_ACCESS_FUNS macro defined in eth_phy.h is used to assign the pointers to the functions. My function wasn't getting called because another function was pointed to by this macro in the MAC portion of the driver (Virtex4), which was a little bit confusing... I think it belongs to the PHY driver... No, it belongs in the platform driver - its purpose is to set up the communication between the PHY and the proessor/MAC device. What sort of initialization does your PHY need? Most PHY devices are quite useful/happy just being taken out of reset and talking to them... - Original Message - From: Christophe Coutand ccout...@stmi.com To: Mikhail Matusov matu...@squarepeg.ca; ecos-discuss@ecos.sourceware.org Sent: Monday, July 05, 2010 3:57 PM Subject: RE: [ECOS] Ethernet PHY Device API My understanding is the init() routine does not initialize the PHY but the MII interface for accessing the PHY. There is no API defined in eCos for actually setting up the PHY, please correct me if I am wrong. Are you calling _eth_phy_init(eth_phy_access_t *f) ? This should execute your init() code prior to probe your PHY. Christophe -Original Message- From: ecos-discuss-ow...@ecos.sourceware.org [mailto:ecos-discuss-ow...@ecos.sourceware.org] On Behalf Of Mikhail Matusov Sent: 5. juli 2010 21:25 To: ecos-discuss@ecos.sourceware.org Subject: Re: [ECOS] Ethernet PHY Device API Hello all, Where should I put the code initializing PHY? The optional init() function I defined along with the required stat() doesn't seem to ever get called. Thanks, /Mikhail - Original Message - From: Christophe Coutand ccout...@stmi.com To: Mikhail Matusov matu...@squarepeg.ca; ecos-discuss@ecos.sourceware.org Sent: Friday, June 25, 2010 6:41 PM Subject: RE: [ECOS] Ethernet PHY Device API In my case, Vitesse VSC8244 PHY is inferred so VSC8244.c is compiled and it includes the line: _eth_phy_dev(Vitesse VSC8244, 0x000FC6C2, VSC8244_stat) In the MAC layer, I call _eth_phy_init() to probe for the PHY and I get the PHY status by calling _eth_phy_state() which uses the stat() function of the PHY. I use the PHY state to configure the MAC layer according to current link speed and duplex mode reported. Christophe -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Ethernet PHY Device API
On 07/06/2010 03:57 PM, Mikhail Matusov wrote: Gary, What sort of initialization does your PHY need? Most PHY devices are quite useful/happy just being taken out of reset and talking to them... I need to switch the PHY to the RGMII mode. By default it is in the GMII mode. It involves a few writes to the PHY registers. Are you saying that I have to be doing this in the platform driver? I don't think it belongs there, but that's actually how I am doing it now... For some reason I can't get ethernet working on this card. I know that hardware is OK because I have another OS running on it happily. I can't find anything wrong except for one MAC register reporting wrong RGMII status. This made me think that perhaps the PHY is initialized too late... However, the register in question doesn't seem to behave properly under another OS either... I agree that initializing the PHY device itself does not belong in the platform driver. However, as you noted, there is no API for the PHY driver to be initialized at reset. Also, switching the PHY device into GMII or RGMII mode would seem to be a platform specific anyway. I don't understand your last comment 'the register in question doesn't seem to behave properly under another OS either...' - what does this mean? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] An unsolved problem?
On 06/28/2010 09:10 PM, Gregg Levine wrote: Hello! Whilst attempting to build the entire eCos collection for the iPaq 3650 I came across this complaint at the very end of the process concerning the flash library: /usr/local/anoncvs/ecos/packages/fs/jffs2/current/src/fs-ecos.c:26:2: #error This compiler is known to be broken. Please see: /usr/local/anoncvs/ecos/packages/fs/jffs2/current/src/fs-ecos.c:27:2: #error http://ecos.sourceware.org/ml/ecos-patches/2003-08/msg6.html; make[1]: *** [src/fs-ecos.o.d] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory `/usr/local/iPaq2/i2_build/fs/jffs2/current' make: *** [build] Error 2 make: Leaving directory `/usr/local/iPaq2/i2_build' Looking at the contents of the referenced messages on that list, I noted that there were references to the gentleman behind the original flash file system. Would anyone know if this was indeed solved, that is an appropriate patch or something else created? Use a newer compiler! GCC 3.2.x (what's being checked for) is incredibly old. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] JFFS2 umount error
On 05/13/2010 09:20 AM, PMD Chakravarthy wrote: Hi, I am using jffs2 file system on ecos 3.0. I am getting the following errors when try to unmount the filesystem. Refuse to unmount. Ino #1 has use count 2 Ino #9 has use count 1 Did any one see these kind of issues? What could be the reason for these warning messages. You still have files open (inode #1 #9). You can't unmount the file system until all files have been closed. Figure out the file name of those inodes and close them. -- 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
[ECOS] Re: [PATCH] redboot - add exec option to set board revision
Please keep your replies on the list so that all may benefit. On 05/13/2010 09:33 AM, Jose Vasconcellos wrote: This allows setting the ATAG_REVISION so it gets passed to the kernel. This is useful for systems that share the same id but have some small hardware differences between board revisions. On Thu, May 13, 2010 at 9:47 AM, Gary Thomasg...@mlbassoc.com wrote: On 05/13/2010 08:02 AM, Jose Vasconcellos wrote: This patch adds an exec option (-v) to set the board revision via the ATAG_REVISION tag. What's it used for? (Why do you need this tag) I think it would be better in this case to have this provided automatically. Whatever value you would be passing seems to be specific to your target, so just define it as a platform defined value and make the RedBoot exec code pass it. Define it wherever you've defined HAL_PLATFORM_MACHINE_TYPE, e.g. #define HAL_PLATFORM_REVISION 123 Then in the code #if defined(HAL_PLATFORM_REVISION) ... #endif Otherwise, you pollute the command with options which do nothing on most platforms and will just be confusing to users. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] JFFS2 umount error
Please keep your replies on the mailing list so that all may benefit. On 05/13/2010 10:34 AM, PMD Chakravarthy wrote: Hi Gary, Thanks for the reply. I am trying to umount the filesystem before a reboot. How can I close all open files before a reboot(and unmount)? If I don't successfully unmount and force reboot(power cycle) the system, I am seeing 2 behaviours. a) The file which is open(Ino #9) during unmount is lost. b) Some times other files in the filesystem are also lost(CRC errors). How can I avoid situation #b ? I no nothing of your application so it's hard to tell you what to do. If you are trying to reboot, you're going to need to figure out a way to make sure all open files have been closed. This will require some application knowledge as the problems you are having may not be directly related (certainly not case a) to JFFS2, but rather buffered I/O (such as the standard fwrite() functions) On Thu, May 13, 2010 at 8:59 PM, Gary Thomasg...@mlbassoc.com wrote: On 05/13/2010 09:20 AM, PMD Chakravarthy wrote: Hi, I am using jffs2 file system on ecos 3.0. I am getting the following errors when try to unmount the filesystem. Refuse to unmount. Ino #1 has use count 2 Ino #9 has use count 1 Did any one see these kind of issues? What could be the reason for these warning messages. You still have files open (inode #1 #9). You can't unmount the file system until all files have been closed. Figure out the file name of those inodes and close them. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: [PATCH] redboot - add exec option to set board revision
On 05/13/2010 11:06 AM, Jose Vasconcellos wrote: On Thu, May 13, 2010 at 10:56 AM, Gary Thomasg...@mlbassoc.com wrote: Please keep your replies on the list so that all may benefit. On 05/13/2010 09:33 AM, Jose Vasconcellos wrote: This allows setting the ATAG_REVISION so it gets passed to the kernel. This is useful for systems that share the same id but have some small hardware differences between board revisions. On Thu, May 13, 2010 at 9:47 AM, Gary Thomasg...@mlbassoc.comwrote: On 05/13/2010 08:02 AM, Jose Vasconcellos wrote: This patch adds an exec option (-v) to set the board revision via the ATAG_REVISION tag. What's it used for? (Why do you need this tag) I think it would be better in this case to have this provided automatically. Whatever value you would be passing seems to be specific to your target, so just define it as a platform defined value and make the RedBoot exec code pass it. Define it wherever you've defined HAL_PLATFORM_MACHINE_TYPE, e.g. #define HAL_PLATFORM_REVISION 123 Then in the code #if defined(HAL_PLATFORM_REVISION) ... #endif Otherwise, you pollute the command with options which do nothing on most platforms and will just be confusing to users. -- Gary Thomas | Consulting for the MLB Associates |Embedded world It would be better to autodetect the hardware revision and pass that when loading the kernel. It would have to be something that's detected in something like plf_hardware_init. I'm not sure how to pass that info to do_exec. Similarly to what I said before, just make 'HAL_PLATFORM_REVISION' be defined as a function that returns the appropriate value, or even the name of the variable that holds it - your choice. Note that my proposed change also fixed another bug. The opts array is declared with a size of 7 but it should be 8 if the option CYGHWR_REDBOOT_LINUX_EXEC_X_SWITCH is used; otherwise it corrupts the stack. Noted, thanks --- a/packages/hal/arm/arch/current/src/redboot_linux_exec.c +++ b/packages/hal/arm/arch/current/src/redboot_linux_exec.c @@ -313,7 +313,7 @@ bool ramdisk_addr_set, ramdisk_size_set; unsigned long base_addr, length; unsigned long ramdisk_addr, ramdisk_size; -struct option_info opts[7]; +struct option_info opts[8]; char line[8]; char *cmd_line; struct tag *params = (struct tag *)CYGHWR_REDBOOT_ARM_LINUX_TAGS_ADDRESS; -- Please keep your replies on the mailing list(s) so that all may benefit. Private support is available under contract from various agents, including MLB Associates. Private email to me without a contract will be ignored. 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
[ECOS] Re: Support for Altera Cyclone IV device
On 05/04/2010 02:30 PM, Gao Feng wrote: Hi, there I am Gao, a electrical design engineer in Linear System Ltd. Recently, we are developing a new project, and we try to use eCos as our device operation system. We plan to use Altera cyclone IV device. Is it supported by the eCos system? If it does not, is it possible to give an estimation when the eCos will support the Cyclone IV device? If possible, could we ask for some source about possible early verification. Thanks. Note: originally sent to ecos-maintainers list. This question belongs on the main discussion list. FPGA support in eCos is orthogonal to processor/target choices. It would be up to you to develop support for such a 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
[ECOS] Re: ks8851_mll driver at eCos
On 04/22/2010 10:05 AM, Choi, David wrote: Hi Gary, As per your suggestion, I have tried to use cvs since yesterday. I use cvs 1.12.13 I have the following message. $cvs -z3 -d :pserver:anon...@ecos.sourceware.org:/cvs/ecos co -P ecos cvs checkout: CVS password file /home/david/.cvspass does not exist - creating a new file cvs [checkout aborted]: unrecognized auth response from ecos.sourceware.org: Service temporarily unavailable, please try again later Any idea to fix this issue? Try again? It just worked for me here. Also, please send your mail to the mailing lists; I'm not the only one who might know the answer :-) -Original Message- From: Gary Thomas [mailto:g...@mlbassoc.com] Sent: Wednesday, April 21, 2010 11:01 AM To: Choi, David Cc: Li, Charles; eCos Maintainers Subject: Re: ks8851_mll driver at eCos On 04/21/2010 11:35 AM, Choi, David wrote: Hello Gary, I get your information after submitting my driver at eCos community a couple of days ago. This is my first time submitting my source code to eCos. So still I am in the learning curve in the eCos world. If you have time, please take a look at it and give me feedback. First glance, it looks pretty good. Some cleanup will need to be done: * Please test submit against the current (anonymous CVS) tree * The copyright boilerplate in each file needs to be updated to match the new FSF style (refer to the CVS tree) By the way, a couple of month ago, I sent an email, which I believe triggers FSF sending [copywrite assignment document]. Until today, I have not received any document about it. I want to know the status but I don't know how to trace it. I've no clue, sorry. Perhaps one of the other maintainers can help? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Problem building redboot
On 04/12/2010 06:00 PM, Mikhail Matusov wrote: Dear experts, experts possibly, mind readers hardly I am trying to build RedBoot with the GUI configtool and I am experiencing some problems with the include paths. I can't figure out why the paths are wrong when the compiler is called and I don't know where some of the flags come from as well... The makefile pointed by the make seems correct, however it seems that there is another source for all these settings, which I haven't been able to track down so far... I am working with the toolchain from ecos-3.0 and the latest anonymous cvs checkout. Without some details, we can't help much... * What target? * What host/build platform? * How did you configure the build? * What are the errors? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Halting RedBoot
On 04/01/2010 06:28 AM, Stefano Mora wrote:
Hi there,
I'm in a trouble with RedBoot cause during the boot it receives a character
from the serial port (different from ^C) and the boot stops waiting for a
Return.
I don't need this behaviour cause the serial port is shared with a printer
that, when the board powers up, sends a char then the board stops.
My question is:
How can i jump it?
The code that enable the behaviour is
} else {
script = hold_script;
}
??
If i comment out this code the bootloader can stops only with Ctrl-C ??
No, this is not how to fix the problem.
The problem is that this loop is calling _rb_gets() which is
expecting to read an entire line from the console. If that
function sees any characters, it will wait until a complete
line is entered, regardless of the timeout.
The correct way to fix this would be to use mon_read_char_with_timeout()
instead of _rb_gets(). This will take a little while to update and
test, but if you're patient I'll give you a patch to try.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Halting RedBoot
On 04/01/2010 08:26 AM, S. Z. wrote:
Hi,
I had the same problem. I solved it by using the following code in
packages/redboot/src/main.c :
while (script_timeout_ms= CYGNUM_REDBOOT_CLI_IDLE_TIMEOUT) {
#if 1
if(_rb_break(CYGNUM_REDBOOT_CLI_IDLE_TIMEOUT)){
res = _GETS_CTRLC;
break;
} else {
res = _GETS_TIMEOUT;
}
#else
res = _rb_gets(line, sizeof(line),
CYGNUM_REDBOOT_CLI_IDLE_TIMEOUT);
if (res= _GETS_OK) {
diag_printf(== Executing boot script in %d.%03d seconds - enter ^C
to abort\n,
script_timeout_ms/1000, script_timeout_ms%1000);
continue; // Ignore anything but ^C
}
if (res != _GETS_TIMEOUT) break;
#endif
script_timeout_ms -= CYGNUM_REDBOOT_CLI_IDLE_TIMEOUT;
}
HTH
Stamatis
Yes, that does look like it will work.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] DSR Assert issue
On 03/25/2010 07:06 AM, Paul Fine wrote: I am forwarding this message for a colleague. His last two messages to the list din't seem to have made it to the list. I wonder if that is because he had attached a small log file. I have copied the text of that log file into to the message, so we will see if that helps. --- From: David Cardin Sent: Wednesday, March 24, 2010 9:31 AM To: 'ecos-de...@ecos.sourceware.org' Subject: Hello, I am having a problem using the flash libraries V2 in eCos 2.0.89. I am working on a system based on an OMAP 5912 processor (ARM core with a TI DSP) using eCosPro v2.0.89. You should take this up with eCosCentric. This list only deals with the public version of eCos. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] R: [ECOS] Problem flashing WinCE
On 03/16/2010 02:07 AM, Stefano Mora wrote: -Messaggio originale- Da: L D [mailto:embed...@gmail.com] Inviato: lunedì 15 marzo 2010 19:28 A: Stefano Mora Cc: ecos-discuss@ecos.sourceware.org Oggetto: Re: [ECOS] Problem flashing WinCE On Mon, Mar 15, 2010 at 12:27 PM, Stefano Mora sm...@eos.pr.it wrote: Hello L D, This is my tests: RedBoot RedBoot lo -r -b 0x0 nk.nb0 Using default protocol (TFTP) Specified address (0x) is not believed to be in RAM - continue (y/n)? n RedBoot RedBoot lo -r -b 0x18 -h 192.168.0.12 nk.nb0 Using default protocol (TFTP) Raw file loaded 0x0018-0x0217, assumed entry at 0x0018 RedBoot RedBoot go ü I guess there is some mistakes in the building phase. Do you have a WinCE image that is known to work on that board or are you porting WinCE? I built the image and I tested it on the same board with a different bootloader (eBoot). Now I need to run it with the RedBoot bootloader. What sort of a file is it (raw binary? ELF image? S-Records?) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] R: [ECOS] Define Flash partition for WinCE storage
On 03/16/2010 07:08 AM, Stefano Mora wrote: On 03/16/2010 05:55 AM, Stefano Mora wrote: Hi all, I have a board with RedBoot + WinCE. What kind of a board is this? It is a SODIMM board based on iMX25 and 2GB of Flash memory I defined a Flash partition for wince and a 64MB partition for storage. WinCE mounts correctly the 64MB storage partition. RedBoot fis list Name FLASH addr Mem addrLength Entry point RedBoot 0x 0x 0x0004 0x wince 0x0004 0x8010 0x01F0 0x storage 0x01F4 0x8200 0x0400 0x FIS directory 0x07F6 0x07F6 0x0001F000 0x RedBoot config0x07F7F000 0x07F7F000 0x1000 0x RedBoot How can i define a 1GB Storage size? You'd have to have a 1GB device on your hardware platform - do you? Yes, of course :-) Not according to RedBoot - it thinks that your FLASH is only 128MB. What sort of FLASH chip(s) do you have that make up 1GB? Do I need to define a RAM (Mem addr) size with the same size of the storage area?? I have not so much RAM !?!?! No these are not related. The 'Mem addr' is simply the RAM address that RedBoot will load an image into by default (when the -b option is not used with 'fis load') So instead of: RedBoot fis create -b 0x8200 -r 0x8200 -l 0x0400 -s 0 -f 0x01f4 storage i need to type: RedBoot fis create -b 0x8200 -r 0x8200 -l 0x4000 -s 0 -f 0x01f4 storage I guess i should have problems with the locations of the RedBoot config FIS directory partitions ... Maybe I could choose a different range of Flash addresses: RedBoot fis create -b 0x8200 -r 0x8200 -l 0x0400 -s 0 -f 0x1000 storage First of all, it's poor form to mess with the actual FLASH addresses - RedBoot will handle that just fine for you, allocating the image you want (based on size, etc) automatically from the free/available space. Get the basic FLASH layout working first - you'll have to rebuild RedBoot to fix this. Once that's going, the rest will fall into place. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Define Flash partition for WinCE storage
On 03/16/2010 05:55 AM, Stefano Mora wrote: Hi all, I have a board with RedBoot + WinCE. What kind of a board is this? I defined a Flash partition for wince and a 64MB partition for storage. WinCE mounts correctly the 64MB storage partition. RedBoot fis list Name FLASH addr Mem addrLength Entry point RedBoot 0x 0x 0x0004 0x wince 0x0004 0x8010 0x01F0 0x storage 0x01F4 0x8200 0x0400 0x FIS directory 0x07F6 0x07F6 0x0001F000 0x RedBoot config0x07F7F000 0x07F7F000 0x1000 0x RedBoot How can i define a 1GB Storage size? You'd have to have a 1GB device on your hardware platform - do you? Do I need to define a RAM (Mem addr) size with the same size of the storage area?? I have not so much RAM !?!?! No these are not related. The 'Mem addr' is simply the RAM address that RedBoot will load an image into by default (when the -b option is not used with 'fis load') -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Bonjour on eCos platform
On 03/12/2010 12:05 AM, ganesh kr wrote: Hi, Has anybody used Bonjour on eCos platform. If so please let me know the code size it requires. Q'est-ce que c'est bonjoir? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Ethernet stack sends empty fragment
On 03/01/2010 03:27 AM, Timo Gerber wrote: Hi guys, I'm working on an ethernet driver with scather gather support and I am wondering: When sending UDP packets from the application with a higher payload-size (e.g. 2500Bytesand more), the ethernet stack calls my DRV_eth_send() function with a weird sg_list. For instance, some packets are fragmented like this: sg_list[1].len = 42 sg_list[1].buf = points to the hdr. sg_list[2].len = 1472 sg_list[2].buf = points to the payload. sg_list[3].len = 0 sg_list[3].buf = points to an empty buffer. As you can see the last sg fragment is kinda weird, but this scheme appears all the time, not only now an then. What's the MTU on that interface? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Ethernet stack sends empty fragment
Please keep your replies on the mailing list so that all benefit. On 03/01/2010 05:31 AM, Timo Gerber wrote: Am 01.03.2010 13:19, schrieb Gary Thomas: On 03/01/2010 03:27 AM, Timo Gerber wrote: Hi guys, I'm working on an ethernet driver with scather gather support and I am wondering: When sending UDP packets from the application with a higher payload-size (e.g. 2500Bytesand more), the ethernet stack calls my DRV_eth_send() function with a weird sg_list. For instance, some packets are fragmented like this: sg_list[1].len = 42 sg_list[1].buf = points to the hdr. sg_list[2].len = 1472 sg_list[2].buf = points to the payload. sg_list[3].len = 0 sg_list[3].buf = points to an empty buffer. As you can see the last sg fragment is kinda weird, but this scheme appears all the time, not only now an then. What's the MTU on that interface? Its a standard ethernet interface with an MTU of 1514 Which matches the request (42+1472==1514). The upper layer which creates the SG list must be messing up when this happens. Which stack (BSD, LWIP) are you using? I don't see how this is possible with the BSD layer as it only counts segments which have a non-zero length. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] LAN9218 driver porting problem
Sample(of
course I use sg_list[i].buf instead of skb),do you think will it work
properly(or permissably) ?
What if there are mismatches between sg_len and data counts written in
RX_Status_FIFO ?
Please enlighten me.
The parameter 'sg_len' indicates how many elements are present
in the sg_list 'sg'. Looking at 'sg', you'll see that it's
and array of scatter gather elements which look like this:
struct eth_drv_sg {
CYG_ADDRESS buf;
CYG_ADDRWORD len;
};
What your function lan91cxx_recv() should do is to move the
data from the device, utilizing the sg list structure. The
higher level network code allocates this based on the callback
from your lan91cxx_RxEvent() function.
To be clear, here's the flow:
Device generates interrupt
lan91cxx_RxEvent() runs, determines how many bytes are in the packet
(sc-funs-eth_drv-recv)(sc, len) tells the network layer
... time passes - maybe a lot of time - until the network input
thread has time/space to read the packet
lan91cxx_recv() is called from the network input thread
for each element in 'sg' (based on 'sg_len'), move the next
sg[n].len bytes from the device buffer into sg[n].buf
--
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] LAN9218 driver porting problem
On 02/12/2010 06:10 PM, m mariga wrote:
Hello,
In danger of calling off using eCos,
again I implore you to lend me your knowledge.
I am still studying your LAN91c111 driver.
I am stuck in fatham of it. Please help me.
I tried to dump cpd-rxpacket,len,sg_len variables in lan91cxx_RxEvent,and
sg_len in lan91cxx_recv like below.
And run nc_test_slave() test program. The result dropped me deeper into the
fatham.
lan91cxx_RxEvent(struct eth_drv_sc *sc)
{
|
stat = get_reg(sc, LAN91CXX_FIFO_PORTS);
// There is an Rx Packet ready
cpd-rxpacket = 0xff (stat 8);
diag_printf(rxpacket=%x\n,cpd-rxpacket);
|
stat = get_data_short(sc);
len = get_data_short(sc);
len = len - 6; // minus header/footer words
diag_printf(len=%x\n,len);
(sc-funs-eth_drv-recv)(sc, len);
}
lan91cxx_recv(struct eth_drv_sc *sc, struct eth_drv_sg *sg_list, int sg_len)
{
|
diag_printf(sg_len=%x\n,sg_len);
}
Here is part of the result.
---
connection from 172.16.1.28.1226
rxpacket=0
len=5ea
sg_len=2
rxpacket=1
len=5ea
sg_len=2
rxpacket=2
len=5ea
sg_len=2
rxpacket=0
len=5ea
sg_len=2
rxpacket=1
len=5ea
sg_len=2
rxpacket=2
len=5a
sg_len=2
rxpacket=1
len=3c
sg_len=2
rxpacket=1
len=3c
sg_len=2
rxpacket=1
len=3c
sg_len=2
rxpacket=0
len=3c
sg_len=2
rxpacket=1
len=5ea
sg_len=2
rxpacket=0
len=5ea
sg_len=2
rxpacket=2
len=5ea
sg_len=2
rxpacket=3
len=5ea
sg_len=2
rxpacket=1
len=5a
sg_len=2
rxpacket=0
len=5ea
sg_len=2
rxpacket=0
len=5ea
sg_len=2
rxpacket=1
len=5ea
sg_len=2
---
My question is,why sg_len is always 2 in spite of len being different.
I know it is too difficult for me to understand your Scatter-Gather or
something,but I need to make it work with LAN9218.
Your LAN91c111 recv routine uses sg_len in whle loop and gather data into
sg_list from DATA_FIFO.
LAN9118/9218 has RX_Status_FIFO,RX_Data_FIFO seperately. RX_Status_FIFO tells
packet length.
We know packet number from calculating data count written in RX_Status_FIFO.
I consulted LAN9118 SMSC Linux sample driver.
Its recv routine is much easier to understand.
Its operation like below.
|
| While RX_Status_FIFO!=0
| |
| alloc new packet to skb
| //update counters
| privateData-stats.rx_packets++;
| |
| copy data into new skb packet from RX_Data_FIFO
| |
--
I rather I would prefer to this, instead of using enigmatic sg_len to receive
data from FIFO.
In xxx_recv routine,if I ignored sg_len and I coded like SMSC Sample(of
course I use sg_list[i].buf instead of skb),do you think will it work
properly(or permissably) ?
What if there are mismatches between sg_len and data counts written in
RX_Status_FIFO ?
Please enlighten me.
The parameter 'sg_len' indicates how many elements are present
in the sg_list 'sg'. Looking at 'sg', you'll see that it's
and array of scatter gather elements which look like this:
struct eth_drv_sg {
CYG_ADDRESS buf;
CYG_ADDRWORD len;
};
What your function lan91cxx_recv() should do is to move the
data from the device, utilizing the sg list structure. The
higher level network code allocates this based on the callback
from your lan91cxx_RxEvent() function.
To be clear, here's the flow:
Device generates interrupt
lan91cxx_RxEvent() runs, determines how many bytes are in the packet
(sc-funs-eth_drv-recv)(sc, len) tells the network layer
... time passes - maybe a lot of time - until the network input
thread has time/space to read the packet
lan91cxx_recv() is called from the network input thread
for each element in 'sg' (based on 'sg_len'), move the next
sg[n].len bytes from the device buffer into sg[n].buf
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Segfault of configtool
On 01/27/2010 07:02 AM, Manuel Borchers wrote: Hi everyone! I'm planning a new (platform) port to an ARM9-based processor. Therefore I'm currently studying the code and fiddling a bit around. As a base I use the ARM Integrator port, as it seems quite fitting for the task (same UART, same ARM966). Previously I used the innovator port, but switched over. The problem I'm having can be reproduced with the Innovator port. When I use the config tool and select the Innovator platform with the redboot template the project is set up fine. To generate a redboot image, I then try to import the redboot_RAM.ecm. There, the configtoll crashes with a segfault. I'm running linux and installed ecos-3.0 with the tcl-installer. It installed the host-toolchain as well as the the binary for the configtool. This happens under a Debian unstable as well as under a scientific linux (4.8). Any ideas, what causes this or is this is a known problem? Honestly, I'm not quite willing to fiddle through all the dependencies of building the graphical configtool myself, but if this will solve my problem, I guess I just need to ;) What happens if you use 'ecosconfig'? e.g. % ecosconfig new target redboot % ecosconfig import .../reboot_ram.ecm % ecosconfig tree % make -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Use of Lauterback debugger
On 01/14/2010 02:50 PM, Alex Lindeijer wrote: Hi again we set the DE (debug enable) also manually at a break long after startup. But then it is reset again. We checked kode around interupt handling but haven't found the code responsible for resetting. It is certainly not done in out application code. So any hint in where the resetting could happen is welcome, Look at .../ecos/packages/hal/powerpc/mpc85xx/current/include/var_regs.h I think you need to change MSR_COMMON to include MSR_DE -Original Message- From: Fahd Abidi Sent: 13/01/2010, 21:38 To: Alex Lindeijer; ecos-disc...@sourceware.org Subject: RE: [ECOS] Use of Lauterback debugger look at the initial .S file, in uboot for instance its called start.S, I'm not sure what its called in ecos. Search in there for MSR or MSR[DE] and you will find the reference for it. Fahd From: Alex Lindeijer [mailto:ale...@3d-perception.com] Sent: Wed 1/13/2010 3:23 PM To: Fahd Abidi; ecos-disc...@sourceware.org Subject: RE: [ECOS] Use of Lauterback debugger Thanks for the quick reply! However I cannot find some ting for that in the config tool. I have look in kernel code for MSR macros etc but those didn't explain the resetting of this bit. Alex Lindeijer | 3D perception AS Senior System Designer ale...@3d-perception.com T: +47 97540959 www.3D-perception.comhttp://www.3D-perception.com Achieving Your Vision From: Fahd Abidi [mailto:fab...@ultsol.com] Sent: 13. januar 2010 21:09 To: Alex Lindeijer; ecos-disc...@sourceware.org Subject: RE: [ECOS] Use of Lauterback debugger You need to set a special flag in ecos, such as CONFIG_HW_DEBUG, where it ignores the code path to disable the debug interrupt bit. This is typically how this issue is handled in uboot or the Linux kernel. Fahd From: ecos-discuss-ow...@ecos.sourceware.org on behalf of Alex Lindeijer Sent: Wed 1/13/2010 2:30 PM To: ecos-disc...@sourceware.org Subject: [ECOS] Use of Lauterback debugger Hi We are trying to use a Lauterbach hardware debugger on a MPC8541. For the debugger to work( like breakpoints/stepping) the debug interrupt enable bit in the Machine State Register must be set. However we see that even when we set it (at start-up in the kernel or manually when breaking/continuing), it is reset by some code in the ecos kernel. Does anybody have hint where? We have not enabled GDB. Thanks in advance Alex Lindeijer Senior System Designer 3D Perception -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] redboot: e2fs_open: e2fs_inode_lookup failed
On 12/24/2009 08:57 PM, Sreeni Guduguntla wrote: Hi, I am trying to load linux from CF on gateworks cambria board. I get the following error. Any insight? CF is formatted properly with ext2 file system in the concerned partition. I was able to mount CF on regular PC and was able to see linux file. --Sreeni RedBoot(tm) bootstrap and debug environment [ROM] Red Hat certified release, version 2.04.13 - built 18:57:33, Oct 24 2008 RedBoot disks hda1 Linux hda2 Linux RedBoot load -r -v -b 0x80 -m disk hda1:/linux e2fs_open: e2fs_inode_lookup failed Can't load 'hda1:/linux': Can't open file RedBoot load -r -v -b 0x80 -m disk hda1:linux e2fs_open: e2fs_inode_lookup failed Can't load 'hda1:linux': Can't open file RedBoot load -r -v -b 0x80 -m disk hda1:/linux e2fs_open: e2fs_inode_lookup failed Can't load 'hda1:/linux': Can't open file RedBoot load -r -v -b 0x80 -m disk hda1:linux e2fs_open: e2fs_inode_lookup failed Can't load 'hda1:linux': Can't open file What version of EXT2 file system did you use? The RedBoot EXT2 driver is rather old and can only handle versions with i-nodes that are 128 bytes each (newer versions of EXT2 can use 256 byte i-nodes). Try formatting your CF card with the -I 128 option. n.b. the first command you tried is the correct syntax - no quotes should be required. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Building ecos image for SAM7EX256
On 11/20/2009 02:30 PM, Benoit Callebaut wrote: Hello, I am new to eCos but not to embedded systems. I need to load eCos on my SAM7EX256 board. What I want to do exactly is to build a binary image containing the eCOS kernel (and everything needed like HAL,drivers...) and my application. Since I have a JTAG probe up and running, I don't want RedBoot. I won't use a terminal to communicate with the board neither by sserial port nor Ethernet. My question is simple. How can I do it ? My toolchains are installed and functionnal, I configured eCos for my board using the template. I know how to use the makefile. I have 2 issues. the definition of CYGPKG_ERROR is nowhere to be found, The makefile and the linker scripts doesn't generate a fully statically linked binary image. How can I generate that image. Be more explicit about the steps you took (either the ecosconfig command lines used or the exact details using the configtool) What steps did you use to build the result? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Generel Information regarding ECOS
On 11/04/2009 03:51 AM, bkankur wrote: Dear Friends, I am working on ARM A8 cortex based processor having MMU. I would like to know following things which will be helpful: 1) Does ECOS support MMU? I tried to search ecos forum and I am a bit confuse on it. Only at the most rudimentary level. On ARM processors, the MMU is typically used to remap memory to a useful consistent layout. 2) What level of virtual memory implementation is done in ecos ? None. If you need VM, run Linux n.b. there is no [public] port of eCos to the A8 or A9 processors. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] How to connect RedBoot via Telnet running application
On 10/16/2009 08:33 AM, m mariga wrote: Hello, I'd like to connect to RedBoot via Telnet during target's running net application. I tried to run nc_test_slave program as application and connect to RedBoot via Telnet from host's cygwin. The result is below. $ telnet 172.16.1.200 9000 Trying 172.16.1.200... telnet: Unable to connect to remote host: Connection refused ...snip Once your application is started, RedBoot is no longer available. Why are you trying to do this? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] How to connect RedBoot via Telnet running application
Please keep your replies on the mailing list so that all may benefit. On 10/16/2009 09:07 AM, m mariga wrote: Hello, Gary wrote I'd like to connect to RedBoot via Telnet during target's running net application. I tried to run nc_test_slave program as application and connect to RedBoot via Telnet from host's cygwin. The result is below. $ telnet 172.16.1.200 9000 Trying 172.16.1.200... telnet: Unable to connect to remote host: Connection refused ...snip Once your application is started, RedBoot is no longer available. Why are you trying to do this? I would like to load new application object to target using RedBoot via Telnet from host PC during target's application running. Is it impossible ? It is not possible. As I said, once your application is running, RedBoot is out of the picture. I got an impression from Anthony J. Massa's book that if setted two different IP addresses between RedBoot and application,I could connect to RedBoot via Telnet during application running. Am I mistaken ? That's a reference to the ability of RedBoot to provide GDB services via the network. The rest of RedBoot's functionality is no longer available, once your application starts. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] How to connect RedBoot via Telnet running application
On 10/16/2009 10:43 AM, m mariga wrote: Hello,Gary,and everyone, I am very sorry. I dare your anger for my obstination,but I must confirm next point. Gary wrote, I would like to load new application object to target using RedBoot via Telnet from host PC during target's application running. Is it impossible ? It is not possible. As I said, once your application is running, RedBoot is out of the picture. Am I right in getting you that even I use BOOTP or DHCP to get dynamic IP address for application and assign other staic IP address for RedBoot,I could not connect to RedBoot via Telnet during application running ? Once your application starts, RedBoot is GONE. The only way to return to it is to exit your application, typically by resetting the hardware. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Attempt to load ELF data xxx which is not valid..
On 10/13/2009 10:33 AM, Jim Bradleigh wrote: Hi, I`m trying to find out how I change the location at which my executable is loaded by redboot.. When I do a 'load -mode file /hdisk/main.elf' I get the following error.. *** Abort! Attempt to load ELF data to address : 0x00108 which is not valid I realise that this address is inside my redboot area, and thus it cannot be used.. I can`t just '-b 0x00109' the code to some other address as eCos application's doesn`t support relocation How do I change this address? I can`t find options in the config tool or any info on the mailing list.. What kind of application is '/hdisk/main.elf'? If it's eCos, look at the mlt files for the RAM startup. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] turn off diag_printf?
On 10/06/2009 01:33 AM, Dave Milter wrote: I used arm cpu from at91 family and its DBGU channel for working with redboot. When my application starting it used dbgu for diag_printf and also ordinary printf working via this channel, now I want interrupt driven IO via this DBGU serial port, but only after full initialization. So I want such scheme: redboot - diag_printf working ecos app: - initialization - diag_printf working - main function is called - diag_printf working - somehow switch off diag_printf - now it nothing print to DBGU port (1) - interrupt driven IO via DBGU port is activated I have problem with (1), how should I do it? I find such code: CYGACC_COMM_IF_CH_DATA_SET(*comm,at91_ser_channels[0]); CYGACC_COMM_IF_WRITE_SET(*comm, cyg_hal_plf_serial_dbg_write); CYGACC_COMM_IF_READ_SET(*comm, cyg_hal_plf_serial_dbg_read); CYGACC_COMM_IF_PUTC_SET(*comm, cyg_hal_plf_serial_dbg_putc); CYGACC_COMM_IF_GETC_SET(*comm, cyg_hal_plf_serial_dbg_getc); CYGACC_COMM_IF_CONTROL_SET(*comm, cyg_hal_plf_serial_dbg_control); CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_dbg_isr); CYGACC_COMM_IF_GETC_TIMEOUT_SET(*comm, cyg_hal_plf_serial_dbg_getc_timeout); if I replace in this code function like cyg_hal_plf_serial_dbg_write with empty functions, diag_printf stop send something to DBGU? The easiest way to handle this is to call this function diag_init_putc(void (*putc)(char c, void **param)) Pass it a function (not NULL as that's how you reset to the default) that takes a character and prints. This will then prevent diag_printf() from accessing your device. Note: I'd suggest that you make this function at least save the last few characters that might be printed in case there's something important that is trying to make its way out :-) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Periodic execution of code in a thread context
On 09/23/2009 08:59 AM, Steven Clugston wrote:
Hi all
I need to have a function with some control code in it to execute at regular
and consistent intervals.
The way I've done this is just to create a thread and trap the execution path
in an infinite loop using while(1){some code;cyg_thread_delay()} or
for(;;){some code; cyg_thread_delay()}.
The trouble with this approach is that if the code doesn't take the same path
every time, then the overall interval will vary and the drift will be
cumulative. This hasn't mattered too much until now, but I need it to not drift
for my current application. I guess it could be improved by using
cyg_real_time_clock() at the start and end of the code section to find how long
it took then modify the delay time to try to keep the time interval at which
the code is started the same, but it seems a bit clumsy and might suffer from
jitter which would still be cumulative.
The other way I've tried is to use a timer/alarm attached to the system clock,
but this executes in a DSR context which causes some limitations and I would
prefer to use a normal thread context.
Could I use a cyg_thread_suspend() at the end of each iteration then re-wake
the thread from an alarm handler?
Is there anything which I've missed like a scheduler policy or API call which
might help?
Do I need to resort to a hardware timer to achieve this goal?
One way to handle this is to use select() with a timeout which
is set to a relative time value (computed by checking the current
time relative to a known value). Hence your loop looks something
like this:
gettimeofday(base_time, NULL);
while (1) {
... do some work
// Calculate when to resume
timeradd(base_time, time_per_loop, base_time);
// And how long that is from now
gettimeofday(now, NULL);
timersub(base_time, now, delta);
// Wait for that much time
select(0,0,0,0,delta);
}
Of course this solution, like the others that have been posted,
is only accurate to the system timer/tick. If you need higher
resolution than that, you'll need a separate hardware timer.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Ethernet traffic causing loss of bytes on UART
On 09/01/2009 08:36 AM, Alex Lindeijer wrote: Hi All This problem is fixed. The drivers that came with our Python MPC8541 eval board, acknowledged the ethernet interrput in the DSR (after processing!) and not in the ISR. It seems to work fine now. How does that have anything to do with losing bytes on the UART? BTW, IMO it's not safe/proper to acknowledge the interrupt in the ISR. The ISR masks the interrupt and only after the network stack has fully processed the data is it acknowledged and unmasked. Acking the interrupt in the ISR could lead to missing some interrupts. -Original Message- From: ecos-discuss-ow...@ecos.sourceware.org [mailto:ecos-discuss-ow...@ecos.sourceware.org] On Behalf Of Alex Lindeijer Sent: 1. september 2009 08:24 To: ecos-disc...@sourceware.org Subject: [ECOS] Ethernet traffic causing loss of bytes on UART Hi We are running a serial port on 38400 baud and are seeing loss of Rx bytes. When unplugging the ethernet cable we have no problems. We are using a MPC8541, it has a PC16550D programming model for the UART. I see that the driver uses the FIFO and reads until the FIFO is empty. The Ethernet driver is a tsec driver . We encountered similar problems when writing to flash. We got some verification/write errors with Ethernet traffic going. In that case we masked the interrupts while writing to flash. But we don't want to do that when receiving bytes on the serial port of course. Has anybody else encounter such problems? Any hints in were to look? We have been looking into this now for some time and are getting a bit desperate.;-( Cheers Alex Lindeijer -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: Ethernet controllers..
Jim Bradleigh wrote: Hi John, Thanks for the update, I`m currently using RTL8139 based cards but my project requires alot of performance from the network elements and eventually Gigabit Ethernet.. In this reguard I`ll have to look into Intel cards sooner or later, can anyone tell me why the Intel 82544 driver uses the function udelay alot - I`m concerned that the udelay is a hardware delay which will prevent threads (or other 82544 cards in the system) from running. None of the uses of udelay are in the main processing path - only during initialization. - Original Message From: John Dallaway j...@dallaway.org.uk To: Jim Bradleigh jim.bradlei...@btinternet.com Cc: ecos-discuss@ecos.sourceware.org Sent: Monday, 24 August, 2009 1:35:09 PM Subject: [ECOS] Re: Ethernet controllers.. Hi Jim Jim Bradleigh wrote: Thought I would throw this out to the list to see if anyone can help... As everyone know's eCos supports a limited device driver list for each platform, I`m currently running on i386 which limits me to a real-tek and two Intel chipsets... Where do most of you purchase network controllers from? The easiest route is probably a D-Link DFE-530TX+ PCI card which uses the RTL8139 part and can be found via Amazon in the UK. I can`t find any network cards which say they contain the Intel i82544 chipset.. It would be nice to start my project with a defined hardware spec that I know I can purchase.. The i82544 featured on the Intel Pro/1000 ethernet card which appears to have been replaced by the Pro/1000 GT card: http://www.intel.com/products/desktop/adapters/pro1000gt/pro1000gt-overview.htm The newer card uses the i82541 part which may or may not be compatible. One other question, does anyone know if a network card with the Marvell 88E chipset exists? The 88E is an ethernet PHY (transceiver), not a controller. I hope this helps. John Dallaway -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: Getting error in ecos/ GDB: found solution by set endian big but another prob
Ajit Mittal wrote:
I found the problem using ecos old mailing list:
Another prob:
But how to fix this problem, when loading program through redboot like
load -r -v -b %{FREEMEMLO} basic1
and exec command give gdb protocol strings like
$T050f:0100;0d:01fc0fec;#d6
How to make it take as big endian.
Two problems:
* Don't use '-r' when loading an ELF image
* Use 'go', not 'exec'
You'll find that this sequence works just as well as via GDB:
RedBoot lo basic1
RedBoot go
This is precisely why I asked you to show your commands before. Had
you followed those instructions, you would have had working code days ago!
Thanks
-
Here is the output from working gdb.
Remote communication error: Connection reset by peer.
ar...@aryan-desktop:~/test2$ xscale-elf-gdb -nw
GNU gdb xscale-030422
Copyright 2002 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-gnulibc2.2
--target=xscale-elf.
(gdb) set endian big
The target is assumed to be big endian
(gdb) target remote 192.168.5.217:9000
Remote debugging using 192.168.5.217:9000
0x5002097c in ?? ()
(gdb) load basic1
Loading section .rom_vectors, size 0x40 lma 0x10
Loading section .text, size 0x13464 lma 0x100040
Loading section .rodata, size 0x4ac lma 0x1134a4
Loading section .data, size 0x3ec lma 0x113950
Start address 0x100040, load size 81212
Transfer rate: 324848 bits/sec, 303 bytes/write.
(gdb) continue
Continuing.
Hello, eCos world!
-
On Sat, Aug 22, 2009 at 2:07 AM, Ajit Mittalajitmit...@gmail.com wrote:
How to fix this problem. This is IXP425 based board with 8MB flash and
32 MB RAM.
I am getting this error:
-
h...@home-desktop:~/test2$ xscale-elf-gdb -nw
GNU gdb xscale-030422
Copyright 2002 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-gnulibc2.2
--target=xscale-elf.
(gdb) target remote 192.168.5.217:9000
Remote debugging using 192.168.5.217:9000
Cannot access memory at address 0xfc0ffc01
0x7c090250 in ?? ()
(gdb) load basic1
Loading section .rom_vectors, size 0x40 lma 0x10
Loading section .text, size 0x13464 lma 0x100040
Loading section .rodata, size 0x4ac lma 0x1134a4
Loading section .data, size 0x3ec lma 0x113950
Start address 0x100040, load size 81212
Transfer rate: 46406 bits/sec, 303 bytes/write.
(gdb) continue
Continuing.
Program received signal SIGBUS, Bus error.
Cannot access memory at address 0xfc0ffc01
0x00100040 in ?? ()
(gdb)
-
I also checked
h...@home-desktop:~/test2$ xscale-elf-objdump -f basic1
basic1: file format elf32-bigarm
architecture: xscale, flags 0x0112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00100040
--
Thanks
Ajit
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Please join ecos forum #ecos on irc server freenode
Ajit Mittal wrote: Lot of people have problem with ecos. Please join #ecos forum at freenode for help and take help. IRC is *not* the way to share information :-( The mailing list is much preferred as it is fully logged and searchable. I have a problem but unable to find the solution. Perhaps if you provided more information, you'd get better feedback. For example, we don't even know what platform you are trying to run eCos on. Or how you configured and built your application. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Problem executing anything on IXP425 based board, redboot is the bootloader
Ajit Mittal wrote: Ihave a board with total RAM of 32 MB, 2 chips of 16 MB each. It has 8 MB flash. It has redboot bootloader and platform is IXP425 processor Booting is fine. I am able to load the program fine to memory but executing gives me an error grabage output on serial output after executing go or exec command like this $T050f:0100;0d:01fc0fec;#d6. I think memory/interrupt of the board is bad. How to test RAM. This is not garbage; it's RedBoot telling you that there is a problem executing the code. This is a GDB protocol string. You could try connecting via GDB to find out why (search the archives) If suppose RAM is bad. Is it possible to modify redboot and burn it again and then use only 16MB RAM.If yes how to do that or how to troubleshoot. More importantly, tell us how you configured eCos to build this program. What steps did you use to load execute it (the actual RedBoot commands and the output when you run them). Without this level of detail, we'd just be guessing... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Problem executing anything on IXP425 based board, redboot is the bootloader
Ajit Mittal wrote: Thanks a lot for your help. Please keep replies on the eCos mailing list so that all may benefit. Private support is available with a support contract only. I have 2 same boards. both running same bootloader. On one openwrt linux is running fine. I created the redboot using intel from this link http://www.intel.com/design/network/products/npfamily/download_ixp400.htm Instructions are clear and I know redboot build system like I use ecosconfig to build the environment for my baord and then use make utility for building it, but not expert in changing files. I load it through the ethernet and access it through serial consle. I have tried GDB but don't know how to troubleshoot it. Thanks again for helping me. You've still not provided the info about how you configured your program. Be specific - prose is inconcise and error prone. Also, what are the *exact* commands you typed to RedBoot? On Wed, Aug 19, 2009 at 2:53 PM, Gary Thomasg...@mlbassoc.com wrote: Ajit Mittal wrote: Ihave a board with total RAM of 32 MB, 2 chips of 16 MB each. It has 8 MB flash. It has redboot bootloader and platform is IXP425 processor Booting is fine. I am able to load the program fine to memory but executing gives me an error grabage output on serial output after executing go or exec command like this $T050f:0100;0d:01fc0fec;#d6. I think memory/interrupt of the board is bad. How to test RAM. This is not garbage; it's RedBoot telling you that there is a problem executing the code. This is a GDB protocol string. You could try connecting via GDB to find out why (search the archives) If suppose RAM is bad. Is it possible to modify redboot and burn it again and then use only 16MB RAM.If yes how to do that or how to troubleshoot. More importantly, tell us how you configured eCos to build this program. What steps did you use to load execute it (the actual RedBoot commands and the output when you run them). Without this level of detail, we'd just be guessing... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] How to write a complicated bootloader?
Stanislav Meduna wrote: Hi, I have a hardware with a complicated ethernet device that is not usable in a polled mode (or at least I don't have enough documentation to be able to use it in such a way). There is an OEM driver needing all kind of stuff (including eCos kernel) to run, that works fine in a regular application. The hardware has a serial port, which is enough for debugging, but pain in the you know where for downloading our 2+ MB large binary over max. 115200 bps. In the field this serial port won't be available at all, so the only way to upgrade the device is via ethernet. What I'd like to have is some kind of bootloader, that is able to - load the application via ethernet - manipulate the flash (application upgrade and at least initialize the jffs, even better to access it filewise) - start the loaded application - support debugging the application at least over serial line including the asynchronous ctrl-c support (ethernet in a way of gdbserver would be nice, but I imagine this can't be achieved in the eCos architecture where the application and OS can't be really separated) Is there any special magic in loading an application somewhere into memory and transfer control to it, while leaving the GDB stubs in the bootloader? For the development cycle I imagine something like: - connect with the gdb over serial - connect with a telnet-like interface over ethernet - initiate a tftp load - run the application - the application loads, runs and breaks into the gdb as soon as the basic initialization is done (everything else in the bootloader is now dead, only the vectors needed for serial comm remain) Is there information (and examples) available on how to approach this? Many thanks for hints Rather than reinvent the wheel (or maybe fire...), I think you'd be better off just getting your ethernet device driver running with RedBoot. eCos network drivers use the same API whether they are running in a full eCos application (using interrupts) or as part of RedBoot (polled), so it should be pretty easy to get it to work if you already have code that runs with a full eCos system. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] JFFS2 alternative
Øyvind Harboe wrote: JFFS2 is fine for smaller file systems, but it breaks down completely on large file systems. What do you mean it breaks down completely? Does anyone know of viable eCos alternatives to JFFS2? LogFS is GPL v2 without exception, so that would make the application linked with eCos GPL. Ditto for UBIFS. I guess it's no good to create a loadable eCos module either. Even if that would allow our application to work with any filing system. It would be a poorly veiled attempt at circumventing GPL, wouldn't it? GPL is problematic because the work in question is under NDA. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] RE: first time compiling ecos
adi baron wrote: Hi thank you for your answer. I have decided to move to compilation on linux - from my experience this would be more native for cross compilers. The absolute best choice (IMO)! I have installed ecos and both EABI and elf toolchain from the tcl script. Now I am facing a new problem on ubuntu machine: What ever package I choose to compile it seems to face similar problem - I receive to following error while compiling (using configuration tool). It seems arch is not build right by build tool from the template chosen. Or else I have searched the code and it seems due to missing include to hal_frv.h file Please advice home/adibaron/Projects/ecos/ecos-3.0/tools/bin/1_install/include/cyg/hal/hal_arch.h:59:5: warning: CYGINT_HAL_FRV_ARCH_FR500 is not defined make[1]: Leaving directory `/home/adibaron/Projects/ecos/ecos-3.0/tools/bin/1_build/hal/arm/arch/v3_0' /home/adibaron/Projects/ecos/ecos-3.0/tools/bin/1_install/include/cyg/hal/hal_arch.h:62:7: warning: CYGINT_HAL_FRV_ARCH_FR400 is not defined make: Leaving directory `/home/adibaron/Projects/ecos/ecos-3.0/tools/bin/1_build' /home/adibaron/Projects/ecos/ecos-3.0/tools/bin/1_install/include/cyg/hal/hal_arch.h:66:2: error: #error No architecture defined? In file included from /home/adibaron/Projects/ecos/ecos-3.0/packages/hal/arm/arch/v3_0/src/hal_mk_defs.c:56: /home/adibaron/Projects/ecos/ecos-3.0/tools/bin/1_install/include/cyg/hal/hal_arch.h:126: error: ‘_NGPR’ undeclared here (not in a function) How did you configure this? If you tell us your steps, we can try and help out. -Original Message- From: John Dallaway [mailto:j...@dallaway.org.uk] Sent: Tuesday, June 23, 2009 3:17 PM To: adi baron Cc: ecos-discuss@ecos.sourceware.org Subject: Re: first time compiling ecos Hi Adi adi baron wrote: I would be happy to use ecos tested toolchain but it seems that the link (ftp://ftp.sourceware.org/pub/ecos/gnutools/cygwin/ecoscentric-gnutools-arm- elf-1.4-2.cygwin.tar.bz2) provided does not work. Apologies. The correct location is: ftp://ecos.sourceware.org/pub/ecos/gnutools/cygwin/ecoscentric-gnutools-arm-elf-1.4-2.cygwin.tar.bz2 John Dallaway -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Redboot size_t signedness issue
Stanislav Meduna wrote:
Hi,
in the packages\redboot\...\fconfig.c there is a check
if ((fisdir_size-cfg_size) (CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_COUNT *
CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_SIZE)) {
// Too bad this can't be checked at compile/build time
diag_printf(Sorry, FLASH config exceeds available space in FIS
directory\n);
return;
}
This check does not work if the size_t is unsigned (which it happens
to be in the distributed arm-eabi-gcc 4.3.2) and cfg_size
is larger than fisdir_size.
Casting the cfg_size to int resolves the problem.
if ((fisdir_size-(int) cfg_size) ...
A better solution would be to remove any signed/unsigned ambiguity.
This test can be written equivalently as:
if (((CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_COUNT *
CYGNUM_REDBOOT_FIS_DIRECTORY_ENTRY_SIZE) + cfg_size) fisdir_size) {
If you can try this to see if it works on your setup, I'll commit
a proper change/patch.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: How to send UDP broadcast to 255.255.255.255?
Grant Edwards wrote: On 2009-06-16, Jay Foster j...@systech.com wrote: You can try the following patch that someone added to my local source. It adds a CDL option (CYGOPT_NET_INET_FORCE_DIRECTED_BROADCAST) to modify this behavior (the default being the same behavior you have now). Sorry it isn't in patch format, but it is straight forward. What is not shown here is configuring this option to '0' in your applications .ecm or template file. Thanks. I'll have to check to see if the need for the feature is significant enough to justify forking the network stack (something I'm pretty ruluctant to do). If this works and is useful to you, we can just check it in. After all, it's controlled by CDL, so the default behaviour will remain the same. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)
Paul D. DeRocco wrote: From: Mervin J As you told, there is some problem with stack pointer handling.Since the program behavior is not predicable with FIQ but works well with IRQ. How can i handle FIQ as it is,without taking it to IRQ level. I'm wondering why you're using FIQ at all. The only legitimate reason I can think of for trying to get FIQ to invoke an eCos ISR is that you've got some external device that's hard-wired to the FIQ pin, and you can't change the board. Otherwise, if you don't mind the overhead of the standard eCos ISR/DSR mechanism, then you'd do better to use a regular interrupt. (Remember, you can make any PIO line an interrupt input, although all such PIO lines would share an ISR.) If you're using FIQ because you want the lower overhead, then routing it to an ISR is probably not what you want. FIQ is most useful for implementing a software-based smart DMA-like system, where the only thing the FIQ handler does is some simple I/O, and not invoking an ISR until some buffer is full or empty. In that case, you should be writing it in assembler. Indeed. I tried to make the FIQ handling the same as IRQ handling back when the ARM port was originally done (ca 1998). Experience has shown that this probably doesn't make sense and the best way to handle FIQ (if you need them at all) is to install your own IHR (interrupt handling routing), typically written 100% in assembler. Try looking at the audio handling in the Cirrus EDB7xxx platform. It uses an FIQ routine to perform DMA like feeding of the audio chip. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Problem in FIQ with ecos for arm(at91sam7x)
Mervin J wrote: Hi, The main reason for using FIQ is that, In Hardware, The external interrupt pin is connected to FIQ pin and also we want to get the interrupt within few ms. I succeed by handling as GPIO Interrupt. But, While handling as FIQ,there is some stack overwrite issue. One more question is that, Whether I can redirect the FIQ to a simple C routine and return to the User mode without more complexity. No Thanks a lot for Your suggestion in handling FIQ. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] copy FIS directory - fis load problem?
M Core wrote: Does anyone know how to copy FIS directory to RAM? (My goal it to copy it off the boards so I can avoid running fconfig on every board). The problem fis load doesn't seem to do anything. RedBoot mfill -b 0x00218000 -l 0x100 -p -4 RedBoot dump -b 0x00218000 -l 0x100 00218000: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218010: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218020: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218030: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218040: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218050: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218060: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218070: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218080: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218090: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180A0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180B0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180C0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180D0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180E0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180F0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || RedBoot fis load -b 0x00218000 -c FIS directory RedBoot dump -b 0x00218000 -l 0x100 00218000: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218010: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218020: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218030: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218040: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218050: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218060: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218070: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218080: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 00218090: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180A0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180B0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180C0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180D0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180E0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || 002180F0: B3 15 00 00 B3 15 00 00 B3 15 00 00 B3 15 00 00 || RedBoot fis load -b 0x00218000 -c FIS directory What's the platform? It works fine on my PowerPC based systems: RedBoot fi lo -b 0x10 FIS directory RedBoot x -b 0x10 0010: 28 72 65 73 65 72 76 65 64 29 00 00 00 00 00 00 |(reserved)..| 00100010: F0 00 00 00 F0 00 00 00 00 02 00 00 00 00 00 00 || Also note that the command you issued is not going to save the 'fconfig' data. For that, you'd need to load 'RedBoot config' RedBoot x -b 0x10 0010: 00 00 10 00 0B AD FA CE 01 0C 01 00 62 6F 6F 74 |boot| 00100010: 5F 73 63 72 69 70 74 00 00 00 00 00 04 11 01 0C |_script.| -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Booting Linux from arm
Gilles Bulthé wrote: Hello, I have difficulties to boot Linux Kernel from my xm27 based platform, and am wondering whether there is link with RedBoot or not. My customized RedBoot starts as following : --- StartOfQuote--- ... Read from 0x03ee-0x03f0 at 0xa006: . ... Read from 0x03ed3000-0x03ed4000 at 0xa007f000: . Turning on PMIC regulators: 1,2,3,4,5 Unrecognized chip: 0xf8!!! hardware reset by WDOG Clock input is 24 MHz Booting from [NOR flash] RedBoot(tm) bootstrap and debug environment [ROMRAM] Non-certified release, version FSL 200904 - built 16:22:29, May 22 2009 Platform: Freescale (i.MX27 ) PASS 1.0 [x32 DDR] Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. Copyright (C) 2003, 2004, 2005, 2006 eCosCentric Limited RAM: 0x-0x03f0, [0xeb78-0x03ed1000] available FLASH: 0xa000 - 0xa400, 512 blocks of 0x0002 bytes each. RedBoot RedBoot load -r -m xmodem -b 0x10 CRaw file loaded 0x0010-0x0028940f, assumed entry at 0x0010 xyzModem - CRC mode, 12585(SOH)/0(STX)/0(CAN) packets, 1 retries RedBoot exec entry=0x80008000, target=0x80008000 Using base address 0x0010 and length 0x00189410 Uncompressing Linux. done, booting the. EndOfQuote--- and then, it stops. I see RAM: 0x-0x03f0, [0xeb78-0x03ed1000] available - why is not all the RAM available ? RedBoot uses the RAM which is listed as not available And : entry=0x80008000, target=0x80008000 - this entry point 0x8008000 is then out of available range, isn't it ? Is it possible to change it ? There are options to 'exec' for this. Try 'help exec' :-) Also, the address '0x80008000' is a PHYSICAL address. The addresses printed by RedBoot (available range, etc) are LOGICAL addresses - not the same. Regarding my ARM Linux sources and debugging with LED, I have notice that Linux bugs from the moment when it __turn_mmu_on. There may be a link. I am now thinking that the MMU and the memory related lines quoted above may have link, but do not really know how. If you have any idea about what's going on, it would be very helpfull ! Thank you in advance for reading me. Gilles. You really should ask these questions on the Linux-ARM lists, not here, as they have basically nothing to do with eCos/RedBoot. -- 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
[ECOS] Re: nc_test_slave in lwIP
Simon Kallweit wrote: Hi Gary As you probably know I've been working on getting lwIP 1.3 into eCos. I had a look at the nc_test_slave test case and upgraded it to get it working with lwIP 1.3. What is this test based on? Is there a corresponding host utility to execute the nc tests? Those tests were written from scratch (by me). They have no relationship, other than basic philosophy to any other program. In the same directory where that test lives, look at 'make.host' :-) Many of these tests can be built for either eCos or non-eCos (e.g. Linux) Sorry if I bother you with this, but your name is mentioned in the source file, so I thought I'd give it a try :) Nonetheless, CC'ing the mailing list is good for all parties. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] ram usage by redboot
Robert Brusa wrote: Hi all I have configured a redboot (using ecos-3.0) for my target. Upon power up it writes out (among a lot of other stuff): Platform: AT91ICB (ARM7TDMI) RAM: 0x0020-0x0022 [0x00204c48-0x0021f300 available] FLASH: 0x0010-0x0013, 1024 x 0x100 blocks This makes me wunder: a) What is the RAM up from 0x0021f300 used for? I can find no hint in the map. It's used as an ad-hoc workspace, mostly for manipulating FLASH. Since the details of the FLASH device are not necessarily at compile time, this has to be dynamic (e.g. the size of a FLASH erase page). Carving this off the end was the simplest way to solve these problems. b) It writes out the flash available on this machine. Why not the flash actually available for other programs? This information is too dynamic/complex for a single print. You get that from 'fis free' Thanks for comments on this issue. Robert -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Building Redboot using specific CFLAGS
alfred steele wrote: Hi All, I am trying to quai-automate the build process for redboot. Inthe process of doing so, i need a way through which i can edit the cdl_option CYGBLD_GLOBAL_CFLAGS through a script. Is there any way that i can override the default CYGBLD_GLOBAL_CFLAGS before doing a ecosconfig tree using the command line instead of editing the file ecos.ecc. Just curious; what CFLAGS are you changing and why? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Using C++ std streams (fstream, ofstream and ifstream) in eCos.
grinder213 wrote: Hi, I'm trying to use the file stream classes of the standard C++ library together with a mounted FAT file system on a SD card. I'm using the eCoscentric release of 2.98. on a ATMEL AT91SAM9260-EK. The regular BSD calls to the filesystem are working just fine! I use the same device paths and filenames in the two examples. When I try to use either the fstream, ofstream or ifstream, the code compiles with no problems, but the open calls (either directly or through the constructor) never succeeds. Is it possible to use the file stream classes the way I want to use them? C++ stdlib is not supported in the public CVS. Check the archives as some help may be available (Zylin has some code, eCosCentric can provide a complete package, etc) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Building Redboot using specific CFLAGS
n.b. please CC the eCos discussion list so that all may benefit. alfred steele wrote: Just curious; what CFLAGS are you changing and why? I am adding another cflag for conditional compile for our custom board. You should probably add this to the CDL [directly] so that it is automatic when you select your target. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] Re: SNMP lockup
Sergei Gavrikov wrote: On Fri, May 08, 2009 at 10:38:24PM +, Grant Edwards wrote: On 2009-05-08, Sergei Gavrikov sergei.gavri...@gmail.com wrote: If your guess is right... It's not a guess. The problem occurs when cyg_snmp_get_if() is called with if_num = 0. The loop takes 1-2 minutes to loop from -1, -2, back to 0, causing the SNMP management thread to lock out all lower priority threads while it's doing so. Then fix it. Can you walk here with/without tweaks when if_num=0 repo/devo/ecos/packages/net/snmp/agent/current/src/mibgroup/mibII/interfaces.c:398 [snip] I'm surprised nobody else has run into this. I'm told all our customers who have HP or Cisco SNMP managers have had to disable SNMP support in our products to keep them from locking up every few minutes. I was just googling +'ifPhysAddress.0' It seems you are not alone :-) http://mtsc.moxa.com:/Software/DN/NPort/Firmware/NPort%205000/NPort%205600/ver3.2/VERSION.TXT quote ver3.1 (2006/05/16) 3. Fixed the problem that querying NPort by SNMP Software would cause NPort stop replying ethernet packet while querying GET iso.3.6.1.2.1.2.2.1.6.0, which is resolved as GET iso.org.dod.internet.mgmt.mib-2.interface.ifTable.ifEntry.ifPhysAddress.0. /quote UCD-SNMP had a lot of holes. eCos UCD-SNMP implementation has even more holes :-( Feel free to improve this - much of the networking code, including SNMP, is more than seven (7!) years old. A lot has gone on in the world in that time... -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] implementation of my personal TCP/IP stack
Jean François HARDY wrote: Hello, eCos people ! I'm working on the implementation of the TCP/IP networking. Today, i use the eCos kernel for MPC5567 (packages : net) , and it's run correctly. But, in this project, i want implementing my personal TCP/IP stack. To resume, i have a FEC driver (fast Ethernet control) of my evaluation board, my TCP/IP stack and the eCos environment. I seek the entrance point in the environment eCos of the current eCos stack (Net package). I must keep the Ethernet driver, and implement my stack on the high level of the driver (eth_drv.h). How to connect my TCP/IP stack to the environment eCos? Which configuration (packages) advise me to tackle this problem? Since this has already been done 3 times, it should be straight forward for you. Just look at the differences in choosing the old (OpenBSD), new (FreeBSD) or LWIP stacks. The low level interface remains the same - the API comes from io/eth -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Re: [ECOS] implementation of my personal TCP/IP stack
Andrew Lunn wrote: Since this has already been done 3 times, it should be straight forward for you. Isn't it four actually? Redboot? The interface is slightly different, polled rather than interrupt driven, but its not that different. True enough; I didn't even think of that one :-) -- 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
