| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> > 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 ...
|
| |
|
|
|
| |
.s files to .S in conformance with GNU conventions. This is a
minor step along the way to supporting automake.
|
| |
|
|
| |
ports.
|
| |
|
|
| |
old way of setting th cpu family and model string names.
|
| |
|
|
|
| |
vector number to user ISR's and other ports could pass both the vector
number and a pointer to the ISF.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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...
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
|
| |
to lib/include.
Went to using a PROJECT_INCLUDE variable.
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNU autoconf. This is the first large step in allowing an RTEMS
user to perform a one-tree build (per crossgcc FAQ) including RTEMS
in the build process. With this change RTEMS is configured in
built in the same style as the GNU tools, yet retains the basic
structure of its traditional Makefiles (ala Tony Bennett).
Jiri Gaisler (jgais@wd.estec.esa.nl) deserves (and received)
a big thank you for doing this.
There are still issues to be resolved but as of this commit, all target
which can be built on a linux host have been using a modified version
of the source Jiri submitted. This source was merged and most targets
built in the tree before this commit.
There are some issues which remain to be resolved but they are primarily
related to host OS dependencies, script issues, the use of gawk
for hack_specs, and the dependence on gcc snapshots. These will
be resolved.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is current as of sis 2.6.
|
| | |
|
| | |
|
| |
|
|
| |
on the real erc32 hardware.
|
| |
|
|
| |
subject to causing unpredictable window underflow/overflows.
|
| |
|
|
| |
score, rtems api, or posix api related.
|
| | |
|
| |
|
|
|
| |
part of the Thread Handler. This required the name of the optional
CPU dependent IDLE thread implementation to change.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
