headers
Dieter Schaefer | 2 Nov 2003 22:30
Picon
Favicon

target mcf5272c3 eva-board

Hello,

I'm trying to build eCos for the mcf5272c3 eva-board. 
It fails when compiling dbg_gdb.cxx , default packages 
selected. Using the package section 'net', it fails to 
compile if_mcf5272.c

I've build the m68k tool-chain according the description, 
and use the ecos-trunk-031102 snapshot.

What am I missing, or what did I do wrong?  
Any information or hint on this topic is appreciated.

Best Regards
Dieter Schaefer
Permalink | Reply | 0 comments |
headers
Tue Brems Olesen | 3 Nov 2003 12:39
Picon
Picon

Porting eCos to PPC 405cr board


Hello,

I am in the process of porting eCos to a board with a PowerPC 405cr
processor.

Currently, eCos supports the PPC 405GP processor, which has built-in PCI
bus and ethernet controller. The PCI subsystem is initialized in the
ppc40x variant code (packages/hal/powerpc/ppc40x/current/include/var_io.h).

However, the PPC 405CR processor has neither PCI bus or ethernet
controller. Hence, the HAL code should not try to initialize them.

My question is: Which method is best for solving the problem: 

1) Wrap the 405GP / 405CR specific code in #define's, keeping all
   code for the different PPC 405 chips in one common file,

or:

2) Create a 405CR-specific variant of the eCos HAL, in a separate
   directory tree in the packages/hal/powerpc structure.

(any better suggestions are, of course, very much appreciated)

Best regards,
--Tue

--

-- 
Tue Brems Olesen          | phone: +45 6133 5015 / +45 9633 0865
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gary Thomas | 3 Nov 2003 12:24
Favicon

Re: Porting eCos to PPC 405cr board

On Mon, 2003-11-03 at 04:39, Tue Brems Olesen wrote:
> Hello,
> 
> I am in the process of porting eCos to a board with a PowerPC 405cr
> processor.
> 
> Currently, eCos supports the PPC 405GP processor, which has built-in PCI
> bus and ethernet controller. The PCI subsystem is initialized in the
> ppc40x variant code (packages/hal/powerpc/ppc40x/current/include/var_io.h).
> 
> However, the PPC 405CR processor has neither PCI bus or ethernet
> controller. Hence, the HAL code should not try to initialize them.
> 

and it won't if you don't include those packages!

> My question is: Which method is best for solving the problem: 
> 
> 1) Wrap the 405GP / 405CR specific code in #define's, keeping all
>    code for the different PPC 405 chips in one common file,
> 
> or:
> 
> 2) Create a 405CR-specific variant of the eCos HAL, in a separate
>    directory tree in the packages/hal/powerpc structure.
> 
> 
> (any better suggestions are, of course, very much appreciated)

Choice (1) is correct.  Note: eCos does run on other 405 processors,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pablo Huerta | 4 Nov 2003 10:43
Picon

Problems with C and Math libraries


Hi,

I'm working in a port to a new target, and I'm having troubles with the
C and Math libraries. The problem is the following: 

When compiling tests for these libraries, the "cyg_libc_main_thread"
constructor and all related stuff to it are not linked, and when running
the tests they loop around all the time at "hal_idle_thread".

I have two questions about it:

Does anyone have any idea about why I'm having this trouble with the
inizialization of this tests?

Is there any way to force eCos to use the standard inizialization for
programs using C and Math libraries (that is, booting from "main"
instead of using "cyg_iso_c_start")?

Thanks to all. I would very pleased if anyone can help me.

Pablo Huerta

P.D: I'm using eCos 2.0, and gcc 3.3.1. I'm also tried with GCC 2.95,
3.1 and 3.4.
Permalink | Reply | 5 comments |
headers
Andrew Lunn | 4 Nov 2003 10:48
Picon

Re: Problems with C and Math libraries

On Tue, Nov 04, 2003 at 10:43:21AM +0100, Pablo Huerta wrote:
> 
> Hi,
> 
> I'm working in a port to a new target, and I'm having troubles with the
> C and Math libraries. The problem is the following: 
> 
> When compiling tests for these libraries, the "cyg_libc_main_thread"
> constructor and all related stuff to it are not linked, and when running
> the tests they loop around all the time at "hal_idle_thread".
> 
> I have two questions about it:
> 
> Does anyone have any idea about why I'm having this trouble with the
> inizialization of this tests?

They should just work. It sounds like a configuration problem, or
possibly a compiler problem. What target is this? Is it a well known
and tested CPU, or some weird and wonderful new device?

Do an ecosconfig export and mail us the results. 

   Andrew
Permalink | Reply | 4 comments |
headers
Pablo Huerta | 4 Nov 2003 11:16
Picon

Re: Problems with C and Math libraries

First of all, thanks for your answer.

The target is OpenRISC 1000 architecture.

The port I'm working on is based on a previous version from eCos 1.3.1,
that has been deeply tested and works 100%.

I know that there is a port of version 2.0 for that architecture at eCos
CVS, but it doesn't work at all, so I decided to make a new one.

