Re: [uCsimm] RTLinux and the uCsimm

From: Digby the TECH !! (petera@paraparaumucollege.school.nz)
Date: Wed Oct 11 2000 - 23:57:53 EDT


To: D. Peter Siddons

I don't think this message was intended for me so I'm just letting
you know it mightn't have reached its intended target!

Pam Childs
Librarian
Paraparaumu College.

Date sent: Wed, 11 Oct 2000 20:42:19 +0000
From: "D. Peter Siddons" <peter@lspc6.nsls.bnl.gov>
Organization: National Synchrotron Light Source
To: ucsimm@uClinux.com
Subject: Re: [uCsimm] RTLinux and the uCsimm
Send reply to: ucsimm@uClinux.com

> 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-2.0.38.0. I also made a copy of that tree into
> uClinux-2.0.38.0-rt0.9j. 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-2.0.38.0-rt0.9j
> deftemplate.sh lib romdisk uClinux-RTL0.9j.diff
> dev m68k-coff src
> include m68k-pic-coff uClinux-2.0.38.0
>
> 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-2.0.38.0/Makefile uClinux-2.0.38.0-rt0.9j/Makefile
> |--- uClinux-2.0.38.0/Makefile Sun Mar 12 20:14:05 2000
> |+++ uClinux-2.0.38.0-rt0.9j/Makefile 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
> anything.
> Pete.
>
>
> 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 (2.0.38.0 vs 2.0.38.1) 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 ucsimm@uclinux.com list server http://www.uClinux.com/
> >
> > 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
> > 'www.openhardware.net', 'www.cyberiansoftware.com'
> > "Windows? No thanks, I have work to do..."
> > This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/
> This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/

Digby the Tech
This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/



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