Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

[Atsumi Hirose]

I'm using gcc-2.95.1 as an arm-elf cross compiler on a
Linux host.  I have only run small bits of code to
initialize the hardware, but it seems to be working so
far -- I haven't tried to run the eCos kernel yet.
What exactly are your errors?

Most of the code I've run so far is assembly
language, so I can't verify that there's nothing wrong
with 2.95.1...
 
Grant Edwards


-------------------------


Before I explain what errors I get, let me explain the
different methods I've used to try to get gcc-2.95.1
to work in eCos.  I basically tried 3 different
approaches however I played around with many files and
compiler options on each approach.

The first thing I tried to do was to build gcc-2.95.1
with the header files from an (arm-linux) linux-2.2.12
kernel that I built.  I was able to build the compiler
and glibc OK but the compiled ("hello world") test app
would not load through gdb.  If I remember correctly,
gdb frooze up after I typed "target remote
/dev/ttyS0".  I also tried to compile the file with
that compiler and the libarary and header files from
eCos but it would not compile.

The second approach I took was to build gcc-2.95.1
with both the header files from the (arm-linux) 2.2.12
kernel (asm and linux) folders, and the header files
from the eCos kernel
(/usr/local/ecos-1.2.1/ecos-work/install/include).  I
pretty much got the same results as my first attempt
with only the arm-linux kernel heade files.

In the previous attempt I did not overwrite any files
when merging the header files since the linux header
files were in their own directories (asm and linux). 
The third and last method I used was to follow the
same approach I took earlier, only overwrite any
arm-linux kernel header files with the header files
from the ecos kernel.  For example, the include file I
used for the building of the compiler had the asm and
linux folders from the arm-linux kernel and it also
had  the pkgcong, sys, and cyg header files (along
with others not in a folder) from the eCos kernel.  I
then searched the asm and linux folders for all the
files from the linux kernel include files and replaced
the arm-linux files with the eCos files if there were
duplicates.  I probably replaced about 1/10 of all the
files in the asm or linux include folders.  The
compiler and glibc were built fine.  In fact, I was
even able to get the test app past "target remote
/dev/ttyS0".  Usually, after I type "load" on a file
made in eCos, I get the following diplayed in my
terminal:
(gdb)load
Loading section .rom_vectors, size 0x44 lma 0xc000
Loading section .text, size 0xd818 lma 0xc044
Loading section .rodata, size 0x3e8 lma 0x1985c
Loading section .data, size 57092
Trarnsfer rate: 25374 bits/sec.
I can then type "Continue" or whatnot.  Anyway, after
I typed "load" with the compiler I built with the
previously mentioned method, I get the following
displayed:
(gdb)load
Loading section .interp, size 0x13 lma 0x20000f4
Ingoring packet error, continuing. . .
Loading section .note.ABI-tag, size 0x20 lma 0x2000110
Ignoring packet error, continuing. . .
Loading section .hash, size 0x28 lma 0x2000130
Ignoring packet error, continuing. . .
Loading section .dynsym, size 0x50 lma 0x2000158
Ignoring packet error, continuing. . .
Loading section .dynstr, size 0x43 lma 0x20001a8
Ignoring packet error, continuing. . .
Loading section ..gnu.version, size 0xa lma 0x20001ec
Ignoring packet error, continuing. . .
Loading section .gnu.version_r, size 0x20 lma
0x20001f8
Ignoring packet error, continuing. . .
Loading section .rel.plt, size 0x18 lma 0x2000218
Ignoring packet error, continuing. . .
Among many other smilar messages.

Something else I tried was to build gcc-2.95.1 with
the header files from the eCos kernel but that build
was not even successful.

