summaryrefslogtreecommitdiffstats
path: root/c/src/exec/score/cpu (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Fixed typo.Joel Sherrill1998-07-011-1/+1
|
* Coldfire support patch from David Fiddes <D.J.Fiddes@hw.ac.uk>.Joel Sherrill1998-06-253-14/+151
|
* Patch from Robin Kirkham <Robin.Kirkham@mlb.dmt.csiro.au> to distinguishJoel Sherrill1998-06-251-7/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between CPU32 and CPU32+ cores. Commentary follows: Unfortunately c/src/exec/score/cpu/m68k/m68k.h incorrectly defines M68K_HAS_MISALIGNED for the plain old CPU32 (it is correct for the CPU32+). As a consequence, the recently-relocated m68k memcpy() may still attempt misaligned memory accesses. I suggest that until such time as egcs/gcc differentiates these cores that we invent a new preprocessor symbol, RTEMS__mcpu32p__ for this purpose, on the assumption that egcs may one day grow a -mcpu32+ option which will define a __mcpu32p__ symbol (whether this option would also define __mcpu32__ is yet to be resolved). BSPs that have a CPU32+ (like gen68360) would for the time being define RTEMS__mcpu32p__ using -D. The symbol is `RTEMS__mcpu32p__' because symbols of the form __xxx__ should only be defined by the compiler itself. Note that the patch tests for RTEMS__mcpu32p__ *before* __mcpu32__, since __mcpu32__ is still defined for the CPU32+. It does not change the gen68360 BSP. An aside: Note that in egcs-1.0.3a, the option -m68332 is identical to -mcpu32, except it defines __mc68332__ as well as __mcpu32__. This is only for the sake of compatibility. The story with -m68302 is similar; it defines __mc68302__ and __mc68000__. In my opinion these options are depreciated and ought to be avoided in RTEMS.
* Suggestion from Robin Kirkham <Robin.Kirkham@mlb.dmt.csiro.au> to improveJoel Sherrill1998-06-241-2/+1
| | | | clarity.
* Added freebsd support from Dario Alcocer <alcocer@connectnet.com>.Joel Sherrill1998-06-183-2/+20
|
* Added optimized version of memcpy.c to this directory since RTEMS makesJoel Sherrill1998-06-122-1/+88
| | | | | | important distinctions between CPU models which are not made by gcc. These distinctions help give us a more optimized memcpy(). This is important for message queues and KA9Q.
* Added CPU_ISR_PASSES_FRAME_POINTER so some ports could pass just theJoel Sherrill1998-06-0311-0/+119
| | | | | vector number to user ISR's and other ports could pass both the vector number and a pointer to the ISF.
* Corrected macros for assembly language program sections.Joel Sherrill1998-06-031-2/+2
|
* Fixed spacingJoel Sherrill1998-05-271-16/+16
|
* Fix from Jiri Gaisler <jgais@ws.estec.esa.nl> for a problem in whichJoel Sherrill1998-05-271-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | external interrupt priorities were not being honored. Here is some of his original report: using rtems/erc32, I have a problem with interrupt priority when interrupts occure simultaneously. Erc32 has an interrupt force register where interrupts can be generated. If more than one interrupt is generated, the interrupt handlers are scheduled in the wrong order, i.e. with the lowest priority first. I have attched a program that generates three interrupts, 0x11, 0x12 and 0x13. Interrupt 0x13 should be handled first, but is actually handled last. Below is the output from sis: sis> go resuming at 0x02000000 RAM size: 4096 K, ROM size: 2048 K Watchdog disabled Waitstates = RAM read: 0, RAM write: 0, ROM read: 0, ROM write: 0 Power-down mode enabled infinite UART baudrate External interrupt received with vector 0x11 External interrupt received with vector 0x12 External interrupt received with vector 0x13 I have verified that sis generates the interrupts in the correct order, i.e. 0x13 first, then 0x12 and then 0x11. So the problem seems to be in the rtems interrupt handler. Do you use the PIL field in the %psr register to mask lower priority interrupts or are all external interrupts considered to have the same priority ..? Here is a description of the fix: it turned out that lower priority interrupts were not at all masked off during interrupt handling. I made the following fix to cpu_asm.s: ... fix is in the code ... There might be a simpler way of doing this, but this works...
* Per suggestion from Ralf Corsepius made all macros solaris2 -- not solarisJoel Sherrill1998-05-211-1/+1
| | | | or solaris2.
* Added bsp_specs.Joel Sherrill1998-05-181-3/+4
|
* fixed swap of unsigned16Joel Sherrill1998-05-041-6/+6
|
* Fixed case where wrong variable was used.Joel Sherrill1998-04-301-1/+1
|
* Added I386_HAS_BSWAP cpu model feature flag so swap u32 could takeJoel Sherrill1998-04-271-10/+28
| | | | | | | | advantage of this instruction. Also up conditionals mapping cpu models to feature flags by having a section which defaults all the i386 family feature flags to the most common value.
* Added swap of unsigned16Joel Sherrill1998-04-2711-3/+69
|
* Fixed spelling errors.Joel Sherrill1998-04-271-3/+3
|
* Fixed trace bit manipulation per requests from Eric Norum and Chris Johns.Joel Sherrill1998-04-271-11/+3
| | | | Actual patch was from Eric Norum.
* Fixed CVS IdJoel Sherrill1998-04-271-1/+1
|
* Added bh, ch, dh, bl, cl, and dl register macros.Joel Sherrill1998-04-151-0/+7
|
* Ralf Corsepius suggested a way to get rid of UNIX compiler files and use ↵Joel Sherrill1998-04-142-2/+1
| | | | gcc-target-default.cfg
* Refreshing effort from Avenger.Joel Sherrill1998-04-148-322/+1046
|
* Added "sigemptyset()" call to insure that the memcmp() would work.Joel Sherrill1998-03-311-0/+4
| | | | | It appears that the new glibc does not clear all the bits of the signal set with a sigprocmask.
* Changed int to unsigned32 to match cpu.h.Joel Sherrill1998-03-271-1/+1
|
* m68k software interrupt stack support from Chris Johns and Eric Norum.Joel Sherrill1998-03-253-32/+36
|
* Added _XOPEN_SOURCE definition to allow use of UNIX IPC.Joel Sherrill1998-03-241-0/+1
|
* Real definition for the beginning of the data section per Eric Norum'sJoel Sherrill1998-03-241-2/+2
| | | | suggestion.
* Corrected register constraints per suggestion from Thomas Doerfler, IMDJoel Sherrill1998-03-242-6/+6
| | | | <td@imd.m.isar.de>.
* More cpu model flags converted to using cpp predefines.Joel Sherrill1998-03-241-2/+2
|
* Rename hppa1_1 to hppa1.1 and switched to using __XXX__ macros forJoel Sherrill1998-03-242-14/+14
| | | | the CPU family name constants.
* Fixed spacing to be consistent with other CPUs.Joel Sherrill1998-03-211-1/+1
|
* Patch from Eric Norum <eric@skatter.usask.ca>:Joel Sherrill1998-03-201-81/+75
| | | | | | Here is my attempt at bringing m68k.h into line with the predefined symbols provided by egcs-1.0.2-prerelease (with R. Kirkham's patch so that -mcpu32, etc. implies -msoft-float).
* SH port submitted from Ralf Corsepius <corsepiu@faw.uni-ulm.de>.Joel Sherrill1998-03-2013-0/+2869
|
* updated copyright to 1998Joel Sherrill1998-02-1759-59/+59
|
* Swapped C++ and ASM "endifs"Joel Sherrill1998-02-171-2/+2
|
* Ralf Corsepius noticed that generally was spelled incorrectly.Joel Sherrill1998-02-0411-11/+11
|
* Big patch form Ralf Corsepius described in this email:Joel Sherrill1998-01-3011-44/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here is the result of my nightly work to get RTEMS_ROOT=$srcdir working with different shells and relative/absolute paths. What I did is relatively simple in principle: Instead of setting RTEMS_ROOT in configure.in and then let configure substitute @RTEMS_ROOT@ inside the Makefiles, I now let each Makefile set RTEMS_ROOT from each Makefile's @top_srcdir@ value. The difference is subtile, but with enormous side effects: - If RTEMS_ROOT is set in configure, then the same single value will be propagated to all Makefiles. This breaks using relative paths, as the relative path to the root of the source tree is used inside of all subdirectory Makefiles. - Now each Makefile.in sets RTEMS_ROOT = @top_srcdir@. top_srcdir is computed individually by configure for each single Makefile.in, hereby receiving the correct value, no matter if relative or absolute paths are used. To get this working, I needed to remove setting RTEMS_ROOT from target.cfg.in, because this overrides the value of RTEMS_ROOT from each individual Makefile. Furthermore, I removed RTEMS_CUSTOM from the Makefiles and replaced all "include $(RTEMS_CUSTOM)" directives with"include $(RTEMS_ROOT)/make/custom/$(RTEMS_BSP)". Perhaps you don't like this, but I think, to have one variable less is clearer and easier to understand than having several variables refering to the next one. I enclose a small patch to this mail, which - fixes the config.h problem (to finally clearify misunderstands) - removes assignment/subsitution of RTEMS_ROOT from configure.in - contains a workaround for the application Makefile's RTEMS_ROOT problem (reported by Eric) - removes some unused lines from the toplevel Makefile.in - removes assignment of RTEMS_ROOT from make/target.cfg.in
* Change to remove warning on glibc2 systems per Ralf Corsepius'sJoel Sherrill1998-01-281-1/+6
| | | | suggestion.
* Solaris port updates from Chris JohnsJoel Sherrill1998-01-231-10/+0
|
* Removed warning per Chris John's suggestion.Joel Sherrill1998-01-201-1/+1
|
* Removed CONFIG_DIR and PROJECT_HOME directories.Joel Sherrill1998-01-2011-11/+11
|
* Changed from .align to .p2align to avoid differences in meaning ofJoel Sherrill1997-12-221-6/+6
| | | | | .align between i386-rtems (real number on .align) and i386-go32-rtems (power of 2).
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-25 00:02:25 +0000