RE: RTEMS Q.

[Joel Sherrill <joel at OARcorp dot com>]

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