I shoudl also probably imphasize that during all 3 
"approaches", I used the compiler option to try
compiling the file from both include files and
libraries(ie. the arm-linux include files and the
glibc that I built, or the eCos include and library
file.

I know it sounds like I am just guessing around in the
dark and have no idea what I am doing and that's
because it's true.  Thus, as mentioned before, any
help or advice is welcome.  I have also read the
section in the FAQ about compiler dependencies and am
guessing that is one of my problems.  Is there anyway
around this?


=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

[Grant Edwards]

On Wed, Nov 03, 1999 at 07:10:07PM -0800, Atsumi Hirose wrote:

> Before I explain what errors I get, let me explain the
> different methods I've used to try to get gcc-2.95.1
> to work in eCos.  I basically tried 3 different
> approaches however I played around with many files and
> compiler options on each approach.

Let's forget about gcc for a second.  Have you verfied that you can
assemble and link a small program and then load/run it with gdb?
Something trivial that just loads values into registers, reads/writes
a few bytes of RAM?

> The first thing I tried to do was to build gcc-2.95.1
> with the header files from an (arm-linux) linux-2.2.12
> kernel that I built.  

Building a cross-compiler isn't an easy process, and it's not
documented anywhere that I have found -- there's a cross-gcc FAQ, but
the steps it outlines do not work.  The part that usually blows up is
the building of various libraries.  The only library you need for
embedded development is libgcc.a, so the easiest thing to do is not
build anything except gcc itself and libgcc.a.

One of the things I'm going to do during the next few days is try to
repeat the build process I used and document exactly what I had to do
to get gcc to build.

> I was able to build the compiler and glibc OK but the compiled
> ("hello world") test app would not load through gdb.  

If you're going to be running an embedded system with eCOS, then you
don't need glibc -- all you need is gcclib.

> If I remember correctly, gdb frooze up after I typed "target remote
> /dev/ttyS0".

I don't think that has anything to do with the compiler, since you
haven't even tried to load the file produced by gcc.  It sounds like a
gdb/target problem.

> I also tried to compile the file with
> that compiler and the libarary and header files from
> eCos but it would not compile.
> 
> The second approach I took was to build gcc-2.95.1 with both the
> header files from the (arm-linux) 2.2.12 kernel (asm and linux)
> folders, and the header files from the eCos kernel
> (/usr/local/ecos-1.2.1/ecos-work/install/include).  I pretty much
> got the same results as my first attempt with only the arm-linux
> kernel heade files.

You should not be using any eCOS headers when building the compiler.

You should be using any ARM headers when building the compiler.  

When building the compiler, you should use only the standard header files
that you use when compiling any other program on your system.  

It's important to note that building gcc involves compiling
programs for two different targets:

 1) gcc itself:  runs (in my case) under Linux/Intel/glibc2.1.  Use the
    standard Linux/Intel/glibc headers.

 2) gcclib, which runs on the ARM processor.  In my case that is a
    big-endian ARM7TDMI.  gcclib should _not_ be using the standard
    Linux/Intel/glibc include files.

If you try to build libio, libiberty, or glibc for the ARM target,
you're going to have to have a whole set of header files configured
for the ARM target.  If you're going to be running eCOS, then you
aren't going to have an OS that supports those libraries -- so don't
try to build them.

I'll try to document the steps I took to build the compiler and gcclib,
and you need to verify that your binutils (as,ld) and gdb are working.
Hopefully I'll have a procedure documented for building a
cross-compiler in a few days.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

[Grant Edwards]

I previously wrote:

> One of the things I'm going to do during the next few days is try to
> repeat the build process I used and document exactly what I had to do
> to get gcc to build.

Here's a link with a lot of useful information:

                   http://www.objsw.com/CrossGCC/

Some of it is specific to older versions of gcc, but much of it is still useful.

Building a cross-compiler for an embedded system isn't quite as bad as it seemed 
the first time through the process.  The steps I used to build an ARM compiler on
my Linux (RH6.0) system are:


 1) Build and install gdb.

    Follow the standard instructions after configuring with 
               --target=arm-elf --program-prefix=arm-elf-

    That should result in a program named arm-elf-gdb being installed in
    /usr/local/bin.


 2) Build and install binutils.

    Follow the standard instructions after configuring with
               --target=arm-elf --program-prefix=arm-elf-

    That should result in programs named arm-elf-as, arm-elf-ld, etc. installed
    in /usr/local/bin.


