| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
Added multiprocessing conditional.
|
|
|
|
|
|
had not yet been debugged.
|
|
|
|
installed.
|
|
|
|
|
|
|
|
|
|
--enable-tests problem a better way.
|
|
This patch addresses a few minor issues and contains a few (minor)
preparations for automake.
* configure.in: Fix for handing c/src/tests subdirectory handling (FIX)
* aclocal/rtems-top.m4:
+ Add TARGET_SUBDIR and --with-target-subdir (preparation of future
enhancements for cross-compiling)
+ Activate RTEMS_ROOT handling (automake preparation)
* automake/*.am: replace comments "#" with "##" so that comments won't
get included into Makefile.in's anymore
* c/update-tools/* automake support (NEW)
* ./autogen update/enhancement (cf. ./autogen for details)
After applying this patch please run:
./autogen
cvs add c/update-tools/configure.in
cvs add c/update-tools/Makefile.am
cvs add c/update-tools/aclocal.m4
|
|
|
|
|
|
In c/src/exec/score/cpu/powerpc/rtems/score/ppc.h:
A lot of hardware interrupts were omitted. Patch enclosed.
I have also added the 821.
In c/src/exec/score/cpu/powerpc/rtems/score/cpu.h:
My patch adds the 821.
In c/src/exec/score/cpu/powerpc/cpu.c:
I have added the MPC821, and also fixed up for the missing hardware
interrupts. It is also inconsistent with
c/src/lib/libcpu/powerpc/mpc860/vectors/vectors.S. This has been fixed.
In c/src/lib/libcpu/powerpc/mpc860/vectors/vectors.S:
Fixed an inconsistency with cpu.c.
I also include some new files to go with the above patches. These are the
cpu library rtems-19990331/c/src/lib/libcpu/powerpc/mpc821/* and
c/src/exec/score/cpu/powerpc/mpc821.h which are minor modifications of
the 860 equivalents.
Other comments:
The various accesses to the DPRAM on the 860 are done with a linktime
symbol. This could be done dynamically at run time by reading the immr
register, and masking off the lower 16 bits. This takes the same amount
of time as loading an address constant, and the same number of
instructions as well (2).
In c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c:
This will silently fail if you attempt to use SCC1. This is only relevant
if you are not using SCC1 for ethernet.
This file also sets one of port B output pins for each port. This is NOT
generic, it should be in the BSP specific console driver.
|
|
|
|
the reset of the CPU specific implementations after comment from
Eric Norum.
|
|
<e.norum@sk.sympatico.ca> and concerns from Thomas Doerfler
<td@imd.m.ISAR.de> when he submitted the patch:
Since enabling XON/XOFF has such a major performance hit on `smart' output
devices I think it should be *off* by default. I think some thought should
be given to adding hooks for hardware that can support XON/XOFF without
software intervention, or for hardware like the 68360 SCC's that can use
large buffers, but still handle special characters immediately.
The patch you sent is a very good start, though. I just think that the
software flow control should be off -- to match the way the serial I/O
support has worked up until now.
|
|
|
|
|
|
Some lines for "documentation":
======================================
One thing should be noted: when XON/XOFF is enabled, the serial
device will always work with one-character buffers, so the interrupt
load for the CPU might get higer, especially on devices like MC68360
and MPC860, where the serial channels are capable of using big
buffers. But, once again, this only happens when XON/XOFF is actually
selected.
Please note that the flag IXON is set by default, so outgoing
XON/XOFF flow control is enabled by default.
XON/XOFF is controlled using the "standard" fields IXON/IXOFF in the
termios structure. The termios flag IXANY is not (yet) supported.
Hardware handshake for the incoming data stream is controlled using
the standard flag CRTSCTS. If this flag is set, whenever the receive
buffer is almost full, the driver function "device.stopRemoteTx()" is
called, when the receive buffer has more space available,
"device.startRemoteTx()" is called again. If the driver does not
provide these interface functions (entries in device structure are
NULL pointers), then these calls are suppressed.
Changes of the flow control options during operation should work at
any time, but this has not been extensively tested.
No changes to the device driver interface are needed.
================================================
One critical point when using this patch might be, that any BSP using
this version of termios will now have outgoing flow control enabled
by default, so the behaviour of these BSPs will change here. The
option IXON has already been set in older termios by default, but it
did not work until this patch. Maybe this option should be switched
off by default, what do you think?
|
|
|
|
indicates an internal error.
|
|
|
|
|
|
|
|
joel@OARcorp.com wrote:
>
> Chris,
>
> sp09 fails on the rtems_port_delete(0) call. This is supposed to give an
> invalid id error. I can't find any changes other than the unlimited
> objects patch which would have tripped this so would appreciate it if you
> could look into it. I suspect that this is a side-effect of the unlimited
> objects patch.
>
It is me.
>
> Basically, there are 0 ports configured in sp09. The test ends up
> dereferecing NULL in local_table[0] and comes up with a non-NULL invalid
> pointer.
>
The issue is not actually allocating a local_table for an object type
which has a maximum value of 0. I cannot remember the exact workings of
the id values and the local_table. I might have changed the nature from
the pre-unlimited change. As you know the id's are an interesting game
where performance is most important.
>
> I know the problem could be solved by adding a check for index == 0. But
> I hate to slow this path down. I think you may have changed the way the
> object information structure gets initialized.
>
---- CVS log ----
This change lets the unlimited and sp09 tests run on the posix Linux
BSP. A static local variable `null_local_table' has been added. This
variable is always set to NULL. The `**local_table' element of the
information structure is set to point to this variable earily in the
initialisation. If the object type has more than 0 elements the
`local_table' element is updated. All object types which have 0 elements
reference `null_local_table'. This change fixes the problem sp09 found
yet does not add any extra processing to the critical
`_Objects_Get_local_object' function.
---- CVS log ----
|
|
included and we ended up with undefined references.
|
|
sequence.
|
|
|
|
|
|
and _POSIX_signals_Set_process_signals was done twice.
|
|
|
|
Yet some more modifications, I would recommend to be considered before
releasing a snapshot:
1. Cleanup to aclocal/
cvs rm -f aclocal/cygwin.m4
cvs rm -f aclocal/exeext.m4
They are neither used nor needed anymore, however they also don't
disturb (we use autoconf-2.13's AC_EXEEXT instead, now)
----------
2. rtems-rc-19990328-0.diff
Some (minor) bug-fixes:
* make/Templates/Makefile.inc.in: use the new installation directory
($(prefix)/ instead of $(prefix)/rtems/)
* c/src/exec/score/tools/generic/Makefile.am: added line to include local.am
* c/src/exec/score/tools/*/configure.in: added CVS Id header
----------
3. rtems-rc-19990328-1.diff
Enhancements and cleanups to autogen, rtems-polish.sh, configure.in etc.
* autogen: Use the file "VERSION" to detect RTEMS toplevel directory,
extended usage-message, use "find -print"
* c/update-tools/cipolish: New script to beautify configure.in scripts
* c/update-tools/rtems-polish.sh: Use the file "VERSION" to detect RTEMS
toplevel directory, extended usage-message, added variable for perl
scripts' subdirectory, use "find -print", cipolish support, new options
-ac -am -ci.
* aclocal/*.m4, configure.in: moved some AC_SUBST lines to aclocal/*.m4
(reduces size of configure.in
scripts, eases splitting configure.in scripts).
----------
|
|
|
|
problem.
|
|
|
|
|
|
routines.
|
|
Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
|
|
There seems to be an ugly dependency between posix-headers and
libcsupport.
Configuring rtems with
../rtems-rc-19990324-0/configure \
--target=i386-rtems \
--prefix=<somewhere> \
--disable-posix
"make RTEMS_BSP=pc386" results into:
[...]
/opt/rtems/bin/i386-rtems-gcc --pipe
-B/users/rtems/src/multi/build/pc386/lib/ -specs bsp_specs -qrtems
-I/users/rtems/src/multi/build/pc386/lib/include/networking -g -Wall
-ansi -fasm -O4 -fomit-frame-pointer -c -o o-pc386/utime.o
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c
In file included from
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:16:
/opt/rtems/i386-rtems/include/utime.h:4: sys/utime.h: No such file or
directory
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:24: warning:
`struct utimbuf' declared inside parameter list
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:24: warning:
its scope is only this definition or declaration,
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:24: warning:
which is probably not what you want.
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c: In function
`utime':
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:34:
dereferencing pointer to incomplete type
../../../../../rtems-rc-19990324-0/c/src/lib/libc/utime.c:34:
dereferencing pointer to incomplete type
make[4]: *** [o-pc386/utime.o] Error 1
make[3]: *** [all] Error 1
make[2]: *** [all] Error 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/lfs/poseidon/users/rtems/src/multi/build/c'
make: *** [all] Error 1
Apparently sys/utime.h is one of the posix headers and therefore gets
not installed (I suppose this is correct).
IMO, this probably indicates that sys/utime.h has to be moved to another
include subdirectory and should not be part of the posix-package.
[AFAIK, sys/*.h are system dependent headers, so why should it be a
posix-header? - Hmm]
|
|
With my most recent automake patch (automake II) we could even simplify more
files below make/, because the host-compiler related parts of those files
aren't used anymore :-.
Whatsoever, the patch below should fix this problem.
Note: This is a mere bug fix, it doesn't move any of the variables involved
to target.cfg nor does it try to eliminate any variable.
|
|
by Jiri Gaisler <jgais@ws.estec.esa.nl>.
|
|
network interface names. This change does not introduce any
compatibility problems.
|
|
description follows:
Description:
* automake for *all* tool subdirectories (Makefile.am, configure.in etc.)
* autogen now also considers CONFIG_HEADER (generates stamp-h.ins and
config.h.ins)
* c/src/tests/tools/generic/difftest and
c/src/tests/tools/generic/sorttimes generated by configure scripts
* c/update-tools/ampolish, beautifier for Makefile.ams, similar to
acpolish
* rtems-polish.sh added to c/update-tools/ + ampolish support
* New subdirectory ./automake, contains automake -Makefile fragments to
support RTEMS make "debug, debug_install, profile, profile_install" for
native Makefile.ams (== ignore these make targets).
* aclocal/rtems-top.m4's RTEMS_TOP now reads the automake makefile
variable VERSION from RTEMS ./VERSION file.
* ./configure.in uses the macros from aclocal + support for the tools'
configure scripts
Remarks:
* To run rtems-polish.sh, "cd <rtems-source-tree>;
./c/update-tools/rtems-polish.sh"
* AFAIS, now all native subdirectories are converted to automake (Please
drop me a note, if I forgot something).
* Unless you notice something fatal, IMO the time has come for a public
try (== snapshot). I do not intend to send more automake related patches
within, say 2 weeks, to give these patches time to settle and to give me
some time to think on how to continue.
* The patch assumes installation to the new main installation directory
[$(prefix)].
|
|
|
