Re: [rtl] Recommend a Kernel

[Stephane List]

Take a look at www.rtai.org 
With LXRT, it's quite better than rtlinux, and doesn't suffer from the fsmlabs
patent.

Stephane

On Wed, Sep 26, 2001 at 07:24:54PM -0400, TJMEAR wrote :
 Hi,
I have convinced my company to allow a small team of us to develop a 
 test bed capability using RTLinux on dual processor PC's. I am soliciting 
 suggestions on a kernel version, set of patches and compiler version upon 
 which to build. While some on the team may enjoy kernel hacking, I am 
 looking for a stable SMP kernel that we can start with. If we can 
 demonstrate some success here, then Linux will have made inroads into 
 another MS-only shop. Your suggestions and advice will be gratefully 
 reviewed and considered.
 
 Thanks,
 
 TJ Mears, II
 
 
 -- [rtl] ---
 To unsubscribe:
 echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
 echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
 --
 For more information on Real-Time Linux see:
 http://www.rtlinux.org/
 

-- 
Stéphane LIST -- [EMAIL PROTECTED]
Alcôve, l'informatique est libre  -- http://www.alcove.com/
-- [rtl] ---
To unsubscribe:
echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Re: [rtl] Interrupts with RTL

[Stephane List]

Don't use SMP in your kernel and your module if you've got only one processor
(and no APIC).
I don't know how it works for rtlinux, but for RTAI, you have a function called
rt_pend_linux_irq to forward an irq to linux, and many other features to share
interrupts with linux.
 
1) Non shared IRQ
rt_request_global_irq : request IRQ
rt_pend_linux_irq : forward IRQ to linux
rt_free_global_irq

2) Shared IRQ
rt_request_linux_irq : share IRQ with Linux
rt_free_linux_irq

Stephane

On Mon, Sep 24, 2001 at 10:02:23AM +0200, David Tsaava wrote :
 Hello,
 
 I have ported one Linux Device Driver to RT-Linux.
 The driver is working properly in polling mode 
 (irq on device disabled) but there is a problem 
 with IRQs. IRQ handler is called only once and 
 run down properly. Then kernel reports 
 segmentation fault or PC crashes.
 I'm calling rtl_hard_enable_irq(irq); at the end 
 of my intrerrupt handler, so the problem is not 
 in interrupt handler itself. The same problem occures
 using ISA or PCI device, that mean the problem is not 
 necessarily shared interrupt on PCI-Bus (RT-L does not 
 support irq-sharing, which is crucial for PCI hardware).
 What I have to take into account while configuring and
 compiling RT-Linux Kernel. I'm using -D__SMP__ flag in my
 Makefile, because SMP support was set for the Kernel. What
 else have I to check?
 
 Thank you for tip.
 
 Looking forward,
 
 David Tsaava 
 
 ___
 1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
 [EMAIL PROTECTED], 8MB Speicher, Verschluesselung - http://freemail.web.de
 
 
 -- [rtl] ---
 To unsubscribe:
 echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
 echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
 --
 For more information on Real-Time Linux see:
 http://www.rtlinux.org/
 

-- 
Stéphane LIST -- [EMAIL PROTECTED]
Alcôve, l'informatique est libre  -- http://www.alcove.com/

-- [rtl] ---
To unsubscribe:
echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Re: [rtl] Making my rtlinux modules load faster

[Stephane List]

You just have to write the name of your module in /etc/modules.

On Sun, Sep 16, 2001 at 12:58:02AM -0600, Daniel Haglund wrote :
 Hi.
 
 I am planning to use rtlinux for an embedded project where the time from
 power on to fully functional is crucial.
 
 How can I load my rtlinux modules as quickly as possible?
 
 Would it even be possible to compile the standard rtlinux modules and my own
 modules into the kernel and thereby making the root filesystem optional?
 
 Any suggestion on how I can make my modules execute as soon as possible are
 appreciated.
 
 Thanks.
 
 Daniel Haglund
 
 -- [rtl] ---
 To unsubscribe:
 echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
 echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
 --
 For more information on Real-Time Linux see:
 http://www.rtlinux.org/
 

-- 
Stéphane LIST -- [EMAIL PROTECTED]
Alcôve, l'informatique est libre  -- http://www.alcove.com/

-- [rtl] ---
To unsubscribe:
echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Re: [rtl] How do I unload a crashed module?

[Stephane List]

Th easiest way is to rebuild your module, change is name and try again..
I reboot only when it crashes.

On Wed, Sep 05, 2001 at 03:58:05PM +0930, Thamm, Russell wrote :
 Hi,
 
 I apparently have an error in init_module() and I get an exception message:
 
   /usr/bin/rtlinux: line 161: 3155 Segmentation fault ${INSMOD} $modules
 
 when I load the module.
 
 However, after this I cannot unload the module :
 
   Device or resource busy.
 
 Is there any way to recover from this apart from rebooting?
 
 thanks
 Russell Thamm
 
 
 
 -- [rtl] ---
 To unsubscribe:
 echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
 echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
 --
 For more information on Real-Time Linux see:
 http://www.rtlinux.org/
 

