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.
