summaryrefslogtreecommitdiffstats
path: root/c/src/exec/score/cpu (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
|
* Patch from Chris Johns <ccj@acm.org>. Comments follow:Joel Sherrill1998-08-131-0/+19
| | | | | | | | | | | Here is a small patch which allows the m68060 to be used. I have not tested the FP switching stuff which we know is broken. This is taken against the libchip snapshot but should merge without problems. If you have any problems please let me know. There are other smaller issues such as superscalar enable and cache control which I have not addressed yet. They are different to all other m68k processors. These can wait IMO.
* Patch from Eric Valette <valette@crf.canon.fr> which brings the i386ex BSPJoel Sherrill1998-08-052-499/+0
| | | | inline with the new IRQ structure.
* Automatic CPU type detection code from Eric Valette <valette@crf.canon.fr>.Joel Sherrill1998-08-051-0/+1
| | | | Enabled on the pc386.
* Redid Makefiles to properly do a preinstall. There was remnants of theJoel Sherrill1998-08-0511-62/+20
| | | | old way of setting th cpu family and model string names.
* Merged patch from David Fiddes <D.J.Fiddes@hw.ac.uk> to add ColdFireJoel Sherrill1998-08-012-1/+15
| | | | specific register macros and correct code in rtems.s.
* Patch from Eric Valette <valette@crf.canon.fr>:Joel Sherrill1998-07-301-1/+1
| | | | | | Now that Joel told me how to compile outside the tree, I have found a few more bugs. Here is a small patch to fix them.
* Patch from Eric VALETTE <valette@crf.canon.fr>:Joel Sherrill1998-07-234-396/+2
| | | | | | | | | | | | | Here is a enhanced version of my previous patch. This patch enables to potentially share the new interrupt management code for all Intel targets (pc386, go32 and force386) bsp. Note : this patch is complete only for pc386. It still needs to be completed for go32 and force386. I carrefully checked that anything needed is in for force386 (only some function name changes for IDT manipulation and GDT segment manipulation). But anyway I will not be able to test any of theses targets...
* Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>:Joel Sherrill1998-07-231-0/+18
| | | | | | | Here is a pure sh-rtems bug-fix patch. The defines to enable the network to host conversion macros in netinet/in.h were missing in sh/cpu.h
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-07 12:11:09 +0000