Timeline



03/06/99:

18:09 Changeset in rtems [3ef8798]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Added F_GETFL support so the fdopen() implementation in newlib 1.8.1 would work. At the same time, the initial implementation of F_SETFL was added. A support routine was added to convert internal libio flags back to the POSIX style. Eventually the internal representation should be eliminated in the interest of simplicity and code reduction. This problem was reported by Jake Janovetz <janovetz@…>.

03/03/99:

18:11 Changeset in rtems [eaefca90]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Wrong constant name was used for the DEBUG exception.
18:11 Changeset in rtems [163b29a]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Generated files were accidentally included in the library.
16:22 Changeset in rtems [4f6d73a]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Patch from Erik Ivanenko <erik.ivanenko@…> to correct a bug that shows up if the BSP uses memory near address 0.

03/02/99:

15:56 Changeset in rtems [97b8b8f]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
This file is linked in
15:43 Changeset in rtems [0077e9e]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
changed version to 19990302
15:32 Changeset in rtems [faf7f46]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Patch from Jay Monkman <jmonkman@…> to address minor issues in the eth_comm BSP documentation.

03/01/99:

23:50 Changeset in rtems [9d81380]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Updated Ethernet driver from Erik Ivanenko <erik.ivanenko@…>. Comments follow: Please find attached, the updated network driver. I have verified that it is working as expected, by timestamping the error messages generated from the ISR. If you've taken a look inside, the network driver has a reset thread in addition to the RX and TX threads. It is possible to avoid the additional reset thread by allowing the TX driver to time out and then checking status bits set by the ISR. However, this approach demands that a transmission is necessary for the NIC to be reset. Due to Eric V's ISR handling, I suppose that the reset routine could be called from the "ISR" itself, due to the 8259 interrupt mode, and that the interrupt is acknowledged prior to running the "ISR". (Providing that no NIC interrupts are generated during reset -- I worry about re-entrancy. ) This would be a minor improvement, but you know, I don't want to make this driver my lifes work. ---------------------------------------------------------------------- ----------------------------------------------------------------------
22:40 Changeset in rtems [73f6236]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Patch from Eric Norum <eric@…> to eliminate external IO handlers scheme that was implemented originally just to support sockets. The file system IO switch is more general and works fine.
15:18 Changeset in rtems [e069cdc3]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Part of the automake VI patch from Ralf Corsepius <corsepiu@…>: > 5) rtems-rc-19990202-1.diff/reorg-install.sh > > reorg-install.sh fixes a Makefile variable name clash of RTEMS > configuration files and automake/autoconf standards. > Until now, RTEMS used $(INSTALL) for install-if-change. Automake and > autoconf use $(INSTALL) for a bsd-compatible install. As > install-if-change and bsd-install are not compatible, I renamed all > references to install-if-changed to $(INSTALL_CHANGED) and used > $(INSTALL) for bsd-install (==automake/autoconf standard). When > automake will be introduced install-if-change will probably be replaced > by $(INSTALL) and therefore will slowly vanish. For the moment, this > patch fixes a very nasty problem which prevents adding any automake file > until now (There are still more).

02/25/99:

19:34 Changeset in rtems [85d8eb2]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Corrected the comments on --enable-gcc28 and switched the sense of the --enable-tests switch.
19:22 Changeset in rtems [e1b77701]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
backed off previous change and switched to tests being disabled by default.
17:30 Changeset in rtems [0ce4728]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Suggestion from Ralf Corsepius <corsepiu@…> to clarify --enable-tests flag.

02/24/99:

