Re: [uCsimm] RTLinux and the uCsimm

From: D. Peter Siddons (
Date: Wed Oct 11 2000 - 16:42:19 EDT

Thanks for all the info. However, I'm stupid; I can't make it work.
I never used the patch command before, sorry :( Here's what I did.
I make a directory /opt/rt-uClinux, and copied the uClinux distribution
into it. Within this directory, I renamed the linux directory to be
uClinux- I also made a copy of that tree into
uClinux- Based on the text in the uClinux-RTL0.9j.diff
file, this seemed to be how it was expecting to find things. So this
is what I had:

peter:/opt/rt-uClinux# ls
bin info man uClinux- lib romdisk uClinux-RTL0.9j.diff
dev m68k-coff src
include m68k-pic-coff uClinux-

and this is what I did:

peter:/opt/rt-uClinux# patch <uClinux-RTL0.9j.diff
can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
|diff -urN uClinux- uClinux-
|--- uClinux- Sun Mar 12 20:14:05 2000
|+++ uClinux- Sun Mar 12 20:07:40 2000
File to patch:

So what am I doing wrong? Reading the man page for patch didn't reveal

Tom Walsh wrote:
> "D. Peter Siddons" wrote:
> >
> > Can anyone point me to simple instructions for making the RT
> > patches to uClinux using the .diff files provided on the
> > March 2000 CD? It seems to me the patches are generated from
> > a different uclinux version ( vs and so
> > the patches fail, or I just don't know what I'm doing.
> > Which is quite likely :) Any pointers would be appreciated.
> > Pete Siddons
> > This message resent by the list server
> I applied the patches against the modified 2.0.381pre1 sources without
> problems, it appears that the patches were made against uClinux as
> opposed to a stock kernel. I have been told that there are problems
> with the RT-Linux patches that need to be cleared up. I was warned that
> the kernel could suddenly do a Hard Crash (freeze) at times and I did
> have this happen to me while with a customer, fortunately, the customer
> did not notice and I quietly reset the board. Since then, I have not
> done anything with the RT-Linux modified sources and have returned to
> attaching the RT problem from the standpoint of adding this
> functionality into the stock uClinux source. The freezing problem seems
> to come from a collision of the RT-Linux patch "forgetting" to
> reprogramm the timer so it will fire again later. The RT patches
> assumed that it would be multiplexing the timer with the jiffies
> interrupts and be calculating when to allow the jiffies to have the
> interrupt response, or the RT ISR would service the interrupt (I have
> not verified this as being the case, but I respect the source of this
> information).
> This does have its own issues, for example, the most powerful realtime
> resource (the Timer) is used to maintain the jiffies clock. As this is
> a level 6 interrupt source, there is little chance of losing "ticks" of
> the clock and timekeeping is stable. It would be possible to tack on
> some additional code to the Timer interrupt to do some fixed realtime
> stuff, but it would have to be at a fixed rate of 1 ms. Not too bad,
> but you have to keep your ISR time down to < 1ms so you don't lose a
> "tick".
> Another solution that I have looked at is to used the SAM (sampling rate
> timer) as a RealTime element, this does work but you are restricted as
> to the rates you can get, with the max period to be at 512hz. I have an
> application that does this, ..., it does have an odd problem that I need
> to track down that seems to be related to the interrupt services,
> occasionally I get an odd reading from my hardware. I am not sure why
> this is, I have to still determine if the erroneous reading is due to an
> actual hardware reading, or if it is a problem with register values
> being indeterminate under some conditions (perhaps a higher level
> interrupt is disturbing the register contents).
> Another solution would be to use the level 7 interupt to drive the
> jiffies clock, thus freeing up the 16 bit timer + SAM timer for
> application use. To do this, some external hardware is needed. I am
> toying with the idea of taking the 32kHz clock of the processor, running
> it thru a 6 stage divider to produce a 1024 Hz interrupt, and changing
> the jiffies rate from 100 to a 1024 divisor (the #define HZ value). You
> have to be careful on implementing this as the *EMUIRQ is a level
> triggered interrupt and you would need to reset the last stage of the
> divider to "ack" the interrupt source. Using a 74HCT393 would work with
> some combinational logic, or a PLD...
> Any other ideas or comments?
> TomW
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> '', ''
> "Windows? No thanks, I have work to do..."
> This message resent by the list server
This message resent by the list server

This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:38 EST