Timeline




matching tags

Feb 19, 1998:

11:02 PM Changeset in rtems [88a877b3]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
changed version to 980219
11:02 PM Changeset in rtems [96c73ab]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Patch from Eric Norum: While trying to work through this problem I decided that the build-time selection of the console I/O operation (polling or interrupt) was too clumsy. Here's a patch that allows run-time (actually init-time) selection of the console I/O mode. It also shows the need for another flags' or options' field in the rtems_driver_address_table structure…
10:55 PM Changeset in rtems [fde74a3]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Increased stack space of tasks.
10:54 PM Changeset in rtems [b3dcd9a2]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Accounted for fixed system overhead.
10:54 PM Changeset in rtems [41f61bc]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Updated so test tools are installed even when --disable-tests is specified. Otherwise a target specific runtest is not installed.
10:53 PM Changeset in rtems [6e73334e]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
update from Ralf Corsepius
10:52 PM Changeset in rtems [6eba9b79]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Increased stack size of initialization task.
5:08 PM Changeset in rtems [2617b345]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Restructured so all times are placed in variables and printed in batch mode at the end of the test. This eliminates the possibility of IO blocking a task unexpectedly and messing up the test.
4:23 PM Changeset in rtems [51c195d5]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
New files missed in previous merge.

Feb 18, 1998:

8:33 PM Changeset in rtems [00632e53]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
changed version to 980218
8:30 PM Changeset in rtems [7324989]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Went back to polled console.
7:34 PM Changeset in rtems [c7744ee0]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Ralf Corsepius noted that there was a dead path in _Thread_Initialize.
2:11 PM Changeset in rtems [bf4cdb70]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Patch from Chris Johns to add the interrupt class destructure.

Feb 17, 1998:

11:46 PM Changeset in rtems [60b791ad]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
updated copyright to 1998
11:45 PM Changeset in rtems [33b304f]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
updated copyright to 1998
11:35 PM Changeset in rtems [f86ec42]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Added .eh_frame, C++ constructor, and C++ destructor sections.
11:34 PM Changeset in rtems [818c361]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Renamed init.o to exinit.o to avoid naming conflicts with tests.
11:33 PM Changeset in rtems [78fdf2b8]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Installing sptables with version information.
11:33 PM Changeset in rtems [98401e0]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
mods from Ralf Corsepius
10:16 PM Changeset in rtems [70a88c3]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
renamed init.c exinit.c
9:39 PM Changeset in rtems [e810408]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
First cut at automatic insertion of version information.
8:42 PM Changeset in rtems [5d1ea96]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
added -Wno-unused to debug flags
7:23 PM Changeset in rtems [540292a]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Ralf Corsepius pushing us farther down the autconf path: "Ladies and Gentlement, we proudly present: a roughly hacked autoconf-ed rtems-glom.in" (:-) BTW, to follow up to the discussion about installation points, rtems-glom in its current shape is an ideal example of a target dependent file. If bsp-specific configure-scripts would exist, it might also be a bsp-dependent file that contains RTEMS_BSP hard-coded (by configure) into it.
7:16 PM Changeset in rtems [ac61209b]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Added unused warning per discussion on rtems-snapshots list.
6:46 PM Changeset in rtems [9646d5be]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Patch from Eric Norum <eric@…>: I've gone through and cleaned up the TFTP driver so that it fits into the libio system. Here's the comment from the new driver: /* * Usage: * * To open /bootfiles/image' on hostname' for reading: * fd = open ("/TFTP/hostname/bootfiles/image", O_RDONLY); * * The `hostname' can be a symbolic name or four * dot-separated decimal values. * * To open a file on the host which supplied the BOOTP * information just leave the `hostname' part empty: * fd = open ("/TFTPbootfiles/image", O_RDONLY); * */ You can `fopen' TFTP files the same way: fp = fopen (fullname, "r"); nread = fread (cbuf, sizeof cbuf[0], sizeof cbuf, fp); The diff's are included below. I've also modified the TFTP demo program and the bootstrap PROM example. They should be on my ftp site `soon'. The one thing I don't like is the way I had to do an end-run on the libio routines to get errno passed back from my driver to the application (since there are some errno codes that don't map to RTEMS status codes). My approach was to set errno in the driver and have the driver routine return an RTEMS status code that I `know' isn't in the errno_assoc[] in libio.c. Perhaps there should be an RTEMS_TRANPARENT_ERRNO status code (or something similar) which driver routines could return to indicate that the driver routine has set errno and that the libio routines shouldn't attempt to map the returned status code to errno. Actually, I think the entire I/O system needs looking at -- as you've already mentioned. The hacks I've dropped in to syscalls.c to make fstat work, for example, are *not* shining examples of good code...…
2:12 PM Changeset in rtems [e81ef51]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Patch from Ralf Corsepius <corsepiu@…>: Yep, I have a bunch of bug-fixes and additions pending (Yet another monster patch, ... I can hear you scream :-). 1) configure.in : one AC_CONFIG_HEADER(...) line too much. 2) configure.in: gcc28 support is enabled by default, i.e. if no --enable-gcc28 option is passed on the command line. I am not sure if this is intentional. IMO, AC_ARG_ENABLE for --enable-gcc28 should look like: AC_ARG_ENABLE(gcc28, \ [ --enable-gcc28 enable use of gcc 2.8.x features], \ [case "${enableval}" in yes) RTEMS_USE_GCC272=no ;; no) RTEMS_USE_GCC272=yes ;; *) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;; esac],[RTEMS_USE_GCC272=yes]) 3) At the end of c/src/exec/score/cpu/m68k/m68k.h > #ifdef cplusplus > } > #endif > > #endif /* !ASM */ in my opinion these two statements should be swapped: > #endif /* !ASM */ > > #ifdef cplusplus > } > #endif I didn't try to compile for m68k, but does't this give an error? Is it compensated somewhere else - or didn't I look carefully enough? 5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as gnu-programs use "cxx" to specify C++ specific configure options, while cpp is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf internally uses $CXX), 6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I submitted the contents of an old aclocal-directory last time. - Sorry. 7) For sh-rtems, we currently need to add additional managers to MANAGERS_REQUIRED (from inside of custom/*.cfg). Currently MANAGERS_REQUIRED is defined in make/compilers/*.cfg. This seems to prevent overriding MANAGERS_REQUIRED from custom/*.cfg files - Obviously the files are included in such a way that the settings from compilers/*cfg always override settings from custom/*.cfg files. Furthermore, I think, defining MANAGERS_* inside gcc-<target>.cfg files is not correct - MANAGERS are not gcc-variant-dependent, but depend on targets/bsps and therefore should be defined in a bsp/target dependent file, e.g. in custom/*.cfg or target.cfg.in. I think defining default settings for MANAGERS* in custom/default.cfg could be an appropriate location. But this requires all custom/*.cfg files to include default.cfg, which *-posix.cfg files don't seem to do. Therefore I would like propose to move MANAGERS* to target.cfg.in - they are included by all custom/*.cfg files. Perhaps we/you should use this opportunity to merge parts from custom/default.cfg into target.cfg.in. This ensures to have the setting included once per target makefile and will open the opportunity to have autoconf doing additional work on bsp-configurations. Peanuts sofar, ... but here it comes ... (:-) 8) I am preparing a major enhancement to autoconf support for gnutools/compilers. It is not yet finished, but usable and I'll therefore attach a preliminary version to this mail. Motivation: * Fix problems with --enable-gcc28, if target-cc is not gcc28 compatible * Fix -pipe problems * Fix problems with hard-coded paths in configuration files (esp. posix) * Fix consistency problems with explictly given gnutools and gcc's gnutools Currently included: * detection and checking of host and target compiler (gcc/g++) * checking if target gnutools are in path * checking if <target>-gcc -specs works (autodisabling gcc28 if not) * checking if <target>-gcc -pipe works Todo : * *posix.cfg files are not yet adapted => The hard-coded paths for these systems are still in use. * Check if the host compiler $CC is properly propagated to the Makefiles (I doubt it, but this should not matter) * Check if rtems' generic tools still work properly (It looks like, but who knows) * Integrate CXX support into default.cfg or gcc-target-default.cfg (It looks like C++ support is only used by posix BSPs) * Automatically handle RANLIB/MKLIB for targets * Plenty ... (:-) Open problems: * Untested for non-gcc compatible host and target compilers. This should be no problem if the tools are named follow gnutool's naming convention and are included in $PATH while running configure. * Intentionally using different tools than that gcc has been configured for, e.g. use a different assembler ? This should be still possible if XX_FOR_TARGET is hard-coded into custom/*.cfg. I don't see why anybody should want to do this, but who knows? I have tested this version on linux and solaris hosts, with gcc's directories mounted at weird non-standard mount points, using egcs (linux/sh-rtemscoff), gcc-2.7.2.2 using native tools (solaris), gcc-2.7.2.3 w/ gnutools (solaris/linux). I don't expect it to break anything, but of cause I can't promise it. It will break most/all *-posix.cfg configuration almost for certain, but not more as rtems' current *posix.cfg configurations already do (hard-coded configurations). I am not sure if this is ready to be included into the next snapshot or not. Perhaps you might try this on your systems and if it you don't notice serious bugs you might put it into the snapshot for public testing (I don't like this, but I don't see another possiblity to test generality). I enclose a patch for configure.in and some configuration files which comprizes fixes for all items mentioned except of #3 . Don't forget to run "aclocal -I aclocal; autoconf;" after applying the patch (:-).
2:09 PM Changeset in rtems [aa8a8c72]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Patch from Ralf Corsepius <corsepiu@@faw.uni-ulm.de>: Yep, I have a bunch of bug-fixes and additions pending (Yet another monster patch, ... I can hear you scream :-). 1) configure.in : one AC_CONFIG_HEADER(...) line too much. 2) configure.in: gcc28 support is enabled by default, i.e. if no --enable-gcc28 option is passed on the command line. I am not sure if this is intentional. IMO, AC_ARG_ENABLE for --enable-gcc28 should look like: AC_ARG_ENABLE(gcc28, \ [ --enable-gcc28 enable use of gcc 2.8.x features], \ [case "${enableval}" in yes) RTEMS_USE_GCC272=no ;; no) RTEMS_USE_GCC272=yes ;; *) AC_MSG_ERROR(bad value ${enableval} for gcc-28 option) ;; esac],[RTEMS_USE_GCC272=yes]) 3) At the end of c/src/exec/score/cpu/m68k/m68k.h > #ifdef cplusplus > } > #endif > > #endif /* !ASM */ in my opinion these two statements should be swapped: > #endif /* !ASM */ > > #ifdef cplusplus > } > #endif I didn't try to compile for m68k, but does't this give an error? Is it compensated somewhere else - or didn't I look carefully enough? 5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as gnu-programs use "cxx" to specify C++ specific configure options, while cpp is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf internally uses $CXX), 6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I submitted the contents of an old aclocal-directory last time. - Sorry. 7) For sh-rtems, we currently need to add additional managers to MANAGERS_REQUIRED (from inside of custom/*.cfg). Currently MANAGERS_REQUIRED is defined in make/compilers/*.cfg. This seems to prevent overriding MANAGERS_REQUIRED from custom/*.cfg files - Obviously the files are included in such a way that the settings from compilers/*cfg always override settings from custom/*.cfg files. Furthermore, I think, defining MANAGERS_* inside gcc-<target>.cfg files is not correct - MANAGERS are not gcc-variant-dependent, but depend on targets/bsps and therefore should be defined in a bsp/target dependent file, e.g. in custom/*.cfg or target.cfg.in. I think defining default settings for MANAGERS* in custom/default.cfg could be an appropriate location. But this requires all custom/*.cfg files to include default.cfg, which *-posix.cfg files don't seem to do. Therefore I would like propose to move MANAGERS* to target.cfg.in - they are included by all custom/*.cfg files. Perhaps we/you should use this opportunity to merge parts from custom/default.cfg into target.cfg.in. This ensures to have the setting included once per target makefile and will open the opportunity to have autoconf doing additional work on bsp-configurations. Peanuts sofar, ... but here it comes ... (:-) 8) I am preparing a major enhancement to autoconf support for gnutools/compilers. It is not yet finished, but usable and I'll therefore attach a preliminary version to this mail. Motivation: * Fix problems with --enable-gcc28, if target-cc is not gcc28 compatible * Fix -pipe problems * Fix problems with hard-coded paths in configuration files (esp. posix) * Fix consistency problems with explictly given gnutools and gcc's gnutools Currently included: * detection and checking of host and target compiler (gcc/g++) * checking if target gnutools are in path * checking if <target>-gcc -specs works (autodisabling gcc28 if not) * checking if <target>-gcc -pipe works Todo : * *posix.cfg files are not yet adapted => The hard-coded paths for these systems are still in use. * Check if the host compiler $CC is properly propagated to the Makefiles (I doubt it, but this should not matter) * Check if rtems' generic tools still work properly (It looks like, but who knows) * Integrate CXX support into default.cfg or gcc-target-default.cfg (It looks like C++ support is only used by posix BSPs) * Automatically handle RANLIB/MKLIB for targets * Plenty ... (:-) Open problems: * Untested for non-gcc compatible host and target compilers. This should be no problem if the tools are named follow gnutool's naming convention and are included in $PATH while running configure. * Intentionally using different tools than that gcc has been configured for, e.g. use a different assembler ? This should be still possible if XX_FOR_TARGET is hard-coded into custom/*.cfg. I don't see why anybody should want to do this, but who knows? I have tested this version on linux and solaris hosts, with gcc's directories mounted at weird non-standard mount points, using egcs (linux/sh-rtemscoff), gcc-2.7.2.2 using native tools (solaris), gcc-2.7.2.3 w/ gnutools (solaris/linux). I don't expect it to break anything, but of cause I can't promise it. It will break most/all *-posix.cfg configuration almost for certain, but not more as rtems' current *posix.cfg configurations already do (hard-coded configurations). I am not sure if this is ready to be included into the next snapshot or not. Perhaps you might try this on your systems and if it you don't notice serious bugs you might put it into the snapshot for public testing (I don't like this, but I don't see another possiblity to test generality). I enclose a patch for configure.in and some configuration files which comprizes fixes for all items mentioned except of #3 . Don't forget to run "aclocal -I aclocal; autoconf;" after applying the patch (:-).
1:49 PM Changeset in rtems [81e0232]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Update from Ralf Corsepius: 6) The macro files from aclocal/*.m4 contain the buggy sed-rules formerly contained in aclocal..m4, i.e. the sed/sort-bug fix to aclocal.m4 didn't make it to aclocal/*.m4. I think I should feel guilty for that - Obviously I submitted the contents of an old aclocal-directory last time. - Sorry.
1:48 PM Changeset in rtems [3771cc6e]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Update from Ralf Corsepius: Yep, I have a bunch of bug-fixes and additions pending (Yet another monster patch, ... I can hear you scream :-). 1) configure.in : one AC_CONFIG_HEADER(...) line too much. 5) configure.in: --enable-cpp should probably be renamed to --enable-cxx, as gnu-programs use "cxx" to specify C++ specific configure options, while cpp is used for the preprocessor (e.g egcs uses --with-cxx-includedir, autoconf internally uses $CXX),
1:21 PM Changeset in rtems [b4589477]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Swapped C++ and ASM "endifs"

Feb 11, 1998:

10:13 PM Changeset in rtems [a858910]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Incorporated Ralf Corsepius' idea for new -q flags to properly support "gmake debug".
9:57 PM Changeset in rtems [fc56b90c]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Don't install tools using variant name.
9:56 PM Changeset in rtems [360930c]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Install size info using "standard" suffix.
9:20 PM Changeset in rtems [2bb990f]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Fixed hppa1.1 configuration.
3:03 PM Changeset in rtems [c2c5fc2]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
new test cases
2:58 PM Changeset in rtems [94a6c986]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
new directory structure for hwapi
2:50 PM Changeset in rtems [7175b59]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
hwapi added
2:50 PM Changeset in rtems [9aceddaf]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
updates

Feb 10, 1998:

4:22 PM Changeset in rtems [84b0f7c9]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Robin Kirkham reported that the install point was incorrect in this file.

Feb 7, 1998:

7:56 PM Changeset in rtems [b68e057e]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Fixed to correctly operate on target variants like debug and profile.
7:43 PM Changeset in rtems [e496c1f]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Should not install build-tools using target variant options.

Feb 6, 1998:

2:14 PM Changeset in rtems [1e524995]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Updated copyrights
1:48 PM Changeset in rtems [5599d6e]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Added @table/@end table capability along with the avdas.d test case where this capability was first used.
1:47 PM Changeset in rtems [f02ffca]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Problem report from Brian Cuthie regarding incorrect calculation of BSS size. The conversion from a count of u8's to a count of u32's was shifting in the wrong direction. This error had been in the start code a long time. It had not caused problems because the BSS is typically much smaller than the C heap which typically follows it in memory. Plus since this code was executed at start time, all that really happened was an extra zeroing of some memory.

Feb 5, 1998:

8:05 PM Changeset in rtems [02d19d8]4.104.114.84.9 by Joel Sherrill <joel.sherrill@…>
Added code to more correctly process abstract types (handle, range, etc).
Note: See TracTimeline for information about the timeline view.