Timeline



03/24/00:

14:08 Changeset in rtems [45a79f38]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Added instructions on running ttcp from Eric Norum <eric@…>.
14:01 Changeset in network-demos [de34d7b]netdemos-4-5-branch by Joel Sherrill <joel.sherrill@…>
Added instructions on running ttcp from Eric Norum <eric@…>.

03/23/00:

13:57 Changeset in rtems [969525fe] by Joel Sherrill <joel.sherrill@…>
Added missing include of <sys/types.h> required by added prototypes.

03/22/00:

14:04 Changeset in rtems [94795bbd] by Joel Sherrill <joel.sherrill@…>
Patch rtems-rc-4.5.0-5-cvs.diff from Ralf Corsepius <corsepiu@…> that allows bootstrap to be run from subdirectories.

03/21/00:

21:35 Changeset in rtems [96cf1812] by Joel Sherrill <joel.sherrill@…>
Removed referecnes to BSP specific files. Other corrections will likely be needed in the efi332 BSP.
21:33 Changeset in rtems [776d696] by Joel Sherrill <joel.sherrill@…>
Corrected mpc505/mpc509 support based on patch from Wilfried Busalski <fue@…>.
20:15 Changeset in rtems [af7a0ed] by Joel Sherrill <joel.sherrill@…>
Patch from Eric Norum <eric@…> to correct calls to memset(). The arguments for value and size were reversed everywhere.
18:35 Changeset in rtems [05a34668] by Joel Sherrill <joel.sherrill@…>
Patch from Gunter Magin <magin@…> where the type was not large enough to support high baud rates. brg_spd[] is an array which stores the baud rates, for which one of the 4 available BRG dividers has been set. The array is used for deciding if a BRG devider may be reused. > 1. What baud_rate and divisor is causing this to fail? divisor is dependent on the system clock (Cpu_table.clock_speed), and gets calculated in m860_get_brg_cd. m860_get_brg_clk fails for any baudrates > (216-1), as those baudrates are truncated to 16 bit which is the size of a short. In fact, as it has been a short and not an unsigned short, it will fail at any baudrate >(215-1). In any case, it failed for my application, which required 250000 Baud.
18:05 Changeset in rtems [abbf55b] by Joel Sherrill <joel.sherrill@…>
Ran ampolish after getting new version from Ralf Corsepius <corsepiu@…>.
17:57 Changeset in rtems [6f921ba] by Joel Sherrill <joel.sherrill@…>
Ran ampolish after getting new version from Ralf Corsepius <corsepiu@…>.
17:11 Changeset in rtems [67077a1] by Joel Sherrill <joel.sherrill@…>
Patches rtems-rc-4.5.0-1.diff from Ralf Corsepius <corsepiu@…> that addresses the following: * Duplicate variables in Makefiles (many Makefile.ams below c/src/test are affected systematically) * Erroniously using local.am instead of host.am in host-Makefile.am (Only host Makefile.ams should be affected; Erroniously using local.am in host-Makefiles doesn't desturb much) * use '.' instead of '$pwd' in ./bootstrap (using $pwd does not work if $pwd is a symlink on linux). * Broken CVS Ids somewhere * Removing redundant/obsolete make variables from *.cfg files. Except of the last item from the list above, most parts of this patch are fairly harmless, sometimes even cosmetical. As mentioned before, this patch also contains a new ampolish script. This script features: * Pretty printing of Makefile.ams (eg. removal of trailing spaces, removal of duplicate empty lines, pretty printing make variables, etc.). * Some syntactical checks on the contents of Makefiles.am * Proper handling of Automake conditionals FYI: * Applying tools/update/rtems-polish.sh -am completely reformats all Makefile.am resulting into a very large (~500k) diff. * Applying tools/update/rtems-polish.sh -am twice, finally does not reformat the Makefile.ams anymore. * Many parts of the patch above result from merging back issues which have shown when applying this new ampolish (i.e. partially result from extracting the essentials of reformating being proposed by applying it on Makefile.ams). Though this ampolish is a very nice tool, IMHO, I am hestitant if you should apply (i.e. run tools/update/rtems-polish.sh -am) it to the sources before the release, because * the resulting diff is fairly large * I am not 100% sure it doesn't break anything. However, applying it after the release would result into compatibility problems in applying patches ;) I would suggest that you might consider trying it locally, then to examine the diff and then to decide whether to apply it in general or not. Joel's Comments: As Ralf points out, this patch is problematic in that applying it before a release could break things but applying it afterwards will result in patches being unusable for Makefiles. My inclination is to forge ahead and apply it.
15:56 Changeset in rtems [15b6e46f] by Joel Sherrill <joel.sherrill@…>
Patch from Charles-Antoine Gauthier <charles.gauthier@…> to fix problem where wait() was in this file -- not waitpid().
15:36 Changeset in rtems [d5666945] by Joel Sherrill <joel.sherrill@…>
After Charles-Antoine Gauthier <charles.gauthier@…> spotted that the prototype for tcsendbreak() was missing, Joel noticed that others were as well and added them.
15:06 Changeset in rtems [d6b0477] by Joel Sherrill <joel.sherrill@…>
Patch from Gunter Magin <magin@…>. It seems to me I have found a bug in m860_smc_initialize(). This function lives in c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c. The following lines are supposed to set the simode register with the baud rate generator index, which has been returned from m860_get_brg_clk(). (line 386 of console-generic.c) /* * Put SMC in NMSI mode, connect SMC to BRG */ m860.simode &= ~0x7000 << ((port-1) * 8); m860.simode |= brg << (12 + ((port-1) * 8)); This works well for port == 1 (SMC1), however for SMC2 (port == 2) it fails. First, the simode register consists of 2 16bit parts (one for SMC1 and SMC2 respectively), hence the shift count is wrong. Second ~0x7000 (which is 0xffff8fff is shifted left and pulls 0 from the right, which kills the SMC1 entries, when written back to the simode register. Substitute those lines by: m860.simode &= ~(0x7000 << ((port-1) * 16)); m860.simode |= brg << (12 + ((port-1) * 16)); I have checked snapshot 20000218a which still contains the bug. Also affected is libcpu/powerpc/mpc821/console_generic.c, which is a cut&paste&substitue decendant of the mpc860 console-generic.c. CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: Tag: rtems-4-5-branch CVS: console-generic.c CVS: ----------------------------------------------------------------------
15:05 Changeset in rtems [218103d] by Joel Sherrill <joel.sherrill@…>
Patch from Gunter Magin <magin@…>. It seems to me I have found a bug in m860_smc_initialize(). This function lives in c/src/lib/libcpu/powerpc/mpc860/console-generic/console-generic.c. The following lines are supposed to set the simode register with the baud rate generator index, which has been returned from m860_get_brg_clk(). (line 386 of console-generic.c) /* * Put SMC in NMSI mode, connect SMC to BRG */ m860.simode &= ~0x7000 << ((port-1) * 8); m860.simode |= brg << (12 + ((port-1) * 8)); This works well for port == 1 (SMC1), however for SMC2 (port == 2) it fails. First, the simode register consists of 2 16bit parts (one for SMC1 and SMC2 respectively), hence the shift count is wrong. Second ~0x7000 (which is 0xffff8fff is shifted left and pulls 0 from the right, which kills the SMC1 entries, when written back to the simode register. Substitute those lines by: m860.simode &= ~(0x7000 << ((port-1) * 16)); m860.simode |= brg << (12 + ((port-1) * 16)); I have checked snapshot 20000218a which still contains the bug. Also affected is libcpu/powerpc/mpc821/console_generic.c, which is a cut&paste&substitue decendant of the mpc860 console-generic.c.
14:46 Changeset in rtems [477f347] by Joel Sherrill <joel.sherrill@…>
Problem reported by Chris Johns <ccj@…> that webcomp.c was being built and included in the target code. It is a host utility.
Note: See TracTimeline for information about the timeline view.