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.