At this point you should be able to assemble and link a program.  You
should be able to load the program into your target and run it with
gdb.  If not, then building gcc isn't going to be of much use. ;)
 
 3) Build and install a gcc cross compiler.

    a) Configure with --target=arm-elf --program-prefix=arm-elf-

    b) The build process for libgcc will try to use an assembler at
       /usr/local/arm-elf/bin/as.  

       Make that a symbolic link to /usr/local/bin/arm-elf-as.

    c) Do "make all-gcc"  

       This should build the compiler itself and libgcc.a.  

       If you just do a "make", it will try to build a wagon-load of stuff
       that will fail: libio, libg++, whatever.

    d) Do "make install-gcc"

       This should install the compiler shell as
       /usr/local/bin/arm-elf-gcc and the rest of the stuff under
       /usr/local/lib/gcc-lib/arm-elf/2.95.1.

At this point you should be able to compile a program with arm-elf-gcc.

NB: The default output from ARM targeted tools is little-endian.  Therefore,
    the libgcc.a created by step 3c) is little-endian.  I had to
    rebuild mine since I have big-endian hardware.  Next, I'll try to
    document the easiest way to do that.

-- 
Grant Edwards
grante@visi.com


    






    
 



    

Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

[Atsumi Hirose]

Let's forget about gcc for a second.  Have you verfied
that you can assemble and link a small program and
then load/run it with gdb? Something trivial that just
loads values into registers, reads/writes a few bytes
of RAM?
------------------------------------
Yes, I built a sample app and it compiles fine using
eCos's arm-elf-gcc.  I was then able to load it to my
ARM evaluation board and run it with arm-elf-gdb
without any problems.
 
-------------------------------------

If you're going to be running an embedded system with
eCOS, then you don't need glibc -- all you need is
gcclib.
-------------------------------------
All the documentation I found on building an ARM-Linux
cross toolchain told me to build glibc.  I read your
recommendations for building gcc as a cross compiler
and am about to try them.

--------------------------------

If you try to build libio, libiberty, or glibc for the
ARM target, you're going to have to have a whole set
of header files configured for the ARM target.  If
you're going to be running eCOS, then you aren't going
to have an OS that supports those libraries -- so
don't try to build them
---------------------------------------
I am guessing that this is the problem.  As I
mentioned before, I have built gcc-2.95.1 and
glibc-2.1.2 for an ARM-Linux target.  The compiler
seemed like it was able to compile alright but the
arm-elf-gdb didn't seem to like the file.

I will try to build the compiler again with only
gcclib.  However, the reason I am building this
compiler is because I want to be able to use gcj, am I
going to come across probelms with libgcj?

Thanks,

Atsumi


=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

[Jonathan Larmour]

Atsumi Hirose wrote:
> 
> I will try to build the compiler again with only
> gcclib.  However, the reason I am building this
> compiler is because I want to be able to use gcj, am I
> going to come across probelms with libgcj?

I'm afraid there are indeed problems with using eCos and gcj - as I
understand it, there is some work required to make them work together
properly that is not yet complete. I would be interested in knowing if
anyone has done this work.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

[Grant Edwards]

> Yes, I built a sample app and it compiles fine using eCos's
> arm-elf-gcc.  I was then able to load it to my ARM evaluation board
> and run it with arm-elf-gdb without any problems.

OK, it's good to have a baseline of know working components upon on
which to build.

> -------------------------------------
> If you're going to be running an embedded system with
> eCOS, then you don't need glibc -- all you need is
> gcclib.
> -------------------------------------

> All the documentation I found on building an ARM-Linux cross
> toolchain told me to build glibc.

That documentation probably assumed that you wanted to build a
compiler that was going to be used to compile programs to be run on a
Linux/ARM system -- which would support glibc.  glibc requires a
Unix/Linux OS underneath it to provide the system calls required by
many of the library routines.  AFAIK, eCOS doesn't provide support to
use glibc in an embedded system.

