Cherrypick from master 2000-05-08 20:36:59 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'New file added on 4.5 branch':
c/src/lib/libbsp/m68k/mvme167/console/console-recording.c
to address problems triggered when switching modes. His ChangeLog:
* c/src/lib/libbsp/m68k/mvme167/console/console-recording:
New file. Console debug info recording functions.
* c/src/lib/libbsp/m68k/mvme167/console/console.c:
Try to eliminate garbled characters when the line characteristics are
changed. Added debug info logging calls
* c/src/tests/libtests/termios/init.c: Remove sleep calls.
His longer description :)
This one was hard. I tried a number of approaches, and eventually came
to the conclusion that one cannot tell when the output FIFO have drained
completely. Consequently, the driver now includes delay loops that get
executed when the line discipline is changed. Yuk. I had a look at the
Linux and FreeBSD drivers; the FreeBSD driver uses delay loops while the
Linux driver contain warnings about characters getting garbled when the
line discipline is changed.
The new driver only re-initializes the cd2401 if some registers need to
change, otherwise, the chip is left alone. This is equivalent to caching
the previous setting and only changing things if they need to be. The
code is kind of ugly, but what can you do. The delay loops are only used
if the chip must be re-initialized.
Optional instrumentation that records what the driver is doing is
provided. It should be obvious how to enable it and how to use it. It's
not the best, but it got the job done.
I ran the termios test. The delay loops I had introduced are no longer
necessary, so I took them out. The patch includes that change. The test
re-initializes the chip whenever the canonical input test (test 4) is
run THE FIRST TIME OR AFTER THE LINE WAS RESET (test 1). The test did
not garble any characters when the chip was re-initialized (or when it
was not) while running at 9600 bsp. I therefore think that I have a
solution.
Cherrypick from master 2000-05-03 13:55:42 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'Added on 4.5 branch.':
c/src/librpc/src/rpc/rtems_portmapper.c
c/src/librpc/src/rpc/rtems_rpc.c
that:
This is the patch I had announced earlier today:
It addresses:
* make dist - support (In a configured build tree, cd .../librpc; make
dist now packages a complete tarball)
* man-pages - support
* missing .cvsignores
* missing Makefile.ams
It does not address the portability issue I mentioned earlier.
To apply the patch:
cd rtems
patch -p1 < rtems-4.5.0-rc-19.diff
cvs add c/src/librpc/include/rpcsvc/Makefile.am
cvs add c/src/librpc/include/rpcsvc/.cvsignore
cvs add c/src/librpc/src/rpc/PSD.doc/Makefile.am
cvs add c/src/librpc/src/rpc/PSD.doc/.cvsignore
cd c/src/librpc
../../../bootstrap
Cherrypick from master 2000-05-01 14:57:46 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'Added on 4.5-branch':
c/src/librpc/include/rpcsvc/.cvsignore
c/src/librpc/include/rpcsvc/Makefile.am
c/src/librpc/src/rpc/.cvsignore
c/src/librpc/src/rpc/PSD.doc/.cvsignore
c/src/librpc/src/rpc/PSD.doc/Makefile.am
c/src/librpc/src/xdr/.cvsignore
functionality from FreeBSD. This update is from Eric Norum
<eric@cls.usask.ca> and he reports that both his RPC netdemo
program and an HP Ethernet/GPIB adapter that makes heavy
use of RPC/XDR for its communication protocol is working with EPICS.
The patch below is a work-around to the "make/gmake" problem.
This only works if gmake-only users set MAKE=gmake at configuration time
or explicitly set it from the environment at make-time.
IIRC, this should be sufficient for ./bit users, because it explicitly
exports MAKE.
Cherrypick from master 2000-04-28 17:42:16 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'New files added on 4.5 branch.':
c/src/libnetworking/memory.h
c/src/libnetworking/sys/un.h
from Ralf Corsepius <corsepiu@faw.uni-ulm.de> that address the following:
* NoSource: 0, 1 in rpm-specs does not work anymore under SuSE-6.4
(rpm-3.0.4), putting each NoSource: onto a separate line however seems
to work. Unfortunately, I don't know the actual cause for this, esp. if
SuSE broke it or if rpm-specs specification has changed (i.e.
Redhat broke it up).
* Add *.spec to several .cvsignores (Prevents cvs from complaining about
<target>*.spec within the source-tree).
from Ralf Corsepius <corsepiu@faw.uni-ulm.de> that address the following:
* NoSource: 0, 1 in rpm-specs does not work anymore under SuSE-6.4
(rpm-3.0.4), putting each NoSource: onto a separate line however seems
to work. Unfortunately, I don't know the actual cause for this, esp. if
SuSE broke it or if rpm-specs specification has changed (i.e.
Redhat broke it up).
* Add *.spec to several .cvsignores (Prevents cvs from complaining about
<target>*.spec within the source-tree).
that addresses configuration issues for posix/linux under SuSE-6.4:
Unbelievable as it is, SuSE has started to use i486-suse-linux as
canonicalization triple which breaks out linux/posix/unix.
I discovered that when specifying -m68000 and -msoft-float to gcc 2.95.2,
it decides that the proper multilib variant is the default one which is
compiled for the m68020 and hardware floating point. This appears to be
because there is no 68000/soft-float library variant. This problem
applies to all m68000 class CPUs options including -m68302.