-- 
Stéphane LIST -- [EMAIL PROTECTED]
Alcôve, l'informatique est libre  -- http://www.alcove.com/

-- [rtl] ---
To unsubscribe:
echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Re: [rtl] user space program hangs

[Stephane List]

If u use SDL, you'll use X !
Why don't try OpenGL too for 3D graphism; ;-)

The best way is to have a realtime PC without X, and to connect to it with an
other PC through ssh for example.

Or through rtcom(for RTAI, or the equivalent for rtlinux)  will be better but less 
confortable.

On Tue, Aug 21, 2001 at 09:38:05PM +0200, David Olofson wrote :
 On Tuesday 21 August 2001 17:57, Dan Peters wrote:
  David Olofson wrote:
   On Saturday 18 August 2001 09:36, Herman Bruyninckx wrote:
On Fri, 17 Aug 2001, Dan Peters wrote:
   
[...]
   
 I believe it all has to do somehow with interrupting X calls.  Do
 you have any experience with running X under rtlinux?  I have
 work with X many times in a non RT environment and have not had
 these problems. Is there a better alternative to running X for
 doing graphical stuff under RT linux.
   
Don't use X!
  
   Or make sure you've got a properly configured X server and a video
   card with a decent driver... Some work, but shouldn't by a major
   issue if you need RTLinux on the machine in the first place. (You
   don't run RTLinux on the average workstation anyway.)
 
  The video chip is a CT 65550, and as far as I know, the server has
  been configured properly.
 
 I don't know anything specific about this chip.
 
 
  This is part of a control system, which I feel needs RTlinux.  The only
  reason to use X is to display an image and
  display some other data on a display.  Are there any better
  alternatives to X.
 
 Try SDL; http://www.libsdl.org - nice and simple API, handles graphics 
 (windowed and fullscreen modes wherever possible), sound, keyboard, 
 mouse, joysticks, threads etc, and there are some helper stuff like 
 graphics loading and saving and image blitting with alpha blending or 
 colorkeying with RLE acceleration. It runs on several different 
 platforms, and most video and audio driver APIs on those platforms.
 
 More specifically; on Linux, you can transparently use X (windowed, 
 fullscreen, DGA), GGI (and whatever that supports on your system), fbdev 
 and svgalib without even recompiling your program. If you want to fiddle 
 with raw graphics data, you don't *have* to support all sorts of pixel 
 formats (like with DirectX and other direct access APIs) - SDL emulates 
 your favorite pixel format on pretty much any target with acceptable 
 speed.
 
 If you want a higher level rendering API, there are various add-on 
 libraries for SDL; fast game toolkits, widget toolkits and the like. 
 
 
 //David Olofson --- Programmer, Reologica Instruments AB
 
 .- M A I A -.
 |  Multimedia Application Integration Architecture  |
 | A Free/Open Source Plugin API for Professional Multimedia |
 ` http://www.linuxdj.com/maia -'
 .- David Olofson ---.
 | Audio Hacker - Open Source Advocate - Singer - Songwriter |
 `-- [EMAIL PROTECTED] -'
 
 -- [rtl] ---
 To unsubscribe:
 echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
 echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
 --
 For more information on Real-Time Linux see:
 http://www.rtlinux.org/
 

-- 
Stéphane LIST -- [EMAIL PROTECTED]
Alcôve, l'informatique est libre  -- http://www.alcove.com/

-- [rtl] ---
To unsubscribe:
echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Re: [rtl] ANNOUNCE: xenodaptor

[Stephane List]

On Mon, Aug 20, 2001 at 07:22:52PM +0200, Philippe Gerum wrote :
 
 Hi everyone,
 
 FYI, aside of CarbonKernel (for the few who are aware of its existence
 :o) I've just started a new free software project (GPL) called
 XENODAPTOR.
 
 It is an attempt to facilitate the migration of applications based on
 proprietary embedded RTOS to hard real-time Linux variants such as
 RTAI and RTLinux. Because the proprietary RTOS have much in common,
 especially from the thread scheduling and synchronization standpoint,
 it is possible to define an abstraction layer exporting a set of
 generic services on top of which emulation modules of these RTOS can
 be built. It is roughly the same approach that was used for
 CarbonKernel (i.e. http://www.sourceforge.net/projects/carbonkernel/),
 the RTOS simulator, but based on a real (i.e. not simulated)
 operating system.
 
 In other words, the principal motivation behind XENODAPTOR is clearly
 to help application designers relying on proprietary commercial RTOSes
 to move as smoothly as possible to Linux-based hard real-time
 extensions.
 
 I will first aim at providing this abstraction layer to support API
 emulations of embedded real-time operating systems on top of hard 
 real-time variants of Linux. Those emulation modules will mimic the
 corresponding real-time kernel APIs. For instance:
 
 +---+
 |  RTAI  |   RTLinux|
 +---+
 |  XENODAPTOR abstraction layer |
 |   |
 |   XENO emulation of pSOS+  |   XENO emulation of VxWorks  |
 +
 |   pSOS+ user application   |   VxWorks user application   |
 +---+
 
 The obtained abstraction layer will rely on the underlying real-time
 Linux variant for hardware control and architecture-dependent system
 software, and provide a high-level interface to the emulation
 modules.
 
 This project is hosted on savannah.gnu.org/projects/xenodaptor/.
 As of now, there is only a roadmap and a source tree containing the
 initial work (non-functional) on a nanokernel standing for the
 abstraction layer. I expect this nanokernel to be functional on top of
 RTAI/x86 in a few weeks, and perhaps the first emulation module
 mimicking a commercial RTOS being available by mid-October or so. I
 haven't made up my mind on the first RTOS personality I will write an
 emulator for, but it surely will be among pSOS+, VxWorks, VRTX32,
 Chorus Micro or perhaps Virtuoso. I will try hard to write some early
 documentation about the nanokernel interface, but don't expect it
 before November.
 
 Well, that's it.
 Questions, suggestions and volunteers are welcome as usual.
 
 PS: I wish to thank the RTLinux and RTAI people who, by their
 long-term effort in making real-time Linux a viable solution, have
 also made this project possible, which I hope will be useful to them
 somehow.
 
 Best regards,
 
 Philippe.
 
Very good news, I think I will try to find a job where I have to port a RT
application from Chorus to RTAI, and then contribute to xenodaptor.

If you've allready got a small documentation, I will be pleased to translate
it in french.

Stephane

-- 
Stéphane LIST -- [EMAIL PROTECTED]
Alcôve, l'informatique est libre  -- http://www.alcove.com/

-- [rtl] ---
To unsubscribe:
echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Re: [rtl] Passing numbers from RT thread to Linux thread

[Stephane List]

I think that the best way is to use union, it's nice and fast.

Stephane


On Fri, Aug 17, 2001 at 03:24:36PM +0200, David Olofson wrote :
 On Friday 17 August 2001 01:29, Calin Culianu wrote:
  On Thu, 16 Aug 2001, Victor Yodaiken wrote:
   On Thu, Aug 16, 2001 at 04:17:48PM -0400, Calin Culianu wrote:
Notice that unlike the rtf_put() function in rt-linux, the read()
system call actually was well enough written to work with void *. 
It escapes me why the rt-linux developers chose char * as opposed
to void * for their second argument to rtf_put().  All I have seen
it to do to date was confuse novices.  Can anyone enlighten me on
this fine point?
  
   Yes. The answer is lack of thought - rtf_put was quite early and
   the early UNIX read was prior to the invention of void * so we
   didn't think about it.
 
  Actually it's pure aesthetics.  char * works fine.
 
 Except that you have to do an explicit typecast to keep the C compiler 
 from warning and the C++ compiler from refusing to compile.
 
 
   And you can say
  that it emphasizes that the third argument is number of bytes.
 
 OTOH, just as sizeof() returns the size in bytes, it makes sense if every 
 size argument in every C API uses units.
 
 
  The
  only potential theoretical issue is if mankind ever builds a machine
  that runs rt-linux and that somehow has sizeof(char *) != sizeof(void
  *).  :)
 
 You know, that's not all that unrealistic. Note that some MCUs use 
 different memory areas (and different addressing modes) for read-only and 
 random access data. And certain architectures (read: x86) still support 
 obsolete and cumbersome memory models where there can be multiple, 
 differently sized kinds of pointers in a system at the same time.
 
 Now, someone else will have to figure out how that would make a void * 
 different from a char *. :-)
 
 
  In that case weird unexpected errors could occur.  Hopefully on that
  machine the compiler will be smart enough to copy the pointers
  correctly anyway :).
 
 If the pointers would really be different, it's entirely possible that 
 they one type can't be translated into the other, and possibly vice 
 versa. (Think about near and far pointers; one can be converted into the 
 other, but not the other way around - copying the buffer is the only way.)
 
 
 Uuurgh!!! I have to go and  or something - too many DOS memories are 
 coming back! ;-)
 
 
 //David Olofson --- Programmer, Reologica Instruments AB
 
 .- M A I A -.
 |  Multimedia Application Integration Architecture  |
 | A Free/Open Source Plugin API for Professional Multimedia |
 ` http://www.linuxdj.com/maia -'
 .- David Olofson ---.
 | Audio Hacker - Open Source Advocate - Singer - Songwriter |
 `-- [EMAIL PROTECTED] -'
 
 -- [rtl] ---
 To unsubscribe:
 echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
 echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
 --
 For more information on Real-Time Linux see:
 http://www.rtlinux.org/
 

-- 
Stéphane LIST -- [EMAIL PROTECTED]
Alcôve, l'informatique est libre  -- http://www.alcove.com/

-- [rtl] ---
To unsubscribe:
echo unsubscribe rtl | mail [EMAIL PROTECTED] OR
echo unsubscribe rtl Your_email | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/