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!