Actually, the port I'm working on works except for that two libraries, C
and Math. All the other tests run correctly.

I attach the file export.out with an export with the minimal
configuration.

About a possible compiler problem, I have already thinked about it, and
with GCC versions 3.3.1 and 3.4 it's possible that the compiler is not
100% accurate, but the port of version 2.95.3 has been deeply tested
with ecos 1.3.1 and other aplications and it seems to work 100% OK.

Thanks for your help,

Pablo Huerta

El mar, 04-11-2003 a las 10:48, Andrew Lunn escribió:
> On Tue, Nov 04, 2003 at 10:43:21AM +0100, Pablo Huerta wrote:
> > 
> > Hi,
> >
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Lunn | 4 Nov 2003 11:57
Picon

Re: Problems with C and Math libraries

On Tue, Nov 04, 2003 at 11:16:07AM +0100, Pablo Huerta wrote:
> First of all, thanks for your answer.
> 
> The target is OpenRISC 1000 architecture.

> I attach the file export.out with an export with the minimal
> configuration.

I just tried your configuration on the synth target by just changing
the HAL packages. It worked fine.

> 
> About a possible compiler problem, I have already thinked about it, and
> with GCC versions 3.3.1 and 3.4 it's possible that the compiler is not
> 100% accurate, but the port of version 2.95.3 has been deeply tested
> with ecos 1.3.1 and other aplications and it seems to work 100% OK.

What binutils are you using. It could be a linker problem as well. You
need to find out why the linker is throwing out the constructor. 

     Andrew
Permalink | Reply | 2 comments |
headers
Pablo Huerta | 4 Nov 2003 12:35
Picon

Re: Problems with C and Math libraries


I'm using GNU assembler and linker version 2.11.93. Is this ok or I
should use a newer version?

I want to ask you another question. I have written a simply program to
test if the C and Math libraries are linked OK or not. It's attached as
"test.c". If I compile it with the "-S" flag, to obtain the assembler
file I can't see any call to "cyg_package_start", "cyg_iso_c_start",
etc. But when compiled and linked completely, if I use eCos 1.3.1 the
libc initializing functions are present (cyg_iso_c_start,
cyg_libc_main_thread, etc), but if I use eCos 2.0 there are not
present.Is it normal? Do I have to add something to the source file to
indicate that it must use the C library initialization? In which stage,
or how, does the linker realize that he must include the C library
initializing routines?

I hope I'm not boring you with such a lot of questions, but I have been
working on it a long time and I'm a bit desperated :-(

Thanks a lot,

Pablo Huerta

El mar, 04-11-2003 a las 11:57, Andrew Lunn escribió:
> On Tue, Nov 04, 2003 at 11:16:07AM +0100, Pablo Huerta wrote:
> > First of all, thanks for your answer.
> > 
> > The target is OpenRISC 1000 architecture.
> 
> > I attach the file export.out with an export with the minimal
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gary Thomas | 4 Nov 2003 12:54
Favicon

Re: Problems with C and Math libraries

On Tue, 2003-11-04 at 04:35, Pablo Huerta wrote:
> I'm using GNU assembler and linker version 2.11.93. Is this ok or I
> should use a newer version?
> 
> I want to ask you another question. I have written a simply program to
> test if the C and Math libraries are linked OK or not. It's attached as
> "test.c". If I compile it with the "-S" flag, to obtain the assembler
> file I can't see any call to "cyg_package_start", "cyg_iso_c_start",
> etc. But when compiled and linked completely, if I use eCos 1.3.1 the
> libc initializing functions are present (cyg_iso_c_start,
> cyg_libc_main_thread, etc), but if I use eCos 2.0 there are not
> present.Is it normal? Do I have to add something to the source file to
> indicate that it must use the C library initialization? In which stage,
> or how, does the linker realize that he must include the C library
> initializing routines?
> 

There should be a reference to "cyg_start" in your "vectors.S" which
is the key file that gets linked with the eCos kernel library.  This
reference in turn will call out to cyg_iso_c_start or 
cyg_libc_main_thread or whatever (albeit indirectly).

> I hope I'm not boring you with such a lot of questions, but I have been
> working on it a long time and I'm a bit desperated :-(
> 
> Thanks a lot,
> 
> Pablo Huerta
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pablo Huerta | 4 Nov 2003 17:12
Picon

Missing Option


Hi all again,

I've been reading again the eCos 2.0 reference manual, and in the
section "C library startup" it talks about a configuration option called
CYGSEM_START_ISO_C_COMPATIBILITY (that seems it is what I need to get
the C and Math tests run properly). The problem is that this option
doesn't exists, at least in the eCos distribution I have. I have created
the default configuration files for a few targets (i386, arm, etc) with
"ecosconfig new target" and this option is neither active nor inactive,
it simply is not defined at all in the .ecc file. 

Is this normal? I have tried it on ecos-1.3.1 and
CYGSEM_START_ISO_C_COMPATIBILITY is included in the defualt
configuration for every target.

Can anyone send to me a configuration file (.ecc) in which that option
appears?

Thanks,

Pablo Huerta
Permalink | Reply | 2 comments |

Gmane