gmane.os.ecos.general

Does NetBSD IPv6 honor rmx_expire?

Grant Edwards — 2012-05-24T22:03:32

Does the NetBSD IPv6 implementation honor the  rtm_rmx.rmx_expire
field in an rt_msghdr structure when IPv6 routes are added?

IOW, if the rmx_expre field is non-zero, will the network stack
automatically delete the route after the specified number of seconds?

RE: Test microwindows nano-x

Christophe Coutand — 2012-05-24T17:57:18

Are you sure this is the correct config file? You have a lot of conflict
in it to be resolved. I might remember wrong but I don't think MW will
compile with LWIP stack.

Christophe

-----Original Message-----
From: medamine [mailto:medamine.ecos< at >gmail.com] 
Sent: 24. mai 2012 15:06
To: Christophe Coutand
Cc: ecos-discuss< at >ecos.sourceware.org
Subject: Re: [ECOS] Test microwindows nano-x

No, I didn't try to compile for synthetic target, but i develop a driver
Frame buffer for STM3240G-EVAL and I add the nano-x library and try to
compile

this is here the config file

Help with LwIP in ecos-3.0

Elad Yosef — 2012-05-24T15:27:46

Hi all I get the following Trace by GDB

(gdb) bt
#0  ~Cyg_Mboxt (this=0x80046e10) at
/localhome/cc-views/elady_Mars_SW/vobs/Mars-eCos/Mars-eCos_OS/Mars_eCos_Config_install/include/cyg/kernel/mboxt.inl:105
#1  0x80017255 in ~Cyg_Mbox (this=0x80046e10) at
/localhome/eCos/ecos-3.0/packages/kernel/v3_0/src/sync/mbox.cxx:92
#2  0x80014409 in cyg_mbox_delete (mbox=2147773968) at
/localhome/eCos/ecos-3.0/packages/kernel/v3_0/src/common/kapi.cxx:851
#3  0x80022a41 in sys_mbox_free (mbox=2147773968) at
/localhome/eCos/ecos-3.0/packages/net/lwip_tcpip/v3_0/src/ecos/sys_arch.c:108
#4  0x800282bd in netconn_delete (conn=0x80049b98) at
/localhome/eCos/ecos-3.0/packages/net/lwip_tcpip/v3_0/src/api/api_lib.c:304
#5  0x800222b5 in lwip_close (s=<value optimized out>) at
/localhome/eCos/ecos-3.0/packages/net/lwip_tcpip/v3_0/src/api/sockets.c:268

