summaryrefslogtreecommitdiffstats
path: root/c/src/exec/score/cpu (follow)
Commit message (Collapse)AuthorAgeFilesLines
* MPC821 support and PPC patches from Andrew Bray <andy@madhouse.demon.co.uk>:Joel Sherrill1999-04-074-56/+1320
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In c/src/exec/score/cpu/powerpc/rtems/score/ppc.h: A lot of hardware interrupts were omitted. Patch enclosed. I have also added the 821. In c/src/exec/score/cpu/powerpc/rtems/score/cpu.h: My patch adds the 821. In c/src/exec/score/cpu/powerpc/cpu.c: I have added the MPC821, and also fixed up for the missing hardware interrupts. It is also inconsistent with c/src/lib/libcpu/powerpc/mpc860/vectors/vectors.S. This has been fixed. In c/src/lib/libcpu/powerpc/mpc860/vectors/vectors.S: Fixed an inconsistency with cpu.c. I also include some new files to go with the above patches. These are the cpu library rtems-19990331/c/src/lib/libcpu/powerpc/mpc821/* and c/src/exec/score/cpu/powerpc/mpc821.h which are minor modifications of the 860 equivalents. Other comments: The various accesses to the DPRAM on the 860 are done with a linktime symbol. This could be done dynamically at run time by reading the immr register, and masking off the lower 16 bits. This takes the same amount of time as loading an address constant, and the same number of instructions as well (2). In c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c: This will silently fail if you attempt to use SCC1. This is only relevant if you are not using SCC1 for ethernet. This file also sets one of port B output pins for each port. This is NOT generic, it should be in the BSP specific console driver.
* Modified to be valid m68k code on all CPU models.Joel Sherrill1999-03-311-5/+0
|
* Fixed paths to include files so this will build.Joel Sherrill1999-03-3110-2/+1053
|
* Towards automake XI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-03-1945-135/+540
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is the most scary of all proposals I've been mailing to you this week until now. It consists of 3 parts: 1. a patch 2. a perl script (acpolish) 3. a shell script wrapper to invoke the perl-script. The perl-script reads in each Makefile.in and modifies them ("polishes/beautifies" them :-). These modifications are not easy to describe: Basically, it hard-codes some automake Makefile-variables and rules into RTEMS autoconf-Makefile.ins (Note: autoconf vs. automake!!) and converts some settings/variables to configure scripts' requirements (Yes, plural). E.g. it adds the automake standard variables $top_builddir and $subdir, adds dependency rules for automatic re-generation of Makefiles from Makefile.in, adds support variables for relative paths to multiple configure scripts etc. The patch is a one-line patch to enable the support of the new features added by acpolish. The shell script is a wrapper which pokes around inside of the source tree for Makefile.ins and invokes acpolish on all autoconf-Makefile.ins. acpolish is designed to be able to run several times on the same Makefile.in and may once become a more general tool to convert RTEMS Makefile.in to automake. Therefore, I'd like to keep it inside of source tree. (e.g. as contrib/acpolish or c/update-tools/acpolish). However, it doesn't make sense to export it outside of RTEMS. To apply this: cd <source-tree> patch -p1 -E < <path-to-patch>/rtems-rc-19990318-1.diff tar xzvf <path-to>/rtems-rc-polish.tar.gz ./rtems-polish.sh ./autogen Note: The path contrib/acpolish is hard-coded into rtems-polish.sh, if you decide to put it in an alternative place, please modify rtems-polish.sh to reflect this change. Later: cvs rm make/rtems.cfg (It isn't used anymore) cvs add contrib cvs add contrib/acpolish cvs commit I've tested this intensively, but naturally I can't exclude bugs. Ralf. PS.: Most probably, this is the last "Towards automake" patch. The next one probably will be a real automake patch.
* Moved mpc860.h around to make things compile.Joel Sherrill1999-02-242-1/+1
|
* Corrected Makefile.in to account for placement of include files.Joel Sherrill1999-02-244-4/+4
|
* Corrected name of constant so this would compile.Joel Sherrill1999-02-241-1/+1
|
* Accidentally moved.Joel Sherrill1999-02-194-2101/+0
|
* Moved back up in tree.Joel Sherrill1999-02-194-0/+2101
|
* Accidentally moved erc32.hJoel Sherrill1999-02-191-521/+0
|
* Moved erc32.h back up in tree.Joel Sherrill1999-02-191-0/+521
|
* Moved asm.h back up in tree.Joel Sherrill1999-02-198-0/+970
|
* Accidentally moved asm.hJoel Sherrill1999-02-198-1143/+0
|
* Moved to proper rtems/scoreJoel Sherrill1999-02-1922-217/+423
|
* Part of the automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1845-44/+134
| | | | | | | | | | | | | | | | > 5) rtems-rc-19990202-1.diff/reorg-install.sh > > reorg-install.sh fixes a Makefile variable name clash of RTEMS > configuration files and automake/autoconf standards. > Until now, RTEMS used $(INSTALL) for install-if-change. Automake and > autoconf use $(INSTALL) for a bsd-compatible install. As > install-if-change and bsd-install are not compatible, I renamed all > references to install-if-changed to $(INSTALL_CHANGED) and used > $(INSTALL) for bsd-install (==automake/autoconf standard). When > automake will be introduced install-if-change will probably be replaced > by $(INSTALL) and therefore will slowly vanish. For the moment, this > patch fixes a very nasty problem which prevents adding any automake file > until now (There are still more).
* Part of the automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1884-0/+17032
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh > > reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a > similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff > contains the diffs after reorg-score-cpu.sh has been run on a > rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff. > > This patch is rather nasty and may break something. However, I've tested > it for about 10 different target/bsp pairs and believe to have shaken > out most bugs. I wonder about the following .h files that were not moved: a29k/asm.h a29k/cpu_asm.h i386/asm.h i960/asm.h m68k/asm.h m68k/m68302.h m68k/m68360.h m68k/qsm.h m68k/sim.h mips64orion/asm.h mips64orion/cpu_asm.h mips64orion/mips64orion.h no_cpu/asm.h no_cpu/cpu_asm.h powerpc/asm.h powerpc/mpc860.h sh/asm.h sparc/asm.h sparc/erc32.h
* Another part of automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>Joel Sherrill1999-02-181-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh > > reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a > similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff > contains the diffs after reorg-score-cpu.sh has been run on a > rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff. > > This patch is rather nasty and may break something. However, I've tested > it for about 10 different target/bsp pairs and believe to have shaken > out most bugs. I wonder about the following .h files that were not moved: a29k/asm.h a29k/cpu_asm.h i386/asm.h i960/asm.h m68k/asm.h m68k/m68302.h m68k/m68360.h m68k/qsm.h m68k/sim.h mips64orion/asm.h mips64orion/cpu_asm.h mips64orion/mips64orion.h no_cpu/asm.h no_cpu/cpu_asm.h powerpc/asm.h powerpc/mpc860.h sh/asm.h sparc/asm.h sparc/erc32.h
* Yet another part of automake VI from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1853-15607/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh > > reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a > similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff > contains the diffs after reorg-score-cpu.sh has been run on a > rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff. > > This patch is rather nasty and may break something. However, I've tested > it for about 10 different target/bsp pairs and believe to have shaken > out most bugs. I wonder about the following .h files that were not moved: a29k/asm.h a29k/cpu_asm.h i386/asm.h i960/asm.h m68k/asm.h m68k/m68302.h m68k/m68360.h m68k/qsm.h m68k/sim.h mips64orion/asm.h mips64orion/cpu_asm.h mips64orion/mips64orion.h no_cpu/asm.h no_cpu/cpu_asm.h powerpc/asm.h powerpc/mpc860.h sh/asm.h sparc/asm.h sparc/erc32.h
* Part of the automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1811-73/+10
| | | | | | | | | | | | | | | | | | > 3) rtems-rc-19990131-2.diff > > This patch removes generating bsp_specs from leaf.cfg and generates > bsp_specs from inside of c/Makefile instead. > > The motivation behind this patch is to avoid "polluting" Makefiles by > unneccessary rules from included Makefile-fragments (*.cfg-files) and > try to handle files by explicit rules in Makefiles instead (FYI: > automake-1.4 physically includes Makefile fragments at the time > automake is run, not at the time make is run as RTEMS Makefile.ins do > now) > > Nevertheless, this patch is rather uncritical, almost cosmetical - If > you don't like it, then dump it ;-, however I doubt that subsequent > patches will apply then ;-.
* Part of automake VI patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-181-2/+2
| | | | | | | | | | | | | | > 2) rtems-rc-19990131-1.diff > > Rework of compilers/*.cfg files (esp. gcc-target-default.cfg) to adapt > the flags/makefile variables to automake and make standards (cf. > make.info - implicit rules/variables). > > This patch is rather risky and may probably break things, but is an > essential step towards automake. > > FWIW: It also reverts the i386-ASMFLAGS/ASFLAGS-patch, which was wrong, > as I had to experience ;-.
* Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1999-02-1811-67/+6
| | | | | | | | | | | | | This patch removes generation of targopts.h from leaf.cfg and generates it in location at score/include/rtems/score instead. To achieve this: * all rules in other Makefile.ins which have accessed targopts.h have been removed. * c/Makefile.in has been modified to generate the directories before doing anything else. I.e. to ensure the directories exist before any preinstall rule fires (This part is a bit kludgy, but it seems to work. Please check if the interaction with libhwapi still works).
* Patch from Emmanuel Raguet <raguet@crf.canon.fr>:Joel Sherrill1999-02-181-1/+9
| | | | | | | You will find enclosed a patch which contains, for Intel PC386 target : - an Ethernet driver for DEC21140 device based boards. - a simple cache management with paging mechanism.
* MPC860 support submitted by Jay Monkman <jmonkman@frasca.com>.Joel Sherrill1999-02-184-2/+256
|
* Jay Monkman <jmonkman@frasca.com> submitted the eth_comm BSP for a PPC860Joel Sherrill1999-02-171-0/+1300
| | | | based board.
* Added caching enable routines.Joel Sherrill1999-02-051-1/+1
|
* New file.Joel Sherrill1999-02-021-0/+61
|
* Patch from Eric Norum <eric@skatter.usask.ca> to make m68360.h usableJoel Sherrill1999-01-201-357/+366
| | | | | | | | outside RTEMS. Comment: I found a couple of places other than RTEMS where I'd like to use the declarations supplied in m68360.h. To make this easier to do, I've redone the declarations in m68360.h to use standard C types.
* Patch from Jiri Gaisler <jgais@ce.chalmers.se>:Joel Sherrill1999-01-192-2/+4
| | | | | | | | getting the spurious trap handling to work required a couple more fixes - I have attached a patch against rtems-4.0.0 with the necessary changes. I also added functionality so that the address of the trapped instruction is reported and in case of a data access error, the data address is also reported.
* Bug report from Jiri Gaisler <jgais@ws.estec.esa.nl>:Joel Sherrill1999-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | > > I think I have found a bug in src/exec/scor/sparc/cpu/erc32.h in: > > > > #define ERC32_Disable_interrupt( _source, _previous ) \ > > do { \ > > unsigned32 _level; \ > > unsigned32 _mask = 1 << (_source); \ > > \ > > sparc_disable_interrupts( _level ); \ > > (_previous) = ERC32_MEC.Interrupt_Mask; \ > > ERC32_MEC.Interrupt_Mask = _previous | _mask; \ > > sparc_enable_interrupts( _level ); \ > > (_previous) &= ~_mask; \ <- IS THIS CORRECT...? > > } while (0) > > > > The previous interrupt mask is returned after first clearing the > > bit to be disabled, regardless whether the bit was set before or > > not. If the bit was set (interrupt masked), subsequent call to > > ERC32_Restore_interrupt() will enable the interrupt even though > > it was supposed to be masked. This is indeed what happens in > > DEBUG_puts when polled console I/O is used. In my opinion, the > > last statement in the macro should be removed - what is your opinion? > > I think the "~" shouldn't be there. I recall that the intent of that line > is to only return the state of the interrupts you were concerned with. > Removing the line returns entire state. Given that the value returned > shuold only be used in conjunction with the map, I suppose either removing > the ~ or the entire line is correct? I can go either way. Just let me > know which you think is more correct and the source will change. :) Hmmm, just removing the '~' should be OK. DEBUG_puts() seems to be the only user of ERC32_Restore_interrupt() anyway ...
* Switched to use of ASM compilation conditional.Joel Sherrill1998-12-152-4/+4
|
* Changed reference from no_cpu to mips64orion.Joel Sherrill1998-12-152-2/+2
|
* Switch from .s to .S on includeJoel Sherrill1998-12-141-2/+2
|
* Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de> to rename allJoel Sherrill1998-12-1424-27/+27
| | | | | .s files to .S in conformance with GNU conventions. This is a minor step along the way to supporting automake.
* Patch from Ian Lance Taylor <ian@airs.com>:Joel Sherrill1998-12-071-1/+1
| | | | This patch avoids a warning from the development version of gas.
* Patch from Emmanuel Raguet <raguet@crf.canon.fr> to add remote debug serverJoel Sherrill1998-12-032-19/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and RPC support to RTEMS. Thanks. :) Email follows: Hello, For Xmas, here is the Remote Debugger on RTEMS ! Here are 2 patches for the Remote Debugger on RTEMS for pc386 from Linux host : - one for RTEMS it self, - one for GDB-4.17. 1/ RTEMS patch -------------- This patch adds 2 libraries : - a simplified SUN RPC library - the Remote Debugger library The configuration command is the following : ../rtems4/configure --target=i386-rtemself --enable-rtemsbsp=pc386 --enable-rdbg The SUN RPC library is built only if networking is set. The RDBG library is built if networking and enable-rdbg are set. The function used to initialize the debugger is : rtems_rdbg_initialize (); A special function has been created to force a task to be in a "debug" state : enterRdbg(). The use of this function is not mandatory. 2/ GDB-4.17 patch ----------------- This patch create a new RTEMS target for GDB-4.17. The configuration command is the following : ./configure --enable-shared --target=i386RTEMS To connect to a target, use : target rtems [your_site_address] Then, attach the target using : attach 1 And... Debug ;) You can obtain the original GDB-4.17 on ftp://ftp.debian.org/debian/dists/stable/main/source/devel/gdb_4.17.orig.tar.gz This has been tested from a Debian 2.0.1 linux host.
* Renamed exception constants per requests from Erik IvanenkoJoel Sherrill1998-11-191-19/+19
| | | | <erik.ivanenko@utoronto.ca> and Eric Valette <valette@crf.canon.fr>.
* Patch from Ian Lance Taylor <ian@airs.com>.Joel Sherrill1998-10-281-11/+19
| | | | | | | | | | | | | | | | | | | | | I just happened across the sync_io support in c/src/exec/score/cpu/unix/cpu.c (is this documented anywhere?). That looked more useful than the signal driven I/O I was using before, so I tried it. I ran across a few bugs in the way it uses select. Select changes its fd_set arguments, so you can't use global variables for them. You have to copy them into local variables first. If select returns -1 with errno set to EINTR, then it has not changed any of the fd_sets. You can't start looking at them. When clearing a descriptor, the code has the usual select off by one error when setting sync_io_nfds. I don't see how this code could ever have worked correctly. I have appended a patch for the problems I found.
* Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de> to correct minorJoel Sherrill1998-10-132-4/+4
| | | | cosmetic things.
* Corrected assembly language to use constants instead of addresses.Joel Sherrill1998-10-061-2/+2
| | | | Thanks to Rod Barman for this one.
* Added missing field (idle_task_stack_size) to CPU Table.Joel Sherrill1998-10-061-0/+1
|
* Patch from Thomas Doerfler <td@imd.m.isar.de> to improve 403 support.Joel Sherrill1998-10-014-1/+42
| | | | | | | | | | | | | | | | | - c/src/exec/score/cpu/powerpc/ppc.h: some small changes (added ppc403 characteristics like a exception vector prefix register, some special register definitions). I am quite sure, they are compatible with the existing sources, although I did not check - c/src/exec/score/cpu/powerpc/cpu.c: There is one severe limitation in the exception entries: Due to the current code arrangement, the "branch absolute" to the ISR handler may only jump to the first 128MByte or the last 128MByte of the 4GByte address range. When the ppc403 is running out of ROM, the ROM functions are located in the last 128MByte (0xFFF00000 and up). These addresses were not handled correctly (sign reduced) in "install_raw_handler". The change I added should work on existing ppc BSPs aswell...
* Patch from Eric Norum <eric@skatter.USask.Ca>:Joel Sherrill1998-09-302-18/+1
| | | | | | | | | | | | | | | | | | | | | | | I found that my 68040/68360 test programs would not run even after I fixed the `wrong BSP' problem. It seems that there's a bug in the interrupt handling code for processors with hardware interrupt stacks (e.g. 68040). The wrong status register was getting pushed on the stack for the `return from exception' to call _ISR__Dispatch. This ended up making the context switch code run on the interrupt stack, so interrupt-driven context switches would always fail. I guess that no one has tried running any of the RTEMS-4.0 snapshots on a 68040 machine! Anyhow, here are the patches for 1) gen68360.cfg --- to fix the `wrong-BSP' problem. 2) m68k/cpu_asm.s --- to fix the hardware interrupt stack problem. With these patches in place, the network demo programs run on my 68040/68360 system. The paranoia program runs with no failures, defects nor flaws.
* IDLE task stack size now specified as a field in the CPU Table for allJoel Sherrill1998-09-2310-0/+10
| | | | ports.
* Patch from Eric Valette <valette@crf.canon.fr>:Joel Sherrill1998-08-311-6/+17
| | | | | | | | | | | | | | | | | | | Eric> NB : there is still a bug on PC386 serial line : exit does not Eric> flush the remaining output queue. As this is not a bug in the Eric> driver itself but somewhere in PC386 initialization/termios Eric> relationship it will be part of another patch. Eric> NB2 : As Emmanuel excerced the exception hanlder code, while Eric> porting the SMC driver to the new BSD stack, we found a bug Eric> in the exception handler : it shall not delete the current Eric> thread in case we are running at interrupt level. This will Eric> be part of another patch... So here is the patch. This patch fixes the two problems mentionned above + it use vpath mechanism intead of copying the irq related files in the right directory. This avoid to compile them each time and is more homogenous with other Makefiles.
* Patch from Eric Valette <valette@crf.canon.fr>:Joel Sherrill1998-08-213-0/+216
| | | | | | | | | | Here is a patch that enables to catch exception and get message before crashing RTEMS :) It should be generic to any Intel port although enabled only for pc386 BSP... [Joel] I fixed the bug I introduced in irq_asm.s...
* Spacing changesJoel Sherrill1998-08-212-16/+14
|
* Patches from Eric NorumJoel Sherrill1998-08-201-1/+25
|
* FreeBSD stack compiles for the first time (except libc/strsep.c)Joel Sherrill1998-08-201-1/+1
|
* Patch from Eric Valette <valette@crf.canon.fr>:Joel Sherrill1998-08-192-5/+37
| | | | | | | - Use the "hlt" instruction for the Idle thread, - Optimise interrupt PATH leadding to thread wakeup, - Preparation for Intel exception management that should come before the end of the week...
* Added 68060 definition from Chris Johns.Joel Sherrill1998-08-191-0/+17
|