This is the mail archive of the email@example.com mailing list for the crossgcc project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
On Thu, 23 Jul 1998, Peter Jeremy wrote: > On 20 Jul 1998, James Youngman wrote: > > >>>>> "ts" == Tomaz Stih <firstname.lastname@example.org> 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 ******************************************************