Sprout from rtems-4-5-branch 2000-07-24 17:58:24 UTC Joel Sherrill <joel.sherrill@OARcorp.com> 'changed version to 4.5.0'
Delete:
automake/host.am
automake/lib.am
automake/local.am
automake/subdirs.am
c/src/lib/libbsp/mips/p4000/liblnk/.cvsignore
c/src/librdbg/src/powerpc/new_exception_processing/.cvsignore
doc/.cvsignore
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.
* On-Line Applications Research Corporation (OAR).
*
* The license and distribution terms for this file may be
* found in the file LICENSE in this distribution or at
* http://www.OARcorp.com/rtems/license.html.
*
* $Id$
*/
#ifndef __ITRON_MBOX_h_
#define __ITRON_MBOX_h_
#ifdef __cplusplus
extern"C"{
#endif
/*
* Create Mailbox (cre_mbx) Structure
*/
typedefstructt_cmbx{
VPexinf;/* extended information */
ATRmbxatr;/* mailbox attributes */
/* Following is implementation-dependent function */
INTbufcnt;/* maximum number of messages to let pend */
/* additional information may be included depending on the implementation */
}T_CMBX;
/*
* mbxatr
*/
#define TA_TFIFO 0x00 /* waiting tasks are handled by FIFO */
#define TA_TPRI 0x01 /* waiting tasks are handled by priority */
#define TA_MFIFO 0x00 /* messages are handled by FIFO */
#define TA_MPRI 0x02 /* messages are handled by priority */
typedefstructt_msg{
/*
* A region (header) reserved by the OS may be included first
* depending on the implementation.
*
* NOTE: The first two fields are RTEMS specific.
*/
INTmsgpri;/* priority of each message */
/* VB msgcont[]; XXX */
unsigned8msgcont[1];
}T_MSG;
/*
* Reference Mailbox (ref_mbx) Structure
*/
typedefstructt_rmbx{
VPexinf;/* extended information */
BOOL_IDwtsk;/* indicates whether or not there is a waiting task */
T_MSG*pk_msg;/* message to be sent next */
/* additional information may be included depending on the implementation */
}T_RMBX;
/*
* Mailbox Functions
*/
/*
* cre_mbx - Create Mailbox
*/
ERcre_mbx(
IDmbxid,
T_CMBX*pk_cmbx
);
/*
* del_mbx - Delete Mailbox
*/
ERdel_mbx(
IDmbxid
);
/*
* snd_msg - Send Message to Mailbox
*/
ERsnd_msg(
IDmbxid,
T_MSG*pk_msg
);
/*
* rcv_msg - Receive Message from Mailbox
*/
ERrcv_msg(
T_MSG**ppk_msg,
IDmbxid
);
/*
* prcv_msg - Poll and Receive Message from Mailbox
*/
ERprcv_msg(
T_MSG**ppk_msg,
IDmbxid
);
/*
* trcv_msg - Receive Message from Mailbox with Timeout
*/
ERtrcv_msg(
T_MSG**ppk_msg,
IDmbxid,
TMOtmout
);
/*
* ref_mbx - Reference Mailbox Status
*/
ERref_mbx(
T_RMBX*pk_rmbx,
IDmbxid
);
#ifdef __cplusplus
}
#endif
#endif
/* end of include file */
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.
