Re: RTEMS Q.

Re: RTEMS Q.

[Geoffroy Montel]

Hi,

> I am new to RTEMS and I have several questions about it.
Welcome!

> I am using my linux-i586 to produce code for m68k which
> will run on embedded 68008 board. I went through asm 
> code step by step to find out where RTEMS starts.
 
> As you might know m68k boards (without using VBR) have
> vector table and first entry in the table is SSP and second is
> RESET vector thus I was looking for code that would be
> compiled to address 0x00000000 and would contain
> vector table. But all I could find was crt0 in newlib and
> start.s (I think) in RTEMS which contain startup code
> and entry point but no vector table.
> 
> I also looked through several BSPs with no success.
> 
> My questions are :
> 
> - does linker produce appropriate RTEMS vector table
> and jumps to entry point without my intervention,
> does this depends on file format produced?
The linkcmds (a script file passed to the linker) has to reserve some
room in your .bss section for the vector table. You can find the
linkcmds
in the BSP
Then the board initialisation code will assign the VBR register to 
the start of the vector table in RAM.
To put the vector table in 0x0, you just have to tell the linker, with
the linkcmds, that the RAM begins at address 0x0, and that the VBR is
the first thing you'll find in RAM.
I don't know if it depends on the file format produced, I don't think so
At least it should work even for coff or a.out format

> - i would like to produce code that would have
> .text and .data in ROM and .bss in RAM, how do I
> produce pure binary code for my ROM that I can simply
> burn to EPROM and what is common practise to do
> this in embedded systems?
You have to use the linkcmds again :)
You can tell the linker where the different sections should go
For instance,
 1. you put the RAM in 0x0
 2. you put the ROM in 0x10000000
and then you assign CS0 to 0x0 (if CS0 controls the RAM chip) and CS1
to 0x10000000 (if CS1 controls the ROM chip) in the board
initialisation code

> - after I (that'll be tha day) successfuly compile RTEMS what
> form does it takes? Is it a library that I simply link with my
> projects or what? Which are the files that I receive as
> results?
RTEMS consists of a library you link with your program. The resulting
form
is an executable which format is the one you specified in the linkcmds

> - i am using original gcc and have problems with
> ctype.h and stdio.h, are there any problems if I 
> use egcs instead?
No problem, the very-soon-to-be-released version of RTEMS needs egcs

> - I tried to compile RTEMS 3.6.0 unix (linux) emulator
> and almost succed, there were some problems with
> conflicting definitions for __open and __seek inside
> my system defined fcntl.h and RTEMS libio.h which
> I solved using conditional compilation but still
> the compilation ends because of libc problems
> (RTEMS cannot find initialization routine for libc).
Wait for the newest version or ask joel@oarcorp.com

> - How do I tell RTEMS to use Cygnus Newlib library
> and header files instead of my linux ones?
RTEMS 4.0 uses Cygnus Newlib :)

> - Does RTEMS come with its own little libc
> (I saw some .c files) there or are those files just
> wrappers to libc or newlib?
No, it just patches Cygnus Newlib

> - Are there simpler packs for specific platforms
> avaliable? I would kill for motorola 68k dev tools
> binaries and compiled main (not BSP dependent)
> RTEMS parts with GNU debugger support.
dunno

Hope it helps, check the GNU LD documentation for more details about 
linkcmds syntax.

Best regards,

Geoffroy

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: RTEMS Q.

[Joel Sherrill]

On Fri, 3 Jul 1998, Geoffroy Montel wrote:

> > I am new to RTEMS and I have several questions about it.
> Welcome!

It is a growing world. :)

> > I am using my linux-i586 to produce code for m68k which
> > will run on embedded 68008 board. I went through asm 
> > code step by step to find out where RTEMS starts.

AFAIK RTEMS has never been run on a 68008.  You might want to look at the
definitions in score/cpu/m68k/m68k.h to see that they are OK.

> the linkcmds, that the RAM begins at address 0x0, and that the VBR is
> the first thing you'll find in RAM.
> I don't know if it depends on the file format produced, I don't think so
> At least it should work even for coff or a.out format

Most of the BSPs for 683xx systems include this type of setup.  

> > - i would like to produce code that would have
> > .text and .data in ROM and .bss in RAM, how do I
> > produce pure binary code for my ROM that I can simply
> > burn to EPROM and what is common practise to do
> > this in embedded systems?
> You have to use the linkcmds again :)
> You can tell the linker where the different sections should go
> For instance,
>  1. you put the RAM in 0x0
>  2. you put the ROM in 0x10000000
> and then you assign CS0 to 0x0 (if CS0 controls the RAM chip) and CS1
> to 0x10000000 (if CS1 controls the ROM chip) in the board
> initialisation code

