Timeline



05/14/99:

16:26 Changeset in rtems [9e7d42dd]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Added C++ linking rule from Rosimildo DaSilva? <rdasilva@…>.
16:25 Changeset in rtems [fcf17a4]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Added testing for C++ exceptions from Rosimildo DaSilva? <rdasilva@…>.
16:23 Changeset in rtems [44dd8a61]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Added 3COM 3C509 driver from Rosimildo DaSilva? <rdasilva@…>.
15:58 Changeset in rtems [222a71a]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Regenerated.
15:33 Changeset in rtems [8e718b67]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Regenerated.
15:31 Changeset in rtems [c5881fc1]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Enabled compilation of rtems_servers at request of Jake Janovetz <janovetz@…>.
15:21 Changeset in rtems [878baa4]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Fixed typo.
15:19 Changeset in rtems [cb20294]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Added tool hints.
15:15 Changeset in rtems [2bd9383]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
New file.
14:43 Changeset in rtems [a0b94685]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Removed check for initialized ID at request of Rosimildo DaSilva? <rdasilva@…> who encountered random failures in his port of omniORB2.
14:34 Changeset in rtems [123d4b7d]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Removed -fomit-frame-pointer from all i386 BSPs since it breaks C++ exceptions and makes debug stack traces impossible.

05/11/99:

16:30 Changeset in rtems [4c5080ed]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Fix based on bug report from Jay Kulpinski <jskulpin@…> that the per task reentrancy structure was not being processed properly during exit(). joel@… 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.
15:15 Changeset in rtems [ddd22e5]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Patch from Erik Ivanenko <erik.ivanenko@…> to correct 32 bit jmp relative offset from .reset section.

05/07/99:

17:09 Changeset in rtems [5a909149]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Made all calls to _Thread_Yield_processor consistent in how they are wrapped by calls to _Thread_Enable_dispatch and _Thread_Disable_dispatch.
16:36 Changeset in rtems [16775a5]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Patch from Jiri Gaisler <jgais@…> to allow stacksize of POSIX Init thread to be user configured.
16:31 Changeset in rtems [07001360]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Added rules to handle alternate suffixes for C++ files.
16:30 Changeset in rtems [acb644a6]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Error reporting fixed by Jennifer.
16:29 Changeset in rtems [c34aaae7]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Bug fix from Gunter Magin <magin@@skil.camelot.de>: 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.
16:28 Changeset in rtems [b06279d]4.104.114.84.95 by Joel Sherrill <joel.sherrill@…>
Bug fix from Gunter Magin <magin@…>: 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.
Note: See TracTimeline for information about the timeline view.