| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that converts the hppa1.1 directory to automake.
NOTE:
* Due to not having a toolchain (gcc refuses to build) this patch is
untested.
* I omited/deactivated the pxfl subdirectory, because I don't
understand how it supposed to work.
Joel's note: It was right to ignore the pxfl directory. It should be
removed one the BSPs are moved outside the tree. This was an old hack.
|
|
|
|
|
|
| |
that converts the a29k directory to automake.
NOTE: This port is not based on the GNU tools so no one can test it.
|
|
|
|
|
|
| |
that converts the a29k directory to automake.
NOTE: This port is not based on the GNU tools so no one can test it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that converts the i960 directory to automake.
The same kind of libbsp configuration as for the mips64orion, now for
the i960.
In addition to libbsp configuration this patch also contains two fixes
for cvme961.cfg and rxgen960.cfg, which contained non-functional
make-exes. (Now both bsps probably have the same issues with linking c++
applications as the gensh2 has, but this is a different open issue not
tried to be solved now).
The rxgen961 also seems to have problems with its start file, because
linking apps fails due to not finding start.o. (Note that
libbsp/i960/rxgen960 lacks a start subdirectory!). I leave solving this
issue to you :)
|
|
|
|
|
|
|
|
| |
that converts the mips64orion directory to automake.
Ralf's Note: This patch demonstrates another kind of supporting the new
style of configuration, which avoids having to port all Makefile.ins to
automake, but to keep using most old style Makefile.ins.
|
|
|
|
|
|
|
|
| |
that converts the mips64orion directory to automake.
Ralf's Note: This patch demonstrates another kind of supporting the new
style of configuration, which avoids having to port all Makefile.ins to
automake, but to keep using most old style Makefile.ins.
|
|
|
|
| |
that converts the no_cpu directory to automake.
|
|
|
|
| |
that converts the no_cpu directory to automake.
|
|
|
|
|
|
|
| |
that converts the unix directory to automake.
Ralf's note: Please check c/src/lib/libbsp/unix/posix/startup/Makefile.am.
I am not sure if it is correct.
|
|
|
|
|
|
|
| |
that converts the sparc directory to automake.
Ralf's note: The implementation of libbsp/sparc/* gives a nearly minimal
example of the new configuration scheme.
|
|
|
|
|
|
|
|
|
|
|
| |
that converts nearly all of libbsp/sh to automake. Comments follow:
1. Almost full automake support for the libbsp/sh/ subdirectories
(exception libbsp/sh/gensh*/wrapup/*)
2. Fixes for libbsp/bare/*
3. Updates to libbsp/* configuration which supports old (autoconf/deep
configuration) and new (automake/flat/cascaded configuration) style
configuration of libbsp/<cpu>/*
|
|
|
|
|
| |
interrupt code works on "old buggy MCP750 boards". The symptom was
that there was no ethernet PCI IRQ at all.
|
|
|
|
|
| |
the mvme2307 and mcp750 BSPs. In addition, it can support many
Motorola PowerPC based VME and PCI boards.
|
|
|
|
| |
serial drivers used in the 'gensh2' BSP for the Hitachi sh7045 CPU.
|
|
|
|
|
|
|
| |
problems:
- unclosed comment in pc386/start/start16.S
- bad #endif in pc386/startup/ldseg.S
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which is described below:
This one is a (minor) patch in preparation of the upcoming patches. It
actually is an excerpt of the upcoming patches and therefore is
completely untested in this standalone form, but I don't expect it to
break something.
The essential changes in this patch are:
* An update to rtems-polish.sh (Now can also be run in subdirectories)
* A bug-fix for the libcpu/powerpc (A directory was missing from
SUBDIRS in a Makefile.am)
* An update to gensh2.cfg.
* Cleanups/Enhancements to configuration files
To apply:
cd <srcdir>
patch -p0 < rtems-rc-20000104-0.diff
cvs rm -f c/src/lib/libbsp/Makefile.am.new
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
At the request of kjoutwater@west.raytheon.com I'm submitting the
following patch.
c/src/lib/libbsp/m68k/gen68360/console/console.c
Allow console baud rate to be set by debugger/downloader.
c/src/lib/libbsp/m68k/gen68360/startup/init68360.c
Add support for generic 68360 with static RAM.
|
|
|
|
|
|
|
|
|
|
|
| |
At the request of kjoutwater@west.raytheon.com I'm submitting the
following patch.
c/src/lib/libbsp/m68k/gen68360/console/console.c
Allow console baud rate to be set by debugger/downloader.
c/src/lib/libbsp/m68k/gen68360/startup/init68360.c
Add support for generic 68360 with static RAM.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In another attempt to get C++ exceptions working on the gen68360 target
I tried building for the m68k-elf target. All the tools built and
installed properly as did all of RTEMS. No applications would run,
though -- not even hello.exe!
It turns out the problem was in the linker script. The alignment was in
the wrong place.
Here's a patch. Exceptions still don't work, but at least I can get
some things working with the ELF format now.
|
| |
|
|
|
|
| |
errors.
|
|
|
|
| |
to added the bin2boot_SOURCES warning.
|
| |
|
|
|
|
| |
and reported by Ralf Corsepius <corsepiu@faw.uni-ulm.de> on the mpc505.
|
| |
|
|
|
|
| |
<valette@crf.canon.fr> and Jay Kulpinski <jskulpin@eng01.gdds.com>.
|
| |
|
| |
|
|
|
|
| |
old_exception_processing tree.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
to automake by Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
|
|
|
|
|
|
|
|
|
|
| |
which fixes a couple of bugs in RTEMS's old style Makefile.ins, which
apparently were introduced by moving the start directories and not
having adapted the Makefile.ins.
To apply:
patch -p1 < rtems-rc-19991203-10.diff
|
|
|
|
|
|
|
|
|
| |
which ontains all what was left over from the other patches (Primarily
minor configuration cleanups).
To apply:
patch -p1 < rtems-rc-19991203-9.diff
./bootstrap
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which adds partial automake support to libcpu/<cpu>/*.
Until now I have only implemented full automake support for the sh (my
demonstration example :) and the i386 (inevitiable for structural
reasons of this subdirectory). For all other cpus only their toplevel
directories (exception: powerpc), include subdirectories and a few
selected subdirectories have been converted to automake.
I did this on purpose, because add automake support to each subdirectory
requires individual adaptations which to be tested individually.
Additionally the weirdnesses of the powerpc subdirectories hit again,
esp. some powerpc cpu-models
* install files to $(PROJECT_INCLUDE)/<cpu-model>/ while others install
them to $(PROJECT_INCLUDE)/
* the scheme used to configure libcpu/powerpc/ is difficult to implement
using automake, therefore this subdirectory still is configured by
autoconf (The one out of an unlimited set selection scheme hits again
:), though powerpc/*/* subdirectories already apply automake.
The patch also reveils structural weaknesses in RTEMS:
E.g. There seem to exist at least 5 different general schemes:
* Not using libcpu at all (eg. i960)
* Strictly tree-style a libcpu/<cpu-variant>/* (eg. m68k, sh)
* Flat libcpu directory layout with cpu-variants merged into sources or
not destinguishing cpu-variants (i386)
* Not supporting variants with deep source tree (sparc, hppa, mips64orion)
* Woven directory structure with shared directories (powerpc)
I regret having to say this, but from my POV this means, that there
doesn't exist a general implementation scheme for libcpu at all.
To apply:
rm -rf ./c/src/lib/libcpu/i386/wrapup
rm -rf ./c/src/lib/libcpu/mips64orion/include
rm -rf ./c/src/lib/libcpu/powerpc/ppc403/include
patch -p1 < rtems-rc-19991203-7.diff
./bootstrap
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which adds partial automake support to libcpu/<cpu>/*.
Until now I have only implemented full automake support for the sh (my
demonstration example :) and the i386 (inevitiable for structural
reasons of this subdirectory). For all other cpus only their toplevel
directories (exception: powerpc), include subdirectories and a few
selected subdirectories have been converted to automake.
I did this on purpose, because add automake support to each subdirectory
requires individual adaptations which to be tested individually.
Additionally the weirdnesses of the powerpc subdirectories hit again,
esp. some powerpc cpu-models
* install files to $(PROJECT_INCLUDE)/<cpu-model>/ while others install
them to $(PROJECT_INCLUDE)/
* the scheme used to configure libcpu/powerpc/ is difficult to implement
using automake, therefore this subdirectory still is configured by
autoconf (The one out of an unlimited set selection scheme hits again
:), though powerpc/*/* subdirectories already apply automake.
The patch also reveils structural weaknesses in RTEMS:
E.g. There seem to exist at least 5 different general schemes:
* Not using libcpu at all (eg. i960)
* Strictly tree-style a libcpu/<cpu-variant>/* (eg. m68k, sh)
* Flat libcpu directory layout with cpu-variants merged into sources or
not destinguishing cpu-variants (i386)
* Not supporting variants with deep source tree (sparc, hppa, mips64orion)
* Woven directory structure with shared directories (powerpc)
I regret having to say this, but from my POV this means, that there
doesn't exist a general implementation scheme for libcpu at all.
To apply:
rm -rf ./c/src/lib/libcpu/i386/wrapup
rm -rf ./c/src/lib/libcpu/mips64orion/include
rm -rf ./c/src/lib/libcpu/powerpc/ppc403/include
patch -p1 < rtems-rc-19991203-7.diff
./bootstrap
|
|
|
|
|
| |
which cleans up and merges some Hitachi SH-2 modifications from
John Mills <jmills@tga.com>.
|
| |
|
|
|
|
|
|
|
|
|
| |
I got tired of having strange clock rates (e.g. #define
CONFIGURE_MICROSECONDS_PER_TICK 52489) and drifting times-of-day with
the gen68360 BSP so I changed the way the programmable-interval clock
interrupt works. The new version will have some jitter in the intervals
between individual calls to the rtems_clock_tick routine, but the
long-term average will match the CONFIGURE_MICROSECONDS_PER_TICK
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
fixes some problems:
I found the problem which prevented opening 'dev/sci1' (the default
console) with the 'gensh2' (sh7045) BSP. Both SCI ports were being
initialized against the same minor device number: '0'. When I tried to
open minor-device '1', it naturally crashed. Fixing that one value in the
'sci_device[]' array solved the problem and allowed 'hello.exe' to run.
|