The linker scripts are fairly complex beasts to master.  The people on the
crossgcc@cygnus.com mailing list have a lot of experience with them.  

> > - after I (that'll be tha day) successfuly compile RTEMS what
> > form does it takes? Is it a library that I simply link with my
> > projects or what? Which are the files that I receive as
> > results?
> RTEMS consists of a library you link with your program. The resulting
> form
> is an executable which format is the one you specified in the linkcmds

Yep.

> > - i am using original gcc and have problems with
> > ctype.h and stdio.h, are there any problems if I 
> > use egcs instead?
> No problem, the very-soon-to-be-released version of RTEMS needs egcs

But still uses gcc2 source for GNAT/RTEMS so it should work OK. 

> > - I tried to compile RTEMS 3.6.0 unix (linux) emulator
> > and almost succed, there were some problems with
> > conflicting definitions for __open and __seek inside
> > my system defined fcntl.h and RTEMS libio.h which
> > I solved using conditional compilation but still
> > the compilation ends because of libc problems
> > (RTEMS cannot find initialization routine for libc).
> Wait for the newest version or ask joel@oarcorp.com

The 3.6.0 linux port was done to a very old linux version.  Unfortunately,
the internal names in the linux libc conflicting with some of the ones we
used for out libc support code (reentrant malloc, etc.).  There is a patch
for 3.6.0 specifically to fix this problem in the directory 
/oarcorp/pub/rtems/3.6.0-patches on ftp.oarcorp.com.  It changes some
symbol names in the libc support and the linux bsp.  It does not make the
same change to every BSP.

> > - How do I tell RTEMS to use Cygnus Newlib library
> > and header files instead of my linux ones?
> RTEMS 4.0 uses Cygnus Newlib :)

On embedded targets, RTEMS uses newlib and has done so since at least
version 3.2.1 :)

> > - Does RTEMS come with its own little libc
> > (I saw some .c files) there or are those files just
> > wrappers to libc or newlib?
> No, it just patches Cygnus Newlib

Patches is a bit understating it.  Actually libc contains a few things:

  + replacement routines like the RTEMS malloc family
  + the glue between newlib and the BSP for IO
  + RTEMS specific implementations of things like gettimeofday

> > - Are there simpler packs for specific platforms
> > avaliable? I would kill for motorola 68k dev tools
> > binaries and compiled main (not BSP dependent)
> > RTEMS parts with GNU debugger support.
> dunno

At various times, there have been prebuilt m68k toolsets for some hosts.
Believe it or not, it is not that hard to build a cross toolset.  The
upcoming RTEMS release includes very detailed instructions and a script
which does most of the work for you.

Geoffroy has put a lot of work into making sure this works on Cygwin as
well.

> Hope it helps, check the GNU LD documentation for more details about 
> linkcmds syntax.

I found that examples of other linker scripts were quite helpful as well.

--joel

RE: RTEMS Q.

[Tomaz Stih]

>    I am using a linux-i586 host to produce code for a
>mvme135 which is an embedded mc68020 computer. I use the
>prom monitor to download the code. 

What is a prom monitor? My problem is that when I write an asm
program like :

	move.l #10,d0
	move.l d0,d1

it linkes not into few bytes but (with stripped option on) into 30Kb 
of code regardless of me using coff, ihex, bin or whatever format.

How do I tell GNU asm and linker to produce pure binary that I can
burn into eprom.

>    My first address is 0x4000 (due to monitor). In this address
>RTEMS put a NOP and a JUMP start_address. So you have almost a
>proper reset vector: you must change NOP and JUMP op. code by your
>SSP.

I thought so but I am still not sure if I understand this.
RTEMS starts with something like:

SYM(start):
SYM(M68kVec):
	NOP
	JUMP start_around
	DC.B 4088 /* space for vectors */
	...

If I understand this then RTEMS is not written to start in pure
68000 environment. Instead in my code I should first 
set the vector table to jump to my program and then jump to 
start of RTEMS.
Is this correct?

Is there anywhere well written documentation for GNU Assembler
for motorola (and for other platforms) avaliable (the asm syntax, tutorial
diffrent from GNU AS which describes the usage of assembler application) 
I know motorola from ATARI ST and it had different assembler syntax.

Regards,
Tomaz

Re: RTEMS Q.

[Andreas Schwab]

"Tomaz Stih" <tomaz.stih@triglif.com> writes:

