| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> 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 ;-.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
.s files to .S in conformance with GNU conventions. This is a
minor step along the way to supporting automake.
|
|
|
|
| |
Thanks to Rod Barman for this one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
ports.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
old way of setting th cpu family and model string names.
|
|
|
|
| |
specific register macros and correct code in rtems.s.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
clarity.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
vector number to user ISR's and other ports could pass both the vector
number and a pointer to the ISF.
|
| |
|
| |
|
|
|
|
| |
Actual patch was from Eric Norum.
|
| |
|
|
|
|
| |
suggestion.
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
any directory in the build tree. The only variable which must be set
before the command "gmake" is invoked is RTEMS_BSP (e.g. RTEMS_BSP=erc32).
|
|
|
|
| |
which have hardware support for a separate interrupt stack.
|
| |
|
|
|
|
|
|
| |
to lib/include.
Went to using a PROJECT_INCLUDE variable.
|
|
|
|
|
|
|
| |
The definition of "BEGIN_DATA" should not be null; should be ".data".
Also, the definition of "BEGIN_BSS" should be ".bss". For this error,
the compiled object has codes that write on the text segment area.
It is fatal when the code runs on ROM.
|
|
|
|
|
| |
<cjohns@plessey.com.au>. This patch includes the ods68302 bsp,
the RTEMS++ class library, and the rtems++ test.
|
|
|
|
|
| |
exiting from an ISR. This allows the trace bit to be set on a per task
basis and tracing to be limited to that task.
|
| |
|
|
|
|
|
|
| |
software floating point emulation code. Code implemented by
Karen Sara Looney <Karen.Looney@colorado.edu> with much
email assistance from Joel.
|
|
|
|
| |
of switching to the modified GNU GPL.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
was done based on the 3.6.0 release and had to be autoconf'ed locally.
It is turned on is the bsp enables it and it is not explicitly disabled
via the configure option --disable-tcpip. As many warnings as possible
were removed locally after the code was merged. Only the gen68360
and mvme136 bsps were compiled this way.
The ka9q port and network driver were submitted by Eric Norum
(eric@skatter.USask.Ca).
The network demo programs are not included in the tree at this point.
|
| |
|
|
|
|
| |
cores.
|