My connect fails (due to wrong IP, but that's O.k by me) so I close
the TCP socket and get the ASSERT from mboxt.inl:105
deleting mbox with messages.

How bad is it? can I ignore it?

Elad

RE: Test microwindows nano-x

Christophe Coutand — 2012-05-23T21:36:14

Did you try compiling for the synthetic target? If yes, did it compile
correctly?

Can you post your eCos configuration file for the STM3240G-EVAL?

Christophe

-----Original Message-----
From: ecos-discuss-owner< at >ecos.sourceware.org
[mailto:ecos-discuss-owner< at >ecos.sourceware.org] On Behalf Of medamine
Sent: 22. mai 2012 12:58
To: ecos-discuss< at >ecos.sourceware.org
Subject: [ECOS] Test microwindows nano-x

Hello every one,

I'm a new user of the microwindows library.
I used the STM3240G-EVAL. I added the framebuffer driver and it's work 
correctly

So, i try to test the nano-x librairie. I followed the procedure in this

link. I added the framebuffer driver, linux netand the microwindows 
library in the configuration with the corresponding changes.

http://www.open-etech.com/RTOS/Debugging/index.php?page=mw

and I tried to build eCos and test the tetris demo but I got these
errors

make[1]: Entering directory 
`/home/st/config_Fatfs/mw_config_build/language/c/libc/setjmp/current'
arm-eabi-gcc -c -I/home/st/config_Fatfs/mw_config_install/include 
-I/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current 
-I/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/src 
-I/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/tests 
-I. 
-I/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/src/ 
-finline-limit=7000 -Wall -Wpointer-arith -Wundef -Woverloaded-virtual 
-Wno-write-strings -mcpu=cortex-m3 -mthumb -g -O2 -ffunction-sections 
-fdata-sections -fno-rtti -fno-exceptions -Wp,-MD,src/longjmp.tmp -o 
src/language_c_libc_setjmp_longjmp.o 
/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/src/longj
mp.cxx
make[1]: Leaving directory 
`/home/st/config_Fatfs/mw_config_build/language/c/libc/setjmp/current'
In file included from 
/home/st/config_Fatfs/mw_config_install/include/setjmp.h:69,
make: Leaving directory `/home/st/config_Fatfs/mw_config_build'
from 
/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/src/longj
mp.cxx:72:

/home/st/config_Fatfs/mw_config_install/include/cyg/posix/sigsetjmp.h:73
: error: 
'sigset_t' does not name a type
make[1]: *** [src/longjmp.o.d] Error 1
make: *** [build] Error 2

It seams an error in the POSIX package.

If any one have any idea about the problem and what should i do?

Great Thanks.

Re: DSR interruptible by scheduler + memory barriers

Stanislav Meduna — 2012-05-22T19:40:20


No. The scheduler lock is claimed while running the DSR
and as far as I know the DSRs are serialized. I can't
comment on multiprocessor cases.


You most probably want to. A thread cannot preempt a DSR, but a DSR
will preempt a thread. So the structures used by both should
be protected.


Search for the HAL_REORDER_BARRIER in your HAL.


A memory barrier and volatile are different beasts. A barrier
only prevents reordering of the memory accesses; it does nothing
with decisions of the compiler what to put in a register or
what optimization it can perform. At least not generally -
maybe gcc gives more guarantees. But it does this even regarding
visibility from other processor cores.

On the other side volatile guarantees that all memory accesses
actually take place and prevents reordering of the volatile
accesses. It does not preserve any order with relation to
non-volatile ones and on a multiprocessor system the order
observed from another processor might be different.


Regarding your case: an eCos driver should not allow the ISR
from the same source to be called before the DSR is complete
(you normally mask and ack the interrupt source in the ISR
and unmask at the end of its DSR).

For the thread/DSR synchronisation use cyg_drv_dsr_lock/unlock
which on systems with scheduler map to cyg_scheduler_lock/unlock.
This guarantees that no DSR will run while a thread is in this
section.

You for sure don't need the barrier here - the lock/unlock will
take care of this (if not, it is a bug).

Strictly said you need volatile here, because if the compiler
provably finds out that the lock/unlock calls do not touch
the variable in question, it is free to cache it in the register
across that call. However, with the function being in another
compilation unit this would be only possible with some
link-time optimization and it would need adressing at much
broader level anyway.

Regards

DSR interruptible by scheduler + memory barriers

Martin Laabs — 2012-05-22T18:01:34

Hello,

unfortunately I couldn't find the answer in the documentation. If the 
scheduler runs a DSR. Can this DSR become interrupted by an other thread or 
another DSR? (Of cause an ISR can interrupt it)

The background is that I wanna share data between a thread an a DSR and 
want to know whether I have to call cyg_(un)lock_scheduler when changing 
the data.

And another question about that - how are memory barriers implemented in 
eCos? (Are they implemented at all?)
Background: I have - for example - a status bit field that is copied to a 
(ISR/DSR) shared variable in the ISR. Now - if the compiler decides to put 
this variable into a register (in the ISR function) the DSR will get the 
wrong data. I could of cause declare the variable as volatile but this 
might be a performance issue in other cases where more data is affected.

Best regards,
  Martin Laabs

Test microwindows nano-x

medamine — 2012-05-22T10:58:18

Hello every one,

I'm a new user of the microwindows library.
I used the STM3240G-EVAL. I added the framebuffer driver and it's work 
correctly

So, i try to test the nano-x librairie. I followed the procedure in this 
link. I added the framebuffer driver, linux netand the microwindows 
library in the configuration with the corresponding changes.

http://www.open-etech.com/RTOS/Debugging/index.php?page=mw

and I tried to build eCos and test the tetris demo but I got these errors

make[1]: Entering directory 
`/home/st/config_Fatfs/mw_config_build/language/c/libc/setjmp/current'
arm-eabi-gcc -c -I/home/st/config_Fatfs/mw_config_install/include 
-I/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current 
-I/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/src 
-I/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/tests 
-I. 
-I/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/src/ 
-finline-limit=7000 -Wall -Wpointer-arith -Wundef -Woverloaded-virtual 
-Wno-write-strings -mcpu=cortex-m3 -mthumb -g -O2 -ffunction-sections 
-fdata-sections -fno-rtti -fno-exceptions -Wp,-MD,src/longjmp.tmp -o 
src/language_c_libc_setjmp_longjmp.o 
/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/src/longjmp.cxx
make[1]: Leaving directory 
`/home/st/config_Fatfs/mw_config_build/language/c/libc/setjmp/current'
In file included from 
/home/st/config_Fatfs/mw_config_install/include/setjmp.h:69,
make: Leaving directory `/home/st/config_Fatfs/mw_config_build'
from 
/home/st/ecos/ecos-3.0/packages/language/c/libc/setjmp/current/src/longjmp.cxx:72:

/home/st/config_Fatfs/mw_config_install/include/cyg/posix/sigsetjmp.h:73: error: 
‘sigset_t’ does not name a type
make[1]: *** [src/longjmp.o.d] Error 1
make: *** [build] Error 2

It seams an error in the POSIX package.

If any one have any idea about the problem and what should i do?

Great Thanks.

cine castiga

2012-05-21T17:50:47

http://www.youtube.com/watch?feature=youtu.be&hl=ro&v=_Sl3Ox7RMnE
 To unsubscribe please send email to unsubscribe< at >cc.psd-prahova.ro

zImage write from Busybox

Mukund — 2012-05-16T13:18:19

Hello All,

I am facing some issue when I flash kernel from busybox and try to boot 
from redboot console.
The same kernel work correctly when I write it using "fis write" 
command. Below are the steps:

1.load kernel + ramdisk from tftp by using below commands :
 > load -r -b 0x100000 zImage -h 10.100.4.78
2.Boot with above kernel using 'exec' command
3.Write zImage from busybox console by using below commands:
 > dd if=zImage of=/dev/block/mtdblock0 bs=128k
4. reboot busybox
5. Stop on redboot
6. load kernel with the help of following command :
 > fis load nx1
 > exec

Redboot stuck while uncompressing linux.
================================================
RedBoot> fis load qnx1
... Read from 0x07ee0000-0x07eff000 at 0x0ffa0000: ..
... Read from 0x00100000-0x00900000 at 0x00540000: 
.................................................................
RedBoot> exec
entry=0x80008000, target=0x80008000
Using base address 0x00100000 and length 0x00800000
Uncompressing Linux.............
================================================

Here is my mtd partitions :
~ # cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00800000 00020000 "nx1"
mtd1: 07520000 00020000 "fs1"
mtd2: 00800000 00020000 "nx2"
mtd3: 07520000 00020000 "fs2"
mtd4: 0001f000 00020000 "FIS directory"
mtd5: 00001000 00020000 "RedBoot config"

RE: Tools or commands for eCos to test footprint, startup time, and response time

Christophe Coutand — 2012-05-15T19:34:01

Hi,

For the footprint you can get most information from the GNU Binutils. Startup time you will have to implement. you can always use a HW timer early in redboot and dump it when your application is fully up and running but you will have to implement such timer for all architecture you are going to test. Response time? Not sure what this is. You can run some test applications such as:

- packages\kernel\current\tests\tm_basic.cxx or the Dhrystone kernel\current\tests\dhrystone.c

Only the i386 HAL support more than 1 core, if you google around, you will find some LEON3, ARM, PPC SMP HAL.

You could look at QEMU but it is not cycle accurate so not necessarily what you are looking for.

Christophe


-----Original Message-----
From: ecos-discuss-owner< at >ecos.sourceware.org [mailto:ecos-discuss-owner< at >ecos.sourceware.org] On Behalf Of Jianmei Guo
Sent: 4. mai 2012 16:03
To: ecos-discuss< at >sources.redhat.com
Subject: [ECOS] Tools or commands for eCos to test footprint, startup time, and response time

Hi,

Is there any tool or command available for ECOS to test footprint, 
startup time, and response time (or any other performance metrics) 
conveniently when eCos is running on different hardware platforms (e.g., 
i386 vs. Powerpc) and/or different software configurations (e.g., 2 cpu 
vs. 4 cpu)?

Another question is about the simulation of many different hardware 
platform. Now I just have several i386 PC and Apple MacBook...

Any help or suggestion would be appreciable. Thanks!


Best Regards,

Jianmei Guo, PhD
Postdoctoral Fellow
University of Waterloo
http://gsd.uwaterloo.ca/gjm

RE: Help with pthread_cond_timedwait

Christophe Coutand — 2012-05-15T19:03:37

You can possibly log the current time (cyg_current_time()) in pthread_cond_timedwait() before the call to:

((Cyg_Condition_Variable *)cond)->wait( *(Cyg_Mutex *)mutex, ticks );

and compare with the ticks value, that way you can rule out any issue with the time/ticks conversion.

Christophe

-----Original Message-----
From: ecos-discuss-owner< at >ecos.sourceware.org [mailto:ecos-discuss-owner< at >ecos.sourceware.org] On Behalf Of Graves, Daniel (GE Healthcare)
Sent: 15. mai 2012 17:34
To: ecos-discuss< at >sourceware.org
Subject: [ECOS] Help with pthread_cond_timedwait

Hello,

I've been developing some communication software that needs to wait for a message over a serial port.  I implemented it using pthread_cond_timedwait under Linux using 2.6.34 kernel.  Basically when a message comes over the serial port the pthread_cond_timedwait is signaled.  It waits for 200ms if it is not signaled in time.  This code has worked really well in Linux, but I needed to port it over to eCos.  At that point the exact same code would timeout immediately even though the serial messages were signaling it on time.  The error 360 for ETIMEDOUT was reporting and it was clear that it wasn't waiting long enough.  As a last desperate attempt to get this to work I changed the code to use cyg_cond_timed_wait and cyg_cond_mutex from eCos.  That worked for me and timeouts were no longer occurring.  However, I would like to know what is wrong with pthread_cond_timedwait, because it seems like there is a bug.  But after looking at the code for each function they both basically end up calling Cyg_Condition_Variable's wait methods.  Below is a snippet of the code I'm referring to.  I've searched through this mailing list for any similar topics.  There was one but that one focused on clock_gettime.  Unfortunately I do not know which version of eCos I'm using as I have just joined the project where we're using eCos.  I will try to find that out.

.....
  struct timespec waittime;
  struct timeval abstime;
.....

    gettimeofday(&abstime,NULL);
   //we want to wait 200 msec before declaring timeout
    abstime.tv_usec += 2000000;

    if(abstime.tv_usec >= 1000000)
    {
      abstime.tv_sec += 1;
      abstime.tv_usec = abstime.tv_usec % 1000000;
    }
    waittime.tv_sec = abstime.tv_sec;
    waittime.tv_nsec = abstime.tv_usec*1000;
    int cond_result = pthread_cond_timedwait(&ackcond,&readlock,&waittime);
    if ( cond_result != 0 )
    {
        printf("SerialComm:Failed to set the conditional variable, error = %d\n", cond_result);
    }
    else
    {
        #if DEBUG
        printf("SerialComm:Successfully set conditional variable ackcond\n");
        #endif
    }

......

Thanks,

Daniel P Graves

Help with pthread_cond_timedwait

Graves, Daniel (GE Healthcare — 2012-05-15T15:33:48

Hello,

I've been developing some communication software that needs to wait for a message over a serial port.  I implemented it using pthread_cond_timedwait under Linux using 2.6.34 kernel.  Basically when a message comes over the serial port the pthread_cond_timedwait is signaled.  It waits for 200ms if it is not signaled in time.  This code has worked really well in Linux, but I needed to port it over to eCos.  At that point the exact same code would timeout immediately even though the serial messages were signaling it on time.  The error 360 for ETIMEDOUT was reporting and it was clear that it wasn't waiting long enough.  As a last desperate attempt to get this to work I changed the code to use cyg_cond_timed_wait and cyg_cond_mutex from eCos.  That worked for me and timeouts were no longer occurring.  However, I would like to know what is wrong with pthread_cond_timedwait, because it seems like there is a bug.  But after looking at the code for each function they both basically end up calling Cyg_Condition_Variable's wait methods.  Below is a snippet of the code I'm referring to.  I've searched through this mailing list for any similar topics.  There was one but that one focused on clock_gettime.  Unfortunately I do not know which version of eCos I'm using as I have just joined the project where we're using eCos.  I will try to find that out.

.....
  struct timespec waittime;
  struct timeval abstime;
.....

    gettimeofday(&abstime,NULL);
   //we want to wait 200 msec before declaring timeout
    abstime.tv_usec += 2000000;

    if(abstime.tv_usec >= 1000000)
    {
      abstime.tv_sec += 1;
      abstime.tv_usec = abstime.tv_usec % 1000000;
    }
    waittime.tv_sec = abstime.tv_sec;
    waittime.tv_nsec = abstime.tv_usec*1000;
    int cond_result = pthread_cond_timedwait(&ackcond,&readlock,&waittime);
    if ( cond_result != 0 )
    {
        printf("SerialComm:Failed to set the conditional variable, error = %d\n", cond_result);
    }
    else
    {
        #if DEBUG
        printf("SerialComm:Successfully set conditional variable ackcond\n");
        #endif
    }

......

Thanks,

Daniel P Graves

General question on TCP/IP stability and security vulnerabilities

Mikhail Matusov — 2012-05-09T18:09:07

Could someone please comment on the following criticism found in Wikipedia:

The FreeBSD TCP/IP network stack port included with eCos is out of 
date—circa 2001—and exposes systems using such to numerous security and 
stability vulnerabilities (FreeBSD RELENG 4 4 0 RELEASE for IPv4 and 
FreeBSD's origin KAME for IPv6). Official eCos maintainers do not appear to 
monitor FreeBSD or KAME for security or stability updates, but rather rely 
on minimal and insufficient bug reports from users of eCos.
The SNMP package is rudimentary at best, once again, apparently due to its 
age.

Is a more robust TCP/IP stack for eCos available at cost?

Thanks,
/Mikhail

Re: simple redboot package donot build for i386!

abhishek srivastava — 2012-05-04T18:38:29

hi

i had renamed it to my name as file-->save as-->abhi. then build-->libraries
still got the similar error. please check the same at your end,if possible.
 
Abhishek kumar Srivastava

Tools or commands for eCos to test footprint, startup time, and response time

Jianmei Guo — 2012-05-04T14:02:42

Hi,

Is there any tool or command available for ECOS to test footprint, 
startup time, and response time (or any other performance metrics) 
conveniently when eCos is running on different hardware platforms (e.g., 
i386 vs. Powerpc) and/or different software configurations (e.g., 2 cpu 
vs. 4 cpu)?

Another question is about the simulation of many different hardware 
platform. Now I just have several i386 PC and Apple MacBook...

Any help or suggestion would be appreciable. Thanks!


Best Regards,

Jianmei Guo, PhD
Postdoctoral Fellow
University of Waterloo
http://gsd.uwaterloo.ca/gjm

Re: simple redboot package donot build for i386!

John Dallaway — 2012-05-04T07:46:11

Abhishek

abhishek srivastava wrote:


The error you are seeing may be just an issue with your current build
tree. Try giving your .ecc file a new name ("File->Save As..") and then
building the new configuration.

Once you have overcome the above issue, you will find that you need to
use the current lancepci ethernet driver sources from CVS when building
with i386-elf-gcc 4.3.2. Ref:

http://ecos.sourceware.org/cgi-bin/cvsweb.cgi/ecos/packages/devs/eth/amd/lancepci/current/src/if_lancepci.c.diff?r1=1.3&r2=1.4&cvsroot=ecos

I hope this helps...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

simple redboot package donot build for i386!

abhishek srivastava — 2012-05-04T03:36:55


hi
it seems that in my last post i was not clear with my question so no one responded !
just repeating the question with detailed error

i am trying to generate package "redboot" for i386 (vmware) hardware.
i have also imported "redboot_FLOOPY.ecm", made no change and tried to build library.
i got error !!! why?

the output i got after building library--


make -j4 --directory "/opt/ecos/ecos-3.0/work/redboot_build"

make: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build'
make -r -C hal/i386/arch/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/arch/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/arch/v3_0'
make -r -C hal/i386/generic/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/generic/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/generic/v3_0'
make -r -C hal/i386/pc/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/pc/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/pc/v3_0'
make -r -C hal/i386/pcmb/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/pcmb/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/pcmb/v3_0'
make -r -C io/pci/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/io/pci/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/io/pci/v3_0'
make -r -C devs/eth/amd/lancepci/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/devs/eth/amd/lancepci/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/devs/eth/amd/lancepci/v3_0'
make -r -C devs/eth/i386/pc/lancepci/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/devs/eth/i386/pc/lancepci/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/devs/eth/i386/pc/lancepci/v3_0'
make -r -C hal/common/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/common/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/common/v3_0'
make -r -C infra/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/infra/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/infra/v3_0'
make -r -C redboot/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/redboot/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/redboot/v3_0'
make -r -C isoinfra/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/isoinfra/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/isoinfra/v3_0'
make -r -C language/c/libc/string/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/language/c/libc/string/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/language/c/libc/string/v3_0'
make -r -C services/crc/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/services/crc/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/services/crc/v3_0'
make -r -C io/eth/v3_0 headers
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/io/eth/v3_0'
make[1]: Nothing to be done for `headers'.
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/io/eth/v3_0'
headers finished
make -r -C hal/i386/arch/v3_0 build
make[1]: Entering directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/arch/v3_0'
i386-elf-gcc -c  -I/opt/ecos/ecos-3.0/work/redboot_install/include -I/opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0 -I/opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0/src -I/opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0/tests -I. -I/opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0/src/ -finline-limit=7000 -Wall -Wpointer-arith -Wstrict-prototypes -Wundef  -Wno-write-strings -g -O2 -ffunction-sections -fdata-sections  -fno-exceptions -Wp,-MD,src/hal_misc.tmp -o src/hal_i386_arch_hal_misc.o /opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0/src/hal_misc.c
i386-elf-gcc -c  -I/opt/ecos/ecos-3.0/work/redboot_install/include -I/opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0 -I/opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0/src -I/opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0/tests -I. -I/opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0/src/ -finline-limit=7000 -Wall -Wpointer-arith -Wstrict-prototypes -Wundef  -Wno-write-strings -g -O2 -ffunction-sections -fdata-sections  -fno-exceptions -Wp,-MD,src/redboot_linux_exec.tmp -o src/hal_i386_arch_redboot_linux_exec.o /opt/ecos/ecos-3.0/packages/hal/i386/arch/v3_0/src/redboot_linux_exec.c
/opt/ecos/ecos-3.0/packages/pkgconf/rules.mak:89: recipe for target `src/hal_misc.o.d' failed
sed: can't read src/hal_misc.tmp: No such file or directory
make[1]: *** [src/hal_misc.o.d] Error 2
make[1]: *** Waiting for unfinished jobs....
/opt/ecos/ecos-3.0/packages/pkgconf/rules.mak:89: recipe for target `src/redboot_linux_exec.o.d' failed
sed: can't read src/redboot_linux_exec.tmp: No such file or directory
make[1]: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build/hal/i386/arch/v3_0'
make[1]: *** [src/redboot_linux_exec.o.d] Error 2
makefile:15: recipe for target `build' failed
make: *** [build] Error 2
make: Leaving directory `/opt/ecos/ecos-3.0/work/redboot_build'



i have checked that i have all the files in "D:\cygwin\opt\ecos\ecos-3.0\packages\hal\i386\arch\v3_0\src" named "hal_misc.c,hal_syscall.c, i386_stub.c,redboot_linux_exe.c" 

any help would be appreciable


Abhishek

Fw: eCosPro query

tayyaba azeem — 2012-05-03T05:25:22

 
Could anyone kindly provide me with the information regarding how and from where to 
buy eCosPro, it's price etc. I did visit http://www.ecoscentric.com though but could only find its datasheet with an email and contact no.s.

Another quick question is that I get to understand from eCosPro datasheet that 
it supports C++ libraries; what other advantages does it has over the open 
source eCos? May be if there's a Pro user on the list he/she could help.

Best Regards,  
Tayyaba Azeem

Re: error in building redboot for i386

abhishek srivastava — 2012-05-03T04:53:06

sir

i have used the template "redboot_floopy" by importing it and changed default IP address and ticked "do not use BOOTP" 
that's it !

________________________________
From: Fabrizio Carrai <fabrizio.carrai< at >gmail.com>
To: abhishek srivastava <just_abhi22< at >yahoo.co.in> 
Sent: Wednesday, 2 May 2012 3:03 PM
Subject: Re: [ECOS] error in building redboot for i386

Did you just use the template or did you change some parameters ?
F.
Il giorno 02/mag/2012 20:29, "abhishek srivastava" <just_abhi22< at >yahoo.co.in> ha scritto:

i get these errors while building for package "redboot", for target i386pc (vmware). what's actually missing? it seems some file are not available for building.how to rectify it?

error in building redboot for i386

abhishek srivastava — 2012-05-02T18:29:50

i get these errors while building for package "redboot", for target i386pc (vmware). what's actually missing? it seems some file are not available for building.how to rectify it?


sed: can't read src/hal_misc.tmp: No such file or directory
/opt/ecos/ecos-3.0/packages/pkgconf/rules.mak:89: recipe for target `src/hal_misc.o.d' failed
make[1]: *** [src/hal_misc.o.d] Error 2
make[1]: *** Waiting for unfinished jobs....
/opt/ecos/ecos-3.0/packages/pkgconf/rules.mak:119: recipe for target `src/context.o.d' failed
sed: can't read src/context.tmp: No such file or directory
make[1]: *** [src/context.o.d] Error 2
/opt/ecos/ecos-3.0/packages/pkgconf/rules.mak:89: recipe for target `src/i386_stub.o.d' failed
sed: can't read src/i386_stub.tmp: No such file or directory
make[1]: *** [src/i386_stub.o.d] Error 2
/opt/ecos/ecos-3.0/packages/pkgconf/rules.mak:89: recipe for target `src/hal_syscall.o.d' failed
sed: can't read src/hal_syscall.tmp: No such file or directory
make[1]: Leaving directory `/work/redboot_build/hal/i386/arch/v3_0'
make[1]: *** [src/hal_syscall.o.d] Error 2
makefile:15: recipe for target `build' failed
make: *** [build] Error 2
make: Leaving directory `/work/redboot_build'

 

Abhishek

Spital nou de pediatrie

2012-05-02T13:57:44

http://www.youtube.com/watch?feature=player_embedded&v=phjGxHn3uKU
 To unsubscribe please send email to unsubscribe< at >cc.psd-prahova.ro