| 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).
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
based board.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This patch avoids a warning from the development version of gas.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
<erik.ivanenko@utoronto.ca> and Eric Valette <valette@crf.canon.fr>.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
cosmetic things.
|
| |
|
|
| |
Thanks to Rod Barman for this one.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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...
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
- 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...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
inline with the new IRQ structure.
|
| |
|
|
| |
Enabled on the pc386.
|
| |
|
|
| |
old way of setting th cpu family and model string names.
|
| |
|
|
| |
specific register macros and correct code in rtems.s.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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...
|
| |
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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...
|
| |
|
|
| |
or solaris2.
|
| | |
|
