Sprout from rtems-4-5-branch 2001-10-16 20:54:30 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'changed version to 4.5.1-pre2'
Cherrypick from master 1999-03-31 23:21:19 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'Fixed paths to include files so this will build.':
c/src/lib/libcpu/mips/clock/clock.S
* libc/termios.c: Fixed a memory leak in the termios
software. Basically the tty open function was allocating an input
raw buffer, an output raw buffer, and a cooked buffer that were
not getting released. I have attached a patch for the latest
snapshot. The patch also has a fix to ensure the tty link list
is updated correctly when a tty is closed.
* cpu_asm.S: Small patch to fix a bug in the rtems sparc port. The
bug has been there all the time, but only hits the leon bsp since the
leon cpu has a 5-stage pipeline (erc32 has 4 stages).
* src/coremutex.c, src/coremutexseize.c, src/coremutexsurrender.c:
The per thread field resource_count should only be manipulated
when a mutex is priority ceiling or priority inherit. This
was reported by Chris Johns <ccj@acm.org> who also noticed that
the use of switches for all disciplines generated less efficient
code than using explicit tests for the one or two cases we were
really interested in. Further review of his modifications made
it apparent that the "isa" methods to test mutex discipline were
not being used so this modification was swept into the code as well.
* src/mqueuesendsupp.c: Account for possibly blocking during the
core send operation.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* src/msgqsubmit.c: Add a comment indicating that we do not have
to account for possibly blocking during the core send operation
because Classic API message queue send is always non-blocking.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* include/rtems/score/coremsg.h, src/coremsgsubmit.c: Add a new
return status to account for blocking sends. Otherwise, the
caller will think that the returned message status will have
the ultimate results of the operation. If the send times out,
the final status will be in the return_code of the thread.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* src/coremutexsurrender.c: Use holder thread not executing
thread because even though they may and often are the same
it is not guaranteed unless the proper attribute is set.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* startup/linkcmds: Modified to work better with gcc 2.8.1 and
gnat 3.13p.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* tools/runtest.in: Recognize debug variant of monitor test.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* sp13/sp13.scn: Id in screen had wrong class field value.
* sp13/system.h: Account for message buffer memory.
* sp13/task2.c: Remove unnecessary check for failure.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* sp20/system.h: Account for extra task stacks properly.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* include/tmacros.h: Attempt to print errno as further information.
* libc/lseek.c: Modified after discussion with Eugeny S. Mints
<jack@oktet.ru> to correct the behavior. There were two mistakes.
First, iop->offset was incorrectly set for SEEK_END. Second,
iop->offset should be left unmodified if there are errors.
This modification attempts to fix both situations.
* src/mqueuesendsupp.c: Account for possibly blocking during the
core send operation.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* src/msgqsubmit.c: Add a comment indicating that we do not have
to account for possibly blocking during the core send operation
because Classic API message queue send is always non-blocking.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* include/rtems/score/coremsg.h, src/coremsgsubmit.c: Add a new
return status to account for blocking sends. Otherwise, the
caller will think that the returned message status will have
the ultimate results of the operation. If the send times out,
the final status will be in the return_code of the thread.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* src/coremutexsurrender.c: Use holder thread not executing
thread because even though they may and often are the same
it is not guaranteed unless the proper attribute is set.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* startup/linkcmds: Modified to work better with gcc 2.8.1 and
gnat 3.13p.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* tools/runtest.in: Recognize debug variant of monitor test.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* sp13/sp13.scn: Id in screen had wrong class field value.
* sp13/system.h: Account for message buffer memory.
* sp13/task2.c: Remove unnecessary check for failure.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* sp20/system.h: Account for extra task stacks properly.
2001-08-16 Joel Sherrill <joel@OARcorp.com>
* include/tmacros.h: Attempt to print errno as further information.
* c/src/lib/libbsp/i386/i386ex/startup/linkcmds,
c/src/lib/libbsp/powerpc/eth_comm/canbus/Makefile.am,
c/src/libnetworking/pppd/ipxcp.c: These files had latent single
bit mistakes from the CVS server's RAM failure.
* cpu_asm.S: This patch was co-developed with Eric Norum
<eric.norum@usask.ca>. It closes a one instruction window
on some m68k CPU cores. It fixes symptoms seen as:
1) No more `interrupt handler invoked twice for
a single interrupt'.
2) No more `lockup when mc68360 CPM and PIT interrupts
are at different levels'.
It does insert a little more overhead on machines without hardware
interrupt stacks but correctness has a price.
* c/src/exec/itron/src/snd_mbx.c, c/src/exec/itron/src/tsnd_mbf.c
c/src/exec/posix/src/mqueuesendsupp.c,
c/src/exec/rtems/src/msgqsubmit.c,
c/src/exec/score/include/rtems/score/coremsg.h,
c/src/exec/score/inline/rtems/score/coremsg.inl,
c/src/exec/score/src/coremsgsubmit.c: Unblocking message queue
operations should NOT use _Thread_Executing for return status
since it is permissible to invoke message send operations from
an ISR. This was reported by Suvrat Gupta <suvrat@utstar.com>.
* src/eventsurrender.c: Clear event condition when task is unblocked.
This makes sure that subsequent event send thinks the task is still
blocked and overwrites the initial events received.
* src/heapallocate.c: Do not allow the size to overflow when
adjusting it. A test allocated a stack of -1 (~0). This
actually resulted in a stack being allocated but with a
size of 0xb. The allocator did not test the size to see if
it rolled through 0 and so allowed the allocation to happen, the
thread to get created. The task crashed as you would expect.
where alarm() did not correctly account for the watchdog start_time
and stop_time fields being based on ticks not seconds. This resulted
in alarm() returning a bogus number of seconds remaining.
that is a hack to workaround a switch generation compiler bug for the
SH2 and cleaned up some warnings.
CVS: ----------------------------------------------------------------------
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: c/src/tests/libtests/termios/init.c
CVS: ----------------------------------------------------------------------
Jennifer Averett <jennifer.averett@oarcorp.com> to fix
appends (O_APPEND at open time) on in-memory files.
A call such as:
fd = open (file, O_APPEND | O_WRONLY);
did not append to the end of the file.
gccnewlib.add applies find -path=... which might cause files.gcc
getting corrupted.
This seems to be gnu-find specific and doesn't seem to be supported
by Solaris find (/usr/bin/find). I didn't see this because I use
gnu-find even under Solaris (/amd/bin/find under our Solaris
installation).
This causes the first call to find in gccnewlib.add to deliver
incorrect results and may result into incorrectly setting up the
files.* files, esp. files.gcc.
1. Fixes a typo in the code conditionalized by GEN68360_WITH_SRAM
2. Mods the code to add support for an additional bank of SRAM (needed more RAM
to run the web server!)
From <vac4050@cae597.rsc.raytheon.com> reviewed by Eric Norum <eric@cls.usask.ca>.
* updated README
* improved misc script for running the RTEMS test programs
* Updated 332 SIM configuration in start.c
* C++ global constructor fix (USE_INIT_FINI)
* change __end_of_ram to _RamEnd to match changes by others
This is the diff to let gcc-target-default.cfg use LINK.c -Wl,-r
instead of LD -r for building *.rels.
BTW: gcc -r works but seems to be undocumented, however
as gcc -r -v shows it seems to works. Now I am using -Wl,-r :-)
of an experiment to determine what it will take to multilib most of
RTEMS per GNU multilib conventions. It is thought that only
interrupt processing and IO are not multlib-able. This means that
a BSP Kit should include IRQ processing from score/cpu, all peripheral
support (header files from score/cpu, libchip, and libcpu), and the
BSPs themselves. The rest of RTEMS should be multlib-able. But to do
this, all RTEMS CPU model feature flags must be derivable from gcc
cpp predefines. By configuring the bare bsp with the rtems_multilib
CPU model, you can try any combination of CPU CFLAGS and see well how the
logic in that section of the <CPU>.h works. Once all CPU multilib
variations can be built, then RTEMS proper can be multilib'ed and
separated from the BSPs.
which splits the current monolithic specs files into a sequence of
subparts. These can be concatenated togather to make a the whole .spec
file. This cleans up the maintenance problem of having "all languages"
and a "C/C++ only" gccnewlib spec files. Plus it should make it easier
to produce variants like the gdb-m68k-bdm which require special hackery. :)
Ralf's comments:
It addresses the way *.spec.in get composed inside of the source
tree.
Changes:
* Each spec.in is broken into several files (*.add), one *.add file
per sub-package.
* Each Makefile.am composes spec.ins from the *.add files
* Removal of redundant automake support files.
* Default value for BuildRoot changed to /tmp/<spec-file-name>
* %clean stage added to *specs
Advantages (IMHO).
* The *.add files are easier to adminstrate and more flexible in
comparison to the former *.specs.ins.
* gccnewlib_c_only.spec.in now is composed from the same sources as
gccnewlib.spec.in (less errors)
* If using the default BuildRoot --clean now deletes all files that
were generated while building.
Notes:
* rtems.spec.in has not yet been adapted to the scheme used for the
other *spec.ins
* Except for cosmetical changes the internals of the *.spec files
should not have changed.
To Apply:
cvs rm -f scripts/binutils/binutils.spec.in
cvs rm -f scripts/gccnewlib/gccnewlib.spec.in
cvs rm -f scripts/gccnewlib/gccnewlib_c_only.spec.in
cvs rm -f scripts/gdb/gdb.spec.in
cvs rm -f scripts/config.sub
cvs rm -f scripts/config.guess
cvs rm -f scripts/install-sh
cvs rm -f scripts/mkinstalldirs
cvs rm -f scripts/missing
patch -p1 < rtems-rc-4.5.0-21.diff
cvs add scripts/*/*.add
cvs add scripts/*/README
What I implemented in this new driver version is, that the driver will
first probe for a DEC21140 card and use it if found. If not found it
will probe for a DEC21143 card and use that if found. This removes the
need for defining/undefining a macro (as was required with my previous
version). I tested the driver with my 21143 card using netdemo and it
apears to work just fine.
Here are some cases that I did not test, mainly because I do not have
the required testing hardware:
- I did not enhance or test PPC support
- I did not test DEC21140 support
- I did not use other test software than netdemo
- CONFIGURE_RTEMS_INIT_TASKS_TABLE was 10 now 0
- CONFIGURE_POSIX_INIT_THREAD_TABLE was 10 now 0
- CONFIGURE_ITRON_INIT_TASK_TABLE was 10 now 0
- CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS was 20 now 3
- added CONFIGURE_NUMBER_OF_TERMIOS_PORTS and defaulted to 1
- added CONFIGURE_TERMIOS_DISABLED defaulted to "enabled"
- miniIMFS is now the default
Added configuration error checks that:
+ Ensure > 0 tasks/threads are configured
+ Ensure at least one inititalization task/thread is defined
bsp.h now defines these so BSP specific requirements
are accounted for.
+ CONFIGURE_NUMBER_OF_TERMIOS_PORTS
+ CONFIGURE_INTERRUPT_STACK_MEMORY
console_reserve_resources and rtems_termios_reserve_resources
are no longer required and considered obsolete. Calls to
rtems_termios_reserve_resources have been eliminated although
the routine is still there and the body "if 0'ed".
We are very close to having NO reason to modify the
configuration tables in the BSP. Be warned that eventually
we would like to see the need for BSP_Configuration
eliminated!
- CONFIGURE_RTEMS_INIT_TASKS_TABLE was 10 now 0
- CONFIGURE_POSIX_INIT_THREAD_TABDE was 10 now 0
- CONFIGURE_ITRON_INIT_TASK_TABLE was 10 now 0
- CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS was 20 now 3
- added CONFIGURE_NUMBER_OF_TERMIOS_PORTS and defaulted to 1
- added CONFIGURE_TERMIOS_DISABLED defaulted to "enabled"
- miniIMFS is now the default
Added configuration error checks that:
+ Ensure > 0 tasks/threads are configured
+ Ensure at least one inititalization task/thread is defined
bsp.h now defines these so BSP specific requirements
are accounted for.
+ CONFIGURE_NUMBER_OF_TERMIOS_PORTS
+ CONFIGURE_INTERRUPT_STACK_MEMORY
console_reserve_resources and rtems_termios_reserve_resources
are no longer required and considered obsolete. Calls to
rtems_termios_reserve_resources have been eliminated although
the routine is still there and the body "if 0'ed".
We are very close to having NO reason to modify the
configuration tables in the BSP. Be warned that eventually
we would like to see the need for BSP_Configuration
eliminated!
Cherrypick from master 2000-05-24 16:51:23 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'New file.':
c/src/tests/libtests/malloctest/malloctest.scn
scripts/config.guess
scripts/config.sub
Comments follow:
This support is (for now) only available for the __i386 target, because
that's the only testing platform I have. It should to my best knowledge
work in the same way for the "__PPC" target, but someone should test
this first before it's put into the code. Thanks go to Andrew Klossner
who provided the vital information about the Intel 21143 chip.
(FWIW: my network card is a Kingston KNE100TX with 21143PD chip)
- CONFIGURE_RTEMS_INIT_TASKS_TABLE was 10 now 0
- CONFIGURE_POSIX_INIT_THREAD_TABLE was 10 now 0
- CONFIGURE_ITRON_INIT_TASK_TABLE was 10 now 0
- CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS was 20 now 3
- added CONFIGURE_NUMBER_OF_TERMIOS_PORTS and defaulted to 1
- added CONFIGURE_TERMIOS_DISABLED defaulted to "enabled"
- miniIMFS is now the default
Added configuration error checks that:
+ Ensure > 0 tasks/threads are configured
+ Ensure at least one inititalization task/thread is defined
bsp.h now defines so BSP specific requirements are accounted for:
+ CONFIGURE_NUMBER_OF_TERMIOS_PORTS
+ CONFIGURE_INTERRUPT_STACK_MEMORY
console_reserve_resources and rtems_termios_reserve_resources
are no longer required and considered obsolete. Calls to
rtems_termios_reserve_resources have been eliminated although
the routine is still there and the body "if 0'ed".
We are very close to having NO reason to modify the
configuration tables in the BSP. Be warned that eventually
we would like to see the need for BSP_Configuration
eliminated!
needed to determine that on x86-linux, RPM builds "i386" RPMs
while on Sparc/Solaris, it builds "sparc" RPMs. Since the
buildall script installs the binutils RPM to build the gccnewlib
RPM, it needs to know this.
eliminate code which assumes that 4 * sizeof(unsigned32) == 16)
and that a 16 byte message can be assumed to be 4 unsigned32's.
These assumptions are invalid on target processors that are
not byte-addressable.
Alexey S. Fadeyev <alexey@vocord.com>. Discussion follows:
"Alexey S. Fadeyev" wrote:
> So if I run this application it tell me :
> > connect_task: Connection established
> > accept somthing
>
> But if I try to connect to invalid port (3001 for example) it also tell me
> that connection
> established but bind_task did't accept it. So how I can find out in
> connect_task does my connection realy
> exist ? What type of socket is here? Blocking or non-blocking? I try used
> select but it did't help - it
> always tell me from connect_task that connection is valid.
>
Yep -- there was a problem alright. The connect() routine wasn't
returning an error indication when it should have. Note that this
problem was not limited to the loopback driver -- a refused connection
from any server would return `success'.
includes RTEMS wrappers invoked by gcc. The beauty of this
is that it puts the implementation in our hands. :)
It uses a mutex ( semaphore ), and task variables simulating
the "keys" for each task.
Thanks to Rosimildo da Silva <rdasilva@connectel.com> for
submitting this.
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.
The patch contains two mid-severity bug fixes:
- bootstrap: fix autoheader invocation
- make/host.cfg.in: comment out RM, required by c/src/make/host.cfg.in,
which is generated from make/host.cfg.in
feedback from Eric Norum <eric@skatter.usask.ca> on static and
dynamic RAM sizing issues while still having as much shared
code as possible across the m68k BSPs.
Cherrypick from master 2000-04-05 13:27:52 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'New file. Copied from i386ex BSP as missing from submission.':
c/src/lib/libbsp/m68k/mvme167/network/Makefile.am
c/src/lib/libbsp/m68k/mvme167/network/netexterns.h
c/src/lib/libbsp/m68k/mvme167/network/network.c
c/src/lib/libbsp/m68k/mvme167/network/uti596.h
make/custom/Cygwin-posix.cfg
Ralf's description of the patch follows:
Now that make VARIANT=xxx has prooven not to be simple enough, I made up
my mind to change again the internals of the mechanism being used to
handle variants:
With the patch below, I introduce the indirection step I had mentioned
in one of my recent mails to translate settings of VARIANT.
The trick is to use the contents of VARIANT as keyword to lookup another
internal keyword (VARIANT_V), which then is used as keyword to lookup
values for setting ARCH, LIB_VARIANT, LIBSUFFIX_VA and AM_CFLAGS from
ARCH_$(VARIANT_V)_V etc. (cf automake/local.am).
This means, at first to translate
VARIANT=[optimize|OPTIMIZE] into VARIANT_V=OPTIMIZE
VARIANT=[debug|DEBUG] into VARIANT_V=DEBUG
VARIANT=[profile|PROFILE] into VARIANT_V=PROFILE
VARIANT=<anything> into VARIANT_V=<anything>
=> perform keyword conversion to uppercase and reduction from 6 to 3+1
internal keywords.
$(VARIANT_V) then is used to lookup make variables from other tables
(eg. CFLAGS_*_V). Eg. ARCH is set up this way:
ARCH_OPTIMIZE_V = o-optimize
ARCH_DEBUG_V = o-debug
ARCH_PROFILE_V = o-profile
ARCH__V = $(ARCH_OPTIMIZE_V)
ARCH = $(ARCH_$(VARIANT_V)_V)
Note the ARCH__V variable. When VARIANT=<anything> is passed to make,
VARIANT_V=<anything> will be set, resulting into ARCH =
$(ARCH_$(<anything>)_V) = $(ARCH__V) = $(ARCH_OPTIMIZE_V), ie. falling
back to OPTIMIZE.
=> o- or o-<anything> should never popup anymore.
The patch contains:
* make uninstall will only work if called from below
<target_alias>/c/<BSP> of if all BSPs in RTEMS_BSP_LIST have been built
previously (c/Makefile will choke otherwise). Not perfect but better
than nothing.
The patch contains:
* Many small cleanups wrt. make VARIANT=[DEBUG|PROFILE] support
* several modifications to make/custom/*.cfg
* Merger with the mvme2307.cfg you had posted two weeks ago (Please
check it, I did not check it against to version you posted today).
* Added a check to the toplevel configure.in to refuse building inside
of the source tree.
The patch contains:
* build variants support
* Reworked make-exe custom/*.cfg for all targets (Should be
self-explanatory, may still be incomplete)
* Several fixes to custom/*.cfgs related to setting debug flags
* Fixes to some bsp_specs for BSPs which apparently have never been
build with debugging before ;)
* pc386.cfg fix attempts (cf. my mail from earlier today)
* Updated ampolish (No need to run it, the patch contains the result
from having applied it)
Known bugs/deficiencies related to this work:
* "make [clean|distclean]" support is still incomplete (e.g. "make
clean" does not delete all Depends-o-*)
* Completely untested for linux/posix and hppa.
* Build failures of i960 BSPs (make VARIANT=DEBUG) - I guess, they are
not related to this patch.
* Successfully tested for all sh, sparc, i386, ppc, m68k BSPs (make
VARIANT=DEBUG)
* make VARIANT=PROFILE not supported by all BSPs (I don't care :)
* make VARIANT=DEBUG failures below tests/ for some BSPs (e.g. gensh1),
because of the tests's binaries being too large to fit into the target
memory layout.
sure the mvme2307 BSP uses new exception processing. Jay included
modifications to the make-exe rule to build bootable binary images
but I (being Joel) am unsure if the way they jump around the tree is
OK for both automake/autoconf and post-install usage.
a floating point support problem discovered with the mvme2307 BSP.
A floating point not available exception would occur when trying
to switch to a new thread with the floating point attribute.
Floating point instructions were disabled, but floating point
loads and stores were needed to save and/or restore the context.
not large enough to support high baud rates.
brg_spd[] is an array which stores the baud rates, for which one of the 4
available BRG dividers has been set. The array is used for deciding if a
BRG devider may be reused.
> 1. What baud_rate and divisor is causing this to fail?
divisor is dependent on the system clock (Cpu_table.clock_speed), and gets
calculated in m860_get_brg_cd.
m860_get_brg_clk fails for any baudrates > (2^16-1), as those baudrates are
truncated to 16 bit which is the size of a short. In fact, as it has been a
short and not an unsigned short, it will fail at any baudrate >(2^15-1). In
any case, it failed for my application, which required 250000 Baud.
that addresses the following:
* Duplicate variables in Makefiles (many Makefile.ams below c/src/test
are affected systematically)
* Erroniously using local.am instead of host.am in host-Makefile.am
(Only host Makefile.ams should be affected; Erroniously using local.am
in host-Makefiles doesn't desturb much)
* use '.' instead of '$pwd' in ./bootstrap (using $pwd does not work if
$pwd is a symlink on linux).
* Broken CVS Ids somewhere
* Removing redundant/obsolete make variables from *.cfg files.
Except of the last item from the list above, most parts of this patch
are fairly harmless, sometimes even cosmetical.
As mentioned before, this patch also contains a new ampolish script.
This script features:
* Pretty printing of Makefile.ams (eg. removal of trailing spaces,
removal of duplicate empty lines, pretty printing make variables, etc.).
* Some syntactical checks on the contents of Makefiles.am
* Proper handling of Automake conditionals
FYI:
* Applying tools/update/rtems-polish.sh -am completely reformats all
Makefile.am resulting into a very large (~500k) diff.
* Applying tools/update/rtems-polish.sh -am twice, finally does not
reformat the Makefile.ams anymore.
* Many parts of the patch above result from merging back issues which
have shown when applying this new ampolish (i.e. partially result from
extracting the essentials of reformating being proposed by applying it
on Makefile.ams).
Though this ampolish is a very nice tool, IMHO, I am hestitant if you
should apply (i.e. run tools/update/rtems-polish.sh -am) it to the
sources before the release, because
* the resulting diff is fairly large
* I am not 100% sure it doesn't break anything.
However, applying it after the release would result into compatibility
problems in applying patches ;)
I would suggest that you might consider trying it locally, then to
examine the diff and then to decide whether to apply it in general or
not.
Joel's Comments:
As Ralf points out, this patch is problematic in that applying it before
a release could break things but applying it afterwards will result in
patches being unusable for Makefiles. My inclination is to forge ahead
and apply it.
It seems to me I have found a bug in m860_smc_initialize(). This
function lives in
c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c.
The following lines are supposed to set the simode register with the
baud rate generator index, which has been returned from m860_get_brg_clk().
(line 386 of console-generic.c)
/*
* Put SMC in NMSI mode, connect SMC to BRG
*/
m860.simode &= ~0x7000 << ((port-1) * 8);
m860.simode |= brg << (12 + ((port-1) * 8));
This works well for port == 1 (SMC1), however for SMC2 (port == 2) it
fails. First, the simode register consists of 2 16bit parts (one for
SMC1 and SMC2 respectively), hence the shift count is wrong. Second ~0x7000
(which is 0xffff8fff is shifted left and pulls 0 from the right, which
kills the SMC1 entries, when written back to the simode register.
Substitute those lines by:
m860.simode &= ~(0x7000 << ((port-1) * 16));
m860.simode |= brg << (12 + ((port-1) * 16));
I have checked snapshot 20000218a which still contains the bug.
Also affected is libcpu/powerpc/mpc821/console_generic.c, which is a
cut&paste&substitue decendant of the mpc860 console-generic.c.
CVS: ----------------------------------------------------------------------
CVS: Enter Log. Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: Tag: rtems-4-5-branch
CVS: console-generic.c
CVS: ----------------------------------------------------------------------
It seems to me I have found a bug in m860_smc_initialize(). This
function lives in
c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c.
The following lines are supposed to set the simode register with the
baud rate generator index, which has been returned from m860_get_brg_clk().
(line 386 of console-generic.c)
/*
* Put SMC in NMSI mode, connect SMC to BRG
*/
m860.simode &= ~0x7000 << ((port-1) * 8);
m860.simode |= brg << (12 + ((port-1) * 8));
This works well for port == 1 (SMC1), however for SMC2 (port == 2) it
fails. First, the simode register consists of 2 16bit parts (one for
SMC1 and SMC2 respectively), hence the shift count is wrong. Second ~0x7000
(which is 0xffff8fff is shifted left and pulls 0 from the right, which
kills the SMC1 entries, when written back to the simode register.
Substitute those lines by:
m860.simode &= ~(0x7000 << ((port-1) * 16));
m860.simode |= brg << (12 + ((port-1) * 16));
I have checked snapshot 20000218a which still contains the bug.
Also affected is libcpu/powerpc/mpc821/console_generic.c, which is a
cut&paste&substitue decendant of the mpc860 console-generic.c.
that fixes numerous miscellaneous issues most related to the debug and
profile build stanzas:
Fix for the "make debug" (1) issue and an analogous issue with "make
profile" (untested).
* Fixes to mcp750.cfg (make debug, directories) (2)
* Updates/minor fixes for shgen (3)
* Updates some custom/*.cfgs to use $(LINK.c) instead of $(CC)
* Leftovers from rtems-rc-4.5.0-[0|1].diff which somehow did not make it
into cvs.
* Cleanups to the perlscripts below tools/update/
* Some unsorted minor fixes.
Footnotes/Remarks:
(1) Tested for all m68k, sh, sparc, unix and selected i386, ppc BSPs.
Known problems: I can't build the debug variant for the m68k/mvme162 and
m68k/mvme162lx (segmentation fault - signal 11 :)
(2) Tested by building the BSP, but I doubt the debug-variant is
functional. The flags used for the debug variant should be checked by
knowledgeable persons and probably at runtime #:o)
(3) I have updated shgen to use getopt_long (it should fall back to
getopt if not available), enhanced the options, cleaned up some minor
tweaks and added help2man support (rough automatic man-page generation).
Technical notes:
* make debug and make profile now work similar in target Makefile.ams as
they did in old autoconf-Makefile.ins using leaf.cfg. Unlike the rules
in leaf.cfg these Makefile.am also recurse once on themselves in
directory Makefiles before or after recursing into subdirectories, not
only in leaf-directories.
To implement this behavior, I renamed the former automake/local.am into
automake/host.am and extended local.am to provide this recursion.
I.e. host.am implements the non-self-recursive variant, while local.am
now implements the self-recursive behavior.
=> all Makefile.ams exploiting build-variants are supposed to include
local.am
=> all Makefile.ams not exploiting build-variants should include host.am
=> Rules of thumb:
- Only include one of both, either local.am or host.am into a
Makefile.am.
-Target-Makefile.ams should include local.am
-Host-Makefile.ams should include host.am (Probably, you now understand
the naming)
- There are exceptions from these rules :)
* Now, make debug|profile|all are independent of each other. However,
each of them however triggers preinstall.
* "make install" still decends into the subdirectories but does not
trigger "all|profile|debug|preinstall" in target Makefile.am anymore.
Besides triggering "install"-rules in some selected Makefile.ams, it
only packs $(PROJECT_ROOT) into a tarballs and unpacks it to $(prefix).
=> "make install" alone is not enough to install RTEMS, now use
make RTEMS_BSP=<bsps> [all] [debug] [profile]
make RTEMS_BSP=<bsp> install
I consider this to be a step back wrt. exploiting automake mechanisms,
and expect this to be reverted if we abandon building target variants in
favour of the standard convention of optionally overriding flags from
the command line (i.e. instead of "make debug", GNU standards favor
"make CFLAGS=<options> --prefix=<location>")
that fixes numerous miscellaneous issues most related to the debug and
profile build stanzas:
Fix for the "make debug" (1) issue and an analogous issue with "make
profile" (untested).
* Fixes to mcp750.cfg (make debug, directories) (2)
* Updates/minor fixes for shgen (3)
* Updates some custom/*.cfgs to use $(LINK.c) instead of $(CC)
* Leftovers from rtems-rc-4.5.0-[0|1].diff which somehow did not make it
into cvs.
* Cleanups to the perlscripts below tools/update/
* Some unsorted minor fixes.
Footnotes/Remarks:
(1) Tested for all m68k, sh, sparc, unix and selected i386, ppc BSPs.
Known problems: I can't build the debug variant for the m68k/mvme162 and
m68k/mvme162lx (segmentation fault - signal 11 :)
(2) Tested by building the BSP, but I doubt the debug-variant is
functional. The flags used for the debug variant should be checked by
knowledgeable persons and probably at runtime #:o)
(3) I have updated shgen to use getopt_long (it should fall back to
getopt if not available), enhanced the options, cleaned up some minor
tweaks and added help2man support (rough automatic man-page generation).
Technical notes:
* make debug and make profile now work similar in target Makefile.ams as
they did in old autoconf-Makefile.ins using leaf.cfg. Unlike the rules
in leaf.cfg these Makefile.am also recurse once on themselves in
directory Makefiles before or after recursing into subdirectories, not
only in leaf-directories.
To implement this behavior, I renamed the former automake/local.am into
automake/host.am and extended local.am to provide this recursion.
I.e. host.am implements the non-self-recursive variant, while local.am
now implements the self-recursive behavior.
=> all Makefile.ams exploiting build-variants are supposed to include
local.am
=> all Makefile.ams not exploiting build-variants should include host.am
=> Rules of thumb:
- Only include one of both, either local.am or host.am into a
Makefile.am.
-Target-Makefile.ams should include local.am
-Host-Makefile.ams should include host.am (Probably, you now understand
the naming)
- There are exceptions from these rules :)
* Now, make debug|profile|all are independent of each other. However,
each of them however triggers preinstall.
* "make install" still decends into the subdirectories but does not
trigger "all|profile|debug|preinstall" in target Makefile.am anymore.
Besides triggering "install"-rules in some selected Makefile.ams, it
only packs $(PROJECT_ROOT) into a tarballs and unpacks it to $(prefix).
=> "make install" alone is not enough to install RTEMS, now use
make RTEMS_BSP=<bsps> [all] [debug] [profile]
make RTEMS_BSP=<bsp> install
I consider this to be a step back wrt. exploiting automake mechanisms,
and expect this to be reverted if we abandon building target variants in
favour of the standard convention of optionally overriding flags from
the command line (i.e. instead of "make debug", GNU standards favor
"make CFLAGS=<options> --prefix=<location>")
that fixes numerous miscellaneous issues most related to the debug and
profile build stanzas:
Fix for the "make debug" (1) issue and an analogous issue with "make
profile" (untested).
* Fixes to mcp750.cfg (make debug, directories) (2)
* Updates/minor fixes for shgen (3)
* Updates some custom/*.cfgs to use $(LINK.c) instead of $(CC)
* Leftovers from rtems-rc-4.5.0-[0|1].diff which somehow did not make it
into cvs.
* Cleanups to the perlscripts below tools/update/
* Some unsorted minor fixes.
Footnotes/Remarks:
(1) Tested for all m68k, sh, sparc, unix and selected i386, ppc BSPs.
Known problems: I can't build the debug variant for the m68k/mvme162 and
m68k/mvme162lx (segmentation fault - signal 11 :)
(2) Tested by building the BSP, but I doubt the debug-variant is
functional. The flags used for the debug variant should be checked by
knowledgeable persons and probably at runtime #:o)
(3) I have updated shgen to use getopt_long (it should fall back to
getopt if not available), enhanced the options, cleaned up some minor
tweaks and added help2man support (rough automatic man-page generation).
Technical notes:
* make debug and make profile now work similar in target Makefile.ams as
they did in old autoconf-Makefile.ins using leaf.cfg. Unlike the rules
in leaf.cfg these Makefile.am also recurse once on themselves in
directory Makefiles before or after recursing into subdirectories, not
only in leaf-directories.
To implement this behavior, I renamed the former automake/local.am into
automake/host.am and extended local.am to provide this recursion.
I.e. host.am implements the non-self-recursive variant, while local.am
now implements the self-recursive behavior.
=> all Makefile.ams exploiting build-variants are supposed to include
local.am
=> all Makefile.ams not exploiting build-variants should include host.am
=> Rules of thumb:
- Only include one of both, either local.am or host.am into a
Makefile.am.
-Target-Makefile.ams should include local.am
-Host-Makefile.ams should include host.am (Probably, you now understand
the naming)
- There are exceptions from these rules :)
* Now, make debug|profile|all are independent of each other. However,
each of them however triggers preinstall.
* "make install" still decends into the subdirectories but does not
trigger "all|profile|debug|preinstall" in target Makefile.am anymore.
Besides triggering "install"-rules in some selected Makefile.ams, it
only packs $(PROJECT_ROOT) into a tarballs and unpacks it to $(prefix).
=> "make install" alone is not enough to install RTEMS, now use
make RTEMS_BSP=<bsps> [all] [debug] [profile]
make RTEMS_BSP=<bsp> install
I consider this to be a step back wrt. exploiting automake mechanisms,
and expect this to be reverted if we abandon building target variants in
favour of the standard convention of optionally overriding flags from
the command line (i.e. instead of "make debug", GNU standards favor
"make CFLAGS=<options> --prefix=<location>")
that fixes numerous miscellaneous issues most related to the debug and
profile build stanzas:
Fix for the "make debug" (1) issue and an analogous issue with "make
profile" (untested).
* Fixes to mcp750.cfg (make debug, directories) (2)
* Updates/minor fixes for shgen (3)
* Updates some custom/*.cfgs to use $(LINK.c) instead of $(CC)
* Leftovers from rtems-rc-4.5.0-[0|1].diff which somehow did not make it
into cvs.
* Cleanups to the perlscripts below tools/update/
* Some unsorted minor fixes.
Footnotes/Remarks:
(1) Tested for all m68k, sh, sparc, unix and selected i386, ppc BSPs.
Known problems: I can't build the debug variant for the m68k/mvme162 and
m68k/mvme162lx (segmentation fault - signal 11 :)
(2) Tested by building the BSP, but I doubt the debug-variant is
functional. The flags used for the debug variant should be checked by
knowledgeable persons and probably at runtime #:o)
(3) I have updated shgen to use getopt_long (it should fall back to
getopt if not available), enhanced the options, cleaned up some minor
tweaks and added help2man support (rough automatic man-page generation).
Technical notes:
* make debug and make profile now work similar in target Makefile.ams as
they did in old autoconf-Makefile.ins using leaf.cfg. Unlike the rules
in leaf.cfg these Makefile.am also recurse once on themselves in
directory Makefiles before or after recursing into subdirectories, not
only in leaf-directories.
To implement this behavior, I renamed the former automake/local.am into
automake/host.am and extended local.am to provide this recursion.
I.e. host.am implements the non-self-recursive variant, while local.am
now implements the self-recursive behavior.
=> all Makefile.ams exploiting build-variants are supposed to include
local.am
=> all Makefile.ams not exploiting build-variants should include host.am
=> Rules of thumb:
- Only include one of both, either local.am or host.am into a
Makefile.am.
-Target-Makefile.ams should include local.am
-Host-Makefile.ams should include host.am (Probably, you now understand
the naming)
- There are exceptions from these rules :)
* Now, make debug|profile|all are independent of each other. However,
each of them however triggers preinstall.
* "make install" still decends into the subdirectories but does not
trigger "all|profile|debug|preinstall" in target Makefile.am anymore.
Besides triggering "install"-rules in some selected Makefile.ams, it
only packs $(PROJECT_ROOT) into a tarballs and unpacks it to $(prefix).
=> "make install" alone is not enough to install RTEMS, now use
make RTEMS_BSP=<bsps> [all] [debug] [profile]
make RTEMS_BSP=<bsp> install
I consider this to be a step back wrt. exploiting automake mechanisms,
and expect this to be reverted if we abandon building target variants in
favour of the standard convention of optionally overriding flags from
the command line (i.e. instead of "make debug", GNU standards favor
"make CFLAGS=<options> --prefix=<location>")
POSIX threads passed the incorrect pointer to a default name on
the stack. POSIX threads did not need a name and neither did
ITRON tasks so this code was eliminated from both APIs.
1) Coalesce outgoing packet into a single mbuf when the packet is spread
over more mbufs than configured transmit buffer descriptors.
2) Add dianostic counters for successful and failed coalesce attempts.
3) Add diagnostic counter for transmit retries.
NOTE: (1) lead to deadlock and the same design based on underlying
hardware characteristics is currently also in the Sonic and
i386ex/network driver.
Bob Wisdon <bobwis@ascweb.co.uk> and Chris Johns <ccj@acm.org>
to resolve a random network lockup problem.
ckinit.c:
Occasional network lockups have been noted when the PIT has a higher
interrupt request level than the CPM. The SCC1 bit in the CISR is set
even though the SCC1 interrupt handler is not active. This blocks
interrupts from SCC1 (and all other CPM sources) and locks up the
system. It has not been determined whether the error is within the
68360 or in the RTEMS interrupt support assembler code. The solution,
for now, is to set both PIT and CPM interrupt request levels to the same
value (4).
network.c:
Set CPM transmitter buffer pointer (_tbptr) to beginning of frame
before restarting transmitter. Don't retire transmitter buffer
descriptors belonging to the restarted frame.
that contains:
* Removes remaining (now illegal) references to $(SRC) from a couple of
Makefile.ams
* Removes duplicate AC_CONFIG_SUBDIRS macro from c/configure.in
* Moves ENABLE_LIBCDIR into RTEMS_PROG_C[C|XX]_FOR_TARGET (hides LIBCDIR
from most configure scripts, i.e. LIBCDIR becomes less visible)
* Adds RTEMS_PROG_C[C|XX]_FOR_TARGET and RTEMS_CANONICALIZE_TOOLS to
libbsp/*/configure.ins (A minor bug in previous implementations, which
only has an impact when switching to GNU/Cygnus canonicalization)
* Cleans up several bogus comments.
* Removes MKLIB
* Switches the version number to 4.5.0 (for testing version number
handling)
that contains the automake files for libnetworking plus a couple of
minor fixes. [Now only one unused/unsupported Makefile.in remains
(./c/src/lib/libbsp/hppa1.1/pxfl/Makefile.in).]
To apply:
patch -p1 < rtems-rc-20000118-7.diff
/bin/sh rtems-rc-20000118-7.rm
/bin/sh rtems-rc-20000118-7.add
./bootstrap
Notes:
* I have tested this one by building all BSPs for m68k, powerpc, sh and
unix with toolchains built since last weekend.
* I did not touch libnetworking's directory layout.
that contains:
The workarounds related to the issues with
ppc/helas403 (triggers a nasty bug in automake-2.14) and mcp750.cfg
(Which is basically broken)
To apply:
patch -p1 < rtems-rc-20000118-6.diff
./bootstrap
Note:
* Though this patch is small, ./bootstrap is absolutely necessary.
* Now your CVS source tree is identical to my local CVS.
that contains:
* The fix for the gen68360/network/Makefile.am
* automatically set permissions to 755 to scripts/buildall and
scripts-ada/buildall (I remembered a trick to achieve this :).
* automake support for libbsp/* and libcpu/* (Attn: This part will
finally break old-style configuration for all non-public cpus)
NOTES:
* This patch has only been tested for a random selection of BSPs (I
haven't rebuilt all toolchains yet).
* This patch is against rtem-cvs as of this morning (MET).
To apply:
patch -p1 <rtems-rc-20000118-5.diff
cvs rm -f ./c/src/lib/libbsp/Makefile.in
cvs rm -f ./c/src/lib/libbsp/shmdr/Makefile.in
cvs rm -f ./c/src/lib/libcpu/Makefile.in
cvs add ./c/src/lib/libbsp/Makefile.am
cvs add ./c/src/lib/libbsp/shmdr/Makefile.am
cvs add ./c/src/lib/libcpu/Makefile.am
./bootstrap
Ralf Corsepius <corsepiu@faw.uni-ulm.de> that contain:
* Modifications, (minor) corrections, cleanups to most existing
Makefile.ams
* Adds automake support to all remaining BSPs which have not yet been
converted to automake.
* Makefile.am for all remaining wrapup/Makefile.ams
that contains:
* cleanups to configuration files
* A reworked gccnewlib.spec.in: I have reformated it for enhanced
readability and added more rtems-base packages. It now should be free of
any installation conflicts (If there still remain some, they should be
regarded as bugs).
* A fix to the bin2boot RTEMS_BSP issue (make RTEMS_BSP="pc386 pc486"
now works).
* removes libbsp/bare/wrapup
* Further cleanups
that converts the a29k to automake.
This patch contains
* An initial merger of the libcpu/a29k stuff you sent yesterday. AFAIS,
most code inside them seems to be empty stubs. One file even contains a
function called mips_*** which might indicate that this part might
contain mips code or the code the initial porter used as template for
porting. Unfortunately, I don't know anything about the a29k so I can't
comment on the details.
* A dummy bsp_specs to libbsp/29k/portsw
* An update to the automake files related to the a29k.
Note:
* This patch is completely untested, because I don't have a toolchain
for it.
* The files in libcpu/a29k include bsp.h => The libbsp vs. libcpu-issue
hits again.
that converts the a29k to automake.
This patch contains
* An initial merger of the libcpu/a29k stuff you sent yesterday. AFAIS,
most code inside them seems to be empty stubs. One file even contains a
function called mips_*** which might indicate that this part might
contain mips code or the code the initial porter used as template for
porting. Unfortunately, I don't know anything about the a29k so I can't
comment on the details.
* A dummy bsp_specs to libbsp/29k/portsw
* An update to the automake files related to the a29k.
Note:
* This patch is completely untested, because I don't have a toolchain
for it.
* The files in libcpu/a29k include bsp.h => The libbsp vs. libcpu-issue
hits again.
by all targets and one or more target specific RPMs. This significantly
reduces the conflicts between the RPMs whether installing one or multiple
targets.
Cygwin support to the RPM scripts. The patch from David did not
apply cleanly and Joel ended up making all the modifications
plus some it should have included for consistency by hand. His comments:
I've included a diff against the last (19991203) snapshot RPM scripts that
adds what I think is required for Cygwin support. Basically all this boils
down to is adding EXE extension support. I've added the AC_EXEEXT rule to
conifgure.in (requires a valid 'cc' to work - this is not available in the
standard Cygwin distro). Each of the *.spec.in have @exe_ext@ includes in
them for each program that results in an EXE. The only odity here is that
the chill driver program is a shell script and thus does not require .exe to
be added... The mk*.in have all been updated to process the new exe_ext
rule.
Janovetz <janovetz@tempest.ece.uiuc.edu> to return a status from
network initialization rather than panic'ing. It changes a bunch
of rtems_panics to printfs and returns a status from
rtems_bsdnet_initialize_network().
I'd like to propose a change to RTEMS task variables that I think would
make them more useful. I think that it is early enough in their
existence to still make changes to their API.
1) Change type from `int' to `void *'.
2) Add extra argument to task_variable_add -- if non-NULL, a pointer to
a `destructor' function to be called when the task exits. This function
would be called with that task's value of the task variable as its
argument. In many cases, the `dtor' function could be `free'.
rtems_status_code rtems_task_variable_add (
rtems_id tid, void **ptr, void (*dtor)(void *));
rtems_status_code rtems_task_variable_delete (rtems_id tid, void **ptr);
This would be all we'd need to cleanly and efficiently support C++
per-thread exception information without dragging in all that POSIX API
stuff.
Some excellent sleuthing by Bob Wisdom <bobwis@ascweb.co.uk> revealed
that an empty mbuf at the end of a packet chain would cause the `retire'
function to blow up. Moving the line of code which bumps the transmit
buffer descriptor pointer fixes the problem. Some additional cleanup of
the sendpacket function was also completed.
that addresses the librdbg/rpcgen related problems:
Changes:
* All rpcgen generated files are now kept inside of the source tree
* Fix librdbg/configure to correctly detect presence of rpcgen and awk
* Use rpcgen -m to generated remdeb_svc.c
* Remove msgout/_msgout from awk.svc
* minor cleanups to librdbg/configure.in
ATTENTION --- IMPORTANT:
* With keeping rpc-generated files pre-build inside of the source tree,
you as the packager of RTEMS have to ensure that timestamps are
correctly set up: The generated files must not be older than the *.x
files.
* This is extraordinarily important when
- putting the package on read-only media
- after checking out from CVS
- after modifications to the *.x files
* If one of the *.x files is modified you have to either
- build for i386/pc386 and powerpc/mcp750
- or to invoke the same rpcgen calls as the
librdbg/src/<cpu>/<bsp>/Makefile.am do manually
before checking-in the files to CVS.
Proposal:
We could add something to bootstrap for touching the rpcgen-generated
sources and/or to manually regenerate them.
NOTE FROM JOEL:
Ralf proposed modifying bootstrap to handle rpcgen. I think this
is the best solution as it is something already done in the
snapshot procedure.
blocking sends when the queue is full. The SuperCore was enhanced
to support blocking on send. The existing POSIX API was debugged
and numerous test cases were added to psxmsgq01 by Jennifer Averett.
SuperCore enhancements and resulting modifications to other APIs
were done by Joel.
There is one significant point of interpretation for the POSIX API.
What happens to threads already blocked on a message queue when the
mode of that same message queue is changed from blocking to non-blocking?
We decided to unblock all waiting tasks with an EAGAIN error just
as if a non-blocking version of the same operation had returned
unsatisfied. This case is not discussed in the POSIX standard and
other implementations may have chosen differently.
blocking sends when the queue is full. The SuperCore was enhanced
to support blocking on send. The existing POSIX API was debugged
and numerous test cases were added to psxmsgq01 by Jennifer Averett.
SuperCore enhancements and resulting modifications to other APIs
were done by Joel.
There is one significant point of interpretation for the POSIX API.
What happens to threads already blocked on a message queue when the
mode of that same message queue is changed from blocking to non-blocking?
We decided to unblock all waiting tasks with an EAGAIN error just
as if a non-blocking version of the same operation had returned
unsatisfied. This case is not discussed in the POSIX standard and
other implementations may have chosen differently.
for the gen68360 that let it work with ELF and C++ exceptions. This
was used as the basis for changes to EVERY m68k bsp_specs and linkcmds.
Before this modification is over, the layout of the starting stack,
heap, and workspace will likely be modified for every m68k BSP. Then
they will all be very similar.
that fixes the following problems:
1. Removing bogus ';' in some configure.in (cosmetical fix)
2. Moves GAS_CODE16 checks to libbsp/i386/*/configure.in (essential fix)
#2 was responsible for the gcc/binutils-2.9.5 choking while building for
the pc386.
being set to 0 to indicate that there should be no Clock Tick. This
was used by the Timing Tests to avoid clock tick overhead perturbing
execution times. Now the Timing Tests simply leave the Clock Tick
Driver out of the Device Driver Table.
must deal with a pending process oriented signal. Prior to the addition
of this testcase, sigtimedwait() did not return properly when a process
oriented signal was pending. The problem was reported by Wayne
Bullaughey <wayneb@cacdsp.com>.
which converts the PowerPC BSPs to configuration and more automake.
* Besides adding partial automake support, rsp converting all powerpc
BSPs to make them compliant to the new configuration scheme, this patch
attempts to fix several configuration bugs in powerpc related Makefiles.
Kulpinski <jskulpin@eng01.gdds.com>, the bsp_specs now defines
USE_ENHANCED_INTR_API and powerpc/shared/include/bsp.h uses that
to enable its tm27 support.
which does the following:
* some cleanups, fixes, addtions to the libbsp automake transition
patches
* The missing Automake transistion patches all libcpu/<cpu>/<variant>/*
previously not yet been converted to automake (libcpu/powerpc,
libcpu/hppa1.1, libcpu/mips64orion, libcpu/sparc)
=> With this patch, libcpu/*/* is under full automake control.
NOTES:
* This patch is tested by building for random set of bsps affected by
this patch, but not tested for all BSPs.
* The parts of this patch related to libcpu/powerpc fix many small bugs
inside of those Makefiles.
* Have a look into libcpu/powerpc/mpc6xx/, which is in rather bad shape,
IMO. Obviously most subdirectories seem to be build but are not included
into libcpu.a by wrapup/Makefile. Addtionally, no actual BSP uses this
cpu-variant subdirectory. Furthermore libcpu/powerpc/mpc6xx has a
different directory layout than all other powerpc/<variant>/
directories.
Joel's note: I agree but the issue is that there is a conflict between
including timer or clock in libcpu/XXX/wrapup/Makefile.* and letting
a BSP specifically decide to pick it up. There is no clear solution
to this at the moment.
that converts the i386 directory to automake.
NOTE: Ralf is unable to build any i386 BSPs. This was true before and
after this patch and appears (to Joel) to be a tool issue unrelated since
others can build i386 BSPs.
that converts the m68k directory to automake.
NOTE: This one is fully tested by building *all* bsps with
../../rtems-rc-20000104/configure \
--target=m68k-rtems \
--prefix=/tmp/rtems \
--enable-cxx \
--disable-posix \
--enable-rdbg \
--disable-networking \
--enable-maintainer-mode \
--enable-multiprocessing \
--disable-tests
make
that converts the hppa1.1 directory to automake.
NOTE:
* Due to not having a toolchain (gcc refuses to build) this patch is
untested.
* I omited/deactivated the pxfl subdirectory, because I don't
understand how it supposed to work.
Joel's note: It was right to ignore the pxfl directory. It should be
removed one the BSPs are moved outside the tree. This was an old hack.
that converts the i960 directory to automake.
The same kind of libbsp configuration as for the mips64orion, now for
the i960.
In addition to libbsp configuration this patch also contains two fixes
for cvme961.cfg and rxgen960.cfg, which contained non-functional
make-exes. (Now both bsps probably have the same issues with linking c++
applications as the gensh2 has, but this is a different open issue not
tried to be solved now).
The rxgen961 also seems to have problems with its start file, because
linking apps fails due to not finding start.o. (Note that
libbsp/i960/rxgen960 lacks a start subdirectory!). I leave solving this
issue to you :)
that converts the mips64orion directory to automake.
Ralf's Note: This patch demonstrates another kind of supporting the new
style of configuration, which avoids having to port all Makefile.ins to
automake, but to keep using most old style Makefile.ins.
that converts the mips64orion directory to automake.
Ralf's Note: This patch demonstrates another kind of supporting the new
style of configuration, which avoids having to port all Makefile.ins to
automake, but to keep using most old style Makefile.ins.
that converts the unix directory to automake.
Ralf's note: Please check c/src/lib/libbsp/unix/posix/startup/Makefile.am.
I am not sure if it is correct.
that converts the sparc directory to automake.
Ralf's note: The implementation of libbsp/sparc/* gives a nearly minimal
example of the new configuration scheme.
that converts nearly all of libbsp/sh to automake. Comments follow:
1. Almost full automake support for the libbsp/sh/ subdirectories
(exception libbsp/sh/gensh*/wrapup/*)
2. Fixes for libbsp/bare/*
3. Updates to libbsp/* configuration which supports old (autoconf/deep
configuration) and new (automake/flat/cascaded configuration) style
configuration of libbsp/<cpu>/*
patch from Emmanuel Raguet <raguet@crf.canon.fr>. Emmanuel's patch
was against the Makefile.in's generated from the Makefile.am's
patched in this file.
which is described below:
This one is a (minor) patch in preparation of the upcoming patches. It
actually is an excerpt of the upcoming patches and therefore is
completely untested in this standalone form, but I don't expect it to
break something.
The essential changes in this patch are:
* An update to rtems-polish.sh (Now can also be run in subdirectories)
* A bug-fix for the libcpu/powerpc (A directory was missing from
SUBDIRS in a Makefile.am)
* An update to gensh2.cfg.
* Cleanups/Enhancements to configuration files
To apply:
cd <srcdir>
patch -p0 < rtems-rc-20000104-0.diff
cvs rm -f c/src/lib/libbsp/Makefile.am.new
power binary/mutex style semaphores already supported by RTEMS. This
was done at the request of Eric Norum <eric@cls.usask.ca> in support
of his effort to port EPICS to RTEMS. This change consisted of
changing the nesting_allowed boolean into a lock_nesting_behavior
enumerated value as well as allowing the core mutex object to optionally
support ensuring that the holder of a binary semaphore released it.
Finally, a more subtle enhancement was to allow the non-holder to release
a priority inheritance/ceiling mutex and still allow the holding task
to return to its original priority.
At the request of kjoutwater@west.raytheon.com I'm submitting the
following patch.
c/src/lib/libbsp/m68k/gen68360/console/console.c
Allow console baud rate to be set by debugger/downloader.
c/src/lib/libbsp/m68k/gen68360/startup/init68360.c
Add support for generic 68360 with static RAM.
At the request of kjoutwater@west.raytheon.com I'm submitting the
following patch.
c/src/lib/libbsp/m68k/gen68360/console/console.c
Allow console baud rate to be set by debugger/downloader.
c/src/lib/libbsp/m68k/gen68360/startup/init68360.c
Add support for generic 68360 with static RAM.
In another attempt to get C++ exceptions working on the gen68360 target
I tried building for the m68k-elf target. All the tools built and
installed properly as did all of RTEMS. No applications would run,
though -- not even hello.exe!
It turns out the problem was in the linker script. The alignment was in
the wrong place.
Here's a patch. Exceptions still don't work, but at least I can get
some things working with the ELF format now.
which fixes a couple of bugs in RTEMS's old style Makefile.ins, which
apparently were introduced by moving the start directories and not
having adapted the Makefile.ins.
To apply:
patch -p1 < rtems-rc-19991203-10.diff
which ontains all what was left over from the other patches (Primarily
minor configuration cleanups).
To apply:
patch -p1 < rtems-rc-19991203-9.diff
./bootstrap
which does minor cleanup for Makefile.ams below mptests, which only
removes some bogus comments from the Makefile.ams.
To apply:
patch -p1 < rtems-rc-19991203-8.diff
./bootstrap
which adds partial automake support to libcpu/<cpu>/*.
Until now I have only implemented full automake support for the sh (my
demonstration example :) and the i386 (inevitiable for structural
reasons of this subdirectory). For all other cpus only their toplevel
directories (exception: powerpc), include subdirectories and a few
selected subdirectories have been converted to automake.
I did this on purpose, because add automake support to each subdirectory
requires individual adaptations which to be tested individually.
Additionally the weirdnesses of the powerpc subdirectories hit again,
esp. some powerpc cpu-models
* install files to $(PROJECT_INCLUDE)/<cpu-model>/ while others install
them to $(PROJECT_INCLUDE)/
* the scheme used to configure libcpu/powerpc/ is difficult to implement
using automake, therefore this subdirectory still is configured by
autoconf (The one out of an unlimited set selection scheme hits again
:), though powerpc/*/* subdirectories already apply automake.
The patch also reveils structural weaknesses in RTEMS:
E.g. There seem to exist at least 5 different general schemes:
* Not using libcpu at all (eg. i960)
* Strictly tree-style a libcpu/<cpu-variant>/* (eg. m68k, sh)
* Flat libcpu directory layout with cpu-variants merged into sources or
not destinguishing cpu-variants (i386)
* Not supporting variants with deep source tree (sparc, hppa, mips64orion)
* Woven directory structure with shared directories (powerpc)
I regret having to say this, but from my POV this means, that there
doesn't exist a general implementation scheme for libcpu at all.
To apply:
rm -rf ./c/src/lib/libcpu/i386/wrapup
rm -rf ./c/src/lib/libcpu/mips64orion/include
rm -rf ./c/src/lib/libcpu/powerpc/ppc403/include
patch -p1 < rtems-rc-19991203-7.diff
./bootstrap
which adds partial automake support to libcpu/<cpu>/*.
Until now I have only implemented full automake support for the sh (my
demonstration example :) and the i386 (inevitiable for structural
reasons of this subdirectory). For all other cpus only their toplevel
directories (exception: powerpc), include subdirectories and a few
selected subdirectories have been converted to automake.
I did this on purpose, because add automake support to each subdirectory
requires individual adaptations which to be tested individually.
Additionally the weirdnesses of the powerpc subdirectories hit again,
esp. some powerpc cpu-models
* install files to $(PROJECT_INCLUDE)/<cpu-model>/ while others install
them to $(PROJECT_INCLUDE)/
* the scheme used to configure libcpu/powerpc/ is difficult to implement
using automake, therefore this subdirectory still is configured by
autoconf (The one out of an unlimited set selection scheme hits again
:), though powerpc/*/* subdirectories already apply automake.
The patch also reveils structural weaknesses in RTEMS:
E.g. There seem to exist at least 5 different general schemes:
* Not using libcpu at all (eg. i960)
* Strictly tree-style a libcpu/<cpu-variant>/* (eg. m68k, sh)
* Flat libcpu directory layout with cpu-variants merged into sources or
not destinguishing cpu-variants (i386)
* Not supporting variants with deep source tree (sparc, hppa, mips64orion)
* Woven directory structure with shared directories (powerpc)
I regret having to say this, but from my POV this means, that there
doesn't exist a general implementation scheme for libcpu at all.
To apply:
rm -rf ./c/src/lib/libcpu/i386/wrapup
rm -rf ./c/src/lib/libcpu/mips64orion/include
rm -rf ./c/src/lib/libcpu/powerpc/ppc403/include
patch -p1 < rtems-rc-19991203-7.diff
./bootstrap
which fixes a nasty dependency bug in optman/Makefile.am. Those
directories have been build twice before, i.e. re-running make after
having built rtems before, was rebuilding the files in optman/
directories.
To apply:
patch -p1 < rtems-rc-19991203-6.diff
./bootstrap
I got tired of having strange clock rates (e.g. #define
CONFIGURE_MICROSECONDS_PER_TICK 52489) and drifting times-of-day with
the gen68360 BSP so I changed the way the programmable-interval clock
interrupt works. The new version will have some jitter in the intervals
between individual calls to the rtems_clock_tick routine, but the
long-term average will match the CONFIGURE_MICROSECONDS_PER_TICK
fixes some problems:
I found the problem which prevented opening 'dev/sci1' (the default
console) with the 'gensh2' (sh7045) BSP. Both SCI ports were being
initialized against the same minor device number: '0'. When I tried to
open minor-device '1', it naturally crashed. Fixing that one value in the
'sci_device[]' array solved the problem and allowed 'hello.exe' to run.
report by Nick.SIMON@syntegra.bt.co.uk:
TFTP uses UDP and UDP packets are prime targets for getting dropped when
the network gets busy. I want the number of retries quite large in my
application. I see that PACKET_REPLY_MILLISECONDS is, in fact, not
being used.
functionality. This puts RTEMS in near compliance with the network
functionality defined in the first draft of the EL/IX API. Comments
follow:
With the attached changes to the libnetworking/libc/Makefile.in, RTEMS
provides all the functions listed in section 4.14 of the EL/IX document
except:
socketpair
if_nametoindex
if_indextoname
if_nameindex
if_freenameindex
Some of the routines which get information from files may be of limited
use unless an application sets up the files somehow (TFTP/untar from
host, etc.), but at least RTEMS is pretty much fully buzzword compliant
with the networking section of the EL/IX API.
in the dec21140 driver. Comments follow:
I have tried to use bootp with the dec21140 driver
and I had problems. I have found them
- Ethernet address must be known in Attach step
(read from the board)
- Endian problem for Ethernet address storage.
Now it is solved and I can use bootp to obtain
the network configuration of the target.
to generalize librdbg for all i386 BSPs. His comments:
The patch below generalizes librdbg for all i386 bsps. It is not a
complete rewrite, but a minimal invasive attempt to generalization.
To apply:
mv c/src/librdbg/src/i386/pc386 c/src/librdbg/src/i386/any
patch -p1 < patches-rc-19991203-1.diff
./bootstrap
delay loop in this BSP. Here is his response to a question about
the patch:
Yes, or that other machine has a different chipset with different
timing requirements on enabling Gate 20. I am strongly suspecting
that it may some how related to the video card I am using (on my
old P-75 target it was plain PCI VGA, on my new one it is Diamond Stealth
3D 2000).
dec21140 drivers from the i386/pc386 and powerpc/mcp750 (all Motorola
PowerPC boards) and move the network driver to libchip. This driver
should work on all PCI based uses of this chip.
<corsepiu@faw.uni-ulm.de>:
The patch below provides
* automake support for score/cpu/powerpc
* The hack to propagate values from *.cfg to automake configuration
* A fix for librdbg/powerpc/mcp750/Makefile.am (Was completely corrupted
before)
* Fixes some files which apparently where missing in
rtems-rc-19991123-rc-2.diff
* some minor configuration related patches
To apply:
rm -rf ./c/src/exec/score/cpu/powerpc/wrap
patch -p1 < rtems-rc-19991123-rc-3.diff
Attention:
c/src/exec/score/cpu/[configure.in|aclocal.m4|configure] should be
removed after applying the patch.
Modifications had been made to the score/cpu/powerpc directory after
the snapshot this was based on. In particular, the mpc750 and
other_cpu directories had been renamed to new_exception_processing
and old_exception_processing. After this patch was applied, modifications
were made to account for this.
<corsepiu@faw.uni-ulm.de>:
The patch below provides
* automake support for score/cpu/powerpc
* The hack to propagate values from *.cfg to automake configuration
* A fix for librdbg/powerpc/mcp750/Makefile.am (Was completely corrupted
before)
* Fixes some files which apparently where missing in
rtems-rc-19991123-rc-2.diff
* some minor configuration related patches
To apply:
rm -rf ./c/src/exec/score/cpu/powerpc/wrap
patch -p1 < rtems-rc-19991123-rc-3.diff
Attention:
c/src/exec/score/cpu/[configure.in|aclocal.m4|configure] should be
removed after applying the patch.
Modifications had been made to the score/cpu/powerpc directory after
the snapshot this was based on. In particular, the mpc750 and
other_cpu directories had been renamed to new_exception_processing
and old_exception_processing. After this patch was applied, modifications
were made to account for this.
<corsepiu@faw.uni-ulm.de>:
The patch below provides
* automake support for score/cpu/powerpc
* The hack to propagate values from *.cfg to automake configuration
* A fix for librdbg/powerpc/mcp750/Makefile.am (Was completely corrupted
before)
* Fixes some files which apparently where missing in
rtems-rc-19991123-rc-2.diff
* some minor configuration related patches
To apply:
rm -rf ./c/src/exec/score/cpu/powerpc/wrap
patch -p1 < rtems-rc-19991123-rc-3.diff
Attention:
c/src/exec/score/cpu/[configure.in|aclocal.m4|configure] should be
removed after applying the patch.
system table from when the rtems_filesystem_operations_table structure changed
and the initializer in libnetworking/lib/tftpDriver.c did not get
updated.
<corsepiu@faw.uni-ulm.de> which implements automake support for some
score/cpu/<RTEMS_CPU> subdirectories and fixes a few minor configuration
bugs.
To apply:
rm -rf c/src/exec/score/cpu/a29k/wrap
rm -rf c/src/exec/score/cpu/hppa1.1/wrap
rm -rf c/src/exec/score/cpu/i386/wrap
rm -rf c/src/exec/score/cpu/mips64orion/wrap
rm -rf c/src/exec/score/cpu/no_cpu/wrap
patch -p1 < rtems-rc-19991123-rc-2.diff.gz
Notes:
* I don't see a possiblity to convert the powerpc subdirectory in its
current layout to automake the time being.
* Besides the fact that this subdirectory is not in single-tree building
layout, the actual showstopper is the ifeq $(RTEMS_CPU_MODEL),mpc750)
gmake-conditional in powerpc/Makefile.in, which automake (correctly)
refuses to handle.
* The problem is *not* specific to the powerpc. Other CPUs basically
have similar problems (SH:sh7032 vs sh7045, SPARC: erc32.h in
score/cpu/sparc), but have been lucky to get around real issues (cf.
configuration files below score/cpu/sh/).
* From a configuration focused POV this problem boils down to a
file/subdirectory selection problem:
ppc: 1 or others
sh: 1 out of 2
sparc: 1 out of 1
Automake's means to implement such behavior is using conditionals to be
evaluated at configuration-time. The old configuration scheme however
used make-time conditionals. The SH port was lucky to get around this
issue because it applies a selection from a limited set of possible
selections, the powerpc however applies a selection from an unlimited
set, based on data not being available at configuration time.
* Currently I only see two general solutions:
1) make RTEMS_CPU_MODEL available at configuration time, ie. replace
make-time configuration by configuration-time configuration
2) Perform the selection at build-time, i.e. always install all files,
but use #ifdef #else #endif in source files. This is what the m68k has
exploited at other locations inside of the source-tree.
=> This directory is the last one remaining not using automake below the
whole exec/ hierarchy.
<corsepiu@faw.uni-ulm.de> which implements automake support for some
score/cpu/<RTEMS_CPU> subdirectories and fixes a few minor configuration
bugs.
To apply:
rm -rf c/src/exec/score/cpu/a29k/wrap
rm -rf c/src/exec/score/cpu/hppa1.1/wrap
rm -rf c/src/exec/score/cpu/i386/wrap
rm -rf c/src/exec/score/cpu/mips64orion/wrap
rm -rf c/src/exec/score/cpu/no_cpu/wrap
patch -p1 < rtems-rc-19991123-rc-2.diff.gz
Notes:
* I don't see a possiblity to convert the powerpc subdirectory in its
current layout to automake the time being.
* Besides the fact that this subdirectory is not in single-tree building
layout, the actual showstopper is the ifeq $(RTEMS_CPU_MODEL),mpc750)
gmake-conditional in powerpc/Makefile.in, which automake (correctly)
refuses to handle.
* The problem is *not* specific to the powerpc. Other CPUs basically
have similar problems (SH:sh7032 vs sh7045, SPARC: erc32.h in
score/cpu/sparc), but have been lucky to get around real issues (cf.
configuration files below score/cpu/sh/).
* From a configuration focused POV this problem boils down to a
file/subdirectory selection problem:
ppc: 1 or others
sh: 1 out of 2
sparc: 1 out of 1
Automake's means to implement such behavior is using conditionals to be
evaluated at configuration-time. The old configuration scheme however
used make-time conditionals. The SH port was lucky to get around this
issue because it applies a selection from a limited set of possible
selections, the powerpc however applies a selection from an unlimited
set, based on data not being available at configuration time.
* Currently I only see two general solutions:
1) make RTEMS_CPU_MODEL available at configuration time, ie. replace
make-time configuration by configuration-time configuration
2) Perform the selection at build-time, i.e. always install all files,
but use #ifdef #else #endif in source files. This is what the m68k has
exploited at other locations inside of the source-tree.
=> This directory is the last one remaining not using automake below the
whole exec/ hierarchy.
<corsepiu@faw.uni-ulm.de> which implements automake support for some
score/cpu/<RTEMS_CPU> subdirectories and fixes a few minor configuration
bugs.
To apply:
rm -rf c/src/exec/score/cpu/a29k/wrap
rm -rf c/src/exec/score/cpu/hppa1.1/wrap
rm -rf c/src/exec/score/cpu/i386/wrap
rm -rf c/src/exec/score/cpu/mips64orion/wrap
rm -rf c/src/exec/score/cpu/no_cpu/wrap
patch -p1 < rtems-rc-19991123-rc-2.diff.gz
Notes:
* I don't see a possiblity to convert the powerpc subdirectory in its
current layout to automake the time being.
* Besides the fact that this subdirectory is not in single-tree building
layout, the actual showstopper is the ifeq $(RTEMS_CPU_MODEL),mpc750)
gmake-conditional in powerpc/Makefile.in, which automake (correctly)
refuses to handle.
* The problem is *not* specific to the powerpc. Other CPUs basically
have similar problems (SH:sh7032 vs sh7045, SPARC: erc32.h in
score/cpu/sparc), but have been lucky to get around real issues (cf.
configuration files below score/cpu/sh/).
* From a configuration focused POV this problem boils down to a
file/subdirectory selection problem:
ppc: 1 or others
sh: 1 out of 2
sparc: 1 out of 1
Automake's means to implement such behavior is using conditionals to be
evaluated at configuration-time. The old configuration scheme however
used make-time conditionals. The SH port was lucky to get around this
issue because it applies a selection from a limited set of possible
selections, the powerpc however applies a selection from an unlimited
set, based on data not being available at configuration time.
* Currently I only see two general solutions:
1) make RTEMS_CPU_MODEL available at configuration time, ie. replace
make-time configuration by configuration-time configuration
2) Perform the selection at build-time, i.e. always install all files,
but use #ifdef #else #endif in source files. This is what the m68k has
exploited at other locations inside of the source-tree.
=> This directory is the last one remaining not using automake below the
whole exec/ hierarchy.
<corsepiu@faw.uni-ulm.de> which implements automake support for some
score/cpu/<RTEMS_CPU> subdirectories and fixes a few minor configuration
bugs.
To apply:
rm -rf c/src/exec/score/cpu/i960/wrap
rm -rf c/src/exec/score/cpu/m68k/wrap
rm -rf c/src/exec/score/cpu/sh/wrap
rm -rf c/src/exec/score/cpu/sparc/wrap
rm -rf c/src/exec/score/cpu/unix/wrap
patch -p1 < rtems-rc-19991123-rc-1.diff
./bootstrap
Known bugs:
* "make debug|profile" in c/src/src/score/cpu/<RTEMS_CPU/Makefile does
not handle recursion to subdirectories correctly (recurses too often).
However, this issue is hardly visible and should be tolerable for the
moment.
<corsepiu@faw.uni-ulm.de> which implements automake support for some
score/cpu/<RTEMS_CPU> subdirectories and fixes a few minor configuration
bugs.
To apply:
rm -rf c/src/exec/score/cpu/i960/wrap
rm -rf c/src/exec/score/cpu/m68k/wrap
rm -rf c/src/exec/score/cpu/sh/wrap
rm -rf c/src/exec/score/cpu/sparc/wrap
rm -rf c/src/exec/score/cpu/unix/wrap
patch -p1 < rtems-rc-19991123-rc-1.diff
./bootstrap
Known bugs:
* "make debug|profile" in c/src/src/score/cpu/<RTEMS_CPU/Makefile does
not handle recursion to subdirectories correctly (recurses too often).
However, this issue is hardly visible and should be tolerable for the
moment.
<corsepiu@faw.uni-ulm.de> which implements automake support for some
score/cpu/<RTEMS_CPU> subdirectories and fixes a few minor configuration
bugs.
To apply:
rm -rf c/src/exec/score/cpu/i960/wrap
rm -rf c/src/exec/score/cpu/m68k/wrap
rm -rf c/src/exec/score/cpu/sh/wrap
rm -rf c/src/exec/score/cpu/sparc/wrap
rm -rf c/src/exec/score/cpu/unix/wrap
patch -p1 < rtems-rc-19991123-rc-1.diff
./bootstrap
Known bugs:
* "make debug|profile" in c/src/src/score/cpu/<RTEMS_CPU/Makefile does
not handle recursion to subdirectories correctly (recurses too often).
However, this issue is hardly visible and should be tolerable for the
moment.
Tomasz only tested this on the mpc823.
The official site for the original source for this PPP implementation is:
ftp://cs.anu.edu.au/pub/software/ppp
NOTE: As of 11/30/1999, the current version of this source is 2.3.10.
which (among other things) converted the mptests to automake.
SUB_DIRS was used instead of SUBDIRS in some Makefile.ins
(apparently a leftover from moving the start* directories)
Addtional major bugs:
* psxtests/include was empty (incomplete psxtests changes).
* bogus handling of *.scn in itrontests (screens/sptests vs.
screens/itrontests installation dirs)
In addition I have added a few more changes (I couldn't resist)
* automake support for itrontests
* OPERATION_COUNT support in tmitrontests/
* automake support for tmitrontests
* automake suppport for mptests
* Some (minor) corrections to several configure.in/Makefile.ams
=> c/src/tests/ is completly under automake control, now.
=> we could start to sort out the structural issues with c/src/tests
(tests/support, stubdr, tools, get "make dist" working)
which (among other things) converted the mptests to automake.
SUB_DIRS was used instead of SUBDIRS in some Makefile.ins
(apparently a leftover from moving the start* directories)
Addtional major bugs:
* psxtests/include was empty (incomplete psxtests changes).
* bogus handling of *.scn in itrontests (screens/sptests vs.
screens/itrontests installation dirs)
In addition I have added a few more changes (I couldn't resist)
* automake support for itrontests
* OPERATION_COUNT support in tmitrontests/
* automake support for tmitrontests
* automake suppport for mptests
* Some (minor) corrections to several configure.in/Makefile.ams
=> c/src/tests/ is completly under automake control, now.
=> we could start to sort out the structural issues with c/src/tests
(tests/support, stubdr, tools, get "make dist" working)
* the PACKHEX etc problem
* prevents the *.rels being removed inside the build-tree
* a typo which only shows for when MP is activated
* Alters some custom/*cfg files
+ Added tests for sem_open, sem_close, and sem_unlink.
+ Yellow lined sem_open, sem_close, sem_unlink,
_POSIX_Semaphore_Delete, _POSIX_Semaphore_Name_to_id,
and _POSIX_Semaphore_Create_support. Except for MP, pshared
OBJECT_REMOTE, and out of memory paths.
.. a major configuration cleanup
... major enhancement of automake support.
... and it contains a *major* breakthough:
Automake support for libchip and libmisc *LEAF* directories.
To implement this I have used several nasty tricks
* The basical trick is to wrap an old Makefile.in's contents into a
Makefile.am and still continue to use (i.e include) the old
*.cfg files.
* Replaced each INSTALL_IF_CHANGE and INSTALL_VARIANT with make
dependencies
* Add a gnu-make ifdef AUTOMAKE to main.cfg to avoid conflicts between
automake and RTEMS make rules
* Replaced each install:: and preinstall:: rule with make dependencies
* Replaced SUB_DIRS with SUBDIRS in all Makefile.ins (Automake
convention)
* Removed each manually added autoconf substitution which automake
performs automatically.
This is not yet full automake support, because using the temporary
installation directory, preinstallation in general and building variants
are in contradiction to automake's basic working principles ...
... the new Makefile.ams work still somewhat clumsy
... nevertheless they work (quite well).
WARNING:
At first glance this patch is small, but
* it affects the whole configuration system.
* it opens the road to introducing automake to all Makefile.ins
currently not being under automake control.
JOEL> Does this remove or add any files?
Both, all Makefile.ins below libchip and libmisc get replaced with
Makefile.ams.
Ralf Corsepius <corsepiu@faw.uni-ulm.de> that adds initial Hitachi SH-2
support to RTEMS. Ralf's comments are:
Changes:
------
1. SH-Port:
* Many files renamed.
* CONSOLE_DEVNAME and MHZ defines removed from libcpu.
* console.c moved to libbsp/sh/shared, build in libbsp/sh/<BSP>/console
applying VPATH.
* CONSOLE_DEVNAME made BSP-specific, replacement is defined in bsp.h
* MHZ define replaced with HZ (extendent resolution) in custom/*.cfg
* -DHZ=HZ used in bspstart.c, only
* Makefile variable HZ used in bsp-dependent directories only.
2. SH1-Port
* clock-driver rewritten to provide better resolution for odd CPU
frequencies. This driver is only partially tested on hardware, ie.
sightly experimental, but I don't expect severe problems with it.
* Polling SCI-driver added. This driver is experimental and completly
untested yet. Therefore it is not yet used for the console (/dev/console
is still pointing to /dev/null, cf. gensh1/bsp.h).
* minor changes to the timer driver
* SH1 specific delay()/CPU_delay() now is implemented as a function
3. SH2-Port
* Merged
* IMO, the code is still in its infancy. Therefore I have interspersed
comments (FIXME) it for items which I think John should look after.
* sci and console drivers partially rewritten and extended (John, I hope
you don't mind).
* Copyright notices are not yet adapted
its name in the name_table. This was required by the POSIX semaphore
and message queue managers which support a concept of open, close, and
unlink. The object becomes "invisible" to further opens following an
unlink but all open sessions remain active until they are closed. This
requires that the removal of an object ID be separate from the removal
of its name.
RTEMS API extension to avoid problems when the extension is freed.
Eventually the task variable switch extension should become part
of the core context switch and the Ada tcb self implemented in
terms of it.
which allow the BSP to override the default number of objects
that will be created in the timing tests. This is useful for
reducing memory consumption on small targets. The BSP_ITERATION_COUNT
can be used to reduce the number of repititions in some of the
tests. This is useful for extremely slow targets (we haven't seen
any slow enough to justify modifying this one yet though. :)
check that the _Thread_Dispatch_disable_level is set to the
proper value (0 99% of the time). This automatic check significantly
reduces the chance of mismatching disable/enable dispatch pairs
while doing internal RTEMS work.
port only uses System V IPC for shared memory and semaphores to
communicate between nodes in a multiprocessor configuration. If you
disable multiprocessing, then this code should be unused. Thus systems
like Cygwin which are POSIX but do not support System V IPC should
not work.
<corsepiu@faw.uni-ulm.de> which does the following:
This is the configuration cleanup patch:
Main changes:
* TARGET_ARCH removed
* target.cfg.in moved to c/make/target.cfg.in (Only configured once for
all BSPs of a target)
* BARE_XXX variables appended to bsp.cfg.in
* autogen renamed to bootstrap
* removed stray variables from make/custom/*.cfg
To apply:
cd <source-tree>
rm c/src/make/target.cfg.in
cp autogen bootstrap
mkdir c/make
cp make/target.cfg.in c/make/target.cfg.in
rm make/target.cfg.in
rm autogen
patch -p1 < rtems-rc-19991105-1.diff
to ITRON_Task_Get.
+ Modified to consistantly call _ITRON_return_errorno with E_OK.
+ Optimized the code to not disable dispatch prior to checking input values.
then sta_tsk used to restart the task to its initial state.
+ Added calls to ref_tsk to yellow paths for suspended and
ready but not running tasks.
+ Fixed output file to correctly state test name
+ Added priority of preempt to the header file. Allows ref_tsk verification.
state and one that is in non-dormant state.
+ Increased the priority of the Init task to force the dummy tasks to
run first.
+ Added calls to ref_tsk to verify the state of the dummy tasks and
test ref_tsk.
of enabling dispatching and returning E_OK.
+ Changed validation of the_thread to validation of location.
+ Set correct error code when dormant state.
+ Fixed comment.
EPICS needs a synchronized time-of-day clock. This patch is the changes
needed to get NTP server information from a BOOTP server.
This patch also adds NTP server information to the network configuration
structure, too.
substantial upgrade of newlibc.c occurred. Now the user extension
data area is used rather than notepads and as many routines as possible
were split into other files further reducing the minimum footprint
of an RTEMS executable.
unnecessarily uses any variables defined by the BSP. On this
sweep, use of BSP_Configuration and Cpu_table was eliminated.
A significant part of this modification was the addition of
macros to access fields in the RTEMS configuration structures.
This is necessary to strengthen the division between the BSP independent
parts of RTEMS and the BSPs themselves. This started after
comments and analysis by Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
particular, using bsp.h, or getting information from the BSP which
should properly be obtained from RTEMS is forbidden. This is
necessary to strengthen the division between the BSP independent
parts of RTEMS and the BSPs themselves. This started after
comments and analysis by Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
The changes primarily eliminated the need to include bsp.h and
peeking at BSP_Configuration. The use of Cpu_table in each
BSP needs to be eliminated.
should not have been. This required that IMFS_rmnod be split into
three separate (per file type) routines to avoid dependencies.
In the end, a miniIMFS application is 6K smaller than one using the
full IMFS.
increase ease of application configuration of the pc386 BSP. This
patch allows switching the printk console to a serial port and
overriding bsp_start by making it a weak alias.
are a dummy for linking programs together when you are primarily
concerned with tricking another package into building.
This may grow into something which could help link programs on
the command line by having a default start sequence.
<valette@crf.canon.fr> to add a port of the GoAhead web server
(httpd) to the RTEMS build tree. They have successfully used
this BSP on i386/pc386 and PowerPC/mcp750.
Mark and Joel spoke with Nick Berliner <nickb@goahead.com> on
26 Oct 1999 about this port and got verbal approval to include
it in RTEMS distributions.
Ralf Corsepius <corsepiu@faw.uni-ulm.de>:
Most significant changes:
* Names for rpms changed again
* gccnewlib.rpm split into 3 rpms, one for chill, gcj, gcc (includes
c/c++/f77/objc), simultaneously built from a common *.spec.
* small patches with major impact to gcc and newlib (Those fixes
mentioned to Ian, ie. libobjc/libchill are built, multilibing works)
* gcc patch against gcc-2.95.2 (Should also apply to gcc-2.95.1 without
major problems)
* Buildroot removed from */*spec.in
* New: rpm Group: "rtems" (rpm -q -g rtems reports all RTEMS packages)
report from Philip A. Prindeville <philipp@zembu.com>:
I was working on a device driver for a certain ethernet chipset that
occassionally wraps in its buffer, and causes a resulting mbuf chain
with only a few dozen bytes in the first mbuf of the chain.
I wouldn't have thought this would be a problem, until I ran some
stress tests that flooded the ethernet receiver with packets and
started to get panics here:
250
251 if (m->m_pkthdr.len < sizeof(struct ip))
252 goto tooshort;
253
254 #ifdef DIAGNOSTIC
255 if (m->m_len < sizeof(struct ip))
256 panic("ipintr mbuf too short");
257 #endif
258
259 if (m->m_len < sizeof (struct ip) &&
260 (m = m_pullup(m, sizeof (struct ip))) == 0) {
261 ipstat.ips_toosmall++;
262 return;
263 }
264 ip = mtod(m, struct ip *);
and the panic was at line 256. But if I #undef'd DIAGNOSTICS,
then the m_pullup() at line 260 does the right thing and the packet
ends up being processed just fine.
So I started wondering, (a) why was the test checking for
something that apparently wasn't a fatal condition but rather
one that is subsequently recovered from a couple of lines later
and (b) why panic as a diagnostic "aid" from a recoverable
condition rather than just (say) log a message to the console?
All of this seems overly severe for no reason that is readily
apparent to me.
issue and has mkbspspec in a better state. user.cfg is now
gone.
There are some miscellaneous changes to buildall done by Joel
to clean up the build process.
is working mostly for sparc at least.
There is one major problem -- the current process generates a unique
source file per RPM when in fact all of the source files are nearly
the same -- it is only the spec part of the rpm which differs.
The new file mkbinutils_subpackage_version is an attempt to
address this. It does part of the job right -- one source file
produces multiple binary RPMs. BUT the end user can not produce
the resulting RPMS themselves from SRPMS unless they also
build all targets.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
Removed all go32 configuration tests.
This patch also comments out some special treatment for Cygwin from
*.m4 macros. According to reports from David Fiddes. these should
not be necessary anymore.
pdf version of figures.
Disabled building of pdf for both the C and Ada Getting Started manuals
because texi2pdf can not handle the construct:
@set URL http://www.rtems.com
@uref{@value{URL},@value{URL}}
It will be reenabled as soon as this problem is fixed.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
now prototypes the malloc family in stdlib.h. This causes conflicts
with the way the network stack overrides the definitions of malloc.
As best I (being Joel) can tell, commenting stdlib.h out keeps the
files compiling and referencing the desired malloc/free but results
in more warnings.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
I'm working on code to mount my host based file system on the base file
system (imfs) and have a suggestion for a change to eval.c in the
c/src/lib/libc directory of the 8/20/1999 snapshot. The current version
does not test the result value returned from the evalpath callback (line 47)
in the case where follow_link is true. Attached is my suggested change.
Without this test the node_type callback may be called after evalpath
failed. node_type could set the type to some value other then
RTEMS_FILESYSTEM_HARD_LINK or RTEMS_FILESYSTEM_SYM_LINK but it seems cleaner
to add the check on result.
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
sigemptyset(&old_mask) needed to be added on glibc2 systems. Ian
Lance Taylor pointed out that sigemptyset() is portable so Joel removed
all conditionals around calls to sigemptyset().
The patch below actuallly consists of two patches:
1) moving librpc to c/src/librpc similar to what has been done to librtems++
2) reworked configure scripts, many safety and dependency checks added to
aclocal/*.m4 macros + configuration fixes.
To apply:
mkdir c/src/librpc
mkdir c/src/librpc/src
cp c/src/lib/librpc/*.c c/src/librpc/src
cp c/src/lib/librpc/Makefile.in c/src/librpc/src
mkdir c/src/librpc/include
mkdir c/src/librpc/include/rpc
cp c/src/lib/include/rpc/* c/src/librpc/include/rpc
patch -p1 < ../rtems-rc-19990820-7.diff
rm -rf c/src/lib/librpc
rm -rf c/src/lib/include/rpc
./autogen
The additional checks in aclocal/*m4 macros add rather restrictive, sometimes
unnecessarily restrictive constraints on the sequence of how macros can be
used in a configure.in script. Adding them has let my problems with some more
complicated configuration options vanish. Apparently some macros had not been
in the required order .
----
Now I still get some linking errors for some cpus and bsps, esp when linking
cdtest, but also at other locations:
e.g. this happens for mips64orion/p4600:
# make[5]: Entering directory
`/lfs/poseidon/users/rtems/src/multi/build/mips64orion-rtems/c/p4600/tests/samples/hello'
/opt/rtems/bin/mips64orion-rtems-gcc --pipe -B../../../../../../p4600/lib/
-specs bsp_specs -qrtems -DP4000 -DCPU_R4000 -DP3_DIAG -D_R4000 -D__mips=3
-mcpu=4600 -G0 -I../../../../../../p4600/lib/include/networking -g -Wall
-ansi -fasm -O4 -fomit-frame-pointer -o o-p4600/hello.exe
o-p4600/init.o ../../../../../../p4600/lib/no-dpmem.rel
../../../../../../p4600/lib/no-event.rel
../../../../../../p4600/lib/no-msg.rel ../../../../../../p4600/lib/no-mp.rel
../../../../../../p4600/lib/no-part.rel
../../../../../../p4600/lib/no-signal.rel
../../../../../../p4600/lib/no-timer.rel
../../../../../../p4600/lib/no-rtmon.rel
/opt/rtems/mips64orion-rtems/lib/libc.a(dtoa.o): In function `_dtoa_r':
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
collect2: ld returned 1 exit status
# mips64orion-rtems-gcc -v
Reading specs from /opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.1/specs
gcc version 2.95.1 19990816 (release)
# mips64orion-rtems-ld -v
GNU ld version 2.9.5 (with BFD 2.9.5)
The patch below actuallly consists of two patches:
1) moving librpc to c/src/librpc similar to what has been done to librtems++
2) reworked configure scripts, many safety and dependency checks added to
aclocal/*.m4 macros + configuration fixes.
To apply:
mkdir c/src/librpc
mkdir c/src/librpc/src
cp c/src/lib/librpc/*.c c/src/librpc/src
cp c/src/lib/librpc/Makefile.in c/src/librpc/src
mkdir c/src/librpc/include
mkdir c/src/librpc/include/rpc
cp c/src/lib/include/rpc/* c/src/librpc/include/rpc
patch -p1 < ../rtems-rc-19990820-7.diff
rm -rf c/src/lib/librpc
rm -rf c/src/lib/include/rpc
./autogen
The additional checks in aclocal/*m4 macros add rather restrictive, sometimes
unnecessarily restrictive constraints on the sequence of how macros can be
used in a configure.in script. Adding them has let my problems with some more
complicated configuration options vanish. Apparently some macros had not been
in the required order .
----
Now I still get some linking errors for some cpus and bsps, esp when linking
cdtest, but also at other locations:
e.g. this happens for mips64orion/p4600:
# make[5]: Entering directory
`/lfs/poseidon/users/rtems/src/multi/build/mips64orion-rtems/c/p4600/tests/samples/hello'
/opt/rtems/bin/mips64orion-rtems-gcc --pipe -B../../../../../../p4600/lib/
-specs bsp_specs -qrtems -DP4000 -DCPU_R4000 -DP3_DIAG -D_R4000 -D__mips=3
-mcpu=4600 -G0 -I../../../../../../p4600/lib/include/networking -g -Wall
-ansi -fasm -O4 -fomit-frame-pointer -o o-p4600/hello.exe
o-p4600/init.o ../../../../../../p4600/lib/no-dpmem.rel
../../../../../../p4600/lib/no-event.rel
../../../../../../p4600/lib/no-msg.rel ../../../../../../p4600/lib/no-mp.rel
../../../../../../p4600/lib/no-part.rel
../../../../../../p4600/lib/no-signal.rel
../../../../../../p4600/lib/no-timer.rel
../../../../../../p4600/lib/no-rtmon.rel
/opt/rtems/mips64orion-rtems/lib/libc.a(dtoa.o): In function `_dtoa_r':
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
collect2: ld returned 1 exit status
# mips64orion-rtems-gcc -v
Reading specs from /opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.1/specs
gcc version 2.95.1 19990816 (release)
# mips64orion-rtems-ld -v
GNU ld version 2.9.5 (with BFD 2.9.5)
The old system would panic when the loopback interface was included as
part of the network initialation structures. With the printf you get an
message, but the interface is still properly initialized.
from Eric Norum <eric@cls.usask.ca>. This patch was rtems-19990820-0-diff
from Ralf.
FYI: In parallel to the transition to automake, RTEMS is on a transition
from make-time configuration to per-bsp and per-bsp configuration at
configuration-time. Due to this several changes to configuration files
have been added and might have broken something that has been working
previously. Most noticeable behavioral change is that you now are required
to use @RTEMS_BSP@ instead of $(RTEMS_BSP) inside of any Makefile.ins
which are configured or build as part of the source-tree.
> It used to be that only RTEMS_MAKEFILE_PATH had to be set. Why is this
> no longer sufficient?
It should still be working, if it doesn't, it has to be considered to be
broken and should be fixed.
I am not sure, but I assume you are using Makefile.inc - In this case, you
have found a bug in Makefile.inc.in which should be worked-around by the
patch below. If my assumption is wrong, I would need more details ...
c/src/lib/librtems++ and c/src/lib/include/rtems++ to
their own package librtems++ at the top of the tree.
To apply:
mkdir c/src/librtems++
cp c/src/lib/librtems++/README c/src/librtems++
mkdir c/src/librtems++/src
cp c/src/lib/librtems++/*.cc c/src/librtems++/src
cp c/src/lib/librtems++/Makefile.in c/src/librtems++/src
mkdir c/src/librtems++/include
mkdir c/src/librtems++/include/rtems++
cp c/src/lib/include/rtems++/*.h c/src/librtems++/include/rtems++
patch -p1 <rtems-rc-19990802-5.diff
rm -rf c/src/lib/librtems++
rm -rf c/src/lib/include/rtems++
./autogen
Attention:
* The procedure above copies the files first, then patches them
and finally removes the old files afterwards. This has been done
to enable you to copy the files in CVS to preserve their history.
Somehow a nasty bug has made it in sh/start.S ("|", instead of "!", to
begin an asm comment).
I have no idea how this could remain undiscovered for so long (It is in
rtems-4.0.0, too!), however upgrading to binutils from sourceware's CVS
sh-rtems-as chokes on this bug. => I guess, either binutils changed its
conventions or an obvious bug in as has been fixed.
This patch addresses a few configuration issues and removes some
duplicate configuration files.
Background:
* some files used in AC_INIT were not unique enough and can lead to
problems if a user plays with configure scripts.
* the Makefile templates are independent of the target/cpu and bsp, so
the bsp dependent versions (c/src/make/Templates) are removed.
To apply:
patch -p1 < rtems-rc-19990820-3.diff
rm -f c/src/make/Templates
./autogen
ATTENTION: This patch removes several files and one directory :)
1. Addition of maintainer-mode dependencies on config.status and
aclocal.m4 for autoconf toplevel Makefile.ins. These rules are taken
over from automake generated Makefile.ins, i.e. they are contained in
any automake generated toplevel Makefile.in. Having this patch in is at
least a great releaf for me when working on RTEMS configuration :)
2. Automated support for #1 in acpolish
3. Some minor "beautifications" on Makefile.ins resulting from running
acpolish.
FYI: This patch has been generated by running
tools/update/rtems-polish.sh -ac on the source tree and manually editing
the resulting patch afterwards to work around a problem with acpolish,
which still corrupts one Makefile.in - WARNING: Be careful with running
acpolish!
The patch below actually consists of 3 patches:
1. Addition of maintainer-mode dependencies on config.status and
aclocal.m4 for autoconf toplevel Makefile.ins. These rules are taken
over from automake generated Makefile.ins, i.e. they are contained in
any automake generated toplevel Makefile.in. Having this patch in is
at least a great releaf for me when working on RTEMS configuration :)
2. Automated support for #1 in acpolish
3. Some minor "beautifications" on Makefile.ins resulting from
running acpolish.
FYI: This patch has been generated by running
tools/update/rtems-polish.sh -ac on the source tree and manually editing
the resulting patch afterwards to work around a problem with acpolish,
which still corrupts one Makefile.in - WARNING: Be careful with running
acpolish!
I expect this patch not to have any influence on normal users, unless
they use --enable-maintainer-mode, thus merging it should be rather
harmless.
The patch below actually consists of 3 patches:
1. Addition of maintainer-mode dependencies on config.status and
aclocal.m4 for autoconf toplevel Makefile.ins. These rules are taken
over from automake generated Makefile.ins, i.e. they are contained in
any automake generated toplevel Makefile.in. Having this patch in is
at least a great releaf for me when working on RTEMS configuration :)
2. Automated support for #1 in acpolish
3. Some minor "beautifications" on Makefile.ins resulting from
running acpolish.
FYI: This patch has been generated by running
tools/update/rtems-polish.sh -ac on the source tree and manually editing
the resulting patch afterwards to work around a problem with acpolish,
which still corrupts one Makefile.in - WARNING: Be careful with running
acpolish!
I expect this patch not to have any influence on normal users, unless
they use --enable-maintainer-mode, thus merging it should be rather
harmless.
Please take a look at this new patch. It contains a cleaner implementation
of the reset operation. These patches are against 4.0.0. But the files
did not change from the 3.6.0 release. Also, the cpu.h patch below still
applies. I.e. instead of using i960ca_PRCB, use i960_PRCB.
Explanation:
The previous patch removed the use of the reset instruction,
because it always fails. But this was due to the fact that
some of the registers were corrupted by the re-init procedure.
The new patches save and restore those registers when a re-init
is done.
Here is another fix, which addresses a few more or less severe bugs in
configuration and unix/posix:
* Configuration fix: c/src/lib/configure.in didn't handle RDBG correctly
* Configuration fix: make depend was non-functional in
c/src/lib/libc/Makefile.in
* Configuration fix: stray comment removed from aclocal/target.m4
* RTEMS fix: termios support for unix/posix now uses the host's headers
only (was completely broken).
- Don't install RTEMS's newlib sys/termios.h for unix (sys/termios.h
apparently is a newlib specific header)
- To be able to compile RTEMS's termios.c with glibc2.1, glibc-2.1
needs __USE_MISC, which is a private define from gcc's features.h, being
defined only when _BSD_SOURCE of _SVID_SOURCE is defined. RTEMS's
termios apparently implements BSD, thus -D_BSD_SOURCE was added to
Linux-posix.cfg.
- Conflicting definitions for __USE_MISC and _BSD_SOURCE inside of
RTEMS codes removed due to definition of _BSD_SOURCE on the toplevel.
This fix has been tested with linux/posix (primary glibc2.1 native),
linux/posix (secondary libc5 native), sh/gensh1, i386/pc386 and a couple
of other bsp's/CPU.
To apply:
cd <srcdir>
patch -p1 < rtems-rc-19990709-9.diff
and
aclocal -I aclocal && automake && autoconf
cd c/src/lib; autoconf
or
./autogen
After upgrading my linux box to the brand new SuSE 6.2 release, which is
glibc-2.1 based, I came across a bug in RTEMS - IIRC, I even warned you
about it about 1/2 a year ago, but nothing has been done since then :-.
The *.m4 macros to check for SYSV/IPC are broken for linux/glibc2.1,
because they assume that linux always defines union semun, which isn't
true anymore for glibc2.1 (the manpage for semctl states _X_OPEN
specifies it this way). Therefore I have tried to implement a more
general approach for handling SYSV for unix/posix which checks for
presence of struct semun, instead of trying to evaluate OS specific
preprocessor symbols.
This approach is a bit adventureous, because I only tested it with
linux/glibc2.1 and linux/libc5, but not under other Unix variants RTEMS
supports. I am quite confident it will work on other hosts, too, but who
knows :-.
[FYI: I think this might also is the cause of some problems with RedHat
6.X / Mandrake linux recently reported on the rtems list -- rtems-4.0.0
can not be build for posix on any glibc2.1 based host]
Furthermore the patch below contains a couple of minor fixes and
configuration cleanups, which IMO should be applied before releasing a
new snapshot.
To apply this patch:
cd <source-tree>
patch -p1 < rtems-rc-19990709-8.diff
./autogen
I'm attaching a big patch for the ts_386ex BSP which adds and includes
the following:
1) Conversion to ELF format + minor code cleanups + documentation.
2) An Ada95 binding to FreeBSD sockets, based on Samuel Tardieu's
adasockets-0.1.3 package. This includes some sample applications.
3) Some Ada and C interfaces to add serial-port debugging to
programs. Comes with examples, too; the Ada one shows how
transparent adding the support can be. Note that Rosimildo sent me
the original C code.
The network stuff is not BSP specific, and could be added to your Ada
code collection. The debugging stuff is specific to the i386. Right
now, everything sits in my "tools" directory.
I'm attaching a big patch for the ts_386ex BSP which adds and includes
the following:
1) Conversion to ELF format + minor code cleanups + documentation.
2) An Ada95 binding to FreeBSD sockets, based on Samuel Tardieu's
adasockets-0.1.3 package. This includes some sample applications.
3) Some Ada and C interfaces to add serial-port debugging to
programs. Comes with examples, too; the Ada one shows how
transparent adding the support can be. Note that Rosimildo sent me
the original C code.
The network stuff is not BSP specific, and could be added to your Ada
code collection. The debugging stuff is specific to the i386. Right
now, everything sits in my "tools" directory.
<raguet@crf.canon.fr>:
- the dec21140 driver code has been hardened (various bug fixed) Emmanuel,
- bug in the mcp750 init code have been fixed (interrupt stack/initial
stack initialization), BSS correctly cleared (Eric V)
- remote debugging over TCP/IP is nearly complete (berakpoints,
backtrace, variables,...) (Eric V),
- exception handling code has also been improved in order to fully
support RDBG requirements (Eric V),
I just released erc32ccs-2.0.6 which includes some fixes and the
Ada-self optimisation. Remote debugging of Ada programs did not
work due to a conflict between monior and rtems trap handlers.
I have attached a modified gnatsupp.c that makes remote debugging
possible again.
to fix problem reported by Ralf Corsepius <corsepiu@faw.uni-ulm.de>.
Date: Fri, 30 Jul 1999 14:53:20 -0500 (CDT)
From: <joel@oarcorp.com>
it is used like this in i386ex/start/start.S
/* set up same values in cache */
start.S: movw $0xFFFB, SYM(i8259s_cache)
I am heading out the door. Any other ideas what could have tripped this?
This instruction appears in a .code16 section. In a .code16 section,
current versions of gas assume that all addresses are 16 bits unless
told otherwise.
If you change the line to
addr32 movw $0xFFFB, SYM(i8259s_cache)
then you will get a 32 bit address reference.
You may want to use addr32 only when NEW_GAS is defined.
The patch below fixes a nasty bug in acpolish, which has broken many
Makefile.ins below c/src/tests/
APPLYING THE PATCH:
patch -p1 < rtems-rc-19990709-5.diff
The essential part of this patch is the diff-fragment for acpolish
contained in this patch. Ie. if any of the other diffs do not apply,
make sure that the acpolish diff was applied correctly and then run
cd <srcdir>
tools/update/rtems-polish.sh -ac
The main topic is replacing the hard-coded values for HAS_MP and
HAS_RDBG in custom/*.cfg with per-bsp configuration-time autoconf checks
(This is the patch I had mentioned before earlier this week).
CHANGES
* HAS_MP removed from custom/*.cfg, replaced with configuration time
autoconf check
* HAS_RDBG removed from custom/*.cfg, replaced with configuration-time
autoconf check
* NEW: c/src/make/bsp.cfg.in, takes configuration-time checked per-bsp
values (i.e. HAS_MP, HAS_RDBG), gets installed as
$(prefix)/<bsp>/make/bsp.cfg
* NEW: default.cfg includes bsp.cfg - this change is backward
compatible.
* IMPORT_SRC: apply VPATH instead for ts_386ex/i386ex subdirectory
Makefile.ins
* HACK: a bug in acpolish mis-handles addtions to makefile variables
which are enclosed in gmake conditionals:
c/src/lib/libbsp/m68k/ods68302/start302/Makefile.in
* Apply inline_dir, HAS_MP and HAS_RDBG for avoiding configuration of
unneeded subdirectories in various configure.in files.
* Several minor changes in Makefile.ins and configure.ins, wrt. to the
order of including *.cfg and defining Makefile variables
APPLYING THE PATCH:
patch -p1 < rtems-rc-19990709-4.diff
./autogen
Problem: a posix thread which is created by
pthread_attr_init(&tattr);
pthread_attr_setinheritsched(&tattr, PTHREAD_EXPLICIT_SCHED);
pthread_attr_setschedpolicy(&tattr, SCHED_RR);
pthread_create(&th, &tattr, func, arg);
has a first timeslice of 2^32 ticks (changing a running thread to
SCHED_RR id ok).
I use RTEMS-4.0.0. I am not sure if the problem exists in the current CVS
head revision. If it's not fixed, the patch at the end should do it.
Peter
--- pthreadcreate.c.orig Wed Jul 28 14:45:58 1999
+++ pthreadcreate.c Wed Jul 28 15:06:09 1999
@@ -199,6 +199,10 @@
api->schedpolicy = schedpolicy;
api->schedparam = schedparam;
+ if ( schedpolicy == SCHED_RR ) {
+ the_thread->cpu_time_budget = _Thread_Ticks_per_timeslice;
+ }
+
/*
* This insures we evaluate the process-wide signals pending when we
* first run.
to address m68k-rtemself for the MVME167.
Here is the rtems patch I promissed you a long time ago to enable ELF
with m68k. The target name I selected is m68k-rtemself. It preserves the
m68k-rtems COFF target, and is parterned after the other ELF/COFF dual
targets.
The mvme167.cfg file causes the -qelf flag to be used during compilation
if the name of the compiler contains rtemself. This flag is used in the
bsp_specs file to select the elflinkcmds file rather than the linkcmds
file. The former is for ELF, the latter for COFF.
Some patches are required to the mc68040 FPSP code. Some of the
assembler files contain instructions that were rejected by the
m68k-rtemself-as assembler. This is a minor bug in the m68k ELF
assembler, I think.
bug report from David Decotigny <David.Decotigny@irisa.fr>:
During the last few days, I've been back working on RTEMS. Let me
remind you that RTEMS didn't boot on our (old) Dell P90 machines (ref:
PC 590) : we could only get a reboot out of them.
1/ The symptoms
---------------
Hopefully, the problem was rather deterministic. The stack couldn't be
written correctly : issueing one or more "push" would always push '0'
onto the stack. The way to solve this was to issue a "pop", such as
"pushl eax ; popl eax". After this "pop", the stack would be writeable
again.
BUT, it will be writable for 8 consecutive "push"s. After these 8
"push"s, the other "push"s are wrong again, and a blank push/pop is
needed.
Considering that the L1 cache lines of this pentium are 32 bytes long,
and that 8 long int are 32 bytes long too, it came to us that there
was a problem with the cache.
Actually, the bug of the push could be shown through memory accesses
directly : writing on an not-in-cache mem location would put 0 until
this mem location is accessed through a single "read". Then, the whole
cache line would be right again.
2/ The consequences
-------------------
Of course, that was the first thing that we've been able to observe ;)
RTEMS could not boot. Actually, when a "call" pushed 0 onto the stack,
the ret could only lead to raise an exception a bit later. Since, in
the early stage, the Interrupt vector points to 0, averything couldn't
get worse : triple fault + reboot.
3/ Explanation
--------------
This cache mechanism corruption only appeared after load_segment()
returned (through a jump). Investigating a bit further shows that this
appears /sometimes/ during the PICs initialization.
"Sometimes" proved to be "When writing something with the 4th bit of
%al set". That is "when writing 0x28 or 0xff" for example. Clearing
this bit would just make the things work right.
Actually, this isn't a bug in the proper PIC initialization (which is
quite academic). It came from the "delay" routine, which theoretically
does nothing but writing to an "inexistant" port (0xed), in order to
lose some time.
BUT, in the special case of our Dell P90, it appears that this 0xed
port does something cruel with the cache mechanism when its 4th bit
(aka bit 3 or 0x8) is set.
I didn't investigate this non-standard behaviour of the P90 any
further : I don't know if this is documented, or if it is just another
(known ?) bug of the early Pentiums. Just notice that we have 5 such
machines, and it has the same effect on the cache mechanism.
----------------------------------------------------------------------
This patch is an addition to "The big-patch"
CHANGES:
* FIX: c/Makefile.am: bogus comment which changed the behavior of
c/Makefile.am removed
* FIX: make/custom/ts_i386ex.cfg did not set HAS_NETWORKING correctly
(Me thinks it might have been me who added this bogus setting :-).
* NEW: removing make targets get, protos, debug_install, profile_install
* NEW: replacing clobber with distclean
* NEW: Reimplement distclean and clean as reverse depth first make
targets (adaptation to automake's behavior)
* NEW: removing RCS_CLEAN from make distclean (tools/build/rcs_clean is
still in - remove it?)
* NEW: "$(RM) Makefile" added to make distclean (adaptation to
automake's behavior)
* NEW: "$(RM) config.cache config.log" to CLOBBER_ADDITIONS in
[lib|exec|tests]/Makefile.in (adaptation to automake's behavior)
* NEW: "$(CLEAN_PROTOS)" removed (Not used anywhere)
* NEW: binpatch.c moved from i386 bsp tools to tools/build (AFAIS,
binpatch is not specific to the pc386 BSP at all)
* NEW: AC_EXEEXT added to all configure scripts which contain AC_PROG_CC
(Cygwin support)
* NEW/Experimental: An experimental implementation of temporary
installation tree support in libbsp/i386/pc386/tools/Makefile.am, based
on dependency tracking with make, instead of applying INSTALL_CHANGE.
REMARK:
* This patch is small in size, but changes the behavior of "make
clean|distclean|clobber" basically.
* This patch does not alter building/compiling RTEMS, ie. there should
be no need to rerun all "make all" building tests.
KNOWN BUGS:
* make RTEMS_BSP="..." distclean in c/ runs "make distclean" in BSPs
subdirectories passed through RTEMS_BSP and in "c/." only, but does not
descend into other BSP subdirectories previously configured with
different settings of make RTEMS_BSP="...".
=> Workaround: always use the same setting of RTEMS_BSP when working
inside the build-tree.
* "make [distclean|clean]" do not clean subdirectories, which have been
configured at configuration time, but which are not used due to
make-time configuration (e.g. macros/networking/rdgb subdirectories).
This will problem will vanish by itself when migrating from make-time to
configuration-time configuration
APPLYING THE PATCH
mv c/src/lib/libbsp/i386/pc386/tools/binpatch.c tools/build
patch -p1 < rtems-rc-19990709-2.diff
autogen
A bug in acpolish made it into rtems-rc-19990709-0.diff, which
unfortunately affects all Makefile.ins:
* The maintainer mode conditional was erroniously applied to the
dependencies of "Makefile".
In case you already checked in rtems-rc-19990709-0.diff to CVS you have
to check in all Makefile.ins again after applying the patch below :).
Please apply the patch below as follows:
patch -p1 < rtems-rc-19990709-1.diff
tools/update/rtems-polish.sh -ac
Note: There is no need to rerun your tests if you have used
--enable-maintainer-mode to configure RTEMS, because this patch converts
all Makefile.ins to the same settings as used for
--enable-maintainer-mode.
to move RTEMS more to automake/autoconf and GNU compliance.
Finally, here they are: the "big-patch" patches - merged into one big
patch (~1.5MB).
Sorry for the delay, but testing took much more time than I had expected
- esp. reworking the acpolish script triggered many more tiny issues
than I had expected (cf. below).
At least, now you've got something to spend your weekend with :-.
WARNINGS:
* I've gone a little (??) further than I had announced before.
* Several directories have been moved.
* Several files have been added and removed
* I have tested it with many BSPs/CPUs and a variety of permutiations of
configuration flags, but not with all.
* Most parts of the patch are automatically generated, however there are
many tiny manual modifications.
APPLYING THE PATCH:
./autogen -c
mkdir tools
mv c/src/exec/score/tools tools/cpu
mv c/build-tools tools/build
mv c/update-tools tools/update
patch -p1 -E < rtems-rc-19990709-0.diff
./autogen
If the patch doesn't apply to rtems-cvs, I would suggest that you should
try to apply it brute-force and then to run tools/update/rtems-polish.sh
-ac -am afterwards. A recursive diff between rtems-19990709 + patch and
rtems-cvs + patch then should report only a few dozen significant
changes to configuration files which need to be merged manually (IIRC, I
did not change any source files).
*** Attention: There are files to be removed, moved, copied and added
in/to CVS!
NEWS/CHANGES:
1. Configuration takes place in 3 stages: 1. per host (toplevel
configure script), 2. per target (c/configure), 3. per bsp
c/src/configure automatically triggered from ./configure and
c/Makefile.am.
2. Building of subdirectory c/ takes place in c/$(target_alias) for
cross-targets in c/ for native targets
3. Building of subdirectory c/src takes place in c/${target_alias}/<bsp>
for cross-targets, c/<bsp> for native targets
4. c/build-tools moved to tools/build
5. c/src/exec/score/cpu/tools moved to tools/cpu (=cpu-tools split out)
6. c/update-tools moved to tools/update
7. New subdirectory c/src/make, handles files from make/ on a per BSP
basis
8. Maintainer mode support: Ie. if configuring with
--enable-maintainer-mode disabled (the default), then tracking of many
dependencies will be disabled in Makefiles. Esp. many dependencies for
auto* generated files will be switched off in Makefiles. Ie. if not
using "--enable-maintainer-mode" many auto* generated files will not be
updated automatically, i.e. normal users should not be required to have
auto* tools anymore (untested).
9. Independent configuration scripts for / (toplevel), tools/build,
tools/cpu, tools/update, c/, c/src/, c/src/exec, c/src/lib, c/src/tests,
c/src/make
10. Automake support for all directories above and besides c/src
11. "preinstall" now is implemented as depth-first recursive make target
12. host compiled tools (exception bsp-tools) are accessed in location
in the build tree instead of inside the build-tree when building RTEMS.
13. RTEMS_ROOT and PROJECT_ROOT now point to directories inside the
build-tree - many tiny changes as consequence from this.
14. --with-cross-host support removed (offically announced obsolete by
cygnus)
15. Changing the order of building libraries below c/src/lib/
16. Former toplevel configure script broken into aclocal/*.m4 macros
17. Newlib now detected by configure macros, RTEMS_HAS_NEWLIB removed
from *cfg.
18. sptables.h now generated by autoconf
19. Rules for "mkinstalldirs temporary installation tree" moved from
c/Makefile to subdirectories.
20. Cpu-tools do not get installed.
21. FIX: Use ACLOCAL_AMFLAGS instead of ACLOCAL = -I ... in Makefile.ams
which are in directories with own configure scripts.
22. Hardcoding BSP names into libbsp/.../tools to avoid RTEMS_BSP get
overridden from the environment.
22. FIX: Handling of MP_PIECES in various Makefiles
23. FIX: Removing "::" rules from some Makefile.ins
24. FIX: File permission chaos: (-m 444 and -m 555 vs. -m 644 and -m
755) - Now all include files use -m 644.
25. Removed many gnumake-conditionals in Makefile.ins - Partially
replaced with automake-conditional, partially replaced with
conditionalized Makefile variables (... _yes_V)
26. Massively reworked acpolish: acpolish now parses Makefile.ins and
interprets parts of the Makefile.ins.
27. FIX: Some $(wildcard $(srcdir)/*.h) macros removed / replaced with
explicit lists of files in Makefile.ins.
28. FIX: Replacing MKLIB with RANLIB in Makefile.ins
29. HACK: Add preinstallation for pc386 specific
$(PROJECT_RELEASE)/BootImgs directory
... many more details, I can't recall
KNOWN BUGS:
1. make [debug|profile]_install do not do what they are promissing.
"make [debug|profile] install" does what "make [debug|profile]_install"
has been doing. Proposal: remove [debug|profile]_install
2. Dependencies between temporary installation tree and source tree are
not yet handled correctly.
3. Dependencies between temporary installation tree and source tree are
handled ineffencently (Using INSTALL_CHANGE instead of make
dependencies)
4. RTEMS_ROOT, PROJECT_ROOT, top_builddir, RTEMS_TOPdir now are
redundant.
5. The new configure scripts still are in their infancy. They contain
redundant checks and might still contain bugs, too.
6. RTEMS autoconf Makefile.ins use a mixture of configuration
information gathered in c/$(target_alias)/<bsp>/make and of information
collected from their configure scripts.
7. make dist is not fully functional
8. Subdirectory host-/build-/target- configure options (--target,
--host, --build) do not conform to Cygnus/GNU conventions.
9. Some RTEMS autoconf Makefile.in's makefile targets are not supported
in automake Makefile.ams/ins (e.g. get, clobber).
10. Some automake standard targets are not propagated from toplevel and
c/Makefile.am to autoconf subdirectories (eg. make dist).
11. rpcgen generated files are not part of the source-tree (Automake
conventions favor supplying generated files inside the source-tree,
however there is no support for rpcgen generated files in automake, cf.
yacc/lex support in automake).
12. RTEMS_HAS_RDBG handling is flaky. make/*.cfg use RTEMS_HAS_RDBG per
CPU, while librdb's sources can only be built per BSP. Raises the more
general question whether librdbg located correctly in the source-tree.
13. All make/*cfg files are configured per cpu, currently there is no
location to store per-bsp configuration information --> bsp.cfg, per
aconfig.h?
14. "make install" without having run "make all" beforehand does not
work.
15. handling of --enable-multiprocessing seems to be broken in
make/custom/*
16. Makefile.ins still exploit many gmake features.
17. File permisson chaos on libraries (no explict -m for
libraries/rels/etc).
18. mcp750 Makefiles are broken (Note: I *do* mean buggy - I am not
talking about "not-conforming to conventions", here :-).
19. Dependencies between configure scripts are not handled, eg. aborting
"make RTEMS_BSP=<bsp>" can leave the build-tree in an unusable state.
20. "make clean" does not delete <build-tree>/<bsp>. This is intentional
for now, because rerunning "make" after "make clean" requires an
explicit "make preinstall" afterwards now. This should be done
automatically, but doesn't work in this case for now. To work around
this problem <build-tree>/<bsp> is kept during "make clean" for now
(HACK).
TODO:
1. split out host-compiled bsp-tools
2. Use Cygnus/GNU standards for cross-compiling target-subdir
(CC=CC_FOR_TARGET .. configure --host=${target_alias}
--build=`config.guess'}), to be added to toplevel configure script after
splitting out bsp-tools.
3. Exploit per cpu support directory (c/src/<cpu>)- Splitting out
per-cpu libraries - Are there any?
4. Further automake support
5. Converting subdirectories into standalone / self-contained
subdirectories (Esp. moving their headers to the same common root as
their sources, eg. mv lib/include/rtems++
lib/librtems++/include/rtems++) - This is the main obstacle which
prevents moving further towards automake.
6. Propagating values from *.cfg into Makefiles instead of propagating
them at make time via Makefile-fragments (i.e. try to avoid using
*.cfg).
7. Testing on cygwin host (I *do* expect cygwin specific problems).
8. The ARCH in o-$(ARCH)-$(VARIANT) build-subdirectories is not needed
anymore.
GENERAL ISSUES:
1. Temporary installation tree -- Ian and I seem to disagree basically.
Though I think that I understand his argumentation, I do not share it.
IMO, his way of using the buildtree is mis-using the build-tree, relying
on an inofficial feature of RTEMS's current implementation, which
doesn't even work correctly in the current build-tree, though it
attempts hard to do so. From my very POV, it unnecessarily complicates
the structures of the source- and build-trees. It is not supported by
automake (No automatic generation for the necessary rules) and
complicates the transition to automake significantly (Generating the
rules with an enhanced version of acpolish could be possible).
As Ian correctly pointed out, here a management decision is needed -
though I don't see the need to draw this decision in short terms.
2. preinstallation generally is a sure means to spoil the structure of
the source tree, IMHO (No ranting intended, I am completly serious about
this one). eg. through tree dependencies. The worst problem related to
this I have found in the meantime is bsp_specs. bsp_specs is part of
libbsp, ie. there is *no* way to build *any* part of the source tree
*without* having a BSP *preinstalled*.
Note: This issue is related to issue 1., but is not identical - The
difference is the change of the order make rules have to be triggered.
While preinstallation triggers rules spread all over the source tree
before a "make all" can be run, a temporary installation tree could also
be installed by post "make all" hooks (all-local:, to be run after make
all in a directory is completed) if the directories' dependencies would
be a tree,
3. Stuctural dependencies between subdirectories.
4. Depth of the source tree (Prevents multilibbing and introduces many
unnecessary configure scripts).
5. per cpu vs. per bsp configuration (There are no real per-cpu parts
yets :-).
6. automake does not support $makefiles in AC_OUTPUT. Unlike before, we
now should try to avoid RTEMS_CHECK_MAKEFILE and to hard-code as much
paths to Makefiles as possible.
7. General redesign of the source tree
8. Main installation point - Changing it to ${prefix}/${target_alias}. ?
Besides item 8. (which is a must, IMHO), as far as I see most of them
can not be solved soon and will remain issues in the mid- to long-term
:-.
REMARKS:
* You (as the maintainer) should always use --enable-maintainer-mode
when building RTEMS to ensure that maintainer mode generated files (esp.
those in c/src/make) will be updated when make/* files have changed.
* Use @RTEMS_BSP@ in Makefile.ins and Makefile.ams below c/src/,
$(RTEMS_BSP) or ${RTEMS_BSP} will be overridden from environment
variables when using make RTEMS_BSP="....".
* c/src/make is a temporary cludge until configuration issues are
solved. At the moment it is configured per bsp, but contains
per-target/cpu info only. Its main purpose now is to circumvent
modifying make/*.cfg files, because I consider make/* to be frozen for
backward compatibilty.
* This patch should only affect configuration files. At least I do not
remember having touched any source files.
* To build the bare bsp you now need to mention it in --enable-rtemsbsp.
Example: building gensh1 and sh1/bare simultaneously:
../rtems-rc-19990709-1/configure --target=sh-rtems \
--enable-rtemsbsp="bare gensh1" \
--prefix=/tmp/rtems \
--enable-bare-cpu-cflags='-DMHZ=20 -m1
-DCPU_CONSOLE_DEVNAME=\"/dev/null\"' \
--enable-bare-cpu-model=sh7032 \
--enable-maintainer-mode \
--enable-cxx
make
make install
* The next steps in development would be to split out bsp-tools and then
to change to Cygnus/GNU canonicalization conventions for building the c/
subdirectory afterwards (i.e. many standard AC_*.m4 macros could be used
instead of customized versions)
FINAL REMARK:
The issues mentioned in the lists above sound much worser than the
situation actually is. Most of them are not specific to this patch, but
are also valid for the snapshot. I just wrote down what I came across
when working on the patch over the last few weeks.
I wouldn't be too surprised if you don't like the patch at the current
point in development. I am willing to discuss details and problems, I
also have no problem if you would post-pone applying this patch to times
after 4.1, but rejecting it as a whole for all times would be a false
management decision, IMHO.
Therefore I would suggest that you, if your time constaints allow it,
should at least play a little while with this patch to understand what
is going on and before drawing a decision on how to handle this
proposal. I know this patch is neither perfect nor complete, but I
consider it to be a major breakthrough. Don't be anxious because of the
size of the patch, the core of the patch is rather small, the size is
mainly the side effect of some systematic cleanups inside the Makefiles
(result of acpolish).
Feel free to ask if you encounter problems, if you don't understand
something or if you meet bugs - I am far from being perfect and am
prepared to answer them.
Ralf.
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999
http://www.faw.uni-ulm.de
to move RTEMS more to automake/autoconf and GNU compliance.
Finally, here they are: the "big-patch" patches - merged into one big
patch (~1.5MB).
Sorry for the delay, but testing took much more time than I had expected
- esp. reworking the acpolish script triggered many more tiny issues
than I had expected (cf. below).
At least, now you've got something to spend your weekend with :-.
WARNINGS:
* I've gone a little ??) further than I had announced before.
* Several directories have been moved.
* Several files have been added and removed
* I have tested it with many BSPs/CPUs and a variety of permutiations of
configuration flags, but not with all.
* Most parts of the patch are automatically generated, however there are
many tiny manual modifications.
APPLYING THE PATCH:
./autogen -c
mkdir tools
mv c/src/exec/score/tools tools/cpu
mv c/build-tools tools/build
mv c/update-tools tools/update
patch -p1 -E < rtems-rc-19990709-0.diff
./autogen
If the patch doesn't apply to rtems-cvs, I would suggest that you should
try to apply it brute-force and then to run tools/update/rtems-polish.sh
-ac -am afterwards. A recursive diff between rtems-19990709 + patch and
rtems-cvs + patch then should report only a few dozen significant
changes to configuration files which need to be merged manually (IIRC, I
did not change any source files).
*** Attention: There are files to be removed, moved, copied and added
in/to CVS!
NEWS/CHANGES:
1. Configuration takes place in 3 stages: 1. per host (toplevel
configure script), 2. per target (c/configure), 3. per bsp
c/src/configure automatically triggered from ./configure and
c/Makefile.am.
2. Building of subdirectory c/ takes place in c/$(target_alias) for
cross-targets in c/ for native targets
3. Building of subdirectory c/src takes place in c/${target_alias}/<bsp>
for cross-targets, c/<bsp> for native targets
4. c/build-tools moved to tools/build
5. c/src/exec/score/cpu/tools moved to tools/cpu (=cpu-tools split out)
6. c/update-tools moved to tools/update
7. New subdirectory c/src/make, handles files from make/ on a per BSP
basis
8. Maintainer mode support: Ie. if configuring with
--enable-maintainer-mode disabled (the default), then tracking of many
dependencies will be disabled in Makefiles. Esp. many dependencies for
auto* generated files will be switched off in Makefiles. Ie. if not
using "--enable-maintainer-mode" many auto* generated files will not be
updated automatically, i.e. normal users should not be required to have
auto* tools anymore (untested).
9. Independent configuration scripts for / (toplevel), tools/build,
tools/cpu, tools/update, c/, c/src/, c/src/exec, c/src/lib, c/src/tests,
c/src/make
10. Automake support for all directories above and besides c/src
11. "preinstall" now is implemented as depth-first recursive make target
12. host compiled tools (exception bsp-tools) are accessed in location
in the build tree instead of inside the build-tree when building RTEMS.
13. RTEMS_ROOT and PROJECT_ROOT now point to directories inside the
build-tree - many tiny changes as consequence from this.
14. --with-cross-host support removed (offically announced obsolete by
cygnus)
15. Changing the order of building libraries below c/src/lib/
16. Former toplevel configure script broken into aclocal/*.m4 macros
17. Newlib now detected by configure macros, RTEMS_HAS_NEWLIB removed
from *cfg.
18. sptables.h now generated by autoconf
19. Rules for "mkinstalldirs temporary installation tree" moved from
c/Makefile to subdirectories.
20. Cpu-tools do not get installed.
21. FIX: Use ACLOCAL_AMFLAGS instead of ACLOCAL = -I ... in Makefile.ams
which are in directories with own configure scripts.
22. Hardcoding BSP names into libbsp/.../tools to avoid RTEMS_BSP get
overridden from the environment.
22. FIX: Handling of MP_PIECES in various Makefiles
23. FIX: Removing "::" rules from some Makefile.ins
24. FIX: File permission chaos: (-m 444 and -m 555 vs. -m 644 and -m
755) - Now all include files use -m 644.
25. Removed many gnumake-conditionals in Makefile.ins - Partially
replaced with automake-conditional, partially replaced with
conditionalized Makefile variables (... _yes_V)
26. Massively reworked acpolish: acpolish now parses Makefile.ins and
interprets parts of the Makefile.ins.
27. FIX: Some $(wildcard $(srcdir)/*.h) macros removed / replaced with
explicit lists of files in Makefile.ins.
28. FIX: Replacing MKLIB with RANLIB in Makefile.ins
29. HACK: Add preinstallation for pc386 specific
$(PROJECT_RELEASE)/BootImgs directory
... many more details, I can't recall
KNOWN BUGS:
1. make [debug|profile]_install do not do what they are promissing.
"make [debug|profile] install" does what "make [debug|profile]_install"
has been doing. Proposal: remove [debug|profile]_install
2. Dependencies between temporary installation tree and source tree are
not yet handled correctly.
3. Dependencies between temporary installation tree and source tree are
handled ineffencently (Using INSTALL_CHANGE instead of make
dependencies)
4. RTEMS_ROOT, PROJECT_ROOT, top_builddir, RTEMS_TOPdir now are
redundant.
5. The new configure scripts still are in their infancy. They contain
redundant checks and might still contain bugs, too.
6. RTEMS autoconf Makefile.ins use a mixture of configuration
information gathered in c/$(target_alias)/<bsp>/make and of information
collected from their configure scripts.
7. make dist is not fully functional
8. Subdirectory host-/build-/target- configure options (--target,
--host, --build) do not conform to Cygnus/GNU conventions.
9. Some RTEMS autoconf Makefile.in's makefile targets are not supported
in automake Makefile.ams/ins (e.g. get, clobber).
10. Some automake standard targets are not propagated from toplevel and
c/Makefile.am to autoconf subdirectories (eg. make dist).
11. rpcgen generated files are not part of the source-tree (Automake
conventions favor supplying generated files inside the source-tree,
however there is no support for rpcgen generated files in automake, cf.
yacc/lex support in automake).
12. RTEMS_HAS_RDBG handling is flaky. make/*.cfg use RTEMS_HAS_RDBG per
CPU, while librdb's sources can only be built per BSP. Raises the more
general question whether librdbg located correctly in the source-tree.
13. All make/*cfg files are configured per cpu, currently there is no
location to store per-bsp configuration information --> bsp.cfg, per
aconfig.h?
14. "make install" without having run "make all" beforehand does not
work.
15. handling of --enable-multiprocessing seems to be broken in
make/custom/*
16. Makefile.ins still exploit many gmake features.
17. File permisson chaos on libraries (no explict -m for
libraries/rels/etc).
18. mcp750 Makefiles are broken (Note: I *do* mean buggy - I am not
talking about "not-conforming to conventions", here :-).
19. Dependencies between configure scripts are not handled, eg. aborting
"make RTEMS_BSP=<bsp>" can leave the build-tree in an unusable state.
20. "make clean" does not delete <build-tree>/<bsp>. This is intentional
for now, because rerunning "make" after "make clean" requires an
explicit "make preinstall" afterwards now. This should be done
automatically, but doesn't work in this case for now. To work around
this problem <build-tree>/<bsp> is kept during "make clean" for now
(HACK).
TODO:
1. split out host-compiled bsp-tools
2. Use Cygnus/GNU standards for cross-compiling target-subdir
(CC=CC_FOR_TARGET .. configure --host=${target_alias}
--build=`config.guess'}), to be added to toplevel configure script after
splitting out bsp-tools.
3. Exploit per cpu support directory (c/src/<cpu>)- Splitting out
per-cpu libraries - Are there any?
4. Further automake support
5. Converting subdirectories into standalone / self-contained
subdirectories (Esp. moving their headers to the same common root as
their sources, eg. mv lib/include/rtems++
lib/librtems++/include/rtems++) - This is the main obstacle which
prevents moving further towards automake.
6. Propagating values from *.cfg into Makefiles instead of propagating
them at make time via Makefile-fragments (i.e. try to avoid using
*.cfg).
7. Testing on cygwin host (I *do* expect cygwin specific problems).
8. The ARCH in o-$(ARCH)-$(VARIANT) build-subdirectories is not needed
anymore.
GENERAL ISSUES:
1. Temporary installation tree -- Ian and I seem to disagree basically.
Though I think that I understand his argumentation, I do not share it.
IMO, his way of using the buildtree is mis-using the build-tree, relying
on an inofficial feature of RTEMS's current implementation, which
doesn't even work correctly in the current build-tree, though it
attempts hard to do so. From my very POV, it unnecessarily complicates
the structures of the source- and build-trees. It is not supported by
automake (No automatic generation for the necessary rules) and
complicates the transition to automake significantly (Generating the
rules with an enhanced version of acpolish could be possible).
As Ian correctly pointed out, here a management decision is needed -
though I don't see the need to draw this decision in short terms.
2. preinstallation generally is a sure means to spoil the structure of
the source tree, IMHO (No ranting intended, I am completly serious about
this one). eg. through tree dependencies. The worst problem related to
this I have found in the meantime is bsp_specs. bsp_specs is part of
libbsp, ie. there is *no* way to build *any* part of the source tree
*without* having a BSP *preinstalled*.
Note: This issue is related to issue 1., but is not identical - The
difference is the change of the order make rules have to be triggered.
While preinstallation triggers rules spread all over the source tree
before a "make all" can be run, a temporary installation tree could also
be installed by post "make all" hooks (all-local:, to be run after make
all in a directory is completed) if the directories' dependencies would
be a tree,
3. Stuctural dependencies between subdirectories.
4. Depth of the source tree (Prevents multilibbing and introduces many
unnecessary configure scripts).
5. per cpu vs. per bsp configuration (There are no real per-cpu parts
yets :-).
6. automake does not support $makefiles in AC_OUTPUT. Unlike before, we
now should try to avoid RTEMS_CHECK_MAKEFILE and to hard-code as much
paths to Makefiles as possible.
7. General redesign of the source tree
8. Main installation point - Changing it to ${prefix}/${target_alias}. ?
Besides item 8. (which is a must, IMHO), as far as I see most of them
can not be solved soon and will remain issues in the mid- to long-term
:-.
REMARKS:
* You (as the maintainer) should always use --enable-maintainer-mode
when building RTEMS to ensure that maintainer mode generated files (esp.
those in c/src/make) will be updated when make/* files have changed.
* Use @RTEMS_BSP@ in Makefile.ins and Makefile.ams below c/src/,
$(RTEMS_BSP) or ${RTEMS_BSP} will be overridden from environment
variables when using make RTEMS_BSP="....".
* c/src/make is a temporary cludge until configuration issues are
solved. At the moment it is configured per bsp, but contains
per-target/cpu info only. Its main purpose now is to circumvent
modifying make/*.cfg files, because I consider make/* to be frozen for
backward compatibilty.
* This patch should only affect configuration files. At least I do not
remember having touched any source files.
* To build the bare bsp you now need to mention it in --enable-rtemsbsp.
Example: building gensh1 and sh1/bare simultaneously:
../rtems-rc-19990709-1/configure --target=sh-rtems \
--enable-rtemsbsp="bare gensh1" \
--prefix=/tmp/rtems \
--enable-bare-cpu-cflags='-DMHZ=20 -m1
-DCPU_CONSOLE_DEVNAME=\"/dev/null\"' \
--enable-bare-cpu-model=sh7032 \
--enable-maintainer-mode \
--enable-cxx
make
make install
* The next steps in development would be to split out bsp-tools and then
to change to Cygnus/GNU canonicalization conventions for building the c/
subdirectory afterwards (i.e. many standard AC_*.m4 macros could be used
instead of customized versions)
FINAL REMARK:
The issues mentioned in the lists above sound much worser than the
situation actually is. Most of them are not specific to this patch, but
are also valid for the snapshot. I just wrote down what I came across
when working on the patch over the last few weeks.
I wouldn't be too surprised if you don't like the patch at the current
point in development. I am willing to discuss details and problems, I
also have no problem if you would post-pone applying this patch to times
after 4.1, but rejecting it as a whole for all times would be a false
management decision, IMHO.
Therefore I would suggest that you, if your time constaints allow it,
should at least play a little while with this patch to understand what
is going on and before drawing a decision on how to handle this
proposal. I know this patch is neither perfect nor complete, but I
consider it to be a major breakthrough. Don't be anxious because of the
size of the patch, the core of the patch is rather small, the size is
mainly the side effect of some systematic cleanups inside the Makefiles
(result of acpolish).
Feel free to ask if you encounter problems, if you don't understand
something or if you meet bugs - I am far from being perfect and am
prepared to answer them.
Ralf.
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999
http://www.faw.uni-ulm.de
to move RTEMS more to automake/autoconf and GNU compliance.
Finally, here they are: the "big-patch" patches - merged into one big
patch (~1.5MB).
Sorry for the delay, but testing took much more time than I had expected
- esp. reworking the acpolish script triggered many more tiny issues
than I had expected (cf. below).
At least, now you've got something to spend your weekend with :-.
WARNINGS:
* I've gone a little (??) further than I had announced before.
* Several directories have been moved.
* Several files have been added and removed
* I have tested it with many BSPs/CPUs and a variety of permutiations of
configuration flags, but not with all.
* Most parts of the patch are automatically generated, however there are
many tiny manual modifications.
APPLYING THE PATCH:
./autogen -c
mkdir tools
mv c/src/exec/score/tools tools/cpu
mv c/build-tools tools/build
mv c/update-tools tools/update
patch -p1 -E < rtems-rc-19990709-0.diff
./autogen
If the patch doesn't apply to rtems-cvs, I would suggest that you should
try to apply it brute-force and then to run tools/update/rtems-polish.sh
-ac -am afterwards. A recursive diff between rtems-19990709 + patch and
rtems-cvs + patch then should report only a few dozen significant
changes to configuration files which need to be merged manually (IIRC, I
did not change any source files).
*** Attention: There are files to be removed, moved, copied and added
in/to CVS!
NEWS/CHANGES:
1. Configuration takes place in 3 stages: 1. per host (toplevel
configure script), 2. per target (c/configure), 3. per bsp
c/src/configure automatically triggered from ./configure and
c/Makefile.am.
2. Building of subdirectory c/ takes place in c/$(target_alias) for
cross-targets in c/ for native targets
3. Building of subdirectory c/src takes place in c/${target_alias}/<bsp>
for cross-targets, c/<bsp> for native targets
4. c/build-tools moved to tools/build
5. c/src/exec/score/cpu/tools moved to tools/cpu (=cpu-tools split out)
6. c/update-tools moved to tools/update
7. New subdirectory c/src/make, handles files from make/ on a per BSP
basis
8. Maintainer mode support: Ie. if configuring with
--enable-maintainer-mode disabled (the default), then tracking of many
dependencies will be disabled in Makefiles. Esp. many dependencies for
auto* generated files will be switched off in Makefiles. Ie. if not
using "--enable-maintainer-mode" many auto* generated files will not be
updated automatically, i.e. normal users should not be required to have
auto* tools anymore (untested).
9. Independent configuration scripts for / (toplevel), tools/build,
tools/cpu, tools/update, c/, c/src/, c/src/exec, c/src/lib, c/src/tests,
c/src/make
10. Automake support for all directories above and besides c/src
11. "preinstall" now is implemented as depth-first recursive make target
12. host compiled tools (exception bsp-tools) are accessed in location
in the build tree instead of inside the build-tree when building RTEMS.
13. RTEMS_ROOT and PROJECT_ROOT now point to directories inside the
build-tree - many tiny changes as consequence from this.
14. --with-cross-host support removed (offically announced obsolete by
cygnus)
15. Changing the order of building libraries below c/src/lib/
16. Former toplevel configure script broken into aclocal/*.m4 macros
17. Newlib now detected by configure macros, RTEMS_HAS_NEWLIB removed
from *cfg.
18. sptables.h now generated by autoconf
19. Rules for "mkinstalldirs temporary installation tree" moved from
c/Makefile to subdirectories.
20. Cpu-tools do not get installed.
21. FIX: Use ACLOCAL_AMFLAGS instead of ACLOCAL = -I ... in Makefile.ams
which are in directories with own configure scripts.
22. Hardcoding BSP names into libbsp/.../tools to avoid RTEMS_BSP get
overridden from the environment.
22. FIX: Handling of MP_PIECES in various Makefiles
23. FIX: Removing "::" rules from some Makefile.ins
24. FIX: File permission chaos: (-m 444 and -m 555 vs. -m 644 and -m
755) - Now all include files use -m 644.
25. Removed many gnumake-conditionals in Makefile.ins - Partially
replaced with automake-conditional, partially replaced with
conditionalized Makefile variables (... _yes_V)
26. Massively reworked acpolish: acpolish now parses Makefile.ins and
interprets parts of the Makefile.ins.
27. FIX: Some $(wildcard $(srcdir)/*.h) macros removed / replaced with
explicit lists of files in Makefile.ins.
28. FIX: Replacing MKLIB with RANLIB in Makefile.ins
29. HACK: Add preinstallation for pc386 specific
$(PROJECT_RELEASE)/BootImgs directory
... many more details, I can't recall
KNOWN BUGS:
1. make [debug|profile]_install do not do what they are promissing.
"make [debug|profile] install" does what "make [debug|profile]_install"
has been doing. Proposal: remove [debug|profile]_install
2. Dependencies between temporary installation tree and source tree are
not yet handled correctly.
3. Dependencies between temporary installation tree and source tree are
handled ineffencently (Using INSTALL_CHANGE instead of make
dependencies)
4. RTEMS_ROOT, PROJECT_ROOT, top_builddir, RTEMS_TOPdir now are
redundant.
5. The new configure scripts still are in their infancy. They contain
redundant checks and might still contain bugs, too.
6. RTEMS autoconf Makefile.ins use a mixture of configuration
information gathered in c/$(target_alias)/<bsp>/make and of information
collected from their configure scripts.
7. make dist is not fully functional
8. Subdirectory host-/build-/target- configure options (--target,
--host, --build) do not conform to Cygnus/GNU conventions.
9. Some RTEMS autoconf Makefile.in's makefile targets are not supported
in automake Makefile.ams/ins (e.g. get, clobber).
10. Some automake standard targets are not propagated from toplevel and
c/Makefile.am to autoconf subdirectories (eg. make dist).
11. rpcgen generated files are not part of the source-tree (Automake
conventions favor supplying generated files inside the source-tree,
however there is no support for rpcgen generated files in automake, cf.
yacc/lex support in automake).
12. RTEMS_HAS_RDBG handling is flaky. make/*.cfg use RTEMS_HAS_RDBG per
CPU, while librdb's sources can only be built per BSP. Raises the more
general question whether librdbg located correctly in the source-tree.
13. All make/*cfg files are configured per cpu, currently there is no
location to store per-bsp configuration information --> bsp.cfg, per
aconfig.h?
14. "make install" without having run "make all" beforehand does not
work.
15. handling of --enable-multiprocessing seems to be broken in
make/custom/*
16. Makefile.ins still exploit many gmake features.
17. File permisson chaos on libraries (no explict -m for
libraries/rels/etc).
18. mcp750 Makefiles are broken (Note: I *do* mean buggy - I am not
talking about "not-conforming to conventions", here :-).
19. Dependencies between configure scripts are not handled, eg. aborting
"make RTEMS_BSP=<bsp>" can leave the build-tree in an unusable state.
20. "make clean" does not delete <build-tree>/<bsp>. This is intentional
for now, because rerunning "make" after "make clean" requires an
explicit "make preinstall" afterwards now. This should be done
automatically, but doesn't work in this case for now. To work around
this problem <build-tree>/<bsp> is kept during "make clean" for now
(HACK).
TODO:
1. split out host-compiled bsp-tools
2. Use Cygnus/GNU standards for cross-compiling target-subdir
(CC=CC_FOR_TARGET .. configure --host=${target_alias}
--build=`config.guess'}), to be added to toplevel configure script after
splitting out bsp-tools.
3. Exploit per cpu support directory (c/src/<cpu>)- Splitting out
per-cpu libraries - Are there any?
4. Further automake support
5. Converting subdirectories into standalone / self-contained
subdirectories (Esp. moving their headers to the same common root as
their sources, eg. mv lib/include/rtems++
lib/librtems++/include/rtems++) - This is the main obstacle which
prevents moving further towards automake.
6. Propagating values from *.cfg into Makefiles instead of propagating
them at make time via Makefile-fragments (i.e. try to avoid using
*.cfg).
7. Testing on cygwin host (I *do* expect cygwin specific problems).
8. The ARCH in o-$(ARCH)-$(VARIANT) build-subdirectories is not needed
anymore.
GENERAL ISSUES:
1. Temporary installation tree -- Ian and I seem to disagree basically.
Though I think that I understand his argumentation, I do not share it.
IMO, his way of using the buildtree is mis-using the build-tree, relying
on an inofficial feature of RTEMS's current implementation, which
doesn't even work correctly in the current build-tree, though it
attempts hard to do so. From my very POV, it unnecessarily complicates
the structures of the source- and build-trees. It is not supported by
automake (No automatic generation for the necessary rules) and
complicates the transition to automake significantly (Generating the
rules with an enhanced version of acpolish could be possible).
As Ian correctly pointed out, here a management decision is needed -
though I don't see the need to draw this decision in short terms.
2. preinstallation generally is a sure means to spoil the structure of
the source tree, IMHO (No ranting intended, I am completly serious about
this one). eg. through tree dependencies. The worst problem related to
this I have found in the meantime is bsp_specs. bsp_specs is part of
libbsp, ie. there is *no* way to build *any* part of the source tree
*without* having a BSP *preinstalled*.
Note: This issue is related to issue 1., but is not identical - The
difference is the change of the order make rules have to be triggered.
While preinstallation triggers rules spread all over the source tree
before a "make all" can be run, a temporary installation tree could also
be installed by post "make all" hooks (all-local:, to be run after make
all in a directory is completed) if the directories' dependencies would
be a tree,
3. Stuctural dependencies between subdirectories.
4. Depth of the source tree (Prevents multilibbing and introduces many
unnecessary configure scripts).
5. per cpu vs. per bsp configuration (There are no real per-cpu parts
yets :-).
6. automake does not support $makefiles in AC_OUTPUT. Unlike before, we
now should try to avoid RTEMS_CHECK_MAKEFILE and to hard-code as much
paths to Makefiles as possible.
7. General redesign of the source tree
8. Main installation point - Changing it to ${prefix}/${target_alias}. ?
Besides item 8. (which is a must, IMHO), as far as I see most of them
can not be solved soon and will remain issues in the mid- to long-term
:-.
REMARKS:
* You (as the maintainer) should always use --enable-maintainer-mode
when building RTEMS to ensure that maintainer mode generated files (esp.
those in c/src/make) will be updated when make/* files have changed.
* Use @RTEMS_BSP@ in Makefile.ins and Makefile.ams below c/src/,
$(RTEMS_BSP) or ${RTEMS_BSP} will be overridden from environment
variables when using make RTEMS_BSP="....".
* c/src/make is a temporary cludge until configuration issues are
solved. At the moment it is configured per bsp, but contains
per-target/cpu info only. Its main purpose now is to circumvent
modifying make/*.cfg files, because I consider make/* to be frozen for
backward compatibilty.
* This patch should only affect configuration files. At least I do not
remember having touched any source files.
* To build the bare bsp you now need to mention it in --enable-rtemsbsp.
Example: building gensh1 and sh1/bare simultaneously:
../rtems-rc-19990709-1/configure --target=sh-rtems \
--enable-rtemsbsp="bare gensh1" \
--prefix=/tmp/rtems \
--enable-bare-cpu-cflags='-DMHZ=20 -m1
-DCPU_CONSOLE_DEVNAME=\"/dev/null\"' \
--enable-bare-cpu-model=sh7032 \
--enable-maintainer-mode \
--enable-cxx
make
make install
* The next steps in development would be to split out bsp-tools and then
to change to Cygnus/GNU canonicalization conventions for building the c/
subdirectory afterwards (i.e. many standard AC_*.m4 macros could be used
instead of customized versions)
FINAL REMARK:
The issues mentioned in the lists above sound much worser than the
situation actually is. Most of them are not specific to this patch, but
are also valid for the snapshot. I just wrote down what I came across
when working on the patch over the last few weeks.
I wouldn't be too surprised if you don't like the patch at the current
point in development. I am willing to discuss details and problems, I
also have no problem if you would post-pone applying this patch to times
after 4.1, but rejecting it as a whole for all times would be a false
management decision, IMHO.
Therefore I would suggest that you, if your time constaints allow it,
should at least play a little while with this patch to understand what
is going on and before drawing a decision on how to handle this
proposal. I know this patch is neither perfect nor complete, but I
consider it to be a major breakthrough. Don't be anxious because of the
size of the patch, the core of the patch is rather small, the size is
mainly the side effect of some systematic cleanups inside the Makefiles
(result of acpolish).
Feel free to ask if you encounter problems, if you don't understand
something or if you meet bugs - I am far from being perfect and am
prepared to answer them.
Ralf.
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:corsepiu@faw.uni-ulm.de FAX: +49/731/501-999
http://www.faw.uni-ulm.de
I get the following warning when compiling the latest snapshot. I had
a quick look at the source -- it certainly looks to me like this is a
real bug.
../../../../src/rtems-19990709/c/src/lib/libc/mount.c:97: warning:
`options' might be used uninitialized in this function
Also, I changed the TFTP test program and TFTP driver to reflect the
changes in the way paths are passed to the TFTP driver. The TFTP driver
now needs a proper `dotted-decimal' hostname as the second component of
the path name.
- The same bug fix that was done on pc386 to prevent interrupt
from occuring (never experienced it but who knows as I have 8259
emulation :()
- Removed every compiler warning (except wrong ones and ones I can't do
anything).
- Removed any libc available code in code linked with mcp750 rtems
executbale. Unfortunately using newlib functions for linking the
bootloader does not work as the compilation options in bootloader
(-mrelocatable -fixed-r13) are not compatible with newlib options.
=> I have put any libc external reference in one single new file (lib.c)
that is linked only with the boot loader. Removing the file from
${OBJ} and using -lc crash the bootloader. Added big warning...
boot_card() and main() into separate files to ease configuration
of other packages. This was a big step in the way to build TCL,
ncurses, and zlib for RTEMS.
-- configure now fails to detect the toolchain for linux-posix.
As work-around, I have reverted to the old behavior of RTEMS_TARGET_CPU_NAME,
thus no_cpu/no_bsp will fail badly in configure again.
> When I run my script that just repeatedly builds different targets, some
> of them die with an error like this:
>
> Making all RTEMS_BSP=gen68360 in cpugmake[5]: Entering directory
> `/usr1/rtems/build/build-m68k-rtems/c/src/exec/score/cpu'
> Making all RTEMS_BSP=gen68360 in @RTEMS_CPU@
> /bin/sh: @RTEMS_CPU@: No such file or directory
> gmake[5]: *** [all] Error 1
> gmake[5]: Leaving directory
> `/usr1/rtems/build/build-m68k-rtems/c/src/exec/score/cpu'
>
> It is not always the same variable substitution that fails. Sometimes it
> is @INSTALL@. But reliably, it is a variable substitution that is
> failing.
>
> Do you have any idea why this happens?
Yep, I think I know what's going on.
AC_SUBST(RTEMS_CPU) is missing in configure.ins, thus @RTEMS_CPU@ in
target.cfg.in doesn't get substituted correctly, causing the bug above. Due
to the redundancy of RTEMS_CPU, other most BSPs don't seem to be affected.
Other similar problems probably exist for the unix/posix bsp and the hppa.1
cpu, because their */tools/*Makefile.ams require RTEMS_CPU, too.
This patch should fix the nastiest configuration bugs for no_cpu/no_bsp.
With this patch applied, configure --target=no_cpu-rtems now correctly
acknowledges its configuration, but later fails building when trying to
build libcsupport (I leave this problem for you :-).
Fixes/Changes:
* aclocal/canonicalize-target-name.m4: use RTEMS_CPU instead of
target_cpu, switch to a native compiler setup if target = no_cpu*rtems,
ie. implicitly use host=target (native) and RTEMS_CPU=no_cpu for
--target=no_cpu*rtems.
* add no_bsp/bsp_specs (Support -qrtems, -qrtems_debug; please check
before adding :-)
* Use RTEMS_CANONICALIZE_TARGET_CPU instead of AC_CANONICAL_SYSTEM in
toplevel/configure.in
* All references to $target_cpu in aclocal/*.m4, Makefile.ins and *.cfg
files changed to RTEMS_CPU
* bug fixes to exec/score/cpu/no_cpu/wrap (This part of the patch may
result into patch rejections, because your recently posted patch may
also have addressed this problem).
After applying this patch, please do:
cvs add c/src/lib/libbsp/no_cpu/no_bsp/bsp_specs
./autogen
* RTEMS_CPU for score603e should be "powerpc" instead of "ppc" (Should
not have any side-effects, because RTEMS_CPU in make/custom/*.cfg
already is overridden in make/target.cfg.in)
* Use $(PACKHEX) instead of $(PROJECT_TOOLS)/packhex
<corsepiu@faw.uni-ulm.de>:
This patch removes MKDIR from RTEMS source tree and fixes another small
bug in the definition of INSTALL_VARIANT (cf. to the patch itself for
details, it should be self-explanatory)
After applying the patch please do:
cvs rm aclocal/mkdir.m4
./autogen
described in the message following this paragraph. This patch also includes
a mcp750 BSP.
From valette@crf.canon.fr Mon Jun 14 10:03:08 1999
Date: Tue, 18 May 1999 01:30:14 +0200 (CEST)
From: VALETTE Eric <valette@crf.canon.fr>
To: joel@oarcorp.com
Cc: raguet@crf.canon.fr, rtems-snapshots@oarcorp.com, valette@crf.canon.fr
Subject: Questions/Suggestion regarding RTEMS PowerPC code (long)
Dear knowledgeable RTEMS powerpc users,
As some of you may know, I'm currently finalizing a port
of RTEMS on a MCP750 Motorola board. I have done most
of it but have some questions to ask before submitting
the port.
In order to understand some of the changes I have made
or would like to make, maybe it is worth describing the
MCP750 Motorola board.
the MCP750 is a COMPACT PCI powerpc board with :
1) a MPC750 233 MHz processor,
2) a raven bus bridge/PCI controller that
implement an OPENPIC compliant interrupt controller,
3) a VIA 82C586 PCI/ISA bridge that offers a PC
compliant IO for keyboard, serial line, IDE, and
the well known PC 8259 cascaded PIC interrupt
architecture model,
4) a DEC 21140 Ethernet controller,
5) the PPCBUG Motorola firmware in flash,
6) A DEC PCI bridge,
This architecture is common to most Motorola 60x/7xx
board except that :
1) on VME board, the DEC PCI bridge is replaced by
a VME chipset,
2) the VIA 82C586 PCI/ISA bridge is replaced by
another bridge that is almost fully compatible
with the via bridge...
So the port should be a rather close basis for many
60x/7xx motorola board...
On this board, I already have ported Linux 2.2.3 and
use it both as a development and target board.
Now the questions/suggestions I have :
1) EXCEPTION CODE
-------------------
As far as I know exceptions on PPC are handled like
interrupts. I dislike this very much as :
a) Except for the decrementer exception (and
maybe some other on mpc8xx), exceptions are
not recoverable and the handler just need to print
the full context and go to the firmware or debugger...
b) The interrupt switch is only necessary for the
decrementer and external interrupt (at least on
6xx,7xx).
c) The full context for exception is never saved and
thus cannot be used by debugger... I do understand
the most important for interrupts low level code
is to save the minimal context enabling to call C
code for performance reasons. On non recoverable
exception on the other hand, the most important is
to save the maximum information concerning proc status
in order to analyze the reason of the fault. At
least we will need this in order to implement the
port of RGDB on PPC
==> I wrote an API for connecting raw exceptions (and thus
raw interrupts) for mpc750. It should be valid for most
powerpc processors... I hope to find a way to make this coexist
with actual code layout. The code is actually located
in lib/libcpu/powerpc/mpc750 and is thus optional
(provided I write my own version of exec/score/cpu/powerpc/cpu.c ...)
See remark about files/directory layout organization in 4)
2) Current Implementation of ISR low level code
-----------------------------------------------
I do not understand why the MSR EE flags is cleared
again in exec/score/cpu/powerpc/irq_stubs.S
#if (PPC_USE_SPRG)
mfmsr r5
mfspr r6, sprg2
#else
lwz r6,msr_initial(r11)
lis r5,~PPC_MSR_DISABLE_MASK@ha
ori r5,r5,~PPC_MSR_DISABLE_MASK@l
and r6,r6,r5
mfmsr r5
#endif
Reading the doc, when a decrementer interrupt or an
external interrupt is active, the MSR EE flag is already
cleared. BTW if exception/interrupt could occur, it would
trash SRR0 and SRR1. In fact the code may be useful to set
MSR[RI] that re-enables exception processing. BTW I will need
to set other value in MSR to handle interrupts :
a) I want the MSR[IR] and MSR[DR] to be set for
performance reasons and also because I need DBAT
support to have access to PCI memory space as the
interrupt controller is in the PCI space.
Reading the code, I see others have the same kind of request :
/* SCE 980217
*
* We need address translation ON when we call our ISR routine
mtmsr r5
*/
This is just another prof that even the lowest level
IRQ code is fundamentally board dependent and
not simply processor dependent especially when
the processor use external interrupt controller
because it has a single interrupt request line...
Note that if you look at the PPC code high level interrupt
handling code, as the "set_vector" routine that really connects
the interrupt is in the BSP/startup/genpvec.c,
the fact that IRQ handling is BSP specific is DE-FACTO
acknowledged.
I know I have already expressed this and understand that this
would require some heavy change in the code but believe
me you will reach a point where you will not be able
to find a compatible while optimum implementation for low level
interrupt handling code...) In my case this is already true...
So please consider removing low level IRQ handling from
exec/score/cpu/* and only let there exception handling code...
Exceptions are usually only processor dependent and do
not depend on external hardware mechanism to be masked or
acknowledged or re-enabled (there are probably exception but ...)
I have already done this for pc386 bsp but need to make it again.
This time I will even propose an API.
3) R2/R13 manipulation for EABI implementation
----------------------------------------------
I do not understand the handling of r2 and r13 in the
EABI case. The specification for r2 says pointer to sdata2,
sbss2 section => constant. However I do not see -ffixed-r2
passed to any compilation system in make/custom/*
(for info linux does this on PPC).
So either this is a default compiler option when choosing
powerpc-rtems and thus we do not need to do anything with
this register as all the code is compiled with this compiler
and linked together OR this register may be used by rtems code
and then we do not need any special initialization or
handling.
The specification for r13 says pointer to the small data
area. r13 argumentation is the same except that as far
as I know the usage of the small data area requires
specific compiler support so that access to variables is
compiled via loading the LSB in a register and then
using r13 to get full address... It is like a small
memory model and it was present in IBM C compilers.
=> I propose to suppress any specific code for r2 and
r13 in the EABI case.
4) Code layout organization (yes again :-))
-------------------------------------------
I think there are a number of design flaws in the way
the code is for ppc organized and I will try to point them out.
I have been beaten by this again on this new port, and
was beaten last year while modifying code for pc386.
a) exec/score/cpu/* vs lib/libcpu/cpu/*.
I think that too many things are put in exec/score/cpu that
have nothing to do with RTEMS internals but are rather
related to CPU feature.
This include at least :
a) registers access routine (e.g GET_MSR_Value),
b) interrupt masking/unmasking routines,
c) cache_mngt_routine,
d) mmu_mngt_routine,
e) Routines to connect the raw_exception, raw_interrupt
handler,
b) lib/libcpu/cpu/powerpc/*
With a processor family as exuberant as the powerpc family,
and their well known subtle differences (604 vs 750) or
unfortunately majors (8xx vs 60x) the directory structure
is fine (except maybe the names that are not homogeneous)
powerpc
ppc421 mpc821 ...
I only needed to add mpc750. But the fact that libcpu.a was not
produced was a pain and the fact that this organization may
duplicates code is also problematic.
So, except if the support of automake provides a better solution
I would like to propose something like this :
powerpc
mpc421 mpc821 ... mpc750 shared wrapup
with the following rules :
a) "shared" would act as a source container for sources that may
be shared among processors. Needed files would be compiled inside
the processor specific directory using the vpath Makefile
mechanism. "shared" may also contain compilation code
for routine that are really shared and not worth to inline...
(did not found many things so far as registers access routine
ARE WORTH INLINING)... In the case something is compiled there,
it should create libcpushared.a
b) layout under processor specific directory is free provided
that
1)the result of the compilation process exports :
libcpu/powerpc/"PROC"/*.h in $(PROJECT_INCLUDE)/libcpu
2) each processor specific directory creates
a library called libcpuspecific.a
Note that this organization enables to have a file that
is nearly the same than in shared but that must differ
because of processor differences...
c) "wrapup" should create libcpu.a using libcpushared.a
libcpuspecific.a and export it $(PROJECT_INCLUDE)/libcpu
The only thing I have no ideal solution is the way to put shared
definitions in "shared" and only processor specific definition
in "proc". To give a concrete example, most MSR bit definition
are shared among PPC processors and only some differs. if we create
a single msr.h in shared it will have ifdef. If in msr.h we
include libcpu/msr_c.h we will need to have it in each prowerpc
specific directory (even empty). Opinions are welcomed ...
Note that a similar mechanism exist in libbsp/i386 that also
contains a shared directory that is used by several bsp
like pc386 and i386ex and a similar wrapup mechanism...
NB: I have done this for mpc750 and other processors could just use
similar Makefiles...
c) The exec/score/cpu/powerpc directory layout.
I think the directory layout should be the same than the
libcpu/powerpc. As it is not, there are a lot of ifdefs
inside the code... And of course low level interrupt handling
code should be removed...
Besides that I do not understand why
1) things are compiled in the wrap directory,
2) some includes are moved to rtems/score,
I think the "preinstall" mechanism enables to put
everything in the current directory (or better in a per processor
directory),
5) Interrupt handling API
-------------------------
Again :-). But I think that using all the features the PIC
offers is a MUST for RT system. I already explained in the
prologue of this (long and probably boring) mail that the MCP750
boards offers an OPENPIC compliant architecture and that
the VIA 82586 PCI/ISA bridge offers a PC compatible IO and
PIC mapping. Here is a logical view of the RAVEN/VIA 82586
interrupt mapping :
--------- 0 ------
| OPEN | <-----|8259|
| PIC | | | 2 ------
|(RAVEN)| | | <-----|8259|
| | | | | | 11
| | | | | | <----
| | | | | |
| | | | | |
--------- ------ | |
^ ------
| VIA PCI/ISA bridge
| x
-------- PCI interrupts
OPENPIC offers interrupt priorities among PCI interrupts
and interrupt selective masking. The 8259 offers the same kind
of feature. With actual powerpc interrupt code :
1) there is no way to specify priorities among
interrupts handler. This is REALLY a bad thing.
For me it is as importnat as having priorities
for threads...
2) for my implementation, each ISR should
contain the code that acknowledge the RAVEN
and 8259 cascade, modify interrupt mask on both
chips, and reenable interrupt at processor level,
..., restore then on interrupt return,.... This code
is actually similar to code located in some
genpvec.c powerpc files,
3) I must update _ISR_Nesting_level because
irq.inl use it...
4) the libchip code connects the ISR via set_vector
but the libchip handler code does not contain any code to
manipulate external interrupt controller hardware
in order to acknoledge the interrupt or re-enable
them (except for the target hardware of course)
So this code is broken unless set_vector adds an
additionnal prologue/epilogue before calling/returning
from in order to acknoledge/mask the raven and the
8259 PICS... => Anyway already EACH BSP MUST REWRITE
PART OF INTERRUPT HANDLING CODE TO CORRECTLY IMPLEMENT
SET_VECTOR.
I would rather offer an API similar to the one provided
in libbsp/i386/shared/irq/irq.h so that :
1) Once the driver supplied methods is called the
only things the ISR has to do is to worry about the
external hardware that triggered the interrupt.
Everything on openpic/VIA/processor would have been
done by the low levels (same things as set-vector)
2) The caller will need to supply the on/off/isOn
routine that are fundamental to correctly implements
debuggers/performance monitoring is a portable way
3) A globally configurable interrupt priorities
mechanism...
I have nothing against providing a compatible
set_vector just to make libchip happy but
as I have already explained in other
mails (months ago), I really think that the ISR
connection should be handled by the BSP and that no
code containing irq connection should exist the
rtems generic layers... Thus I really dislike
libchip on this aspect because in a long term
it will force to adopt the less reach API
for interrupt handling that exists (set_vector).
Additional note : I think the _ISR_Is_in_progress()
inline routine should be :
1) Put in a processor specific section,
2) Should not rely on a global variable,
As :
a) on symmetric MP, there is one interrupt level
per CPU,
b) On processor that have an ISP (e,g 68040),
this variable is useless (MSR bit testing could
be used)
c) On PPC, instead of using the address of the
variable via __CPU_IRQ_info.Nest_level a dedicated
SPR could be used.
NOTE: most of this is also true for _Thread_Dispatch_disable_level
END NOTE
--------
Please do not take what I said in the mail as a criticism for
anyone who submitted ppc code. Any code present helped me
a lot understanding PPC behavior. I just wanted by this
mail to :
1) try to better understand the actual code,
2) propose concrete ways of enhancing current code
by providing an alternative implementation for MCP750. I
will make my best effort to try to brake nothing but this
is actually hard due to the file layout organisation.
3) make understandable some changes I will probably make
if joel let me do them :-)
Any comments/objections are welcomed as usual.
--
__
/ ` Eric Valette
/-- __ o _. Canon CRF
(___, / (_(_(__ Rue de la touche lambert
35517 Cesson-Sevigne Cedex
FRANCE
Tel: +33 (0)2 99 87 68 91 Fax: +33 (0)2 99 84 11 30
E-mail: valette@crf.canon.fr
described in the message following this paragraph. This patch also includes
a mcp750 BSP.
From valette@crf.canon.fr Mon Jun 14 10:03:08 1999
Date: Tue, 18 May 1999 01:30:14 +0200 (CEST)
From: VALETTE Eric <valette@crf.canon.fr>
To: joel@oarcorp.com
Cc: raguet@crf.canon.fr, rtems-snapshots@oarcorp.com, valette@crf.canon.fr
Subject: Questions/Suggestion regarding RTEMS PowerPC code (long)
Dear knowledgeable RTEMS powerpc users,
As some of you may know, I'm currently finalizing a port
of RTEMS on a MCP750 Motorola board. I have done most
of it but have some questions to ask before submitting
the port.
In order to understand some of the changes I have made
or would like to make, maybe it is worth describing the
MCP750 Motorola board.
the MCP750 is a COMPACT PCI powerpc board with :
1) a MPC750 233 MHz processor,
2) a raven bus bridge/PCI controller that
implement an OPENPIC compliant interrupt controller,
3) a VIA 82C586 PCI/ISA bridge that offers a PC
compliant IO for keyboard, serial line, IDE, and
the well known PC 8259 cascaded PIC interrupt
architecture model,
4) a DEC 21140 Ethernet controller,
5) the PPCBUG Motorola firmware in flash,
6) A DEC PCI bridge,
This architecture is common to most Motorola 60x/7xx
board except that :
1) on VME board, the DEC PCI bridge is replaced by
a VME chipset,
2) the VIA 82C586 PCI/ISA bridge is replaced by
another bridge that is almost fully compatible
with the via bridge...
So the port should be a rather close basis for many
60x/7xx motorola board...
On this board, I already have ported Linux 2.2.3 and
use it both as a development and target board.
Now the questions/suggestions I have :
1) EXCEPTION CODE
-------------------
As far as I know exceptions on PPC are handled like
interrupts. I dislike this very much as :
a) Except for the decrementer exception (and
maybe some other on mpc8xx), exceptions are
not recoverable and the handler just need to print
the full context and go to the firmware or debugger...
b) The interrupt switch is only necessary for the
decrementer and external interrupt (at least on
6xx,7xx).
c) The full context for exception is never saved and
thus cannot be used by debugger... I do understand
the most important for interrupts low level code
is to save the minimal context enabling to call C
code for performance reasons. On non recoverable
exception on the other hand, the most important is
to save the maximum information concerning proc status
in order to analyze the reason of the fault. At
least we will need this in order to implement the
port of RGDB on PPC
==> I wrote an API for connecting raw exceptions (and thus
raw interrupts) for mpc750. It should be valid for most
powerpc processors... I hope to find a way to make this coexist
with actual code layout. The code is actually located
in lib/libcpu/powerpc/mpc750 and is thus optional
(provided I write my own version of exec/score/cpu/powerpc/cpu.c ...)
See remark about files/directory layout organization in 4)
2) Current Implementation of ISR low level code
-----------------------------------------------
I do not understand why the MSR EE flags is cleared
again in exec/score/cpu/powerpc/irq_stubs.S
#if (PPC_USE_SPRG)
mfmsr r5
mfspr r6, sprg2
#else
lwz r6,msr_initial(r11)
lis r5,~PPC_MSR_DISABLE_MASK@ha
ori r5,r5,~PPC_MSR_DISABLE_MASK@l
and r6,r6,r5
mfmsr r5
#endif
Reading the doc, when a decrementer interrupt or an
external interrupt is active, the MSR EE flag is already
cleared. BTW if exception/interrupt could occur, it would
trash SRR0 and SRR1. In fact the code may be useful to set
MSR[RI] that re-enables exception processing. BTW I will need
to set other value in MSR to handle interrupts :
a) I want the MSR[IR] and MSR[DR] to be set for
performance reasons and also because I need DBAT
support to have access to PCI memory space as the
interrupt controller is in the PCI space.
Reading the code, I see others have the same kind of request :
/* SCE 980217
*
* We need address translation ON when we call our ISR routine
mtmsr r5
*/
This is just another prof that even the lowest level
IRQ code is fundamentally board dependent and
not simply processor dependent especially when
the processor use external interrupt controller
because it has a single interrupt request line...
Note that if you look at the PPC code high level interrupt
handling code, as the "set_vector" routine that really connects
the interrupt is in the BSP/startup/genpvec.c,
the fact that IRQ handling is BSP specific is DE-FACTO
acknowledged.
I know I have already expressed this and understand that this
would require some heavy change in the code but believe
me you will reach a point where you will not be able
to find a compatible while optimum implementation for low level
interrupt handling code...) In my case this is already true...
So please consider removing low level IRQ handling from
exec/score/cpu/* and only let there exception handling code...
Exceptions are usually only processor dependent and do
not depend on external hardware mechanism to be masked or
acknowledged or re-enabled (there are probably exception but ...)
I have already done this for pc386 bsp but need to make it again.
This time I will even propose an API.
3) R2/R13 manipulation for EABI implementation
----------------------------------------------
I do not understand the handling of r2 and r13 in the
EABI case. The specification for r2 says pointer to sdata2,
sbss2 section => constant. However I do not see -ffixed-r2
passed to any compilation system in make/custom/*
(for info linux does this on PPC).
So either this is a default compiler option when choosing
powerpc-rtems and thus we do not need to do anything with
this register as all the code is compiled with this compiler
and linked together OR this register may be used by rtems code
and then we do not need any special initialization or
handling.
The specification for r13 says pointer to the small data
area. r13 argumentation is the same except that as far
as I know the usage of the small data area requires
specific compiler support so that access to variables is
compiled via loading the LSB in a register and then
using r13 to get full address... It is like a small
memory model and it was present in IBM C compilers.
=> I propose to suppress any specific code for r2 and
r13 in the EABI case.
4) Code layout organization (yes again :-))
-------------------------------------------
I think there are a number of design flaws in the way
the code is for ppc organized and I will try to point them out.
I have been beaten by this again on this new port, and
was beaten last year while modifying code for pc386.
a) exec/score/cpu/* vs lib/libcpu/cpu/*.
I think that too many things are put in exec/score/cpu that
have nothing to do with RTEMS internals but are rather
related to CPU feature.
This include at least :
a) registers access routine (e.g GET_MSR_Value),
b) interrupt masking/unmasking routines,
c) cache_mngt_routine,
d) mmu_mngt_routine,
e) Routines to connect the raw_exception, raw_interrupt
handler,
b) lib/libcpu/cpu/powerpc/*
With a processor family as exuberant as the powerpc family,
and their well known subtle differences (604 vs 750) or
unfortunately majors (8xx vs 60x) the directory structure
is fine (except maybe the names that are not homogeneous)
powerpc
ppc421 mpc821 ...
I only needed to add mpc750. But the fact that libcpu.a was not
produced was a pain and the fact that this organization may
duplicates code is also problematic.
So, except if the support of automake provides a better solution
I would like to propose something like this :
powerpc
mpc421 mpc821 ... mpc750 shared wrapup
with the following rules :
a) "shared" would act as a source container for sources that may
be shared among processors. Needed files would be compiled inside
the processor specific directory using the vpath Makefile
mechanism. "shared" may also contain compilation code
for routine that are really shared and not worth to inline...
(did not found many things so far as registers access routine
ARE WORTH INLINING)... In the case something is compiled there,
it should create libcpushared.a
b) layout under processor specific directory is free provided
that
1)the result of the compilation process exports :
libcpu/powerpc/"PROC"/*.h in $(PROJECT_INCLUDE)/libcpu
2) each processor specific directory creates
a library called libcpuspecific.a
Note that this organization enables to have a file that
is nearly the same than in shared but that must differ
because of processor differences...
c) "wrapup" should create libcpu.a using libcpushared.a
libcpuspecific.a and export it $(PROJECT_INCLUDE)/libcpu
The only thing I have no ideal solution is the way to put shared
definitions in "shared" and only processor specific definition
in "proc". To give a concrete example, most MSR bit definition
are shared among PPC processors and only some differs. if we create
a single msr.h in shared it will have ifdef. If in msr.h we
include libcpu/msr_c.h we will need to have it in each prowerpc
specific directory (even empty). Opinions are welcomed ...
Note that a similar mechanism exist in libbsp/i386 that also
contains a shared directory that is used by several bsp
like pc386 and i386ex and a similar wrapup mechanism...
NB: I have done this for mpc750 and other processors could just use
similar Makefiles...
c) The exec/score/cpu/powerpc directory layout.
I think the directory layout should be the same than the
libcpu/powerpc. As it is not, there are a lot of ifdefs
inside the code... And of course low level interrupt handling
code should be removed...
Besides that I do not understand why
1) things are compiled in the wrap directory,
2) some includes are moved to rtems/score,
I think the "preinstall" mechanism enables to put
everything in the current directory (or better in a per processor
directory),
5) Interrupt handling API
-------------------------
Again :-). But I think that using all the features the PIC
offers is a MUST for RT system. I already explained in the
prologue of this (long and probably boring) mail that the MCP750
boards offers an OPENPIC compliant architecture and that
the VIA 82586 PCI/ISA bridge offers a PC compatible IO and
PIC mapping. Here is a logical view of the RAVEN/VIA 82586
interrupt mapping :
--------- 0 ------
| OPEN | <-----|8259|
| PIC | | | 2 ------
|(RAVEN)| | | <-----|8259|
| | | | | | 11
| | | | | | <----
| | | | | |
| | | | | |
--------- ------ | |
^ ------
| VIA PCI/ISA bridge
| x
-------- PCI interrupts
OPENPIC offers interrupt priorities among PCI interrupts
and interrupt selective masking. The 8259 offers the same kind
of feature. With actual powerpc interrupt code :
1) there is no way to specify priorities among
interrupts handler. This is REALLY a bad thing.
For me it is as importnat as having priorities
for threads...
2) for my implementation, each ISR should
contain the code that acknowledge the RAVEN
and 8259 cascade, modify interrupt mask on both
chips, and reenable interrupt at processor level,
..., restore then on interrupt return,.... This code
is actually similar to code located in some
genpvec.c powerpc files,
3) I must update _ISR_Nesting_level because
irq.inl use it...
4) the libchip code connects the ISR via set_vector
but the libchip handler code does not contain any code to
manipulate external interrupt controller hardware
in order to acknoledge the interrupt or re-enable
them (except for the target hardware of course)
So this code is broken unless set_vector adds an
additionnal prologue/epilogue before calling/returning
from in order to acknoledge/mask the raven and the
8259 PICS... => Anyway already EACH BSP MUST REWRITE
PART OF INTERRUPT HANDLING CODE TO CORRECTLY IMPLEMENT
SET_VECTOR.
I would rather offer an API similar to the one provided
in libbsp/i386/shared/irq/irq.h so that :
1) Once the driver supplied methods is called the
only things the ISR has to do is to worry about the
external hardware that triggered the interrupt.
Everything on openpic/VIA/processor would have been
done by the low levels (same things as set-vector)
2) The caller will need to supply the on/off/isOn
routine that are fundamental to correctly implements
debuggers/performance monitoring is a portable way
3) A globally configurable interrupt priorities
mechanism...
I have nothing against providing a compatible
set_vector just to make libchip happy but
as I have already explained in other
mails (months ago), I really think that the ISR
connection should be handled by the BSP and that no
code containing irq connection should exist the
rtems generic layers... Thus I really dislike
libchip on this aspect because in a long term
it will force to adopt the less reach API
for interrupt handling that exists (set_vector).
Additional note : I think the _ISR_Is_in_progress()
inline routine should be :
1) Put in a processor specific section,
2) Should not rely on a global variable,
As :
a) on symmetric MP, there is one interrupt level
per CPU,
b) On processor that have an ISP (e,g 68040),
this variable is useless (MSR bit testing could
be used)
c) On PPC, instead of using the address of the
variable via __CPU_IRQ_info.Nest_level a dedicated
SPR could be used.
NOTE: most of this is also true for _Thread_Dispatch_disable_level
END NOTE
--------
Please do not take what I said in the mail as a criticism for
anyone who submitted ppc code. Any code present helped me
a lot understanding PPC behavior. I just wanted by this
mail to :
1) try to better understand the actual code,
2) propose concrete ways of enhancing current code
by providing an alternative implementation for MCP750. I
will make my best effort to try to brake nothing but this
is actually hard due to the file layout organisation.
3) make understandable some changes I will probably make
if joel let me do them :-)
Any comments/objections are welcomed as usual.
--
__
/ ` Eric Valette
/-- __ o _. Canon CRF
(___, / (_(_(__ Rue de la touche lambert
35517 Cesson-Sevigne Cedex
FRANCE
Tel: +33 (0)2 99 87 68 91 Fax: +33 (0)2 99 84 11 30
E-mail: valette@crf.canon.fr
described in the message following this paragraph. This patch also includes
a mcp750 BSP.
From valette@crf.canon.fr Mon Jun 14 10:03:08 1999
Date: Tue, 18 May 1999 01:30:14 +0200 (CEST)
From: VALETTE Eric <valette@crf.canon.fr>
To: joel@oarcorp.com
Cc: raguet@crf.canon.fr, rtems-snapshots@oarcorp.com, valette@crf.canon.fr
Subject: Questions/Suggestion regarding RTEMS PowerPC code (long)
Dear knowledgeable RTEMS powerpc users,
As some of you may know, I'm currently finalizing a port
of RTEMS on a MCP750 Motorola board. I have done most
of it but have some questions to ask before submitting
the port.
In order to understand some of the changes I have made
or would like to make, maybe it is worth describing the
MCP750 Motorola board.
the MCP750 is a COMPACT PCI powerpc board with :
1) a MPC750 233 MHz processor,
2) a raven bus bridge/PCI controller that
implement an OPENPIC compliant interrupt controller,
3) a VIA 82C586 PCI/ISA bridge that offers a PC
compliant IO for keyboard, serial line, IDE, and
the well known PC 8259 cascaded PIC interrupt
architecture model,
4) a DEC 21140 Ethernet controller,
5) the PPCBUG Motorola firmware in flash,
6) A DEC PCI bridge,
This architecture is common to most Motorola 60x/7xx
board except that :
1) on VME board, the DEC PCI bridge is replaced by
a VME chipset,
2) the VIA 82C586 PCI/ISA bridge is replaced by
another bridge that is almost fully compatible
with the via bridge...
So the port should be a rather close basis for many
60x/7xx motorola board...
On this board, I already have ported Linux 2.2.3 and
use it both as a development and target board.
Now the questions/suggestions I have :
1) EXCEPTION CODE
-------------------
As far as I know exceptions on PPC are handled like
interrupts. I dislike this very much as :
a) Except for the decrementer exception (and
maybe some other on mpc8xx), exceptions are
not recoverable and the handler just need to print
the full context and go to the firmware or debugger...
b) The interrupt switch is only necessary for the
decrementer and external interrupt (at least on
6xx,7xx).
c) The full context for exception is never saved and
thus cannot be used by debugger... I do understand
the most important for interrupts low level code
is to save the minimal context enabling to call C
code for performance reasons. On non recoverable
exception on the other hand, the most important is
to save the maximum information concerning proc status
in order to analyze the reason of the fault. At
least we will need this in order to implement the
port of RGDB on PPC
==> I wrote an API for connecting raw exceptions (and thus
raw interrupts) for mpc750. It should be valid for most
powerpc processors... I hope to find a way to make this coexist
with actual code layout. The code is actually located
in lib/libcpu/powerpc/mpc750 and is thus optional
(provided I write my own version of exec/score/cpu/powerpc/cpu.c ...)
See remark about files/directory layout organization in 4)
2) Current Implementation of ISR low level code
-----------------------------------------------
I do not understand why the MSR EE flags is cleared
again in exec/score/cpu/powerpc/irq_stubs.S
#if (PPC_USE_SPRG)
mfmsr r5
mfspr r6, sprg2
#else
lwz r6,msr_initial(r11)
lis r5,~PPC_MSR_DISABLE_MASK@ha
ori r5,r5,~PPC_MSR_DISABLE_MASK@l
and r6,r6,r5
mfmsr r5
#endif
Reading the doc, when a decrementer interrupt or an
external interrupt is active, the MSR EE flag is already
cleared. BTW if exception/interrupt could occur, it would
trash SRR0 and SRR1. In fact the code may be useful to set
MSR[RI] that re-enables exception processing. BTW I will need
to set other value in MSR to handle interrupts :
a) I want the MSR[IR] and MSR[DR] to be set for
performance reasons and also because I need DBAT
support to have access to PCI memory space as the
interrupt controller is in the PCI space.
Reading the code, I see others have the same kind of request :
/* SCE 980217
*
* We need address translation ON when we call our ISR routine
mtmsr r5
*/
This is just another prof that even the lowest level
IRQ code is fundamentally board dependent and
not simply processor dependent especially when
the processor use external interrupt controller
because it has a single interrupt request line...
Note that if you look at the PPC code high level interrupt
handling code, as the "set_vector" routine that really connects
the interrupt is in the BSP/startup/genpvec.c,
the fact that IRQ handling is BSP specific is DE-FACTO
acknowledged.
I know I have already expressed this and understand that this
would require some heavy change in the code but believe
me you will reach a point where you will not be able
to find a compatible while optimum implementation for low level
interrupt handling code...) In my case this is already true...
So please consider removing low level IRQ handling from
exec/score/cpu/* and only let there exception handling code...
Exceptions are usually only processor dependent and do
not depend on external hardware mechanism to be masked or
acknowledged or re-enabled (there are probably exception but ...)
I have already done this for pc386 bsp but need to make it again.
This time I will even propose an API.
3) R2/R13 manipulation for EABI implementation
----------------------------------------------
I do not understand the handling of r2 and r13 in the
EABI case. The specification for r2 says pointer to sdata2,
sbss2 section => constant. However I do not see -ffixed-r2
passed to any compilation system in make/custom/*
(for info linux does this on PPC).
So either this is a default compiler option when choosing
powerpc-rtems and thus we do not need to do anything with
this register as all the code is compiled with this compiler
and linked together OR this register may be used by rtems code
and then we do not need any special initialization or
handling.
The specification for r13 says pointer to the small data
area. r13 argumentation is the same except that as far
as I know the usage of the small data area requires
specific compiler support so that access to variables is
compiled via loading the LSB in a register and then
using r13 to get full address... It is like a small
memory model and it was present in IBM C compilers.
=> I propose to suppress any specific code for r2 and
r13 in the EABI case.
4) Code layout organization (yes again :-))
-------------------------------------------
I think there are a number of design flaws in the way
the code is for ppc organized and I will try to point them out.
I have been beaten by this again on this new port, and
was beaten last year while modifying code for pc386.
a) exec/score/cpu/* vs lib/libcpu/cpu/*.
I think that too many things are put in exec/score/cpu that
have nothing to do with RTEMS internals but are rather
related to CPU feature.
This include at least :
a) registers access routine (e.g GET_MSR_Value),
b) interrupt masking/unmasking routines,
c) cache_mngt_routine,
d) mmu_mngt_routine,
e) Routines to connect the raw_exception, raw_interrupt
handler,
b) lib/libcpu/cpu/powerpc/*
With a processor family as exuberant as the powerpc family,
and their well known subtle differences (604 vs 750) or
unfortunately majors (8xx vs 60x) the directory structure
is fine (except maybe the names that are not homogeneous)
powerpc
ppc421 mpc821 ...
I only needed to add mpc750. But the fact that libcpu.a was not
produced was a pain and the fact that this organization may
duplicates code is also problematic.
So, except if the support of automake provides a better solution
I would like to propose something like this :
powerpc
mpc421 mpc821 ... mpc750 shared wrapup
with the following rules :
a) "shared" would act as a source container for sources that may
be shared among processors. Needed files would be compiled inside
the processor specific directory using the vpath Makefile
mechanism. "shared" may also contain compilation code
for routine that are really shared and not worth to inline...
(did not found many things so far as registers access routine
ARE WORTH INLINING)... In the case something is compiled there,
it should create libcpushared.a
b) layout under processor specific directory is free provided
that
1)the result of the compilation process exports :
libcpu/powerpc/"PROC"/*.h in $(PROJECT_INCLUDE)/libcpu
2) each processor specific directory creates
a library called libcpuspecific.a
Note that this organization enables to have a file that
is nearly the same than in shared but that must differ
because of processor differences...
c) "wrapup" should create libcpu.a using libcpushared.a
libcpuspecific.a and export it $(PROJECT_INCLUDE)/libcpu
The only thing I have no ideal solution is the way to put shared
definitions in "shared" and only processor specific definition
in "proc". To give a concrete example, most MSR bit definition
are shared among PPC processors and only some differs. if we create
a single msr.h in shared it will have ifdef. If in msr.h we
include libcpu/msr_c.h we will need to have it in each prowerpc
specific directory (even empty). Opinions are welcomed ...
Note that a similar mechanism exist in libbsp/i386 that also
contains a shared directory that is used by several bsp
like pc386 and i386ex and a similar wrapup mechanism...
NB: I have done this for mpc750 and other processors could just use
similar Makefiles...
c) The exec/score/cpu/powerpc directory layout.
I think the directory layout should be the same than the
libcpu/powerpc. As it is not, there are a lot of ifdefs
inside the code... And of course low level interrupt handling
code should be removed...
Besides that I do not understand why
1) things are compiled in the wrap directory,
2) some includes are moved to rtems/score,
I think the "preinstall" mechanism enables to put
everything in the current directory (or better in a per processor
directory),
5) Interrupt handling API
-------------------------
Again :-). But I think that using all the features the PIC
offers is a MUST for RT system. I already explained in the
prologue of this (long and probably boring) mail that the MCP750
boards offers an OPENPIC compliant architecture and that
the VIA 82586 PCI/ISA bridge offers a PC compatible IO and
PIC mapping. Here is a logical view of the RAVEN/VIA 82586
interrupt mapping :
--------- 0 ------
| OPEN | <-----|8259|
| PIC | | | 2 ------
|(RAVEN)| | | <-----|8259|
| | | | | | 11
| | | | | | <----
| | | | | |
| | | | | |
--------- ------ | |
^ ------
| VIA PCI/ISA bridge
| x
-------- PCI interrupts
OPENPIC offers interrupt priorities among PCI interrupts
and interrupt selective masking. The 8259 offers the same kind
of feature. With actual powerpc interrupt code :
1) there is no way to specify priorities among
interrupts handler. This is REALLY a bad thing.
For me it is as importnat as having priorities
for threads...
2) for my implementation, each ISR should
contain the code that acknowledge the RAVEN
and 8259 cascade, modify interrupt mask on both
chips, and reenable interrupt at processor level,
..., restore then on interrupt return,.... This code
is actually similar to code located in some
genpvec.c powerpc files,
3) I must update _ISR_Nesting_level because
irq.inl use it...
4) the libchip code connects the ISR via set_vector
but the libchip handler code does not contain any code to
manipulate external interrupt controller hardware
in order to acknoledge the interrupt or re-enable
them (except for the target hardware of course)
So this code is broken unless set_vector adds an
additionnal prologue/epilogue before calling/returning
from in order to acknoledge/mask the raven and the
8259 PICS... => Anyway already EACH BSP MUST REWRITE
PART OF INTERRUPT HANDLING CODE TO CORRECTLY IMPLEMENT
SET_VECTOR.
I would rather offer an API similar to the one provided
in libbsp/i386/shared/irq/irq.h so that :
1) Once the driver supplied methods is called the
only things the ISR has to do is to worry about the
external hardware that triggered the interrupt.
Everything on openpic/VIA/processor would have been
done by the low levels (same things as set-vector)
2) The caller will need to supply the on/off/isOn
routine that are fundamental to correctly implements
debuggers/performance monitoring is a portable way
3) A globally configurable interrupt priorities
mechanism...
I have nothing against providing a compatible
set_vector just to make libchip happy but
as I have already explained in other
mails (months ago), I really think that the ISR
connection should be handled by the BSP and that no
code containing irq connection should exist the
rtems generic layers... Thus I really dislike
libchip on this aspect because in a long term
it will force to adopt the less reach API
for interrupt handling that exists (set_vector).
Additional note : I think the _ISR_Is_in_progress()
inline routine should be :
1) Put in a processor specific section,
2) Should not rely on a global variable,
As :
a) on symmetric MP, there is one interrupt level
per CPU,
b) On processor that have an ISP (e,g 68040),
this variable is useless (MSR bit testing could
be used)
c) On PPC, instead of using the address of the
variable via __CPU_IRQ_info.Nest_level a dedicated
SPR could be used.
NOTE: most of this is also true for _Thread_Dispatch_disable_level
END NOTE
--------
Please do not take what I said in the mail as a criticism for
anyone who submitted ppc code. Any code present helped me
a lot understanding PPC behavior. I just wanted by this
mail to :
1) try to better understand the actual code,
2) propose concrete ways of enhancing current code
by providing an alternative implementation for MCP750. I
will make my best effort to try to brake nothing but this
is actually hard due to the file layout organisation.
3) make understandable some changes I will probably make
if joel let me do them :-)
Any comments/objections are welcomed as usual.
--
__
/ ` Eric Valette
/-- __ o _. Canon CRF
(___, / (_(_(__ Rue de la touche lambert
35517 Cesson-Sevigne Cedex
FRANCE
Tel: +33 (0)2 99 87 68 91 Fax: +33 (0)2 99 84 11 30
E-mail: valette@crf.canon.fr
The select function is not particularly efficient when dealing with a
large number of sockets. The application has to build a big set of
bits and pass it in. RTEMS has to look through all those bits and see
what is ready. Then the application has to look through all the bits
again.
On the other hand, when using RTEMS, the select function is needed
exactly when you have a large number of sockets, because that is when
it becomes prohibitive to use a separate thread for each socket.
I think it would make more sense for RTEMS to support callback
functions which could be invoked when there is data available to read
from a socket, or when there is space available to write to a socket.
Accordingly, I implemented them.
This patch adds two new SOL_SOCKET options to setsockopt and
getsockopt: SO_SNDWAKEUP and SO_RCVWAKEUP. They take arguments of
type struct sockwakeup:
struct sockwakeup {
void (*sw_pfn) __P((struct socket *, caddr_t));
caddr_t sw_arg;
};
They are used to add or remove a function which will be called when
something happens for the socket. Getting a callback doesn't imply
that a read or write will succeed, but it does imply that it is worth
trying.
This adds functionality to RTEMS which is somewhat like interrupt
driven socket I/O on Unix.
After the patch to RTEMS, I have appended a patch to
netdemos-19990407/select/test.c to test the new functionality and
demonstrate one way it might be used. To run the new test instead of
the select test, change doSocket to call echoServer2 instead of
echoServer.
Ian Lance Taylor <ian@airs.com>:
Ian Lance Taylor wrote:
>
> In rtems-19990528, sbwait sets SB_WAIT in sb_flags. sowakeup checks
> it. Why doesn't socket_select set it?
>
> I don't know that this is a bug--I haven't tried to create a test
> case. However, it certainly looks odd.
>
> Ian
Yes, there's a bug there. Sorry about that.
It was introduced when I did some cleanup on the sleep/wakeup handling
in rtems_glue.c.
This patch fixes a nasty problem with build-tools/Makefile.am:
When using install-sh instead of /usr/bin/install, only the first file
gets installed during the preinstall stage.
I found a small buglet in the mips64orion _CPU_ISR_Set_level; the
original was wiping out the level argument, and then comparing the
current interrupt level with some random value of v0. See patch below.
that the per task reentrancy structure was not being processed properly
during exit().
joel@oarcorp.com wrote:
>
>
> This is always an ugly place to poke around. :(
>
> The code in newlib/libc/stdlib/exit.c walks the atexit chain for the
> reentrancy structure for JUST the current task. The code in libc_wrapup()
> does it for both the current task and the global reentrancy structure
> (which tends to be where driver atexit()'s were registered.
>
> So I think the _wrapup_reent(0) in libc_wrapup() should be commented out.
>
> If you concur, then I will make the change and improve the comment on this
> line of code to explain things:
>
> libc_wrapup(); /* Why? XXX */
>
> --joel
That does the job. cdtest.exe works correctly now.
in libcpu/powerpc/mpc860/clock/clock.c:InstallClock() the reload value for
the PIT is defined as:
pit_value = (BSP_Configuration.microseconds_per_tick *
Cpu_table.clicks_per_usec) - 1 ;
What exactly is a tick, and what is a click?
My confusion stems from the fact, that Jay defines clicks_per_usec to 1
which is correct for his configuration, where a 4MHz clock is predivided
by 4 and then fed to the PIT. So I assume a "click" is just the period of
the PIT input frequency.
However, our HW config seems to have 32.768 kHz crystal input for PIT.
Mandatory division by 4 means 8.196kHz (122usec) at the PIT.
I think, the above assignment should read:
pit_value = (BSP_Configuration.microseconds_per_tick /
Cpu_table.clicks_per_usec) - 1;
where I can define Cpu_table.clicks_per_usec in bspstart.c to 122
(clicks_per_usec). That would lead to a PIT reload value of
10000/122 - 1 = 81 to reach a 10ms "tick" period.
in libcpu/powerpc/mpc860/clock/clock.c:InstallClock() the reload value for
the PIT is defined as:
pit_value = (BSP_Configuration.microseconds_per_tick *
Cpu_table.clicks_per_usec) - 1 ;
What exactly is a tick, and what is a click?
My confusion stems from the fact, that Jay defines clicks_per_usec to 1
which is correct for his configuration, where a 4MHz clock is predivided
by 4 and then fed to the PIT. So I assume a "click" is just the period of
the PIT input frequency.
However, our HW config seems to have 32.768 kHz crystal input for PIT.
Mandatory division by 4 means 8.196kHz (122usec) at the PIT.
I think, the above assignment should read:
pit_value = (BSP_Configuration.microseconds_per_tick /
Cpu_table.clicks_per_usec) - 1;
where I can define Cpu_table.clicks_per_usec in bspstart.c to 122
(clicks_per_usec). That would lead to a PIT reload value of
10000/122 - 1 = 81 to reach a 10ms "tick" period.
a BSP for the TS-1325 embedded PC from Technologic Systems
(http://www.t-systems.com) and patches to enable software
floating-point emulation for x86 targets.
I have made test with the Dec21140 driver and it appears that all
works fine even if the cache is enabled for the memory space in
which the incoming and outcoming Ethernet frames are stored.
I have had #ifdef to "comment" the code. If you want to disable
cache, you only have to #define the name. It could be mandatory
for some BSPs.
University of British Columbia. The BSP is for:
Yes, this is the "entry model" of a series of boards from Technologic
Systems. Costs <$200 I believe. They have a WWW page at www.t-systems.com.
I am letting them know about the availability of this BSP too.
the build-tools layout to simplify it.
This script reorganizes and simpilfies the build-tools subdirectories.
It moves all source-files and scripts to c/build-tools/. This will
enable use to use this directory directly to refer to the build-tools
instead of copying them around in a "preinstall" step in future.
However, RTEMS's autoconf Makefile.ins and *.cfg files are not yet
prepared to apply this approach and therefore require additional work.
This one is an enhancement to acpolish.
It replaces some Makefile variables by others variable in Makefile.ins
(tries to use unique name for some variables). It therefore eases
parsing Makefile.ins for further automatic Makefile.in conversions in
future.
To apply:
cd <rtems-source-tree>
sh <path-to>/rtems-rc-19990407-8.sh
./autogen
This is an attempt to work-around a couple of nasty bugs in librdbg's
Makefiles and configuration:
Configure and build RTEMS as below:
configure --enable-networking --enable-rdbg --target=i386-rtems
make RTEMS_BSP=i386ex
After a few minutes you will notice that building aborts in librdbg ....
Analysis:
1) librdbg is tried to be built, though librdbg is not supported and the
required directory hierarchy librdbg/i386/i386ex/ is not existant.
The cause for this is incorrect setting of HAS_RDBG in most
make/custom/*.cfg files (except pc386.cfg). At the moment all
custom/*.cfg files (except pc386.cfg) in general are required to contain
HAS_RDBG=no. However, having HAS_NETWORKING=no in most custom/*.cfg
files and the toplevel configure script suppress building librdbg for
all CPUs except of i386.
=> The i386ex BSP falls though this scheme and librdbg is tried to be
build (CPU=i386 and HAS_NETWORKING=yes).
2) The Makefile.ins below lib/librdbg in general support i386/pc386 only
and are not capable to be used for multiple CPUs or BSPs (RPCGEN
generates it's target and bsp-specific files into librdbg/, therefore no
other CPU or BSP can ever be built afterwards). This problem is hidden
until now, because only a single CPU/BSP pair (i386/pc386) is really
supported.
3) The Makefile.ins below lib/librdbg can delete source files due to
improper handling of source files (make clean removes the *.x files in
the source-tree when configuring inside of the source-tree).
The patch below tries to work-around these problems for the i386ex and
the pc386 BSPs. This work-around is rather fragile (it applies rpcgen
-D, I don't know how portable this is) and incomplete (all custom/*.cfg
except of pc386.cfg should contain HAS_RDBG=no), nevertheless it should
work.
FYI: I am not talking about using "make -C <dir>", which probably
is much faster on M$ hosts than RTEMS's implementation, but about
removing --enable-gmake-print support and to apply a variant of
automake's subdirectory.
Automake's subdirectory rule seems to be a little bit faster, but I
wouldn't bet on this.
Attached to this mail is my proposal.
After applying the patch, please run
cvs rm aclocal/enable-gmake-print.m4
./autogen
2) ./c/src/lib/libbsp/i386/go32/startup
> all: ${ARCH} $(SRCS) $(PGM)
> $(INSTALL_CHANGE) ${PROJECT_RELEASE}/lib
>
>
This also is very questionable, because it means "install
$(PROJECT_RELEASE)/$/lib to the void". I think, removing the
INSTALL_CHANGE is the right way to fix it.
1) ./c/src/lib/libbsp/i386/i386ex/startup/Makefile.in
> preinstall:
> $(INSTALL_CHANGE) ${IMPORT_SRC} .
>
> # ${CP} ${IMPORT_SRC} .
>
>
>
This fragment is broken, because IMPORT_SRC is always empty.
IMO, the fix would be to remove this fragment or to replace it with
test -z "${IMPORT_SRC}" || cp ${IMPORT_SRC} .
if an external shell variable IMPORT_SRC shall be supported by this
Makefile, which IMO should not be done.
This first one below looked like it only belonged in a
virtual memory environment. The second one was causing
problems without the PROVIDE() - I don't know why.
Installing of bsp_specs for aliased bsps is broken. Instead of installing
RTEMS_BSP_FAMILY/bsp_specs, RTEMS_BSP/bsp_specs was tried to be installed.
The patch below should fix this problem (tested with mips64orion p4600 and
p4650).
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
Date: Mon, 12 Apr 1999 00:38:04 +0000
From: Brendan Simon <brendan@dgs.monash.edu.au>
To: Jay Monkman <jmonkman@frasca.com>, "joel@OARcorp.com" <joel@oarcorp.com>
Subject: [Fwd: Goof in SMC initialize for mpc860]
Nick Simon reported this bug in the eth_comm BSP sources. I see that it is
still there in the latest snapshot that Joel sent me (thanks). I thought I
better forward this on to you guys.
Brendan.
Nick.SIMON@syntegra.bt.co.uk wrote:
> Sice I believe you're using the same base BSP as I am (you sent it to me) I
> thought I'd mention..
>
> In console-generic.c, in m860_smc_initialize, the receive buffer is malloced
> and assigned to RxBd[port+3]-> buffer - it should be [port-1].
>
> TTFN
B
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.
In your various bsp_specs files, even when ecrti.o is defined as a
startfile, ecrtn.o is not defined as an endfile. Instead it seems to
be in the library list - untidy.
I'd like to make the following change which adds the m360 structure
information to the debugging symbols in the final executable. This
makes it much easier to use the debugger to look at the elements of
the m360 structure.
and Emmanuel Raguet <raguet@crf.canon.fr>. It was submitted in LaTeX
and converted to Texinfo by Joel. At this point, the figures are
largely ignored except to put in an example block to show they are
missing.
The Makefile should be just enough to produce output with no links between
chapters.
<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?
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 ----
rtems-rc-19990326-2.diff: Enhancements to autoconf support for librdbg
* autoconf-checks for AWK and RPCGEN
* disable librdbg if either AWK, RPCGEN or librdbg/$target_cpu
cannot be found
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).
----------
Emmanuel Raguet <raguet@crf.canon.fr> to eliminate a problem
during the boot process on the pc386 BSP. On fast PC's the
calibration routine would hand.
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.
fix some problems encountered when reusing this driver on
a SPARC ERC32 based Tharsys board. He eliminted the need
for TX interrupts and added code that can optionally ensure that
the IP address is 32-bit aligned. He also fixed a handful of
problems that only occured because the 8 Mhz ERC32 was
enough slower than the 100 Mhz PPC603e that timing
issues in this driver were magnified.
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)].
This is the first real automake patch.
It adds automake support to c/build-tools and cleans up a few minor
issues.
I consider this to be a testing probe to examine problems with automake.
Therefore, this patch is just a more or less harmless replacement of the
former RTEMS Makefiles and I expect it not last for long. If you want to
give automake Makefiles a public try and if you want/need to learn about
problems with it, then it's about time for a new snapshot, IMO. I may
have screwed up something not directly related to automake, but I expect
very few (none to be precise) problems with automake. However, somebody
should at least try building on Cygwin. If you feel a bit more
adventureous, then I also can continue to submit more patches.
[FYI: I still have a couple of automake files laying around, but they
need some cleanup before being submitted as patches. Now, that I am just
into it, I'll perhaps submit another one tonight :-]
After applying this patch (patch -p1 -E <
<path-to>/rtems-rc-19990318-0), first run the "autogen" script from the
toplevel source directory, before committing to CVS. Be careful about
dependencies between Makefile.am and Makefile.ins when cutting tarballs
from CVS. Makefile.ins are required to be newer than Makefile.ams,
otherwise users would need to have automake, autoconf and perl. Some
people recommend to "touch" all Makefile.in after checkout from cvs (cf.
egcs/contrib/egcs_update).
ATTENTION:
* This patch adds a number of new files.
* remove aclocal/exeext.m4 and aclocal/cygwin.m4 from CVS, They are now
covered by autoconf-2.13`s AC_EXEEXT.
Some features/side-effects which are probably interesting for you:
In a configured build-tree "cd c/build-tools", then try
* "make RTEMS_BSP=<bsp> install"
* "make RTEMS_BSP=<bsp> dist"
This patch is the most scary of all proposals I've been mailing to you
this week until now.
It consists of 3 parts:
1. a patch
2. a perl script (acpolish)
3. a shell script wrapper to invoke the perl-script.
The perl-script reads in each Makefile.in and modifies them
("polishes/beautifies" them :-).
These modifications are not easy to describe:
Basically, it hard-codes some automake Makefile-variables and rules into
RTEMS autoconf-Makefile.ins (Note: autoconf vs. automake!!) and converts
some settings/variables to configure scripts' requirements (Yes,
plural).
E.g. it adds the automake standard variables $top_builddir and $subdir,
adds dependency rules for automatic re-generation of Makefiles from
Makefile.in, adds support variables for relative paths to multiple
configure scripts etc.
The patch is a one-line patch to enable the support of the new features
added by acpolish.
The shell script is a wrapper which pokes around inside of the source
tree for Makefile.ins and invokes acpolish on all autoconf-Makefile.ins.
acpolish is designed to be able to run several times on the same
Makefile.in and may once become a more general tool to convert RTEMS
Makefile.in to automake. Therefore, I'd like to keep it inside of source
tree. (e.g. as contrib/acpolish or c/update-tools/acpolish). However, it
doesn't make sense to export it outside of RTEMS.
To apply this:
cd <source-tree>
patch -p1 -E < <path-to-patch>/rtems-rc-19990318-1.diff
tar xzvf <path-to>/rtems-rc-polish.tar.gz
./rtems-polish.sh
./autogen
Note: The path contrib/acpolish is hard-coded into rtems-polish.sh, if
you decide to put it in an alternative place, please modify
rtems-polish.sh to reflect this change.
Later:
cvs rm make/rtems.cfg (It isn't used anymore)
cvs add contrib
cvs add contrib/acpolish
cvs commit
I've tested this intensively, but naturally I can't exclude bugs.
Ralf.
PS.: Most probably, this is the last "Towards automake" patch. The next
one probably will be a real automake patch.
This one once again changes the scheme to preinstall bsp_specs.
It moves generating PROJECT_ROOT/lib/bsp_specs to
libbsp/<cpu>/<bsp>/wrapup/Makefile.in.
I.e. it decentralizes generation of bsp_specs to a bsp-dependent
directory, because preinstalling bsp_specs in a centralized Makefile
like it has been done until now does not harmonize well with spliting
the toplevel configure script in cpu and bsp-dependent configure scripts
and automake.
First apply the patch (rtems-rc-19990318-0.diff) below, then run the
reorg-bsp_specs.sh script.
IMO, this one is comparatively harmless and eases automake support
significantly.
This is the next step towards automake:
* Two scripts for the toplevel directory:
a) "autogen" (Idea borrowed from libtool and gnome) A helper script to
recursively regenerate autoconf/automake/aclocal generated files
(Still not perfect but sufficient).
b) "missing" (from automake-cvs archive). This file normally is
automatically generated by automake, but we have to manually add
it until we add automake support to the toplevel configure script.
"chmod 755 missing autogen" after applying the patch.
* Changing the toplevel installation directory [ I can hear you
falling off the chair ;-]
Until now rtems installed itself to $(prefix)/rtems. This is in
contradiction to automake and GNU/FSF/Cygnus conventions.
With this patch applied, rtems installs into $(prefix).
To achieve the old behaviour simply configure with
--prefix=<install-dir>/rtems instead of --prefix=<install-dir>
This is a widely visible change and I can understand if you don't
like it at the present point. It enables us to use automake's
default installation paths instead of having to set up installation
paths manually. At the moment this doesn't help much, but in the not
so far future this would enable us to mix cpu-only dependent libraries
into the host's cross-compiler library and header files into
newlib's include directories, tools into the toolchain directories etc.
I would recommend to change the main installation directory, however it's
up to you to draw the final design decision.
OK, I 've made up my mind to cut a big chunk of my automake-patches (:-).
Below you can find a drop-in replacement of the aclocal directory. It
contains a lot of new macro files, most of them are directly cut from rtems
top-level configure script, some are new some are identical to former
versions. The motivation behind these files is to reuse parts from rtems
current top-level configure.in script in up-coming subdirectory configure.in
scripts.
I'd like to ask you to untar the archive ontop of the source tree and to
add/commit these files to CVS. Adding these files should not have any
influence on RTEMS momentary configuration (except of you are required to
run aclocal -I aclocal && autoconf afterwards), because most of them
currently are not used at all.
---------
BTW: Please upgrade to autoconf-2.13 and automake-2.4, if you havn't done
this already (egcs/CVS require them, too). My upcoming automake files
require automake-2.4 which requires autoconf-2.13 or later.
Erik Ivanenko pointed out a problem in the ne2000.c driver I
submitted: it did not work correctly with bootp. Here is a patch,
based on a patch he sent me.
First, the unlimited patch. I have compiled the unlmited patch for the
Linux posix BSP only and it seems to work cleanly. I would like a really
major application run on this change before commiting as the changes are
very core and significant. I am currently building all the tests to run.
I have no targets suitable to test on at the moment.
I have tested the patch for inline functions and macros.
Turning macros on has found some core bugs. I have fixed these but have
not run all the tests. Please review the patch for these changes. They
are:
1) The conditional compilation for MP support broke the core messages
code. You cannot embed a conditional macro in another macro. The Send
and Urgent Send calls are macros.
2) User extensions handler initialisation now has two parameters. I have
updated the macros to support the extra parameter.
The patch also contains the gcc-target-default.cfg fix required to build
the kernel. More of a by product than a fix for you.
problems that prevented the 19990302 snapshot from running on
the efi332.
I'm happy to report that rtems-19990302 is running on the efi332
board. I have enclosed a few minor patches below to the efi332 bsp. All
patches are within that library but one. make/custom/efi332.cfg has a
patch to select the right CPU_CFLAGS (at one time -m68332 was a
problem... -mcpu32 or -m68332 work fine now).
would work. At the same time, the initial implementation of F_SETFL
was added. A support routine was added to convert internal libio
flags back to the POSIX style. Eventually the internal representation
should be eliminated in the interest of simplicity and code reduction.
This problem was reported by Jake Janovetz <janovetz@tempest.ece.uiuc.edu>.
Comments follow:
Please find attached, the updated network driver. I have verified
that it is working as expected, by timestamping the error messages
generated from the ISR.
If you've taken a look inside, the network driver has a reset thread
in addition to the RX and TX threads. It is possible to avoid the
additional reset thread by allowing the TX driver to time out and then
checking status bits set by the ISR. However, this approach demands
that a transmission is necessary for the NIC to be reset.
Due to Eric V's ISR handling, I suppose that the reset routine could
be called from the "ISR" itself, due to the 8259 interrupt mode, and
that the interrupt is acknowledged prior to running the "ISR".
(Providing that no NIC interrupts are generated during reset -- I
worry about re-entrancy. )
This would be a minor improvement, but you know, I don't want to make
this driver my lifes work.
----------------------------------------------------------------------
----------------------------------------------------------------------
> 5) rtems-rc-19990202-1.diff/reorg-install.sh
>
> reorg-install.sh fixes a Makefile variable name clash of RTEMS
> configuration files and automake/autoconf standards.
> Until now, RTEMS used $(INSTALL) for install-if-change. Automake and
> autoconf use $(INSTALL) for a bsd-compatible install. As
> install-if-change and bsd-install are not compatible, I renamed all
> references to install-if-changed to $(INSTALL_CHANGED) and used
> $(INSTALL) for bsd-install (==automake/autoconf standard). When
> automake will be introduced install-if-change will probably be replaced
> by $(INSTALL) and therefore will slowly vanish. For the moment, this
> patch fixes a very nasty problem which prevents adding any automake file
> until now (There are still more).
rather then NAME_MAX. NAME_MAX is 255 and that lets IMFS chew up memory
too fast. Perhaps in the future, the places in IMFS that put a maximum
length name string on the stack and the jnode structure does not include
a maximu length name string can be fixed so this is not a problem.
FP issues on this target:
The default variants of libc, libm and libgcc assume that a 68881
coprocessor is present. Without the FPSP, any floating point operation,
including printf() with a "%f" format specifier, is likely to cause an
unimplemented instruction exception.
The FPSP works with the default variants of libc, libm and libgcc. It does not
work in conjunction with the msoft-float variants. The paranoia test goes into
an infinite loop at milestone 40. I am guessing that floor() is returning an
incorrect value.
The msoft-float variants of libc, libm and libgcc appear to do floating point
I/O properly. They only failed in paranoia. Offhand, I can't think of why they
would conflict with the FPSP, so I think that there is something wrong with the
msoft-float code. It might be my installation.
Given my experiences, I decided to install the FPSP in bsp_start(), and to link
against the default variants of libc, libm and libgcc. This causes the
executables to increase in size by about 60 KB. The README file and the
mvme167.cfg specify how to remove the FPSP, and how to link against the
msoft-float variants of the libraries. This is not what Eric Norum had done: on
my host, his gen68360_040 port links RTEMS code with the msoft-float variants
of libc and libm, and the default variant of libgcc. In this configuration, the
output of printf() with "%f" is garbage on my target.
FP issues on this target:
The default variants of libc, libm and libgcc assume that a 68881
coprocessor is present. Without the FPSP, any floating point operation,
including printf() with a "%f" format specifier, is likely to cause an
unimplemented instruction exception.
The FPSP works with the default variants of libc, libm and libgcc. It does not
work in conjunction with the msoft-float variants. The paranoia test goes into
an infinite loop at milestone 40. I am guessing that floor() is returning an
incorrect value.
The msoft-float variants of libc, libm and libgcc appear to do floating point
I/O properly. They only failed in paranoia. Offhand, I can't think of why they
would conflict with the FPSP, so I think that there is something wrong with the
msoft-float code. It might be my installation.
Given my experiences, I decided to install the FPSP in bsp_start(), and to link
against the default variants of libc, libm and libgcc. This causes the
executables to increase in size by about 60 KB. The README file and the
mvme167.cfg specify how to remove the FPSP, and how to link against the
msoft-float variants of the libraries. This is not what Eric Norum had done: on
my host, his gen68360_040 port links RTEMS code with the msoft-float variants
of libc and libm, and the default variant of libgcc. In this configuration, the
output of printf() with "%f" is garbage on my target.
is long but I hate to lose the information so I am including it here.
> I am still fixing and recompiling but this is the issue that was not the
> result of another patch. This is a fundamental build issue that I value
> your opinion on.
This is difficult issue (I.e. I have no destinct solution for it)
Background:
(gnu-) make's implicit rules apply CFLAGS, CPPFLAGS, CXXFLAGS, ASFLAGS and
LDFLAGS (cf. make.info/Implicit Rules/Catalogue of Rules), only.
In brief:
CPPFLAGS .. passed to the c-preprocessor
CFLAGS ... passed to the c-compiler
CXXFLAGS ... equivalent to CFLAGS but passed to the c++ compiler
(Attention: CFLAGS is not passed to the c++ compiler)
ASFLAGS .. equivalent to CFLAGS, but passed to the assembler
LDFLAGS .. equivalent to CFLAGS, but passed to the linker
A bit oversimplifying, these make rules are as follows
.c.o:
$(CC) $(CPPFLAGS) $(CFLAGS) -c
.cc.o:
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c
.S.s:
$(CPP) $(CPPFLAGS)
.s.o:
$(AS) $(ASFLAGS)
My reading of the documentation (make.info) is that {AS|AR|CC|CXX|CPP}FLAGS
are ment to be passed to the related tools directly, however examinating
the rule set of gmake (gmake -p -f /dev/null") shows that many rules use
$(CC) instead of the related tools (eg. linker rules) etc.
I.e. these flags should not rely on being passed through cpp or gcc. With
gcc being the common frontend for all of these tools of a gnu-toolchain the
situation becomes difficult (Which option is passed to whom and which tool
really uses it?), because these variable can also contain the toolchain's
frontend (eg. AS=gcc, LD=gcc, CPP=gcc -E).
For some commonly used options the situation is quite clear:
* -g -> CFLAGS
* -OX -> CFLAGS
* -D -> CPPFLAGS
* -A -> CPPFLAGS
But where to add -m, -B, -specs, -qrtems_XXX ?
* -B, -specs, -qrtems_XXX are gcc-frontend options
* -m is a combinations of flags to go to different destinations, in many
(all?) cases, the following is valid
-m is expanded by gcc into a set of -D and -A options
-m is interpreted by cc1 as a machine flag to generate a specific
instruction set.
-m is interpreted by gcc as an implicit linker search path for multilibs to
set up calls to LD.
>From my point of view this indicates we can either destingush between these
different usages (= separately add -m to CFLAGS, LDFLAGS etc) or to add it
to CPPFLAGS and use gcc (the frontend) instead of calling each tool
directly (less error prone) -- I vote for CPPFLAGS, but I am not sure.
-----------------
Now, where to add CPU_CFLAGS?
AFAIS, in probably all cases CPU_CFLAGS contain -D -A, and -m options,
only.
* -D and -A are supposed to go to CPPFLAGS
* -mXXX options can have multiple meanings (It can be gcc, collect2/ld and
cc1/cc1plus option simultaneously)
Here, I made a mistake - I destinguished between CPU_DEFINES to be added to
CPPFLAGS and CPU_CFLAGS to be added to CFLAGS and CXXFLAGS (cf.
gcc-target-default.cfg), generally assuming CPU_CFLAGS are CFLAGS.
This breaks preprocessing *.S into *.i files because CPU_CFLAGS flags were
not added to CPPFLAGS. Hence *all* *.S were compiled without taking
-mXX-flags into account. The i960/cvme BSP was the only one which
explicitly checked for a specific -m flag (-mca) and refused to compile
without it -- all other CPUs/BSPs silently swallowed this.
IMO, we can either
1) add CPU_CFLAGS and CPU_DEFINES to CPPFLAGS, thus silently convert
CPU_CFLAGS's meaning into CPU_DEFINES (Alternative solution: rename
CPU_CFLAGS to CPU_DEFINES and merge CPU_FLAGS with CPU_DEFINES).
or
2) destinguish between CPU_DEFINES and CPU_CFLAGS. In this case we would
need to check the contents of each CPU_CFLAGS in custom/*.cfg and move the
some parts of the contents to CPU_DEFINES and keep other parts in
CPU_CFLAGS (CFLAGS must contain options for the c/c++-compiler only!).
Though Solution 2) is the clearer one, I implemented 1) which is the
simplier one (the patch below).
ATTENTION: This patch is small in size, but affects almost everything.
------------
Additional complications araise with linking:
Some BSPs call LD and AS directly (esp. gcc-2.7 make-exe rules). If LD=gcc
then LDFLAGS are supposed to be gcc-options, but if LD=ld then LDFLAGS is
supposed to contain ld-options.
An analog thought is valid for AS, but luckily enough ASFLAGS is not used
of inside the whole source tree.
Most RTEMS' custom/*.cfg use $(CC) $(CFLAGS) to link with gcc-2.8 make-exe
rules. With the patch below (CPU_CFLAGS added to CPPFLAGS) this means
CPU_CFLAGS will not be passed to the linker, which is incorrect for
multilibbed CPU's.
gmake's default rule set contains a variety of rules for linking, all
ending up in calling $(CC) $(LDFLAGS) for linking at their very end.
IMO, this means we should use something like
LINK.o = $(CC) $(LDFLAGS) in gcc-target-default.cfg
+ modify all gcc-2.8 make-exe rules to use
$(LINK.o) .......
+ setup LDFLAGS according to the requirements of the above.
I.e. we should use $(CC) for linking instead of calling the linker (LD)
directly and set LDFLAGS = $(CPPFLAGS) $(CFLAGS) or similar.
Here is a patch which slightly improves the i386 interrupt handling
macros. These macros were written to use both input and output
parameters, which is not necessary. This patch changes them to use
only an input or output parameter, as appropriate. It also changes
the constraints to permit the interrupt level to be loaded directly in
and out of memory, rather than always requiring a register.
that were accidentally not committed earlier. The DECNet driver
is being added as its own directory to avoid forcing the driver to
have to pull in the complete set of network drivers.
Both the ne2000 and the wd80x3 are based on the National Semiconductor
8390 chip, so there is a fair amount of overlap between the two
drivers. It would be possible in principle to combine some code into
a separate set of subroutines called by both. In fact, the drivers in
both OpenBSD and Linux work this way. I didn't bother, because for
the relatively simple drivers used by RTEMS, the overlap is not
especially large, and any reasonable use of subroutines would lead to
slightly less efficient code.
This ne2000 driver uses two transmit buffers. While one packet is
being transmitted over the Ethernet, RTEMS will upload another. Since
uploading a packet to the ne2000 is rather slow, I don't think there
is any point to having more than two transmit buffers. However, the
code does make it possible, by changing NE_TX_BUFS, although that
would of course reduce the number of receive buffers.
I suspect that the wd80x3 driver would benefit slightly from copying
the multiple transmit buffer code. However, I have no way to test
that.
> 5) rtems-rc-19990202-1.diff/reorg-install.sh
>
> reorg-install.sh fixes a Makefile variable name clash of RTEMS
> configuration files and automake/autoconf standards.
> Until now, RTEMS used $(INSTALL) for install-if-change. Automake and
> autoconf use $(INSTALL) for a bsd-compatible install. As
> install-if-change and bsd-install are not compatible, I renamed all
> references to install-if-changed to $(INSTALL_CHANGED) and used
> $(INSTALL) for bsd-install (==automake/autoconf standard). When
> automake will be introduced install-if-change will probably be replaced
> by $(INSTALL) and therefore will slowly vanish. For the moment, this
> patch fixes a very nasty problem which prevents adding any automake file
> until now (There are still more).
> 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh
>
> reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a
> similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff
> contains the diffs after reorg-score-cpu.sh has been run on a
> rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff.
>
> This patch is rather nasty and may break something. However, I've tested
> it for about 10 different target/bsp pairs and believe to have shaken
> out most bugs.
I wonder about the following .h files that were not moved:
a29k/asm.h
a29k/cpu_asm.h
i386/asm.h
i960/asm.h
m68k/asm.h
m68k/m68302.h
m68k/m68360.h
m68k/qsm.h
m68k/sim.h
mips64orion/asm.h
mips64orion/cpu_asm.h
mips64orion/mips64orion.h
no_cpu/asm.h
no_cpu/cpu_asm.h
powerpc/asm.h
powerpc/mpc860.h
sh/asm.h
sparc/asm.h
sparc/erc32.h
> 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh
>
> reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a
> similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff
> contains the diffs after reorg-score-cpu.sh has been run on a
> rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff.
>
> This patch is rather nasty and may break something. However, I've tested
> it for about 10 different target/bsp pairs and believe to have shaken
> out most bugs.
I wonder about the following .h files that were not moved:
a29k/asm.h
a29k/cpu_asm.h
i386/asm.h
i960/asm.h
m68k/asm.h
m68k/m68302.h
m68k/m68360.h
m68k/qsm.h
m68k/sim.h
mips64orion/asm.h
mips64orion/cpu_asm.h
mips64orion/mips64orion.h
no_cpu/asm.h
no_cpu/cpu_asm.h
powerpc/asm.h
powerpc/mpc860.h
sh/asm.h
sparc/asm.h
sparc/erc32.h
> 4) rtems-rc-19990202-0.diff /reorg-score-cpu.sh
>
> reorg-score-cpu.sh reorganizes the cpu/<cpu>/* subdirectories in a
> similar manner than previous reorg scripts did. rtems-rc-19990202-0.diff
> contains the diffs after reorg-score-cpu.sh has been run on a
> rtems-19981215 snapshot + my patches up to rtems-rc-19990131-2.diff.
>
> This patch is rather nasty and may break something. However, I've tested
> it for about 10 different target/bsp pairs and believe to have shaken
> out most bugs.
I wonder about the following .h files that were not moved:
a29k/asm.h
a29k/cpu_asm.h
i386/asm.h
i960/asm.h
m68k/asm.h
m68k/m68302.h
m68k/m68360.h
m68k/qsm.h
m68k/sim.h
mips64orion/asm.h
mips64orion/cpu_asm.h
mips64orion/mips64orion.h
no_cpu/asm.h
no_cpu/cpu_asm.h
powerpc/asm.h
powerpc/mpc860.h
sh/asm.h
sparc/asm.h
sparc/erc32.h
> 3) rtems-rc-19990131-2.diff
>
> This patch removes generating bsp_specs from leaf.cfg and generates
> bsp_specs from inside of c/Makefile instead.
>
> The motivation behind this patch is to avoid "polluting" Makefiles by
> unneccessary rules from included Makefile-fragments (*.cfg-files) and
> try to handle files by explicit rules in Makefiles instead (FYI:
> automake-1.4 physically includes Makefile fragments at the time
> automake is run, not at the time make is run as RTEMS Makefile.ins do
> now)
>
> Nevertheless, this patch is rather uncritical, almost cosmetical - If
> you don't like it, then dump it ;-, however I doubt that subsequent
> patches will apply then ;-.
> 2) rtems-rc-19990131-1.diff
>
> Rework of compilers/*.cfg files (esp. gcc-target-default.cfg) to adapt
> the flags/makefile variables to automake and make standards (cf.
> make.info - implicit rules/variables).
>
> This patch is rather risky and may probably break things, but is an
> essential step towards automake.
>
> FWIW: It also reverts the i386-ASMFLAGS/ASFLAGS-patch, which was wrong,
> as I had to experience ;-.
> Adds variables to the custom/*cfg files to specify the location of
> tools. The purpose is to remove hard-coded paths from the Makefiles.
>
> In later steps this eases moving the tools to other locations.
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.
allows one to trace the enqueueing and dequeueing of messages. This
can be used to insure that packets are getting to the boundary between
the network stack and the device driver.
I have a few patches for the efi332 bsp. If you let me know when you
expect the next snapshot release, I will try to have them to you
before then. Also, the malloctest has some problems that I would think
would prevent it from running on almost any platform. I have enclose
patches below to fix (1) Task_id and Task_name dimensioning, (2) end
of test message, (3) the amount of memory malloc'ed, and (4) retry on
unsuccessful (out of memory) molloc's.
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.
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.
<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.
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.
automake:
Notes:
* I didn't yet touch the cpu subdirectory. I still need some time to
think on how to handle them.
* I probably will wait for the next snapshot before mailing more patches
(I still have some pending), giving you a chance to apply them and me a
chance to become target of the bullets which will probably be aimed at
me after these modifications.
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.
directory in preparation for automake:
Here is a shell script which reorganizes some parts of the exec/posix
source tree.
This shell scripts moves include files below exec/posix to different
locations than now. It doesn't yet apply automake, but still use the old
autoconf configuration scheme. It doesn't influence the build scheme at
all (unless I corrupted something), only the location of the header
files is different, which would ease applying automake later.
The purpose of this shell script is to demonstrate the style of
structural changes I would like to see in rtems in near future to
prepare a smooth transition to automake. Then CC could pickup rtems'
header files from their location inside of the source tree in future,
instead of the build tree as it is done now.
In case you would accept this patch/script, there would be more similiar
ones to come.
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.
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.
I use the m68k/efi332 BSP together with a home made board. After some
time of debugging I found that the m68020 CPU is used to build rtems.
This is not correct, because the 68332 does not have some of the 68020
features (no separate int stack ...). It is necessary to change this to
mcpu32. After a clean/make everything works fine.
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.
The RTEMS i386 stub in
c/src/lib/libbsp/i386/shared/comm/i386-stub.c
doesn't take advantage of some of the newer gdb remote features which
permits shorter and fewer packets.
Here is a patch which uses the 'T' response to report the registers
which gdb generally needs, and implements the 'P' request to set only
a single register. The general effect is to avoid sending all the
register contents back and forth between gdb and the stub every time
the stub stops. This also implements the 'D' request which handles
the gdb detach command, so you can cleanly quit out of the debugger
and leave the target board running.
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.
Please find attached a new i386ex.cfg. It has been altered to change
the files that get generated with the .nxe extension to .coff. This
change is necessary to align the file names generated by "make-exe" to
the those referred to in the GDB.HOWTO found in the
i386/shared/comm directory. It has been successfully tested on ticker (
without GDB), and base_sp( with GDB ) . I just set a breakpoint and
continue...
I noticed that in the 4.0.0-beta4a tar file, the file
c/src/lib/libbsp/i386/pc386/startup/linkcmds
was changed so that it no longer handles the .gnu.linkonce.r*
sections. The appended patch was applied to the file. I'm not sure
why. I think this patch should probably be backed out, although it's
not critical for the release.
1. Rtems contains some perl scripts that use hard-coded paths to
/usr/bin/perl or /usr/local/bin/perl I have already fixed these
problems by adding some checks to configure.in. While doing this,
I also cleaned up some more autoconf related problems for generating
shell scripts. This patch might seem a bit scary to you, but I am
quite confident it won't break something (I've been testing it for
almost a week now, however it might introduce typos for a limited
number configurations I don't have access to - But it shouldn't be
a problem for you to test them :-).
I expect to get this finished tonight, hence you will very likely
have the patch when you get up tomorrow.
Changes:
* Check for PERL and disable all PERL scripts if perl wasn't found.
* Generate all KSHELL-scripts with autoconf instead of make-script
* Automatic dependency handling for autoconf generated KSHELL or PERL
scripts (make/rtems.cfg)
Notes:
* this patch contains new files and deletes some other files.
* The patch is relative to rtems-4.0.0-beta4 with my previous
rtems-rc-981014-1.diff patch applied.
Testing:
I tested it with sh-rtems and posix under linux. Now all targets
which are touched by this patch and which are not used while building
for sh-rtems and posix still need to be tested. AFAIS, only the
sparc/erc32 BSP should be affected by this criterion. And if you
like to, you should also consider testing it on a Cygwin32 and a
Solaris host for one arbitrary BSP.
2. "make profile" doesn't work. It aborts when building host-tools
for embedded targets. I didn't yet have enough time to fix this
problem. AFAIS this problem is related to handling of
LDFLAGS_PROFILE[|_V] in gcc.cfg.in. For host applications, we use
gcc for linking host applications, too. With profiling enabled
CFLAGS_PROFILE_V contains -pg and is used to compile, but
LDFLAGS_PROFILE_V is empty, hence -pg will not be passed to the
linker causing gcc to fail to link, because it can't resolve some
symbols introduced by compiling with -pg.
I am not sure if I can provide a patch for this - Ether it is trivial
to fix or requires basic work on host configuration ;-
Fixing this one was trivial - But hard to trace.
LDFLAGS_PROFILE_V needs to contain the same flags as CFLAGS_PROFILE_V,
if gcc is used for linking (What else should have been expected ?,
:-). The same problem was present for *_DEBUG_V, but apparently wasn't
noticed by anybody, because things didn't break, but were silently
ignored.
I fixed these problems by setting these flags in configure.in whenever
gcc is reported to be the host-compiler. For non-gcc host compilers
"make debug" and "make profile" now becomes the same as an ordinary
"make". This is a hack and addressing this problen could be more
sophisticated, but I don't think it gives much sense to support
compile variants for any host program (Who will ever try to
profile/debug host tools?). Therefore I don't think it's useful
to invest more effort into this problem.
moves pieces of the pc386 bsp up to a shared level for all i386 BSPs
and modifies the i386ex BSP to use those shared pieces. Serial remote
debugging is included for both targets. Erik's notes:
There are several workarounds in it:
1) #define NEXT_GAS is hardcoded in pc386/start/start.s
2) #define NEXT_GAS is hardcoded in i386ex/start/start.s
3) #define NEW_GAS is hardcoded in pc386/start16.s
4) #undef __assert and redeclare _assert hardcoded in console.c for
both pc386 and i386ex due to my egcs1.1b ~ newlib problem. Should have
modified t-rtems.cfg ( no time )
I've tested pc386 with both video and serial consoles and GDB remote.
All work fine, except that GDB acts weird. ( re: other posting)
I hope this will work for you. It took quite some time to locate the
autoconf error. The remainder was just grunt work.
Unfortunately, I think I've unwound the removal of the IBMPCInitVideo
stuff. Sorry. I REALLY can't spend more time... I've been at this
conversion to 4.0 locally and updating the release since Sept. 8th, and
have yet to compile my network driver.... This is as much as I can do
right now.
I look forward to the next patch to really test i368ex. I did make sure
that the sample tests worked for pc386.
As mentioned in other mails before, there is are minor inconsistencies in the
posix custom/*cfg files.
Linux-posix.cfg sets RTEMS_BSP=posix
FreeBSD-posix.cfg sets RTEMS_BSP=posix
Solaris-posix.cfg first sets RTEMS_BSP=posix, later it sets
RTEMS_BSP=solaris2
1. Setting RTEMS_BSP=posix is redunant to settings in default.cfg
2. The solaris variant of setting RTEMS_BSP is merely non-functional.
The patch attached to this mail should clean up this issue.
The patch was tested by building the posix bsp under
i686-pc-linux-glibc1/glibc2 and Solaris2.6 (I did not run any
rtems program, however) The HPUX9 and FreeBSD configuration files
were adapted in analogy to the solaris and linux configurations.
The reentrant versions of the malloc functions in
c/src/lib/libc/malloc.c
do not match the definitions in newlib. These will be used if you use
newlib routines such as fdopen. I believe this patch to malloc.c is
needed to provide the correct versions.
- 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...
Here's a patch to get rid of the `#define RTEMS__mcpu32p__ 1' when
gen68360.cfg is being used as a companion for gen68360_040.cfg. The
old version worked because of the order of the conditional tests in
m68k.h (the check for __mc68040__ is before the test for
RTEMS__mcpu32p__) , but I think it might have been a little confusing
to others just getting started.
Finally I am through: I have found the last bugs that made RTEMS-
4.0-beta3 start on my ppc403 board from ROM. So now the '403
support is up to date again.
Roughly I have added the following features:
- support for the on-chip interrupt controller (in a separate module)
- interrupt support for the console device
- termios support for the console device
==============================================
Since the BSP behaivour changed in some details (console no
longer is polling, other memory layout etc) I have created a new
BSP "helas403" rather than changing the "papyrus" BSP. The old
"polled" console driver still sticks around in "console.c.polled"
To get the BSP up and running, I had to create the new BSP files
(derived from papyrus). Besides that, the following source areas
have been changed:
- c/src/lib/libcpu/powerpc/ppc403: changes to console driver, small
changes to clock driver, new "ictrl" interrupt controller driver
- 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...
- c/src/lib/libc/termios.c: During my tests, I added one change you
sent me, so this patch will already be incorporated in the current
source tree.
There are some smaller changes, see the attached diff file.
=========================================
Concerning the GNU toolchain:
I tried several tool chains. Finally I almost succeeded with
egcs-1.0.3a with patch egcs-1.0.3-rtems-diff-19980527
I had to add the following lines to the egcs files. Without them
configure complaint that the cross compiler could not generate
executable output.
- additional lines needed in egcs distribution in file
gcc/config/rs6000/rtems.h:
+++ lines start
#undef STARTFILE_DEFAULT_SPEC
#define STARTFILE_DEFAULT_SPEC "ecrti.o%s"
#undef ENDFILE_DEFAULT_SPEC
#define ENDFILE_DEFAULT_SPEC "ecrtn.o%s"
++++ lines end
As far as I have seen in the Changelog of egcs, you have recently
sent two patches affecting the powerpc support, but they were
added in the wrong order.... :-(
egcs-19980628 with patch egcs-19980628-rtems-diff-19980707 does
not work!
I used binutils 2.9.1 with patch binutils-2.9.1-rtems-diff-19980515
(binutils 2.8.1 does not work, internal error in gas)
and newlib-1.8.0 with patch newlib-1.8.0-rtems-diff-19980707
Finally I had to poke a line in the "bit" script, since, on my LINUX
machine, the GNU make is only available as "make", not as
"gmake"...
For all the tools and newlib I selected configuration "powerpc-
rtems".
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: td@imd.m.isar.de
Finally I am through: I have found the last bugs that made RTEMS-
4.0-beta3 start on my ppc403 board from ROM. So now the '403
support is up to date again.
Roughly I have added the following features:
- support for the on-chip interrupt controller (in a separate module)
- interrupt support for the console device
- termios support for the console device
==============================================
Since the BSP behaivour changed in some details (console no
longer is polling, other memory layout etc) I have created a new
BSP "helas403" rather than changing the "papyrus" BSP. The old
"polled" console driver still sticks around in "console.c.polled"
To get the BSP up and running, I had to create the new BSP files
(derived from papyrus). Besides that, the following source areas
have been changed:
- c/src/lib/libcpu/powerpc/ppc403: changes to console driver, small
changes to clock driver, new "ictrl" interrupt controller driver
- 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...
- c/src/lib/libc/termios.c: During my tests, I added one change you
sent me, so this patch will already be incorporated in the current
source tree.
There are some smaller changes, see the attached diff file.
=========================================
Concerning the GNU toolchain:
I tried several tool chains. Finally I almost succeeded with
egcs-1.0.3a with patch egcs-1.0.3-rtems-diff-19980527
I had to add the following lines to the egcs files. Without them
configure complaint that the cross compiler could not generate
executable output.
- additional lines needed in egcs distribution in file
gcc/config/rs6000/rtems.h:
+++ lines start
#undef STARTFILE_DEFAULT_SPEC
#define STARTFILE_DEFAULT_SPEC "ecrti.o%s"
#undef ENDFILE_DEFAULT_SPEC
#define ENDFILE_DEFAULT_SPEC "ecrtn.o%s"
++++ lines end
As far as I have seen in the Changelog of egcs, you have recently
sent two patches affecting the powerpc support, but they were
added in the wrong order.... :-(
egcs-19980628 with patch egcs-19980628-rtems-diff-19980707 does
not work!
I used binutils 2.9.1 with patch binutils-2.9.1-rtems-diff-19980515
(binutils 2.8.1 does not work, internal error in gas)
and newlib-1.8.0 with patch newlib-1.8.0-rtems-diff-19980707
Finally I had to poke a line in the "bit" script, since, on my LINUX
machine, the GNU make is only available as "make", not as
"gmake"...
For all the tools and newlib I selected configuration "powerpc-
rtems".
--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: td@imd.m.isar.de
test were suggested by Ian Taylor <ian@airs.com> and Joel did the
hard part of putting it in aclocal and editting all the offending
Makefiles and source code which could use this feature.
<ian@airs.com>:
The pc386 linker scripts omits .gnu.linkonce.r* sections. It's not a
big deal, but they should be treated like .rodata sections. ELF
versions of g++ generate them for static constants defined in template
classes, such as string::npos.
The pc386 linker scripts omits .gnu.linkonce.r* sections. It's not a
big deal, but they should be treated like .rodata sections. ELF
versions of g++ generate them for static constants defined in template
classes, such as string::npos.
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.
Please find enclosed a patch which enables me to build the bare-bsp for
sh-rtems.
Changes:
1. Add preinstall to libbsp/bare/include/Makefile.in
2. Removed FORCEIT, add preinstall to
libbsp/sh/gensh1/include/Makefile.in
3. Disabled support of set_vector from sh code (shared/setvec.c is still
present but isn't used anymore), set_vector replaced with standard rtems
functions.
Problems still present:
1. Support of spin-delays in bare bsp
2. Proper support of cpu frequency
To configure I used:
<srcdir>/configure \
--target=sh-rtems \
--prefix=<instdir>/sh-bare \
--enable-bare-cpu-model=sh7032 \
--enable-bare-cpu-cflags='-Wall -m1 -DMHZ=20
-DCPU_CONSOLE_DEVNAME="\"/dev/null\""'
--enable-rtemsbsp=bare \
--disable-networking \
--disable-cxx \
--disable-posix \
--disable-tests
IMO, if there are no objections to this patch, a similar approach should
be applied to all CPUs/BSPs (esp. hppa1.1, mips64orion, ppc403, because
they apply set_vector inside of libcpu).
Remember the test to see if a socket could be read and written at
the same time by two different tasks? I discovered that if both
tasks attempt to close the socket a panic can occur from inside the
BSD code.
Closing the same socket twice from two different threads is
certainly an error, but a panic is not the greatest error reporting
method :-)
The following small change to the socket close routine should reduce
the chances of the panic.
Please find attached a start.s that includes a cli prior to the hlt
instruction. This ensures that external interrupts cannot restart
the system after returning to the startup code. ( According to the hlt
docs, they will! )
Also find a new timer.c. ( I forgot to update the countdowm value
in the timer when I changed the PSCLK frequency in start.s) . This
improves timer accuracy.
The raw_idt_notify messages are no longer infinite, I tested sp11 and
sp05, both which were bad, and I have seen the message print once in
one test. I think it's ok if it prints out once. In fact, I don't
think you can effectively stop it!
Please find attached the two files that have been changed relative to
980921 . The changes here are in the handling of the counter-timer used
as the basis for the rtems executive clock. For the most part, these
are housekeeping changes.
The PSCLK frequency change in start.s... was a part of several
bug-fixes. The fix improves executive clock and timer accuracy.
changes :
start.s -- All timers are disabled by the initialization routine
-- PSCLK ( used by clock and timers ) frequency changed to 1MHz
The clock_initialize routine now assumes that the PSCLK frequency is
exactly 1 MHz.
ckinit.c
Clock_isr -- removed division by 1000. Now use 'static'
variable -- clock_intial_isr_value -- to reset Clock_isrs variable.
clock_initialize -- moved counter timer initialization here. Values
used to configure the timer are totally dependent on
BSP_configuration.microseconds_per_tick ( and the PSCLK assumption).
Initializes clock_initial_isr_value used by th Clock_isr to reset
Clock_isrs.
clock_on -- no longer configures the timer, just enables it.
Since altering the number of sections in the BSP, I decided to give it a
good "once over" . The clock handling is now cleaner.
1. Finally fixes raw interrupts for pc386
2. Makes some minor cleanup in console and startup
3. Makes rtems_termios_dequeue_characters() to return count of
outstanding chars - it allows to simplify console isrs a little
bit.
4. pc386 uart modified to be friendlier to termios parameter changes,
to have minor performance improvement and to take advantage of
of above termios modification.
Here's a patch to make the rtems_showroute routine a little more
useful. For `host' route table entries the link-level address is now
displayed. This is equivalent to the old `show arp table'
information displayed by the KA9Q code.
Here are patches that bring 980911 back to what I think is a correct
version of raw IDT management as well as a correct initialisation
of video console and rtems managed interrupts.
I fixed the problems noted by Victor Vengerov.
1) Fix typo in cfsetispeed().
2) In rtems_termios_open, ensure that args->iop->data1 is set before calling
device-specific open routine.
I've fixed a few minor probs with the optimised version that Eric put
together for me the other day and sent the fixes back to him. Provided he
doesn't have a problem with it we've got a pretty solid in_cksum for the
ColdFire as well as straight m68k. I've enclosed my updated in_cksum_m68k.c
At the moment my own bottlenecks are elsewhere...as my driver is pulling
16bit data chunks through a libchip-esq access routine from the chip which
for a polled I/O device is never going to be quick.
I have managed to build the bsp ods68302 and the rtti test case I made
with egcs-1.1b and binutils-2.9.1.
I have built our C++ application and got no link errors so it looks like
this is now working. I am yet to test the code but getting the thing to
link was the problem.
Please find a patch attached which removes the -fno-rtti option.
in a previous patch. Comments from Eric:
patch_com2 was before your own fixes of raw IDT vector management
routine.
It mainly use human readable constants for the serial line driver code
+ the patch you gave me for com2 write routine.
I applied your patch for raw IDT mngt on top of that. Then made minor
cleaning in patch_idt_mngt. I hope this helps.
After some good comments from Eric Norum [thanks, Eric !],
I have added some modifications to my previous driver patch :
- wait for transmitter ready before sending a packet,
- new delay management in case of ring-overwritting.
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 brief description of the attached patch :
1) There was a bug in the code for the COM2 serial line driver. Aleksey
gave me a fix that fixes the driver code itself. I would like to thank
him again publicly,
2) I introduced constants in the serial driver code because I had a hard
time reading the meanning of hexadecimal values in the NS data book :)
3)You can now mix printk and printf on serial line (tested on COM2).
There is a #ifdef PRINTK_ON_SERIAL in console.c that enables to have
printk on console while printf on serial line,
4) Removed call to displayCpuInfo because anyway if was at the wrong
place for serial line console (too early). It can anyway be called at
application level,
5) The original printk was unable to display negative integer values
and was also recursive. It now works corectly,
All the modifications have been tested here on the COM2 port from
a PC running RTEMS to a PC running linux,
NB : there is still a bug on PC386 serial line : exit does not flush the
remaining output queue. As this is not a bug in the driver itself but
somewhere in PC386 initialization/termios relationship it will be part
of another patch.
NB2 : As Emmanuel excerced the exception hanlder code, while porting the
SMC driver to the new BSD stack, we found a bug in the exception
handler : it shall not delete the current thread in case we are running
at interrupt level. This will be part of another patch...
I think I figured out why rtems_panic was locking up instead of
shutting down the executive and returning to the code that called
boot_card().
Later on there is code to print some messages on the standard error
stream, a recursive call back to rtems_verror (through rtems_error)
and finally a call to _exit().
I think that the _Thread_Disable_dispatch() is preventing the final
context switch back to the boot_card() code. Does this sound right
to you?
Celso Labinaz <labinaz@tin.it> pointed to me thatthe console on serial
line was not working. After spending quite a time to find the right
cable and software, I confirm this.
I'm going to debug this in the next days because I want to use the
serial line for debugging. In the meantime, in order to be sure that
this was a driver initialization/bug, I made printk work on the serial
line in order to be sure the receiver part and configuration was OK.
Here is the for printk on serial line. BTW, does anyone else use the
serial line facilities for PC? printf seems to output nothing (hello.exe
output everything that has a printk but application printf seems to be
broken).
The patch (rtems-rc-980821.diff) I had sent recently to fix the "make
install" problem in rtems-980821/make/ still contained a bug (Thanks to
Eric N. for reporting it).
The patch enclosed to this mail is a corrected version of this patch,
which finally should fix this problem.
Here is another patch to hopefully enhance rtems' configuration.
Motivation: Try to support other c-compilers besides gcc (I tried to
build rtems under Solaris using sun's WSPro c-compiler).
Here is a couple of small patches concerning the host compiler
configuration, which fix/work-around the worst problems when using sun's
WSPro c-compiler.
Changes:
* Replaced make/compilers/gcc.cfg with make/compilers/gcc.cfg.in, ie.
gcc.cfg is generated by configure now.
* Removed a line containing a hard-coded "gcc" from gcc.cfg (BUG-fix).
* Add -g to host compiler flags only if configure reported -g to work
* Add -Wall to host compiler flags only if configure reported that the
host compiler is gcc (WSPro's cc chokes on -Wall).
* Some modifications to make/Makefile.in
* Adapted make/custom/default.cfg to the new location of gcc.cfg
BTW, gcc.cfg/gcc.cfg.in seems to be full of unused code (DEBUG-VARIANTS
etc.) which deserves to be cleaned up, IMO.
IMO, a similar patch should be applied to gcc-target-default.cfg
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...
"Thomas Doerfler" <td@imd.m.isar.de> wrote:
>
> While implementing/testing the console/termios support for
> PPC403 in RTEMS-4.0.0-beta3, I am stuck at a certain location in
> termios.c:
>
> During "rtems_termios_initialize", the main control data structure
> "*tty" is allocated using malloc(). (Note, that malloc does not
> clear the allocated memory and my BSP does not clear memory during
> startup). Furtheron, a lot of fields of that structure are
> initialized, but the field "rawOutBufState" is not, and therefore
> keeps an arbitrary contents.
>
> When "osend()" is called the first time(with the serial device
> driver working in interrupt mode), termios gets stuck and will not
> call the device drivers output function.
>
> My questions now are:
>
> - anybody already experienced this bug?
> - is it a bug at all or did I do anything fundamentally wrong?
> - is there already a common bugfix for that?
>
> I don't like poking around in other people code, as long as I am
> not absolutely sure, what I do...
Yes, there's a bug there.
I thought that Joel had patched this already, but here's a patch to
fix this. This patch also addresses a concern that many others have
raised regarding enabling and disabling of transmitter interrupts.
First, here's the example I've been using of a simple UART-style
interrupt-driven driver:
===============================================================
void
device_write_routine (int minor, char *buf, int count)
{
UART->control_register &= ~UART_TRANSMITTER_READY;
UART->output_register = *buf;
UART->control_register |= UART_TRANSMIT_INTERRUPT_ENABLE;
}
void
device_transmit_interrupt_routine (int vector)
{
UART->control_register &= ~UART_TRANSMIT_INTERRUPT_ENABLE;
rtems_termios_dequeue_characters (device_ttyp, 1);
}
==============================================================
Several people have expressed their concern about the disable/enable
of transmitter interrupts for every character. On some machines
this disable/enable is an expensive operation. With the attached
patch applied you can write the two routines as:
==============================================================
void
device_write_routine (int minor, char *buf, int count)
{
code_to_clear_transmitter_ready_status ();
if (device_ttyp->rawOutBufState == rob_idle)
code_to_enable_transmitter_interrupts ();
code_to_send_one_character_to_transmitter (*buf);
}
void
device_transmit_interrupt_routine (int vector)
{
rtems_termios_dequeue_characters (device_ttyp, 1);
if (device_ttyp->rawOutBufState == rob_idle)
code_to_disable_transmitter_interrupts ();
}
===============================================================
- 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...
This patch has same changes as one I sent to you earlier plus
it fixes _heap_size problem for pc386 we had discussed earlier.
Now, _heap_size is defined and set to 0 in pc386/startup/bspstart.c
It can be patched to desireable value in binary image. If it is
left unpatched, then startup code will determine size of memory
(on the assumption that at least 2MB are present) and use
max possible heap.
make solaris target buildable.
> 1. The ipc check fails since solaris does not define union semun.
> The unix port code actually defines this type itself on solaris. Doing
> the same thing lets it get configured. Then...
> 2. It looks like BSDINSTALL is not defined properly.
BSDINSTALL is defined in make/host.cfg.in as
BSDINSTALL=@INSTALL@
@INSTALL@ is generated by autoconf's standard macro AC_PROG_INSTALL, which
is widely used in almost any autoconf/automake configured package. In case
there is really something wrong with it, then it must be considered a bug
in autoconf.
I can see a doubious fragment in AC_PROG_INSTALL, which is used when no
appropriate bsd-install is found.
Finally Ralf saw a problem with the find on solaris which I also saw and
fixed.
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.
Moved CAM Descriptor types to sonic.h.
CAM memory is now malloced to insure it shares the same upper address bits.
Removed increment of RX interrupt count on TX interrupt path.
Added SONIC_DEBUG_FRAGMENTS and SONIC_DEBUG_CAM conditionals.
Fixed bugs in fragment manipulation. First bug was that the pad overwrote
the last fragment. The second bug was that the link information overwrote
the size of the last fragment.
Rewrote initialization of TDA to simplify it.
Added pointer to RDA to sonic structure.
Added macro names for values used in the in_use field of RDA entries.
Rewrote the RX Descriptor Area initialization loop.
Added a check to barf if this is a Rev B sonic chip.
Enabled check that the CAM was properly loaded.
This primarily included setting the state of the programmable outputs
and the RX and TX FIFO depths.
Moved all of the TX, RX, and RRA data structure initialization to before
the hardware initialization. As part of this, the hardware initialization
was consolidated. More than likely, some of this movement broke stuff.
Used constants added to sonic.h which gave more logical names to some
of the register bit settings.
Switched to calloc to insure the data areas where initialized to 0.
Commented out a panic check in the RX server which may or may not have
been right.
Increased the size of the CAM initialization area. It is possible
that this could be decreased or code added to handle the management
of multiple hardware addresses.
Added sonic read and write register routines which aid greatly in
debugging and provide the core for the eventual movement of this
driver to libchip.
Added debug code to the read and write register routines which can
print the value read from or written to a register. This code also
prints the register name which significantly eases reading the log.
Reworked transmit interrupt processing to remove ring buffer and
to mask the TX empty interrupt when it was not expected. This code
now uses termios to buffer TX output.
Here's a small patch I forgot about from earlier in the week that removes
the hack fix Geoffroy had to use to get his BSP to work properly.
The termios osend() fix took care of this.
Here is a patch for KA9Q stack.
This patch contains an Ethernet Driver for Western Digital,
some fixes for the UDP and TCP protocols (for endian conversion)
and some little programs which allow the test of UDP and TCP
sockets via Ethernet.
I have tested that on an Intel machine. If someone can test it
on a big-endian machine, ...
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...
<corsepiu@faw.uni-ulm.de> which attempts to detect when the UNIX port
is being configured on a system without System V IPC support. This
is an optional component on both FreeBSD and Linux systems. Most
Linux 2.x kernels ship with it enabled but it is still a real risk.
This test may have undesirable side-effects on some hosts. We will
address those conflicts as they arise.
Deleted CSS interface related items.
Added items required to access DMA Control and Status Register so we
could figure out dynamically what the clock speed of the SCC really is.
RS-422 converter. We now see the TD light blink when typing
characters in HyperTerminal and when the board is reset we see
the RD light blink. This leads us to believe the cabling is
basically right.
returned a buffer which was not zero-filled, the reference count
was not correct. When the application exitted, the "lastClose"
handler was not being called to flush the output. This problem
had manifested itself on a variety of platforms.
The function rtems_termios_dequeue_characters() incorrectly incremented
the buffer pointers when it was invoked and there were no characters
in the ring buffer. This problem had also manifested itself on a
variety of platforms. The symptom was a strange repeating of the
data in the transmitter buffer when the transmitter serial device
was supposed to go idle.
* Added support for bsd "install" ($(BSDINSTALL)) to host.cfg.in, i.e.
the standard "install" program that most packages (including automake)
use. In Makefiles outside of rtems, "install" normally is referenced by
$(INSTALL), but rtems already uses $(INSTALL) for install-if-change,
hence I used $(BSDINSTALL) instead to keep up backward compatibility.
* Removed references to @GREP@ etc. from host.cfg.in, as configure.in
doesn't check for them (Minor cleanup).
* Added installation flags INST*FLAGS to host.cfg.in, which should
replace -m XXXX flags for installation calls.
*Changes to gcc.cfg to enable it to build host programs from multiple
sources files.
Should not disturb existing sources, but neccessary.
* There was a not-so-minor bug in the configuration files: "make
install" and "make debug_install" don't work in all subdirectories!! I
tried to fix this by adding "install" to MTARGETS in main.cfg, which
seems to solve most of the problems. But there still seem to be rare (?)
cases where "make debug_install" still seems to have problems.
* Changes to many host related tool-Makefiles to demonstrate the
abilities of INST*FLAGS, BSDINSTALL and the new rules in gcc.cfg.
..of cause ... but BSDINSTALL is THE standard method to install files
in most program packages besides rtems. This part of the patch fixes
some minor protection setting problems, but doesn't support
TARGET_VARIANTS
NOTE:
I hope you will like the BSDINSTALL, INST*FLAGS stuff. It is a step to
get rid of "install-if-change" and to rely on a more standard
installation procedure. If you don't like BSDINSTALL, removing it from
the patch isn't difficult- just grep for BSDINSTALL and replace
BSDINSTALL with INSTALL or MKDIR.
FINALLY:
I still have another patch pending (well, not a complete patch yet, it's
a partial patch to demonstrate the principle), which adds automatic
rebuilding of files generated by autoconf/configure. At the moment I
don't dare to submit it, because integrating this patch would require to
modify all Makefile.ins because we'd need to add a new "include " line
to each Makefile.in.
* c/src/exec/score/tools/sh - NEW DIRECTORY - contains shgen
Most of it should be self-explanatory. I am a little bit concerned about
host-dependent features (getopt, floating point libraries). This
shouldn't disturb much now, as this tool should be compileable on all
gnu-based hosts and is only applicable for the sh. But in case somebody
complains, we may need to add autoconf checks or even restructurize
parts of rtems (IMO, rtems needs to be restructurized - remember the
"turning rtems upside down" issue).
Haven't had a chance to do an extensive shake-out of 980710, but it
builds just fine on FreeBSD 2.2.5 (after termios is fixed using the
attached patch), and the tests run fine. FYI: FreeBSD doesn't support
System V IPC out of the box, but one only needs to add three options
to the kernel build configuration file, recompile the kernel, and
you're ready.
the need for the ringbuffer manipulation in this driver. It should
also allow the removal of mc68681_flush. This greatly simplified the
interrupt processing.
Reworked Interrupt Mask Register handling. Added imr field to the device
context. This handling makes sure that the IMR accurately reflects the
state of the port in use and its mate. This required the reworking of
the mc68681_enable_interrupts() routine to allow for the specification
of which interrupt sources were being enabled/disabled.
Reworked initialization to reset using port address rather than chip
base address. Basically we were always resetting port 0.
Added deviceType field which allows for multiple chips of the same
class to have the same vector number.
driven.
Redid "mate determination" code to check that the chip base address was
the same but the port address was different.
Moved mc68681_process and mc68681_build_imr to the bottom of the file
so they would not be inlined.
Removed the code which forced mc68681_build_imr to always return 0 which
resulted in interrupts never being enabled from the chip.
Corrected spacing in prototype of mc68681_write_support_int.
<corsepiu@faw.uni-ulm.de> and his comments are below:
Joel, obviously you did apply my previous patch to
gcc-target-default.cfg -- This should have been gcc.cfg
(gcc-target-default.cfg should NOT contain any EXEEXT).
c/src/lib/libbsp/i386/pc386/console/console.c
__assert() modified so it prints on selected console instead of
PC console
c/src/lib/libbsp/i386/pc386/console/inch.c
inch_sleep() modified, so it does not depend upon tmacros.h
c/src/lib/libbsp/i386/pc386/pc386dev/GDB.HOWTO
description updated
c/src/lib/libbsp/i386/pc386/startup/exit.c
last output before call to exit() will be printed properly on
serial console
c/src/lib/libbsp/i386/pc386/startup/irq.c
re-submitted bug fix for problem in irqs over 7.
> It seems that rules for %{EXEEXT} don't exist in gcc-target-default.cfg
No, gcc-target-default.cfg is used to compile executables for the target
only, not for the host.
EXEEXT may only be used for programs to be run on the host.
> What should I add please?
This was a bug in my initial configuration patch to rtems-980616. A
correction to this patch I had sent to Joel at 26.06.98 doesn't seem to
have made it into the snapshot.
Please find attached the patch I had sent to Joel, hopefully this patch
fixes this problem.
With a bit of help from Ralf I was able to trace the problem with sed. It
was a typo, sed should have had it's params surrounded by 's rather than "s
which bash picked up and discarded. The patch is enclosed.
Ralf and I aren't sure why configure didn't just stop at this point... The
rest of configure/build went OK because there are two sections where the
\\-for-/ hack is implemented and the other one is more important and worked
just fine.
Temporarily "if 0" of code which enables interrupts.
Moved setting of command registers at open but the current implementation
is questionable.
Added reset of RX errors while polling TX.
Read polled character as unsigned.
Baud rate mask must be in upper and lower nibble.
globally visiable to ease debugging.
Added support for mc68681 "2 column" style baud rate table as
well as the Exar 88681 "4 column" style baud rate table.
Added support for user override of the default baud rate table.
Exar 88681 but not in the base 68681.
Added support for user provided baud rate tables. This is needed
when the board does not use the standard baud rate clock.
for the z85c30 found on the DMV177. This effort started with the
console driver from the Radstone PPC2. But some simplifications were
made in the hope that console.c can be made a shared file at some point
in the near future.
Split the debugio from console. This was done so at some point in the
future printk support as is found in the pc386 BSP can be shared
across all BSPs.
<qqi@world.std.com>). Unfortunately after merging these,
the pc386 will not boot using grub for for. It still does not
work using netboot for me. Here is his summary of changes:
rtems/c/src/lib/libbsp/i386/pc386/Makefile.in
Added support for new sub-directory
rtems/c/src/lib/libbsp/i386/pc386/bsp_specs
Made possible to build COFF image
rtems/c/src/lib/libbsp/i386/pc386/console/console.c
Added support for serial consoles, selectable by patching
binary image, added __assert(), use _IBMPC_inch_sleep()
instaed of _IMBPC_inch()
rtems/c/src/lib/libbsp/i386/pc386/console/inch.c
Added _IMBPC_inch_sleep()
rtems/c/src/lib/libbsp/i386/pc386/console/outch.c
Oops - just formatting
rtems/c/src/lib/libbsp/i386/pc386/include/Makefile.in
Added support for new files
rtems/c/src/lib/libbsp/i386/pc386/include/bsp.h
Added support for new features
rtems/c/src/lib/libbsp/i386/pc386/include/pc386uart.h
New file: definitions for serial ports
rtems/c/src/lib/libbsp/i386/pc386/include/pcibios.h
New file: definitions for PCI BIOS
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/Makefile.in
New file: makefile in new directory
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/i386-stub-glue.c
New file: i386-stub interface
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/i386-stub.c
New file: i386-stub itself
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/pc386uart.c
New file: serial ports
rtems/c/src/lib/libbsp/i386/pc386/pc386dev/pcibios.c
New file: PCI BIOS support
rtems/c/src/lib/libbsp/i386/pc386/start/start.s
Commented out DEBUG_EARLY stuff, everything is working fine
rtems/c/src/lib/libbsp/i386/pc386/start/start16.s
Cleaned up
rtems/c/src/lib/libbsp/i386/pc386/startup/bspstart.c
Added call to console_resereve_resources
rtems/c/src/lib/libbsp/i386/pc386/startup/exit.c
Added support for serial console
rtems/c/src/lib/libbsp/i386/pc386/startup/ldsegs.s
Fixed typo in comments
rtems/c/src/lib/libbsp/i386/pc386/tools/Makefile.in
Changed to reflect cnages in code
rtems/c/src/lib/libbsp/i386/pc386/tools/bin2boot.c
Trivialized, problem - I do not know how to make patch
remove obsolete files - there are a lot of them there
rtems/c/src/lib/libbsp/i386/pc386/tools/binpatch.c
New file: utility to do binary patches
rtems/c/src/lib/libbsp/i386/pc386/wrapup/Makefile.in
Added support for new directory
rtems/make/custom/pc386.cfg
Add COFF image building
made no attempt to divide the comments up and place them with just
the appropriate files. Here is an excerpt from Ralf's email:
Changes including comments on changes I made after cycling through
all the targets:
* Added ranlib support. Now all targets use "ranlib" instead of "ar -s"
to build an index for a library. If ranlib isn't detected during
configuration, check if ar -s is working and try "ar -s" instead of
* Removed $(XXX_FOR_TARGET) from make/target.cfg.in, use $(XXX) instead now.
* gcc-target-default.cfg: LINK_XXXX-defines reworked to solve the -l
problem under posix (cf gcc-target-default.cfg)
* rtems-glom replaced by Makefile-rules inside of the wrapup/Makefile.in
that has been using rtems-glom until now.
* Removed CCC and friends in gcc-target-default.cfg, as they have been
breaking CXX support.
* Removed CONFIG.$(TARGET_ARCH).CC lines from several custom/*.cfg
files, because this is now set in custom/default.cfg.
* Added aclocal/ar-s.m4, check whether "ar -s" is working
* Added aclocal/cygwin.m4 and aclocal/exeext.m4.
* Reworked aclocal/canonicalize-tools.m4: Added ar -s check; fixes for
problems when XXX_FOR_TARGET is given via environment variables (didn't
work for gcc until now), adding cygwin check, improved autoconf-cache
handling.
* Removed -l from make rule dependencies. LINK_LIBS is now allowed to
contain -L and -l. LINK_OBJS and LINK_FILES must not contain -L or -l.
gcc28 make-exe rules now link using $(LINK_OBJS) $(LINK_LIBS) => Almost
all custom/*.cfg are modified. This is very likely to break something
because of typos or having missed to edit a file.
Open problems, known bugs, things I didn't do:
* custom/p4000.cfg seems to be out of date and requires to be reviewed.
(JRS NOTE: It is subordinate p4650 and p4600 -- both of which build ok
after minor changes.)
* custom/psim.cfg needs to be reviewed, I added some changes to it, I am
insecure about.
(JRS NOTE: psim had a minor problem endif/endef swapped but runs fine.)
* rtems-glom.in can now be removed.
* gcc*.cfg files "make depend" rules don't honor language specific flags
(e.g CXXFLAGS is ignored for *.cc) - Nothing to worry about now, but may
cause problems for hosts/targets not using gcc or rtems-add-ons that use
external packages.
* AFAIS, the no_bsp BSP can't be build anymore, i.e. configure refused
to configure for it whatever I tried.
* The toplevel and toplevel+1 README files are quite out-dated
* cygwin.m4 isn't of much use for rtems. In most cases (cf.
aclocal/*.m4) it is worked around by directly using $host_os. I think
I'll remove it soon after the next snapshot
* Before release the cygwin patch needs to be tested under cygwin. I may
have broken/missed something (esp. the sed-pattern to convert \\ into /
may be broken).
* You should try to build/run the posix-BSP under solaris - I don't
expect problems, but I am not 100% sure, esp. with regard to ranlib/ar -s.
* You should consider to convert all make/compilers/*.cfg files into
make/compilers/*.cfg.in files and let autoconf generate the *.cfg. This
may help getting rid of some if/then/else statements and help
hard-coding some defines into those files in future and shouldn't
disturb now.
* Not having installed libc.a/libm.a on a host may still break building
rtems, esp. when using -disable-gcc28 as the gcc27-configuration scheme
directly accesses libc.a and libm.a. The problem should not appear when
using gcc28 because it references libc/libm only through -lc and -lm
which may be static or dynamic (I didn't test this).
* shgen is not yet included (I didn't yet have enough time to integrate it).
* I know about a few more configure-probs (esp. cross-checking
--enable-* flags).
+ warn/refuse to configure when --enable-libcdir and
--enable-gcc28 are given.
+ force --enable-libcdir when --disable-gcc28 is given
* Replaced KSHELL with @KSH@ in some shell scripts generated by configure.in.
* Added a dependency to aclocal/*.m4 in the toplevel Makefile => configure
and aclocal.m4 will now be rebuild when any aclocal/*.m4 file is changed
* Some changes to aclocal/gcc-pipe.m4 and aclocal/gcc-specs.m4
* Replaced i[[3456]]86-unknown-freebsd2.[[12]] with i[[3456]]86-*freebsd2.*
in configure.in, as I suppose there might exist a variety of valid vendors
(2nd field of the name-tripple)
* Disabled override MAKEFLAGS in toplevel Makefile.in - Potential
side-effects are not really clear to me.
* In mvme162.cfg, $(LINK_LIBS) is missing in the CC line in gcc28's make-exe
rule (yet another one I missed to edit). Just append $(LINK_LIBS) to
the "CC" line, like I hopefully did to ALL other custom/*.cfg files.
* the problem with mvme162lx.cfg is a follow-up problem of the
mvme162.cfg-bug.
* mvme162/console and idp/console had variables named Buffer which
conflicted with similarly named variables in some tests.
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.
automatic handling of RTS/CTS. This only protects the on-chip buffers
and FIFOs -- not the termios queues as the RTS/CTS code in here did. It
may be necessary in the future to enable this automatic support.
Interrupt processing code added.
In some places, channel and duart base addresses were swapped.
task to be deleted was created via the same API (i.e. were of the object
class created by this API). For example, a POSIX thread calling
the rtems_task_delete(SELF) directive would incorrectly update the RTEMS
object local pointer table.
Jennifer discovered this when moving tests implemented in C using the
Classic RTEMS API into a tree of Ada tests. The Ada tests were implicitly
using POSIX services. This lead to some unexpected behavior.
of seconds since 1988 from RTEMS and not adding in the 1970-1988 correction
factor. Plus removed checks for data/time set since POSIX does not permit
this call to fail. GNAT 3.12 depends on this.
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.
This was called the dmv170 BSP in that source tree but since the DMV171
is now obsolete, we have transitioned to the DMV177 and have no intention
of checking compatibility with any other models.
+ DEBUG_EARLY_START re-added (Eric Valette)
+ segment register initialization (Aleksey/Quality Quorum)
+ heap size use correction
+ more debug printk's
+ increased heap size.
Now works with grub boot on all systems I have access to including
desktops and a laptop. This is with the i386-rtems tools.
Neither i386-rtemself nor netboot produces a working executable.
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...
Bare BSP is now only enabled when explicitly specified.
Bare BSP options and variables are clearly named so as to be obviously
BSP specific. This should avoid conflicts.
Eric Norum per request from Geoffroy Montel:
> The rtems_termios_enqueue_raw_characters function type is void.
> The problem is that I can't return an error message if the input
> buffer is full.
> Could we add a return value?
Sure, but what would you do with the overflow indication? POSIX says,
``when the input limit is reached, the saved characters are thrown away
without notice''.
Anyhow, the change is so small I've done it and enclosed the patch.
The breakdown:
* CC_FOR_TARGET and CXX_FOR_TARGET were not correctly re-read
from autoconf's configuration cache (config.cache)
* If <target>-[gcc|g++] was not found while running configure,
the config macros tried to use other (wrong) compilers (e.g. cc).
Changes:
* New RTEMS_PROG_CC macro (aclocal/prog-cc.m4).
* New RTEMS_PROG_CXX macro (aclocal/prog-cxx.m4)
* Moved a shell script fragment from configure.in to a
new m4-autoconf macro (New file: aclocal/tool-prefix.m4)
* Minor changes to configure.in
I tested it with linux/posix (native gcc/primary libc) and
sh-rtems/gensh1 on a linux host and didn't notice any bugs
related to the problems mentioned above. There seem to be
more bugs with the posix bsp, but I consider them minor as
the build run completed successfully. It is just too late
for me to attempt to fix them now.
is now correct enough where this is not necessary. This was in to
cover up the deficiencies in figuring out how much memory a GNAT/RTEMS
application required. There is a good stab at this now.
advantage of this instruction.
Also up conditionals mapping cpu models to feature flags by having a
section which defaults all the i386 family feature flags to the most
common value.
This makes the headings line up above the columns a little better.
Now that it's so easy to include/exclude the stack check code I find
myself adding it to all my `debug' targets.
* Posix BSP configuration: Moved some rules from make/custom/*-posix.cfg
files to make/custom/posix.cfg, Removed references to stdc++ from
*posix.cfg files (rtems doesn't use/need libstdc++)
NOTE: Building Posix-BSPs should now work again for native compilation with
gcc, i..e. linux using primary compiler and primary libc.
All Posix-BSP configurations that don't use gcc as primary compiler or
don't use the primary libc don't work, e.g. solaris, linux w/ egcs as
secondary compiler won't be built correctly.
use a wildcard rule instead of explicit listing all include files
(I have more libcpu header files than the public version has. This patch
removes the need to patch this Makefile for my private bsps)
+ POSIX threads
+ Ada tasks
+ POSIX threads API support
+ POSIX condition variables
+ POSIX keys (still do not account for data fields)
+ POSIX mutexes
+ POSIX queued signals
+ added macro for extra memory for task stacks
+ default value for CONFIGURE_MAXIMUM_FAKE_ADA_TASKS
+ extra memory for Ada task stacks
code in each BSP's bspstart.c. These changes were:
+ confdefs.h now knows libio's semaphore requirements
+ shared/main.c now copies Configuration to BSP_Configuration
+ shared/main.c fills in the Cpu_table with default values
This removed the need for rtems_libio_config() and the constant
BSP_LIBIO_MAX_FDS in every BSP. Plus now the maximum number of open
files can now be set on the gcc command line.
to multiple. This lets the stack check extension be installed
at system initialization time and avoids the BSP having to
even know about its existence.
to multiple. This lets the stack check extension be installed
at system initialization time and avoids the BSP having to
even know about its existence.
Here are some patches to the gen68360 BSP. The improvements include:
Boot prom run-time selection of DRAM size (1/4/16 Mbytes)
Full 32-bit ethernet address obtained from boot prom.
Updated README.
Here are some patches to the gen68360 BSP. The improvements include:
Boot prom run-time selection of DRAM size (1/4/16 Mbytes)
Full 32-bit ethernet address obtained from boot prom.
Updated README.
based on the GNU tools. This usually involved correcting the
type of bsp_start(), bsp_cleanup(), adjusting the start code to
call the right start routine (the shared boot_card()), and then
removing code from bsp_start() which was performed in the new
boot_card()/main() path.
I've included a version of make/custom/gen68360.cfg that works with
this. Note that I've removed the option of using `-m68020
-msoft-float -mno-bitfield' as an alternative to using `-mcpu32'.
The alternative won't work with the new system (since it predefines
__mc68020__ and not __mcpu32__), and didn't really work before anyway
(since the newlib that gets linked was built with `-m68020
-msoft-float' and so could contain bitfield operators).
Here is my attempt at bringing m68k.h into line with the predefined
symbols provided by egcs-1.0.2-prerelease (with R. Kirkham's patch so
that -mcpu32, etc. implies -msoft-float).
Here's another small patch. The changes to socket.h are to provide
some definitions that UNIX BSD socket programmers expect. The
memcpy.c contains a memcpy routine optimized for the CPU32+. When I
run the ttcp benchmark with this routine I get host->68360 transfers
around 165 kbytes/sec (about a 25% improvement) and 68360->host
transfers of around 290 kbytes/sec (about a 50% improvement).
While trying to work through this problem I decided that the
build-time selection of the console I/O operation (polling or
interrupt) was too clumsy. Here's a patch that allows run-time
(actually init-time) selection of the console I/O mode.
It also shows the need for another `flags' or `options' field in
the rtems_driver_address_table structure...
"Ladies and Gentlement, we proudly present: a roughly hacked autoconf-ed
rtems-glom.in" (:-)
BTW, to follow up to the discussion about installation points, rtems-glom in
its current shape is an ideal example of a target dependent file. If
bsp-specific configure-scripts would exist, it might also be a bsp-dependent
file that contains RTEMS_BSP hard-coded (by configure) into it.
I've gone through and cleaned up the TFTP driver so that it fits
into the libio system. Here's the comment from the new driver:
/*
* Usage:
*
* To open `/bootfiles/image' on `hostname' for reading:
* fd = open ("/TFTP/hostname/bootfiles/image", O_RDONLY);
*
* The `hostname' can be a symbolic name or four
* dot-separated decimal values.
*
* To open a file on the host which supplied the BOOTP
* information just leave the `hostname' part empty:
* fd = open ("/TFTP//bootfiles/image", O_RDONLY);
*
*/
You can `fopen' TFTP files the same way:
fp = fopen (fullname, "r");
nread = fread (cbuf, sizeof cbuf[0], sizeof cbuf, fp);
The diff's are included below. I've also modified the TFTP demo
program and the bootstrap PROM example. They should be on my ftp
site `soon'.
The one thing I don't like is the way I had to do an end-run on the
libio routines to get errno passed back from my driver to the
application (since there are some errno codes that don't map to RTEMS
status codes). My approach was to set errno in the driver and have
the driver routine return an RTEMS status code that I `know' isn't in
the errno_assoc[] in libio.c.
Perhaps there should be an RTEMS_TRANPARENT_ERRNO status code (or
something similar) which driver routines could return to indicate
that the driver routine has set errno and that the libio routines
shouldn't attempt to map the returned status code to errno.
Actually, I think the entire I/O system needs looking at -- as
you've already mentioned. The hacks I've dropped in to syscalls.c to
make fstat work, for example, are *not* shining examples of good
code......
Yep, I have a bunch of bug-fixes and additions pending (Yet another monster
patch, ... I can hear you scream :-).
1) configure.in : one AC_CONFIG_HEADER(...) line too much.
2) configure.in: gcc28 support is enabled by default, i.e. if no
--enable-gcc28 option is passed on the command line. I am not sure if this
is intentional.
IMO, AC_ARG_ENABLE for --enable-gcc28 should look like:
AC_ARG_ENABLE(gcc28, \
[ --enable-gcc28 enable use of gcc 2.8.x features], \
[case "${enableval}" in
yes) RTEMS_USE_GCC272=no ;;
no) RTEMS_USE_GCC272=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;;
esac],[RTEMS_USE_GCC272=yes])
3) At the end of c/src/exec/score/cpu/m68k/m68k.h
> #ifdef __cplusplus
> }
> #endif
>
> #endif /* !ASM */
in my opinion these two statements should be swapped:
> #endif /* !ASM */
>
> #ifdef __cplusplus
> }
> #endif
I didn't try to compile for m68k, but does't this give an error? Is it
compensated somewhere else - or didn't I look carefully enough?
5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as
gnu-programs use "cxx" to specify C++ specific configure options, while cpp
is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf
internally uses $CXX),
6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly
contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't
make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I
submitted the contents of an old aclocal-directory last time. - Sorry.
7) For sh-rtems, we currently need to add additional managers to
MANAGERS_REQUIRED (from inside of custom/*.cfg). Currently MANAGERS_REQUIRED
is defined in make/compilers/*.cfg. This seems to prevent overriding
MANAGERS_REQUIRED from custom/*.cfg files - Obviously the files are included
in such a way that the settings from compilers/*cfg always override settings
from custom/*.cfg files.
Furthermore, I think, defining MANAGERS_* inside gcc-<target>.cfg files is
not correct - MANAGERS are not gcc-variant-dependent, but depend
on targets/bsps and therefore should be defined in a bsp/target dependent
file, e.g. in custom/*.cfg or target.cfg.in.
I think defining default settings for MANAGERS* in custom/default.cfg could
be an appropriate location. But this requires all custom/*.cfg files to
include default.cfg, which *-posix.cfg files don't seem to do.
Therefore I would like propose to move MANAGERS* to target.cfg.in - they are
included by all custom/*.cfg files. Perhaps we/you should use this
opportunity to merge parts from custom/default.cfg into target.cfg.in. This
ensures to have the setting included once per target makefile and will open
the opportunity to have autoconf doing additional work on
bsp-configurations.
Peanuts sofar, ... but here it comes ... (:-)
8) I am preparing a major enhancement to autoconf support for
gnutools/compilers. It is not yet finished, but usable and I'll therefore
attach a preliminary version to this mail.
Motivation:
* Fix problems with --enable-gcc28, if target-cc is not gcc28 compatible
* Fix -pipe problems
* Fix problems with hard-coded paths in configuration files (esp. posix)
* Fix consistency problems with explictly given gnutools and gcc's gnutools
Currently included:
* detection and checking of host and target compiler (gcc/g++)
* checking if target gnutools are in path
* checking if <target>-gcc -specs works (autodisabling gcc28 if not)
* checking if <target>-gcc -pipe works
Todo :
* *posix.cfg files are not yet adapted => The hard-coded paths for these
systems are still in use.
* Check if the host compiler $CC is properly propagated to the Makefiles (I
doubt it, but this should not matter)
* Check if rtems' generic tools still work properly (It looks like, but who
knows)
* Integrate CXX support into default.cfg or gcc-target-default.cfg (It looks
like C++ support is only used by posix BSPs)
* Automatically handle RANLIB/MKLIB for targets
* Plenty ... (:-)
Open problems:
* Untested for non-gcc compatible host and target compilers. This should be
no problem if the tools are named follow gnutool's naming convention and are
included in $PATH while running configure.
* Intentionally using different tools than that gcc has been configured for,
e.g. use a different assembler ? This should be still possible if
XX_FOR_TARGET is hard-coded into custom/*.cfg. I don't see why anybody
should want to do this, but who knows?
I have tested this version on linux and solaris hosts, with gcc's
directories mounted at weird non-standard mount points, using egcs
(linux/sh-rtemscoff), gcc-2.7.2.2 using native tools (solaris), gcc-2.7.2.3
w/ gnutools (solaris/linux). I don't expect it to break anything, but of
cause I can't promise it. It will break most/all *-posix.cfg configuration
almost for certain, but not more as rtems' current *posix.cfg configurations
already do (hard-coded configurations).
I am not sure if this is ready to be included into the next snapshot or not.
Perhaps you might try this on your systems and if it you don't notice
serious bugs you might put it into the snapshot for public testing (I don't
like this, but I don't see another possiblity to test generality).
I enclose a patch for configure.in and some configuration files which
comprizes fixes for all items mentioned except of #3 . Don't forget to run
"aclocal -I aclocal; autoconf;" after applying the patch (:-).
Yep, I have a bunch of bug-fixes and additions pending (Yet another monster
patch, ... I can hear you scream :-).
1) configure.in : one AC_CONFIG_HEADER(...) line too much.
2) configure.in: gcc28 support is enabled by default, i.e. if no
--enable-gcc28 option is passed on the command line. I am not sure if this
is intentional.
IMO, AC_ARG_ENABLE for --enable-gcc28 should look like:
AC_ARG_ENABLE(gcc28, \
[ --enable-gcc28 enable use of gcc 2.8.x features], \
[case "${enableval}" in
yes) RTEMS_USE_GCC272=no ;;
no) RTEMS_USE_GCC272=yes ;;
*) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;;
esac],[RTEMS_USE_GCC272=yes])
3) At the end of c/src/exec/score/cpu/m68k/m68k.h
> #ifdef __cplusplus
> }
> #endif
>
> #endif /* !ASM */
in my opinion these two statements should be swapped:
> #endif /* !ASM */
>
> #ifdef __cplusplus
> }
> #endif
I didn't try to compile for m68k, but does't this give an error? Is it
compensated somewhere else - or didn't I look carefully enough?
5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as
gnu-programs use "cxx" to specify C++ specific configure options, while cpp
is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf
internally uses $CXX),
6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly
contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't
make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I
submitted the contents of an old aclocal-directory last time. - Sorry.
7) For sh-rtems, we currently need to add additional managers to
MANAGERS_REQUIRED (from inside of custom/*.cfg). Currently MANAGERS_REQUIRED
is defined in make/compilers/*.cfg. This seems to prevent overriding
MANAGERS_REQUIRED from custom/*.cfg files - Obviously the files are included
in such a way that the settings from compilers/*cfg always override settings
from custom/*.cfg files.
Furthermore, I think, defining MANAGERS_* inside gcc-<target>.cfg files is
not correct - MANAGERS are not gcc-variant-dependent, but depend
on targets/bsps and therefore should be defined in a bsp/target dependent
file, e.g. in custom/*.cfg or target.cfg.in.
I think defining default settings for MANAGERS* in custom/default.cfg could
be an appropriate location. But this requires all custom/*.cfg files to
include default.cfg, which *-posix.cfg files don't seem to do.
Therefore I would like propose to move MANAGERS* to target.cfg.in - they are
included by all custom/*.cfg files. Perhaps we/you should use this
opportunity to merge parts from custom/default.cfg into target.cfg.in. This
ensures to have the setting included once per target makefile and will open
the opportunity to have autoconf doing additional work on
bsp-configurations.
Peanuts sofar, ... but here it comes ... (:-)
8) I am preparing a major enhancement to autoconf support for
gnutools/compilers. It is not yet finished, but usable and I'll therefore
attach a preliminary version to this mail.
Motivation:
* Fix problems with --enable-gcc28, if target-cc is not gcc28 compatible
* Fix -pipe problems
* Fix problems with hard-coded paths in configuration files (esp. posix)
* Fix consistency problems with explictly given gnutools and gcc's gnutools
Currently included:
* detection and checking of host and target compiler (gcc/g++)
* checking if target gnutools are in path
* checking if <target>-gcc -specs works (autodisabling gcc28 if not)
* checking if <target>-gcc -pipe works
Todo :
* *posix.cfg files are not yet adapted => The hard-coded paths for these
systems are still in use.
* Check if the host compiler $CC is properly propagated to the Makefiles (I
doubt it, but this should not matter)
* Check if rtems' generic tools still work properly (It looks like, but who
knows)
* Integrate CXX support into default.cfg or gcc-target-default.cfg (It looks
like C++ support is only used by posix BSPs)
* Automatically handle RANLIB/MKLIB for targets
* Plenty ... (:-)
Open problems:
* Untested for non-gcc compatible host and target compilers. This should be
no problem if the tools are named follow gnutool's naming convention and are
included in $PATH while running configure.
* Intentionally using different tools than that gcc has been configured for,
e.g. use a different assembler ? This should be still possible if
XX_FOR_TARGET is hard-coded into custom/*.cfg. I don't see why anybody
should want to do this, but who knows?
I have tested this version on linux and solaris hosts, with gcc's
directories mounted at weird non-standard mount points, using egcs
(linux/sh-rtemscoff), gcc-2.7.2.2 using native tools (solaris), gcc-2.7.2.3
w/ gnutools (solaris/linux). I don't expect it to break anything, but of
cause I can't promise it. It will break most/all *-posix.cfg configuration
almost for certain, but not more as rtems' current *posix.cfg configurations
already do (hard-coded configurations).
I am not sure if this is ready to be included into the next snapshot or not.
Perhaps you might try this on your systems and if it you don't notice
serious bugs you might put it into the snapshot for public testing (I don't
like this, but I don't see another possiblity to test generality).
I enclose a patch for configure.in and some configuration files which
comprizes fixes for all items mentioned except of #3 . Don't forget to run
"aclocal -I aclocal; autoconf;" after applying the patch (:-).
6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly
contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't
make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I
submitted the contents of an old aclocal-directory last time. - Sorry.
Yep, I have a bunch of bug-fixes and additions pending (Yet another monster
patch, ... I can hear you scream :-).
1) configure.in : one AC_CONFIG_HEADER(...) line too much.
5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as
gnu-programs use "cxx" to specify C++ specific configure options, while cpp
is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf
internally uses $CXX),
of BSS size. The conversion from a count of u8's to a count of
u32's was shifting in the wrong direction. This error had been in
the start code a long time. It had not caused problems because
the BSS is typically much smaller than the C heap which typically
follows it in memory. Plus since this code was executed at start
time, all that really happened was an extra zeroing of some memory.
I am not sure if this is related to this problem, but here is an observation:
All config.sub scripts from rtems' intrastructure packages internally
transform i386-rtems into i386-pc-rtems
newlib-1.8.0-rtems/config.sub i386-rtems --> i386-pc-rtems
egcs-1.0/config.sub i386-rtems ---> i386-pc-rtems
egcs-1.0.1/config.sub i386-rtems ---> i386-pc-rtems
bintutils-2.8.1.0.19/config.sub i386-rtems ---> i386-pc-rtems
gas-98xxxx/config.sub i386-rtems ---> i386-pc-rtems
The only exception is rtems itself:
rtems/config.sub i386-rtems ---> i386-rtems
I am not sure if this influences i386-rtems + c++/posix, but this indicates
that rtems' config.sub script should to be updated.
To fix this, simply copying config.sub e.g. from egcs and removing all
i[3456]-rtems* case statement lines from configure.in should be sufficient.
BTW, from autoconf's point of view i386-pc-rtems is the correct target
conforming autoconf's naming conventions, but using i386-rtems for all
packages (infrastructure and rtems) should make no difference.
It adds make rules for reconfiguring build-trees ("make Makefile") and
adds dependency rules for configure and friends (i.e. calls autoconf).
Most of this code has been "borrowed" from automake and was adapted to
rtems.
Addionally, I added automatic generation of the "aclocal.m4"-file by
"aclocal" (from the automake package). Therefore I splitted aclocal.m4
into several separate files (attached to this mail), each containing one
of rtems customized autoconf/m4-macros and have put them into a new
subdirectory "aclocal". Normal users won't be influenced and won't even
need this, unless they try to modify configure.in.
The main advantage of this is: these aclocal/m4-macros become reusable
and easier to administer. As a disadvantage, rtems becomes dependent of
having aclocal/automake installed. To keep building rtems functional if
autoconf or aclocal isn't installed, the related Makefile commands are
prefixed by "-" -- only an error message should be issued by "make".
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
> 4) The toplevel Makefile.in contains rules named make_subdir and
> clean_modules, which probably can be deleted, IMO.
> At least make_subdir doesn't give any sense anymore. (I had removed it
> im my original patch).
> RTEMS is under CVS control and has been since rtems 3.1.16 which was
> around May 1995. So I just to add the $Id$. If you notice other files
> with missing $Id$'s let me know. I try to keep w\up with it.
Now that you have asked -- I'll attach a list of files lacking an RCS-Id to
this mail. This list has been generated by a little sh-script I'll also
enclose.
RTEMS_CHECK_FILES_IN uses a sequence of find, sort and sed to collect
all *.in files in a given subdirectory.
The current version uses : `find $1 -name $2 -print | sed 's%\.in%%' |
sort` with $1 being a subdirectory $2 set to Makefile.in.
This works as long all subdirectories start with a letter that is
lexically bigger than the letter M, but will fail otherwise.
>> >>There is a 30 day error in _TOD_Days_since_last_leap_year[2..3]
>> >
>> >Thanks.
>> >What's the condition to hit this error?
>> >Every year 4n+2 and 4n+3 ?
>> >(i.e. 1998, 1999, 2002, 2003, ...)
>> >
>> OK: 96 97 00 01 04 05 ...
>> Bad: 98 99 02 03 06 07 ...
There is also a problem in newlib 1.7.x reported at the same time:
>> I found another, that would strike only on 2/29/2000, or other leapyears.
>> Only a problem on 1 day.
>>
>> Joel: FYI, there is a bug in Newlib localtime.c, localtime or (_tm_time).
>> Ours is modified for dst and timezones, but the bug was in original source.
>> I have not looked at the latest public source (nor do I know where to find
>> it).
configuration successfully.
Added code to detect configuring macros and POSIX API at the same time.
There is no macro implementation for the POSIX API.
for GNAT. It was the number of Ada tasks when in fact the run-time
only required a single key.
Also added the CONFIGURE_MAXIMUM_FAKE_ADA_TASKS constant to account
for resources allocated for each non-Ada task/thread which invokes
the Ada run-time implicitly through an Ada call.
1) In my haste to add C++ constructor/destructors to the 68360
linkcmds scripts I managed to break all existing 68360 programs.
Linker scripts which actually produce a working executable are
contained below. The problem was that the constructor/destructors
weren't included before the etext symbol.
On top of that Eric and I appear to have problems with attachments:
2) In deciphering the above problem I think I stumbled across the
reason you've had with patches mailed from me. I noticed that the
linkcmds (and linkcmds.bootp) scripts in the latest distribution have
a control-M (carriage return) at the end of each line. Could you
check the files below before installing them in the distribution and
see that there aren't returns in the files? Maybe if I send
everything as a tar attatchment things will work better.
interpreted at the right point per Eric Norum's discovery:
The problem with the my previous `fix' for adding linker commands
was with the ordering of the options to the linker.
For example, to make a larger heap size, the application Makefile would
CFLAGS_LD = -Wl,--defsym -Wl,HeapSize=0x40000
The command passed to the linker would be :
m68k-rtems-ld .... -T xxx/linkcmds .... --defsym HeapSize=0x40000 .....
This doesn't work because the script in linkcmds inserts a default
value for HeapSize if HeapSize is not defined by the time the linker
looks at the linkcmds script.
The solution seems to be to move the -T linkcmds%s in the bsp_specs
file out of the link specfication and into the lib specification -- a
little unorthodox, perhaps, but it seems to work!
match the one in CPU.H. Added spurious_handler and exceptions_in_RAM items.
Added definations for clicks_per_usec, spurious_handler,exceptions_in_RAM,
serial_external_clock, serial_cts_rts, timer_average_overhead, and
timer_least_valid.
generating Makefiles where possible.
Added code to make sure make/custom file and bsp directory exist for
configured bsps. This code also accounts for "aliased" BSPs.
was necessary to fix some bugs and to support the "@subsubsection",
"@raise", and "@lower" commands. The major known bug was that
single section chapters were not being processed correctly.
Added the -c option so chapter names do not always have to included
in the node names.
After weeks of trying to figure why my RTEMS/KASQ server crashes now
and then I found a nasty bug I introduced in adding multiple-driver
support to libio. The bug only affects `add-on' driver classes (like
the networking code). Old-style file descriptors were not affected.
The bug cleared 32 bytes of memory (unspecified location) whenever a
`close' of a socket was performed! I was clearing an IOP I hadn't
allocated -- and the pointer wasn't initiallized, either!
Enable 68360 watchdog. The watchdog control register is a
`write-once' register, so the watchdog has to be enabled in the boot
roms if it is to be used at all. To make the change transparent I
added a default feed of the watchdog to the clock interrupt handler.
This can be overridden if the application wants to handle the
watchdog. The only difficulty with this change is that an
application has to either include the clock driver or handle the
watchdog explicitely. I don't think this is much of a problem since
I am pretty sure that almost every application includes the clock
driver.
The definition of "BEGIN_DATA" should not be null; should be ".data".
Also, the definition of "BEGIN_BSS" should be ".bss". For this error,
the compiled object has codes that write on the text segment area.
It is fatal when the code runs on ROM.
Also, I ran across a nasty problem the first time I tried
downloading and running an application compiled with the new
snapshot. To make a very long story short, the `start' in
...../m68k/gen6860/start360/start360.s must not be global. The
change is simple -- just remove the
.globl start
from start360.s.
(Sapporo, Japan) submitted the extended console driver for the
MVME162LX BSP and the POSIX tcsetattr() and tcgetattr() routines.
This device driver supports four serial ports, cooked IO, and
provides a portable base for Zilog 8530 based console drivers.
were a number of minor problems which had to be fixed to get it
to compile including modifying the compile rule to handle C++ comments,
changing the syntax of the include statement, and getting rid of "%"
as part of register names.
as an RTEMS task. This avoid problems resulting from differences in the
tasking mode/priority of Ada tasks from the typical way an RTEMS initialization
task is created.
in the unix port idle thread task. This should keep the entire application
from blocking when any component does a blocking application. Also added
TOD_MICROSECONDS_TO_TICKS.
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.
argument indicates whether the task is to be placed at the head or tail of
its priority fifo when it is lowering its own priority. POSIX normally
follows the RTEMS API conventions but GNAT expects that all lowering of
a task's priority by the task itself will result in being placed at the
head of the priority FIFO. Normally, this would only occur as the result
of lose of inherited priority.
argument indicates whether the task is to be placed at the head or tail of
its priority fifo when it is lowering its own priority. POSIX normally
follows the RTEMS API conventions but GNAT expects that all lowering of
a task's priority by the task itself will result in being placed at the
head of the priority FIFO. Normally, this would only occur as the result
of lose of inherited priority.
The RTEMS API always puts tasks at the end of their priority group except
upon loss of inherited priority.
he received using the Microtec C++ compiler. Most of these are
either missing casts from/to (void *), heavy handed use of enumerated
types, or simply assumed conversions. There is at least one actual
bug in an error path in thread.c in which the wrong argument was
passed to _Thread_Stack_Free and was not being caught by gcc.
statuses being returned to gnat runtime in order for it to raise
use_errors. This was needed to identify the places in gnat's runtime
which needed to be addressed.
to made signals sent to a particular thread from an ISR operated correctly.
This behavior was required by the exception detection/reporting code
in the gnat runtime.
the timeout is given as a wall-time not an interval as was previously
implemented. Second, the interpretation of ETIMEDOUT behavior was
incorrect as all possible error cases needed to be checked before
this error was returned. This caused problems when the wall-time
specified was in the past.
explicit to inherit scheduler to be consistent with FSU pthreads for gnat.
_POSIX_Threads_Create_extension: now inherit signal blocked mask from
creator if the new thread is a posix thread.
_POSIX_Threads_Initialize_user_threads: make sure posix initialization
threads start with a useful priority. If they inherit the priority
of the creating thread, they will end up at the same priority as the
idle thread. Since the idle thread does not yield, they will not run.
if the queue has been emptied of waiting tasks.
_POSIX_Condition_variables_Wait_support: added error check for different mutexesfor the same condition variable. Also added _Thread_queue_Enter_critical_section
send signals to the current thread or to another blocked thread. nanosleep()
can be interrupted by a signal and return the time remaining.
Post switch extension added to dispatch posix signal handlers.
in the core to support multiple algorithms to handle cpu time budgetting
which resulted in a change to the calling sequence of _Thread_Initialize.
Makde _Context_Switch_necessary volatile.
implemented sigemptyset() sigfillset(), sigaddset(), sigdelset(), and
sigismember().
added checks for valid attribute values to some of the pthread_attr_t sets.
There is a potential problem if setting PTHREAD_STACK_MIN to 0 does not
work with all applications since it is in limit.h over in newlib. There
is a potential build order issue with newlib needing to know the rtems
cpu dependent stack size minimum.
of the POSIX API necessary to support the GNAT runtime to initially compile.
We now have verified that the specifications for the necessary routines
are correct per the POSIX standards we have.
of the POSIX API necessary to support the GNAT runtime to initially compile.
We now have verified that the specifications for the necessary routines
are correct per the POSIX standards we have.
The removed files were moved to newlib as they were duplicates of files
already included there.
Contact information:
W. Eric Norum
Saskatchewan Accelerator Laboratory
107 North Road
University of Saskatchewan
Saskatoon, Saskatchewan, CANADA
S7N 5C6
the inline implementation. The impetus for this was twofold. First,
it is incorrect to have static inline prototypes when using the macro
implementation. Second, this reduced the number of lines in the include
files seen by rtems.h by about 2000 lines.
Next we restricted visibility for the inline routines to inside the
executive itself EXCEPT for a handful of objects. This reduced the
number of include files included by rtems.h by 40 files and reduced
the lines in the include files seen by rtems.h by about 6000 lines.
In total, these reduced the compile time of the entire RTEMS tree by 20%.
This results in about 8 minutes savings on the SparcStation 10 morgana.
the inline implementation. The impetus for this was twofold. First,
it is incorrect to have static inline prototypes when using the macro
implementation. Second, this reduced the number of lines in the include
files seen by rtems.h by about 2000 lines.
Next we restricted visibility for the inline routines to inside the
executive itself EXCEPT for a handful of objects. This reduced the
number of include files included by rtems.h by 40 files and reduced
the lines in the include files seen by rtems.h by about 6000 lines.
In total, these reduced the compile time of the entire RTEMS tree by 20%.
This results in about 8 minutes savings on the SparcStation 10 morgana.
only required in a multiprocessor system. It was replace by the MPCI
Receive Server. As a result, the CPU Table field for extra stack for
the SYSI task was changed to be extra stack for the MPCI Receive Server.
the thread handler (IDLE), MPCI object (SYSI now MP Receive)
and initialize_executive_early (IO initialization). The SYSI task
no longer exists in a single processor configuration. This reduces
single processor Workspace requirements by a TCB and a stack which
is often larger than the minimum stack size. Moving the IO initialization
plus accompanying BSP hooks eliminated an initialization ordering problem
in which a global task could be created before the MPCI was initialized.
the thread handler (IDLE), MPCI object (SYSI now MP Receive)
and initialize_executive_early (IO initialization). The SYSI task
no longer exists in a single processor configuration. This reduces
single processor Workspace requirements by a TCB and a stack which
is often larger than the minimum stack size. Moving the IO initialization
plus accompanying BSP hooks eliminated an initialization ordering problem
in which a global task could be created before the MPCI was initialized.
initialize_executive_early. This was done to clear up an ordering problem
in which global tasks could be created before the MPCI layer was initialized.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.