Re: 68000/RTEMS question..

[Geir Frode Raanes <geirfrs@invalid.ed.ntnu.no>]

On Thu, 23 Jul 1998, Peter Jeremy wrote:

> On 20 Jul 1998, James Youngman wrote:
> > >>>>> "ts" == Tomaz Stih <tomaz.stih@triglif.com> writes:
> > 
> >   ts> When dealing with 68000 boards with no vector base register
> >   ts> there is a problem with setting vectors because it is common
> >   ts> to put ROM at 0x0000 address where vectors reside thus making
> >   ts> it impossible to change them.
> > 
> > 00000000 does not have to be ROM.  You just have to be able to load 8
> > bytes from it at reset time.   I've seen boards by Pro-Active Control
> > which use a counter to change the memory mapping after the right
> > number of bus cycles to that the vectors can be in RAM (except,
> > effectively, the reset vector).
> 
> It easier than this.  All you need to do is map the ROM at both its
> correct address and at address 0 from reset until the first processor
> write.  If you don't want supervisor code in RAM, you could also
> permanently map the ROM at address 0 in the Supervisor Program Space. 

(I will comment on this HW issue first, but I have some programming
 questions regarding GCC interrupt routines and symbol table qonventions 
 at the end of this mail.)

Unfortunately no.  At the first write ROM will withdraw from the vector
table address range, while RAM has yet to be filled with the vector table
copy to replace it.  Hence in the meantime you run without a vector table.
This will probabely do if all interrupts are masked and you can guarantee
no SW traps or IPL=7 (NMI).  This is very often not the case.

To fix your idea you need to implement the full shadow RAM concept.
I.e. every read from the vector table addresses origin from the ROMs,
while every write to the same range ends up in RAM.  When the full vector
table has been copied and you are ready to withdraw the ROMs, you do 
this specifically/manually through an dedicated IO port.  This concept 
is very easily implemented in hardware as a handful of gates plus one
flip-flop.  To make this implementation behave automatic, you might 
settle for copying the vector table from zero and up to the vector 
table end at address 1023.  Then add some HW that toggle the
flip-flop whenever a write is performed at this ending address.
The flip-flop itself has of cause to be reset by system wide reset,
and the system must also implement Power On Reset.  But this is a 
M68K requirement in any case.

Still, the developement of programmable chip select lines has put any
such shadowing tricks out of fashion.  The TMP68301 from Thoshiba 
for instance, has two programmable chip select lines, /CS0 and /CS1 
onchip.  The /CS0 takes presedence over /CS1 if assigned to the same
address range.  Neither is active under a interrupt acknowledge cycle.
Also, only /CS0 is initialized and active when coming out of POR.  
It will respond to any address below 8MByte.  /CS1 is inhibited.

This allows one to fetch SSP and Reset vector from ROM through /CS0,
immediately jumping to the ROM alias whitin 0-8 MByte range where one
intend to put the fully qualified ROM decoding later. Then initialize 
/CS1 to decode RAM addresses above 8MByte, copy the vector table from
ROM (any alias) and thereafter relocate/overlay RAM to low addresses.
Because /CS0 takes presedence over /CS1, ROM will still be target until
/CS0 is reprogrammed to shrink to the final placement of ROM, thereby
surfaceing /CS1 at the low addresses.  With some complicating issues
presented by limitations in my TMP68303 MCU and later by the inclusion of
a Altera EPLD circut, this is the method I intend use to boot my design.



***********



It should come as no surprise to every reader by now that I am actually
an student in HW engineering.  But I need to write some minimalistic code
to support my latest design.  I need some clear cut answers.


1) Under Linux, will a recompilation from GCC source make changes to my
   existing x86 GCC bintree/libtree even if 'prefix' is given or does
   all compilation results stay in the 'prefix' indicated directory?

2) Under Win32, are the Cygnus changes to the GCC code adopted into the
   ordinary source tree or do I need a specially patched source code?
   I.e. can I download any newer GCC source and just copile it under 
   Cygnus bash just as in the Unix case?  Apart from --host=i386-cygwin32
   that is?

3) GCC version 2.8.1, can it be configured as an crosscompiler, or must
   I apply the newly arrived patch at Cygnus FTP?

4) EGCS, is that something a mere mortal should touch or does it break
   more than it fix/offer?

5) How do I configure GCC+BinUtils to target 68000 per default and not
   68020 the --target=m68k supposedly gives? 

6) --exec-prefix.  Is that a --prefix override or are they completely
   decoupled and both necessary?

7) What symbol table format to use.  Is ELF supported for plain 68000?
   In any case, what is ELF32?  COFF is rumored to be a 'memory pig'
   assigning 16 bytes to any variable.  True?  a.out reportedly use a
   'jmp __main' into a enduser supplied crt0.o.  This I can handle and
   actually use for initializing as long as nothing like the stack is
   touched beforehand.  Is there a list somewhere as to what the egg or
   hen libraries libc/newlic actually contain and what constructions make
   explicit or - even more scaring to me - implicit calls to them?  
   Is there a price to be paid for the more advanced ELF format?

8) Is there a X11 based frontend for GDB supporting a m68k configuration?
   (I have seen documentation specifically excepting m68k from the list.)

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

9) How do I actually write an interrupt handler for m68k in GCC?

10) I hope the compilation of the linker extracts som useful information
    om how to do section allocation and what sections GCC generate.
    Where is this info present on the net?

11) Does RTEMS require 68020 at the minimum or will plain 68000 do?





  ******************************************************

  Never ever underestimate the power of human stupidity.
  -Robert Anson Heinlein

		GeirFRS@invalid.ed.ntnu.no

  ******************************************************