| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Comments follow:
Here is the contents of the network directory of the i386ex BSP. The
reset function has been recently added, and tested through a command
line interface. A reset event to the reset thread to reset the NIC.
This is done when the ISR detects that the NIC is in an invalid state.
It has not been tested "in real life" since the board has not seen an
invalid state since the reset function was implemented.
|
|
|
|
|
|
|
|
|
|
| |
<ian@airs.com> to fix this problem:
There is a small bug in __rtems_close in c/src/lib/libc/libio.c. It
does not check whether the file descriptor it is passed is open. This
can cause it to make a null dereference if it is passed a file
descriptor which is in the valid range but which was not opened, or
which was already closed.
|
| |
|
| |
|
|
|
|
|
| |
with the --disable-posix option, stubs for some routines (_getpid_r and
_kill_r) that are normally defined with POSIX were added.
|
|
|
|
|
|
|
|
| |
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 ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This problem should and likely was occurring with other BSPs. This is from
Chris' email:
I had a look in the psim bsp for the older snapshot I have and it looks
like you are using the `libbsp/shared/main.c' and this is known to work.
I have just built the powerpc tools, and compiled the bsp. I have not
added the linker command file patch so got the list of linker warnings.
It looks to me like a compiler bug. The `main' call is being inlined and
when that happens the special code to call `__eabi' is not being added
to the inlined version. I have attached a patch which places `main'
after `boot_card' and a call to main is now generated. I have not tested
it but it should work. I also include a dump of `boot_card' and `main'
showing the bug.
|
|
|
|
| |
prototype.
|
| |
|
|
|
|
| |
properly in conditionals
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
compiler dependent flag in a Makefile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some Makefile.ins depend on gcc by hard-coded gcc-specific compiler
flags:
-g added to CFLAGS /LDFLAGS in
> find . -name Makefile.in -exec grep -l ' \-g' {} \;
./c/src/lib/libbsp/i386/i386ex/startup/Makefile.in
./c/src/lib/libbsp/i386/pc386/tools/Makefile.in
-Wall added CFLAGS in
> find . -name Makefile.in -exec grep -l ' \-Wall' {} \;
./c/src/exec/score/tools/sh/Makefile.in
./c/src/lib/libbsp/i386/pc386/tools/Makefile.in
Both -g and -Wall should not be used in any Makefile.in (Yes, I know,
tools/sh/Makefile.in was written by me :-).
I'd like to propose to remove these flags from the files mentioned
above.
|
|
|
|
|
| |
.s files to .S in conformance with GNU conventions. This is a
minor step along the way to supporting automake.
|
|
|
|
|
| |
.s files to .S in conformance with GNU conventaons. This is a
minor step along the way to supporting automake.
|
| |
|
|
|
|
| |
Corsepius <corsepiu@faw.uni-ulm.de>.
|
|
|
|
| |
all conflicts.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Eric Norum <eric@skatter.usask.ca>
Date: Sat, 5 Dec 98 13:20:51 -0600
What do you think of this patch? It implements your `tap'
suggestion in a way that adds support for all ethernet devices with
no driver modifications. I also added a return value from the tap
function. If the return value is zero, the packet will be passed up
the chain as usual. If the return value is non-zero the mbuf holding
the packet will be freed and the packet will be dropped.
If you like it, please submit it to Joel.
I guess there needs to be an addition to the network documentation
describing the additional ioctl's -- and a big warning that the tap
function is called from a context that holds the network semaphore.
Here is Eric's patch. I've tested it a bit, and made a couple of
trivial changes. This is certainly better than mine: it should work
for all Ethernet drivers.
==================================================
The only concern I have about this patch is that the tap function may
want to fiddle with the mbuf, calling functions like m_pullup and the
like. If those force the networking code to rearrange the mbuf
structure, then the caller's call to m_freem may crash. I don't know
if this is a realistic concern--I don't know enough about the mbuf
layer.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RTEMS permits using the SO_SNDTIMEO and SO_RCVTIMEO socket options to
set a timeout for most socket I/O operations. However, in RTEMS
4.0.0, those options do not affect connect or accept. I don't know of
any way to put a timeout on those calls in RTEMS 4.0.0; can anybody
point to one.
Since it is frequently useful to have a timeout on accept, and
sometimes useful to have a timeout on connect shorter than the BSD
system default of 75 seconds, the following patch causes SO_RCVTIMEO
to affect connect and accept.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Modifications for RTEMS_UNIX.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Include files now installed as <rtems/*.h>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
overhaul of the RTEMS system call interface. This base file system is
the "In-Memory File System" aka IMFS.
The design and implementation was done by the following people:
+ Joel Sherrill (joel@OARcorp.com)
+ Jennifer Averett (jennifer@OARcorp.com)
+ Steve "Mr Mount" Salitasc (salitasc@OARcorp.com)
+ Kerwin Wade (wade@OARcorp.com)
PROBLEMS
========
+ It is VERY likely that merging this will break the UNIX port. This
can/will be fixed.
+ There is likely some reentrancy/mutual exclusion needed.
+ Eventually, there should be a "mini-IMFS" description table to
eliminate links, symlinks, etc to save memory. All you need to
have "classic RTEMS" functionality is technically directories
and device IO. All the rest could be left out to save memory.
|
| |
|
| |
|
|
|
|
| |
it work.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Here is a cosmetic patch which corrects a few spelling problems in parts
written by me.
Apparently, I must have written these under the influence of ether (:-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Socket timeout field changed from `short' to `long'. This makes longer
timeouts possible. With a 1 kHz system clock the old system allowed
timeouts only up to a little over 30 seconds! This change is a
slightly cleaned-up version of the patch proposed by Ian Lance Taylor.
2) Major changes to BOOTP/DHCP reply handling. Now supports much of
RFC2132. These changes were done at the request of, and with the
assistance of, Erik Ivanenko.
If you're making changes, you might want to change the network
supplement Essentially just do a global search and replace of BOOTP
with BOOTP/DHCP.
|