routines and structures that require CPU model specific information
are now in libcpu. This required significant rework of the
score/cpu header files and the creation of multiple header files
and subdirectories in libcpu/i960.
that decouples exec/ for the sh, m68k and i960 from targopts.h.
NOTE: The change to system.h is a hack to enable cpuopts.h
for some targets, but keep using targopts.h for others - I know it
does *not* work for sparc, mips, i386 and ppc. This will have
to be addressed as work continues on multilibing.
that addresses aspects of the targopts.h multilib related
issues.
Changes:
* Move targopts.h to libbsp/include, because the current targopts.h
actually is a per-BSP-header and therefore can not stay below exec/.
* Introduce an autoheader generated header file
(exec/score/include/rtems/score/cpuopts.h), which shall take per-cpu
configuration options only.
* Move all autoconf-detectable/configure specified per-cpu
option-defines from targopts.h to cpuopts.h.
* Add Makefiles to the libbsp/shared directory hierarchy.
Notes:
* The new per-bsp targopts.h in libbsp includes the per-cpu
cpuopts.h. This way, the new targopts.h is kept backward compatible
to the old targopts.h and existing BSPs which (carelessly) include
targopts.h (i386, ppc) should be kept working when using the
multilib-disabled configuration scheme.
* cpuopts.h is not yet complete, because the per-BSP make-targopts
rules from custom/<BSP>.cfg files can not be applied to files below
exec/ when building multilibs.
* All files below exec/ should not include targopts.h anymore, but
should include cpuopts.h instead. However, eliminating inclusion of
targopts.h currently triggers further structural / header file inclusion
related issues, because several ports apply BSP or CPU_MODEL specific
defines from targopts.h below exec/
from score/cpu to libcpu because the determination of which to use is
based on RTEMS_CPU_MODEL. Thus it can not be determined based solely on
multilib information.
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.
Hitachi H8 family. This port was done by Philip Quaife
<philip@qs.co.nz> of Q Solutions and sponsored by
Comnet Technologies Ltd. The port was done based on RTEMS 3.5.1
to a Hitach H8300H. The port was updated to RTEMS 4.5 style
Makefiles/configure by Joel Sherrill <joel@OARcorp.com>.
While doing this Joel added support for the h8300-rtems to
binutils, gcc, newlib, and gdb.
NOTE: Philip submitted a BSP for a Hitachi evaluation board
which is being merged as a separate entity.
that breaks when the target has 16 bit address space. One of the H8
multilibs is a 16-bit address space CPU. When a real attempt is
made to support this CPU model, the code that assumes an address
is 32 bits will have to change. This constant is probably not
flagging all impacted code.
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.
to:
I have also added the ability to register and unregister commands. This
allows me to create a set of monitor commands for the network stack plus
basic memory dump/patch commands (needs a working probe interface). I
will also look at a basic ls/cd/rm/mv/cp command set at some stage.
I have been thinking about changing the monitor in the future to more
like a light weight RTEMS shell, `eshell' for embedded shell. This is a
story for another day but is a process or getting the commands to map to
the filesystem (eg, major=commands, minor=command) and supporting an
environment. The filesystem provide a structure for the commands.
initialization. This adds an interface which makes it easier to
control the BSD stack from user code. The BSD stack initialise uses
it. It is a sort of `function' interface for an ifconfig
command.
I also added support for attaching and removing interfaces. With hot
swap PCI comming online support for hot swap PCI will be an important
factor in "state of art" RTOS's. This is also part of a general move on
my part to allow RTEMS to be configured at runtime by calls rather than
table driven at initialisation.