There may be a subset of glibc that can be used in an embedded system,
but generally people use newlib instead of glibc for embedded work.
The cross-compiler FAQ URL I provided earlier discusses this problem
in more detail.

> I am guessing that this is the problem.  As I mentioned before, I
> have built gcc-2.95.1 and glibc-2.1.2 for an ARM-Linux target.  The
> compiler seemed like it was able to compile alright but the
> arm-elf-gdb didn't seem to like the file.

That's odd, then.  If you do a "file" command on the file you're
trying to load does it say something like:

 ELF 32-bit MSB executable, Advanced RISC Machines ARM, version 1

If you do an arm-elf-objdump --headers on the file, do the sections
all show up at the right addresses?  If you're using a "PID" eval
board they should all get mapped into RAM starting at 0x04000.

Remember that when linking a file to be run on an embedded system, you
have to use a linker command file that specifies exactly where in
memory each section is to be loaded.  It must also be statically
linked with no unresolved external symbols.

> I will try to build the compiler again with only gcclib.  However,
> the reason I am building this compiler is because I want to be able
> to use gcj, am I going to come across probelms with libgcj?

I don't know what support libgcj requires.  If it is a stand-alone
library like libgcc, then there's a chance it might work. If libgcj
calls stuff in glibc or other libraries, then it depends on how those
requirements can be satisfied under eCOS.

-- 
Grant Edwards
grante@visi.com

[ECOS] building gcc-2.95.1 for eCos 1.2.1

[Atsumi Hirose]

Hi all,

I want to use gcj with ecos on an ARM processor and it
is turning out to be MUCH more difficult than
anticipated.  I though that all I would have to do is
build gcc-2.95.1 as an arm-linux cross compiler and
then configure/build the compiler for java and build
the java library.  After that I thought I could just
copy the java libraries into the kernel and then play
around with some headers and include files.  I have
thus learned that I was wrong and was wondering if
somebody could tell me just what is involved when
trying to get gcj to run with eCos.  Has anybody been
able to do this?

For starters let me say that I cannot even get the
gcc-2.95.1 arm-linux cross compiler that I built to
run on my ARM board with eCos (C or C++).  Of course
the arm-linux cross compiler that comes with eCos
works just fine.  I can compile a file with my new
2.95.1 toolchain.  It just won't run on the board.  I
can give a bunch of details on some "errors" that I
get but that might not even be relavant.  I have tried
many different methods (ie swithing eCos's and
gcc-2.95.1's header files etc.) but nothing works.

As you can tell, I am not to experienced at developing
GNU tools.  I just imagined that if a file was
compiled successfully for my ARM board, I could use
the other tools in eCos, gdb, the libs and header
files, etc. . . to load the file into the board. 
Ofcourse I would obviously have to change out some
headers and libarary files.  I guess I am just
learning the hard way what it means to "port"
something to eCos.  Just what does that mean?

Anyway, I am grateful for any comments or suggestions.

Atsumi


=====

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

[Grant Edwards]

On Tue, Nov 02, 1999 at 04:02:07AM -0800, Atsumi Hirose wrote:

> For starters let me say that I cannot even get the gcc-2.95.1
> arm-linux cross compiler that I built to run on my ARM board with
> eCos (C or C++).  Of course the arm-linux cross compiler that comes
> with eCos works just fine.  I can compile a file with my new 2.95.1
> toolchain.  It just won't run on the board.  I can give a bunch of
> details on some "errors" that I get but that might not even be
> relavant.

I'm using gcc-2.95.1 as an arm-elf cross compiler on a Linux host.
I have only run small bits of code to initialize the hardware, but it
seems to be working so far -- I haven't tried to run the eCOS kernel
yet.

What exactly are your errors?

> I have tried many different methods (ie swithing eCos's and
> gcc-2.95.1's header files etc.) but nothing works.

Most of the code I've run so far is assembly language, so I can't
verify that there's nothing wrong with 2.95.1...

-- 
Grant Edwards
grante@visi.com