| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
<rdasilva@connecttel.com> who encountered random failures in his
port of omniORB2.
|
| |
|
|
| |
exceptions and makes debug stack traces impossible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that the per task reentrancy structure was not being processed properly
during exit().
joel@oarcorp.com 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.
|
| |
|
|
| |
jmp relative offset from .reset section.
|
| |
|
|
| |
wrapped by calls to _Thread_Enable_dispatch and _Thread_Disable_dispatch.
|
| |
|
|
| |
of POSIX Init thread to be user configured.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
a BSP for the TS-1325 embedded PC from Technologic Systems
(http://www.t-systems.com) and patches to enable software
floating-point emulation for x86 targets.
|
| |
|
|
|
|
|
|
|
|
| |
I have made test with the Dec21140 driver and it appears that all
works fine even if the cache is enabled for the memory space in
which the incoming and outcoming Ethernet frames are stored.
I have had #ifdef to "comment" the code. If you want to disable
cache, you only have to #define the name. It could be mandatory
for some BSPs.
|
| |
|
|
| |
that results in an error in parsing network unit names/numbers.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
University of British Columbia. The BSP is for:
Yes, this is the "entry model" of a series of boards from Technologic
Systems. Costs <$200 I believe. They have a WWW page at www.t-systems.com.
I am letting them know about the availability of this BSP too.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
based on 3.6.0. It was very lucky that this went in as well as it
did.
|
| | |
|
| |
|
|
| |
<ccj@acm.org> of Objective Design Systems.
|
| |
|
|
| |
porting of ACE to RTEMS.
|
| | |
|
| |
|
|
|
| |
Jiri Gaisler caught this and submitted a patch but a subsequent patch
backed it out accidentally.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
seeing.
|
| |
|
|
|
| |
I added __INSIDE_RTEMS_BSD_TCPIP_STACK__ that trips all the needed
macro definitions for a network driver.
|
| |
|
|
|
| |
I added __INSIDE_RTEMS_BSD_TCPIP_STACK__ that trips all the needed
macro definitions for a network driver.
|
| |
|
|
|
| |
I added __INSIDE_RTEMS_BSD_TCPIP_STACK__ that trips all the needed
macro definitions for a network driver.
|
