.
So to get documentation about as, using a.out, type:
man m68k-unknown-aout-as
STEP 5
unpack the c-compiler to some directory:
tar xzf gcc-2.6.3.tar.gz
STEP 6
Apply ftp.cygnus.com:/pub/embedded/crossgcc-2.6.3.patch.gz by changing to
the gcc source tree by entering:
zcat /crossgcc-2.6.3.patch.gz | patch -p0 -s
STEP 7
Using coff, gcc complains on my system about missing syms.h.
Here is a
patch, apply it from the gcc source directory.
STEP 8
./configure --target m68k-unknown-<format> --with-gnu-ld --with-gnu-as --nfp \
--gas
True, this is the same configuration used for the binutils.
STEP 9
make LANGUAGES=c CFLAGS='-O2 -fomit-frame-pointer'
This will, after some time, complain about a missing crt0.o (a.out) or
a missing libc (coff). This is normal.
Any other error should be closely examined.
NOTE: When make builds the libgcc.a, it appears as if make is trapped in an
endless loop, building libgcc.a over and over again.
This is not true. In fact, make builds a libgcc.a for several
different members of the 68k family.
(AUTHORS NOTE: I am not experienced enough to let the make finish cleanly.
However, all that we need is now compiled.
Any volunteer to fill in this part?)
STEP 10
Install gcc-stage-files to /usr/local/lib/gcc-lib/m68k-unknown-<format>/2.6.3,
and install the gcc binary to /usr/local/m68k-unknown-<format>/bin:
make LANGUAGES=c install
AUTHORS NOTE:
On my system, it complained on makeinfo. I didn't care, the
executables got installed successfully and the info documentation was
readable.
STEP 11
Now we have the gcc in /usr/local/lib/gcc-lib/m68k-unknown-<format>/2.6.3, the
executables in /usr/local/m68k-unknown-<format>/bin and the library stuff in
executables in /usr/local/m68k-unknown-<format>/lib, but libc.a is still
missing.
You can find a newlib-1.6.tar.gz on
ftp.cygnus.com.
(AUTHORS NOTE: I had no luck installing it yet, and don't really need it.
Any volunteer who wants to fill in this part?)
STEP 12
A usual way to start up a c program is to provide a small assembly program
which prepares for the actual run and cleans up the dishes afterwards.
Classically, this file is called crt0.o. Using a.out, gcc automagically
links in crt0.o when building the final executable. Using coff, you are
on your own.
The contents of crt0.o depend heavily on the target system, so this howto
can't go very much into detail. However, a sample crt0.S can be found
here. You can assemble it with:
gcc68k crt0.S -o crt0.o
(Note: gcc knows that it should preprocess and then assemble the file)
USING A LINKER SCRIPT TO DESCRIBE YOUR EMBEDDED SYSTEM
Nearly noone knows that ld contains a small script language which can be used
to describe the system.
A classic program consists of three sections:
- .text-section:
This section contains the program code and constants. This section usually
ends up in an EPROM or ROM. On unix machines, this section gets write
protected by the operating system.
- .data-section:
This section holds global/static variables which must have defined values
on startup. A global variable like:
int foo = 0xF00;
gets placed there.
- .bss-section:
This section contains all global or static variables which get initialized
to zero on startup. An object file doesn't actually contain code for this
section, just the information how much ram a variable needs.
For example, a global declaration like this:
char buf[1024];
is placed into the .bss-section. It is the responsibility of the startup
code to fill the complete .bss-section with zeros before calling the
main() c-code.
On an EPROM based machine, a problem arises from this:
The .data-section must be placed into RAM and must be initialized before
startup. The obvious solution is to place the initial values into an area
in the EPROM and copy them to RAM before starting the actual program.
A linker script can prepare for this by telling the linker two things:
- Place the initial .data-section contents into the EPROM right after .text.
- Define several symbols like __s_text, __e_text, __s_data, etc...
These addresses are the used by the startup code to copy the initial data
into RAM.
This
script
does this for my board. You will surely have to modify it
according to your hardware.
To use a linker script, pass -T <script-filename> to ld68k while linking.
When linking through gcc, this is done with -Wl,-T,<script-filename>
USING mot2bin TO CONVERT S-RECORDS INTO BINARY
I have written a simple program for converting s-records to binary data.
The source is
here. To build, type:
gcc -s -O2 -fomit-frame-pointer mot2bin.c -o mot2bin
Install mot2bin to /usr/local/bin, be sure not to accidentally use the
cross-gcc... (:
The use of mot2bin should be straightforward:
mot2bin .srec -o .bin
The options are:
mot2bin [--output file] [--name] [--start] [--skipzero] [file]
or mot2bin [-o file] [-n] [-s] [-z] [file]
--output <file>, -o <file> Place binary output to . Defaults to
stdout.
--name, -n If there is a record 0, print the name
found in that record to stdout, prefixed
by N:
--entry, -e Usually the start-address is found in a
record. This prints it to stdout as hex
prefixed by S:
Be warned, this is linker's idea of the
start address...
--skip <addr>, -s <addr> Ignore every data from the srecord file
which's address is smaller than .
You should also use --skipzero to truncate
the file.
--skipzero, -z Don't pad the output file with zeroes to
match addresses in the output file 1:1 with
real addresses.
Example: If the s-record file begins at
address 0x2000, binary output would start
with 8192 zeroes. Use this option to
avoid that.
If there is no inputfile on the commandline, stdin is used.
Some tips and hints for using the crosdevelopment system:
I hope i didn't make too much mistakes. If you find some, please tell me.
Please tell me also about language errors, since english is not my native
language.
Enjoy,
Olav (
wosch@rbg.informatik.th-darmstadt.de)
crt0.S
mot2bin.c
basename.patch
syms.patch
ldscript
Back to my homepage