20:58 Changeset in rtems [3cf8394]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Changed IMFS to use IMFS_NAME_MAX as the maximum length of a basename rather then NAME_MAX. NAME_MAX is 255 and that lets IMFS chew up memory too fast. Perhaps in the future, the places in IMFS that put a maximum length name string on the stack and the jnode structure does not include a maximu length name string can be fixed so this is not a problem.
20:46 Changeset in rtems [32a98d2]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Moved mpc860.h around to make things compile.
15:46 Changeset in rtems [7d7b2a3]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Patch from Charles Gauthier <Charles.Gauthier@@iit.nrc.ca> to address FP issues on this target: The default variants of libc, libm and libgcc assume that a 68881 coprocessor is present. Without the FPSP, any floating point operation, including printf() with a "%f" format specifier, is likely to cause an unimplemented instruction exception. The FPSP works with the default variants of libc, libm and libgcc. It does not work in conjunction with the msoft-float variants. The paranoia test goes into an infinite loop at milestone 40. I am guessing that floor() is returning an incorrect value. The msoft-float variants of libc, libm and libgcc appear to do floating point I/O properly. They only failed in paranoia. Offhand, I can't think of why they would conflict with the FPSP, so I think that there is something wrong with the msoft-float code. It might be my installation. Given my experiences, I decided to install the FPSP in bsp_start(), and to link against the default variants of libc, libm and libgcc. This causes the executables to increase in size by about 60 KB. The README file and the mvme167.cfg specify how to remove the FPSP, and how to link against the msoft-float variants of the libraries. This is not what Eric Norum had done: on my host, his gen68360_040 port links RTEMS code with the msoft-float variants of libc and libm, and the default variant of libgcc. In this configuration, the output of printf() with "%f" is garbage on my target.
15:37 Changeset in rtems [4e4e691]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Patch from Charles Gauthier <Charles.Gauthier@…> to address FP issues on this target: The default variants of libc, libm and libgcc assume that a 68881 coprocessor is present. Without the FPSP, any floating point operation, including printf() with a "%f" format specifier, is likely to cause an unimplemented instruction exception. The FPSP works with the default variants of libc, libm and libgcc. It does not work in conjunction with the msoft-float variants. The paranoia test goes into an infinite loop at milestone 40. I am guessing that floor() is returning an incorrect value. The msoft-float variants of libc, libm and libgcc appear to do floating point I/O properly. They only failed in paranoia. Offhand, I can't think of why they would conflict with the FPSP, so I think that there is something wrong with the msoft-float code. It might be my installation. Given my experiences, I decided to install the FPSP in bsp_start(), and to link against the default variants of libc, libm and libgcc. This causes the executables to increase in size by about 60 KB. The README file and the mvme167.cfg specify how to remove the FPSP, and how to link against the msoft-float variants of the libraries. This is not what Eric Norum had done: on my host, his gen68360_040 port links RTEMS code with the msoft-float variants of libc and libm, and the default variant of libgcc. In this configuration, the output of printf() with "%f" is garbage on my target.
15:26 Changeset in rtems [d6a5c81]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Switch to using standard compile rule for assembly.
15:15 Changeset in rtems [4d20133]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Patch from Ralf Corsepius <corsepiu@…>. The following email is long but I hate to lose the information so I am including it here. > I am still fixing and recompiling but this is the issue that was not the > result of another patch. This is a fundamental build issue that I value > your opinion on. This is difficult issue (I.e. I have no destinct solution for it) Background: (gnu-) make's implicit rules apply CFLAGS, CPPFLAGS, CXXFLAGS, ASFLAGS and LDFLAGS (cf. make.info/Implicit Rules/Catalogue? of Rules), only. In brief: CPPFLAGS .. passed to the c-preprocessor CFLAGS ... passed to the c-compiler CXXFLAGS ... equivalent to CFLAGS but passed to the c++ compiler (Attention: CFLAGS is not passed to the c++ compiler) ASFLAGS .. equivalent to CFLAGS, but passed to the assembler LDFLAGS .. equivalent to CFLAGS, but passed to the linker A bit oversimplifying, these make rules are as follows .c.o: $(CC) $(CPPFLAGS) $(CFLAGS) -c .cc.o: $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c .S.s: $(CPP) $(CPPFLAGS) .s.o: $(AS) $(ASFLAGS) My reading of the documentation (make.info) is that {AS|AR|CC|CXX|CPP}FLAGS are ment to be passed to the related tools directly, however examinating the rule set of gmake (gmake -p -f /dev/null") shows that many rules use $(CC) instead of the related tools (eg. linker rules) etc. I.e. these flags should not rely on being passed through cpp or gcc. With gcc being the common frontend for all of these tools of a gnu-toolchain the situation becomes difficult (Which option is passed to whom and which tool really uses it?), because these variable can also contain the toolchain's frontend (eg. AS=gcc, LD=gcc, CPP=gcc -E). For some commonly used options the situation is quite clear: * -g -> CFLAGS * -OX -> CFLAGS * -D -> CPPFLAGS * -A -> CPPFLAGS But where to add -m, -B, -specs, -qrtems_XXX ? * -B, -specs, -qrtems_XXX are gcc-frontend options * -m is a combinations of flags to go to different destinations, in many (all?) cases, the following is valid -m is expanded by gcc into a set of -D and -A options -m is interpreted by cc1 as a machine flag to generate a specific instruction set. -m is interpreted by gcc as an implicit linker search path for multilibs to set up calls to LD. >From my point of view this indicates we can either destingush between these different usages (= separately add -m to CFLAGS, LDFLAGS etc) or to add it to CPPFLAGS and use gcc (the frontend) instead of calling each tool directly (less error prone) -- I vote for CPPFLAGS, but I am not sure. ----------------- Now, where to add CPU_CFLAGS? AFAIS, in probably all cases CPU_CFLAGS contain -D -A, and -m options, only. * -D and -A are supposed to go to CPPFLAGS * -mXXX options can have multiple meanings (It can be gcc, collect2/ld and cc1/cc1plus option simultaneously) Here, I made a mistake - I destinguished between CPU_DEFINES to be added to CPPFLAGS and CPU_CFLAGS to be added to CFLAGS and CXXFLAGS (cf. gcc-target-default.cfg), generally assuming CPU_CFLAGS are CFLAGS. This breaks preprocessing *.S into *.i files because CPU_CFLAGS flags were not added to CPPFLAGS. Hence *all* *.S were compiled without taking -mXX-flags into account. The i960/cvme BSP was the only one which explicitly checked for a specific -m flag (-mca) and refused to compile without it -- all other CPUs/BSPs silently swallowed this. IMO, we can either 1) add CPU_CFLAGS and CPU_DEFINES to CPPFLAGS, thus silently convert CPU_CFLAGS's meaning into CPU_DEFINES (Alternative solution: rename CPU_CFLAGS to CPU_DEFINES and merge CPU_FLAGS with CPU_DEFINES). or 2) destinguish between CPU_DEFINES and CPU_CFLAGS. In this case we would need to check the contents of each CPU_CFLAGS in custom/*.cfg and move the some parts of the contents to CPU_DEFINES and keep other parts in CPU_CFLAGS (CFLAGS must contain options for the c/c++-compiler only!). Though Solution 2) is the clearer one, I implemented 1) which is the simplier one (the patch below). ATTENTION: This patch is small in size, but affects almost everything. ------------ Additional complications araise with linking: Some BSPs call LD and AS directly (esp. gcc-2.7 make-exe rules). If LD=gcc then LDFLAGS are supposed to be gcc-options, but if LD=ld then LDFLAGS is supposed to contain ld-options. An analog thought is valid for AS, but luckily enough ASFLAGS is not used of inside the whole source tree. Most RTEMS' custom/*.cfg use $(CC) $(CFLAGS) to link with gcc-2.8 make-exe rules. With the patch below (CPU_CFLAGS added to CPPFLAGS) this means CPU_CFLAGS will not be passed to the linker, which is incorrect for multilibbed CPU's. gmake's default rule set contains a variety of rules for linking, all ending up in calling $(CC) $(LDFLAGS) for linking at their very end. IMO, this means we should use something like LINK.o = $(CC) $(LDFLAGS) in gcc-target-default.cfg + modify all gcc-2.8 make-exe rules to use $(LINK.o) ....... + setup LDFLAGS according to the requirements of the above. I.e. we should use $(CC) for linking instead of calling the linker (LD) directly and set LDFLAGS = $(CPPFLAGS) $(CFLAGS) or similar.
14:39 Changeset in rtems [d6f28200]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Added $(LIB_VARIANT) to start16.bin.
14:39 Changeset in rtems [98e8c7f2]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Corrected spacing.
14:36 Changeset in rtems [3dd7a72]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Removed dependency on bsp.h.
14:35 Changeset in rtems [d7e2aa65]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Corrected name of file.
14:34 Changeset in rtems [38381a66]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Changed to include FPSP in library.
14:34 Changeset in rtems [1b82a0b3]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Changed from $(INSTALL) to $(INSTALL_CHANGE).
14:34 Changeset in rtems [4b4d4a75]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Corrected Makefile.in to account for placement of include files.
14:32 Changeset in rtems [6dfebd9]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Corrected name of constant so this would compile.
Note: See TracTimeline for information about the timeline view.