|> >    I am using a linux-i586 host to produce code for a
|> >mvme135 which is an embedded mc68020 computer. I use the
|> >prom monitor to download the code. 
|> 
|> What is a prom monitor? My problem is that when I write an asm
|> program like :
|> 
|> 	move.l #10,d0
|> 	move.l d0,d1
|> 
|> it linkes not into few bytes but (with stripped option on) into 30Kb 
|> of code regardless of me using coff, ihex, bin or whatever format.
|> 
|> How do I tell GNU asm and linker to produce pure binary that I can
|> burn into eprom.

Use objcopy -O binary.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

RE: RTEMS Q.

[Joel Sherrill]

On Fri, 10 Jul 1998, Tomaz Stih wrote:

> >    I am using a linux-i586 host to produce code for a
> >mvme135 which is an embedded mc68020 computer. I use the
> >prom monitor to download the code. 

Who is out there with a mvme135 and RTEMS?  I would like to hear from you
for testing and update purposes. :)

And most of this belongs on an RTEMS list not egcs. :)

> What is a prom monitor? My problem is that when I write an asm
> program like :

It is a simple program in ROM which initializes the board and provides
some simple assembly oriented debug and download capabilities (typically
via some ASCII format like Srecords).  Some are very sophisticated but
most are pretty simple.

> 	move.l #10,d0
> 	move.l d0,d1
> 
> it linkes not into few bytes but (with stripped option on) into 30Kb 
> of code regardless of me using coff, ihex, bin or whatever format.

You are either (1) using "ls" not "size" to look at the file or 
(2) (more likely) linking in some standard support code unknowingly.

> How do I tell GNU asm and linker to produce pure binary that I can
> burn into eprom.

A few RTEMS BSPs (gen68360 and gen68340 come to mind) include examples on
this.

> >    My first address is 0x4000 (due to monitor). In this address
> >RTEMS put a NOP and a JUMP start_address. So you have almost a
> >proper reset vector: you must change NOP and JUMP op. code by your
> >SSP.
> 
> I thought so but I am still not sure if I understand this.
> RTEMS starts with something like:
> 
> SYM(start):
> SYM(M68kVec):
> 	NOP
> 	JUMP start_around
> 	DC.B 4088 /* space for vectors */
> 	...
> 
> If I understand this then RTEMS is not written to start in pure
> 68000 environment. Instead in my code I should first 
> set the vector table to jump to my program and then jump to 
> start of RTEMS.
> Is this correct?

Which BSP's start code are you looking at?  On a m68k with a vbr, you can
put the vectors anywhere but not on a cpu model without.  On a "non-vbr"
m68k, you will have to be more careful about memory layout.  I think the
ods68302 is a good non-vbr bsp to look at.

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

RTEMS Q.

[Tomaz Stih]

I am new to RTEMS and I have several questions about it.

I am using my linux-i586 to produce code for m68k which
will run on embedded 68008 board. I went through asm 
code step by step to find out where RTEMS starts.

As you might know m68k boards (without using VBR) have
vector table and first entry in the table is SSP and second is
RESET vector thus I was looking for code that would be
compiled to address 0x00000000 and would contain
vector table. But all I could find was crt0 in newlib and
start.s (I think) in RTEMS which contain startup code
and entry point but no vector table.

I also looked through several BSPs with no success.

My questions are :

- does linker produce appropriate RTEMS vector table
and jumps to entry point without my intervention,
does this depends on file format produced?

- i would like to produce code that would have
.text and .data in ROM and .bss in RAM, how do I
produce pure binary code for my ROM that I can simply
burn to EPROM and what is common practise to do
this in embedded systems?

- after I (that'll be tha day) successfuly compile RTEMS what
form does it takes? Is it a library that I simply link with my
projects or what? Which are the files that I receive as
results?

- i am using original gcc and have problems with
ctype.h and stdio.h, are there any problems if I 
use egcs instead?

- I tried to compile RTEMS 3.6.0 unix (linux) emulator
and almost succed, there were some problems with
conflicting definitions for __open and __seek inside
my system defined fcntl.h and RTEMS libio.h which
I solved using conditional compilation but still
the compilation ends because of libc problems
(RTEMS cannot find initialization routine for libc).

- How do I tell RTEMS to use Cygnus Newlib library
and header files instead of my linux ones?

- Does RTEMS come with its own little libc
(I saw some .c files) there or are those files just
wrappers to libc or newlib?

- Are there simpler packs for specific platforms
avaliable? I would kill for motorola 68k dev tools
binaries and compiled main (not BSP dependent)
RTEMS parts with GNU debugger support.

Regards,
Tomaz