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.