Embedded Linux Vs. Real time Linux - Embedded

This is a discussion on Embedded Linux Vs. Real time Linux - Embedded ; Hi all, I have some newbie questions regarding embedded Linux targeted a real time application. We are on my job considering the use of Linux in the next generation of our product line. We are looking into either a ordinary ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 38

Thread: Embedded Linux Vs. Real time Linux

  1. Embedded Linux Vs. Real time Linux

    Hi all,

    I have some newbie questions regarding embedded Linux targeted a real
    time application.

    We are on my job considering the use of Linux in the next generation
    of our product line. We are looking into either a ordinary Linux port
    (Montavista) or a Real Time port of Linux (Montavista or Wind River).
    My questions are:

    Will we still be able to write specific program code for some of the
    hardware interrupts which still operates completely independant of the
    linux kernel? For instance a DMA interrupt that needs real time
    handling will it be possible for this interrupt to immediately "de-
    schedule" the Linux kernel and service the DMA ISR and then return to
    the linux kernel, without the Linux kernel ever knowing that this
    interrupt happened?

    If this is possible and no problem to implement - what is the use and
    idea of a Real Time Linux? As I understand the Real Timelinux kernel
    allows for low interrupt latency and preemptive behavior. Also it
    implements a defined interface to the Linux application via special
    FIFOs.

    I had this discussion with one of my coworkers and I insisted on that
    this solution would not be a good Idea since the Linux kernel operates
    and handles the CPU hardware such as the interrupt controller. Writing
    specific code outside the the Linux address space accessing some sort
    of shared memory (for data transfer) and shared hardware resources
    such as the interrupt controller would in my naive opinion introduce
    some conflicts and would require some "tweaking" or modifications of
    the Linux kernel? - Is this totally of track and if so....why?

    Another question comes to my mind. If an ordinary Linux distribution
    is optimized for soft real time applications how is the hardware of
    for example a 1Gbit Ethernet mac then serviced ? On high loads holding
    relevant packets the Linux kernel (or device driver ?) must service
    the MAC hardware very often to offload the data and prevent loss of
    packets and data - How is this done fast enough in in a ordinary
    Linux?

    I hope I'm not talking totally gibberish here. I apologize for the
    eventually stupid questions - but hope that some of you experienced
    Linux guys can help clearing these questions for me.


    Best Regards.

    --
    Morten M. J - (Linux nOOb).

  2. Re: Embedded Linux Vs. Real time Linux

    >
    > Will we still be able to write specific program code for some of the
    > hardware interrupts which still operates completely independant of the
    > linux kernel?


    With any type of Linux you need to write a device driver to handle a
    hardware interrupt (but a device driver is just a kind of program )

    > For instance a DMA interrupt that needs real time
    > handling will it be possible for this interrupt to immediately "de-
    > schedule" the Linux kernel and service the DMA ISR and then return to
    > the linux kernel, without the Linux kernel ever knowing that this
    > interrupt happened?


    Same is true for DMA, as well, even if no interrupt is used.

    >
    > If this is possible and no problem to implement - what is the use and
    > idea of a Real Time Linux? As I understand the Real Timelinux kernel
    > allows for low interrupt latency and preemptive behavior. Also it
    > implements a defined interface to the Linux application via special
    > FIFOs.


    You need to decide if you need hard realtime (a (maybe even some 100 ms)
    timeout needs to be met in any case) or a soft realtime specification
    (e.g.: as an average, every years once a 100 msec timeout is allowed to
    be missed). Kernel 2.6.x offers quite good soft realtime behavior. for
    hard realtime, standard Linux is not applicable. Here you need
    commercial stuff or add-ins (like RTAI).

    >
    > I had this discussion with one of my coworkers and I insisted on that
    > this solution would not be a good Idea since the Linux kernel operates
    > and handles the CPU hardware such as the interrupt controller. Writing
    > specific code outside the the Linux address space accessing some sort
    > of shared memory (for data transfer) and shared hardware resources
    > such as the interrupt controller would in my naive opinion introduce
    > some conflicts and would require some "tweaking" or modifications of
    > the Linux kernel? - Is this totally of track and if so....why?


    If you use Linux, you need to do everything "the Linux way". There are
    lot's of specs that help and restrict.

    >
    > Another question comes to my mind. If an ordinary Linux distribution
    > is optimized for soft real time applications how is the hardware of
    > for example a 1Gbit Ethernet mac then serviced ? On high loads holding
    > relevant packets the Linux kernel (or device driver ?) must service
    > the MAC hardware very often to offload the data and prevent loss of
    > packets and data - How is this done fast enough in in a ordinary
    > Linux?


    I once heard about "realtime Ethernet", but I don't know much about
    this. Linux Realtime solutions (e.g. RTAI or PikeOS) provide a basic OS
    and Linux runs as a low priority task of same. So all realtime stuff has
    priority above all Linux stuff (including Ethernet).

    -Michael

  3. Re: Embedded Linux Vs. Real time Linux

    "Morten M. Jørgensen" skrev i meddelandet
    news:bb3f24e5-e90b-4451-8510-e16168c839cc@k2g2000hse.googlegroups.com...
    > Hi all,
    >
    > I have some newbie questions regarding embedded Linux targeted a real
    > time application.
    >
    > We are on my job considering the use of Linux in the next generation
    > of our product line. We are looking into either a ordinary Linux port
    > (Montavista) or a Real Time port of Linux (Montavista or Wind River).
    > My questions are:


    Why bother with Montavista, if you just want ordinary Linux?
    www.kernel.org?

    >
    > Will we still be able to write specific program code for some of the
    > hardware interrupts which still operates completely independant of the
    > linux kernel? For instance a DMA interrupt that needs real time
    > handling will it be possible for this interrupt to immediately "de-
    > schedule" the Linux kernel and service the DMA ISR and then return to
    > the linux kernel, without the Linux kernel ever knowing that this
    > interrupt happened?
    >


    You are likely to run with a MMU enabled.
    Your code and data needs to be in the virtual address space of a Linux
    process.

    > If this is possible and no problem to implement - what is the use and
    > idea of a Real Time Linux? As I understand the Real Timelinux kernel
    > allows for low interrupt latency and preemptive behavior. Also it
    > implements a defined interface to the Linux application via special
    > FIFOs.


    Anything is possible, given the right interrupt controller, but
    that does not mean that it is supported by Linux.
    On the AT91, you could will get a vectorized interrupt
    but I assume all vectors are the same in Linux.
    Doing something else will require modifying the linux kernel.

    The key problem is probably the transfer of data between your
    interrupt and the linux kernel.

    >
    > I had this discussion with one of my coworkers and I insisted on that
    > this solution would not be a good Idea since the Linux kernel operates
    > and handles the CPU hardware such as the interrupt controller. Writing
    > specific code outside the the Linux address space accessing some sort
    > of shared memory (for data transfer) and shared hardware resources
    > such as the interrupt controller would in my naive opinion introduce
    > some conflicts and would require some "tweaking" or modifications of
    > the Linux kernel? - Is this totally of track and if so....why?
    >
    > Another question comes to my mind. If an ordinary Linux distribution
    > is optimized for soft real time applications how is the hardware of
    > for example a 1Gbit Ethernet mac then serviced ? On high loads holding
    > relevant packets the Linux kernel (or device driver ?) must service
    > the MAC hardware very often to offload the data and prevent loss of
    > packets and data - How is this done fast enough in in a ordinary
    > Linux?


    You use a fast enoúgh processor, or rely on the TCP/IP protocol
    to resend data that gets lost because you do not have time to process it.
    At 1 Gbit, you hopefully have a DMA which can store multiple packets without
    CPU intervention.

    > I hope I'm not talking totally gibberish here. I apologize for the
    > eventually stupid questions - but hope that some of you experienced
    > Linux guys can help clearing these questions for me.
    >
    >
    > Best Regards.
    >
    > --
    > Morten M. J - (Linux nOOb).





    --
    Best Regards,
    Ulf Samuelsson
    This is intended to be my personal opinion which may,
    or may not be shared by my employer Atmel Nordic AB



  4. Re: Embedded Linux Vs. Real time Linux

    On Jan 9, 7:25 pm, "Morten M. Jørgensen" wrote:
    > We are on my job considering the use of Linux in the next generation
    > of our product line. We are looking into either a ordinary Linux port
    > (Montavista) or a Real Time port of Linux (Montavista or Wind River).


    Next to the commercial versions there are also some open source
    versions, like Xenomai or RTAI. These have the same concept: a small
    realtime kernel, and Linux as a low priority task of this kernel.
    I don't have experience with the commercial version, only with
    Xenomai, so the answers below relate to this, but are probably also
    true for other realtime versions of Linux.

    > My questions are:
    >
    > Will we still be able to write specific program code for some of the
    > hardware interrupts which still operates completely independant of the
    > linux kernel? For instance a DMA interrupt that needs real time
    > handling will it be possible for this interrupt to immediately "de-
    > schedule" the Linux kernel and service the DMA ISR and then return to
    > the linux kernel, without the Linux kernel ever knowing that this
    > interrupt happened?


    Yes, this is possible, even when Linux is processing another interrupt
    the realtime interrupt can interrupt this.
    An interrupt can be processed by Xenomai, or by Linux, or even by
    both. When leaving the ISR you can indicate if the interrupt was
    handled. If not the interrupt will be serviced by Linux.

    > If this is possible and no problem to implement - what is the use and
    > idea of a Real Time Linux? As I understand the Real Timelinux kernel
    > allows for low interrupt latency and preemptive behavior. Also it
    > implements a defined interface to the Linux application via special
    > FIFOs.


    Real time Linux allows your user level applications to run in real
    time, even under stress conditions. Using a very simple application it
    is possible to test this: wait for timer interrupt, read timestamp,
    calculate difference with previous timestamp. If you use a 10 msec
    timer interrupt you would expect the difference to be 10 msec. Under
    low/no load this is true: the variation is within 20 usec. Under load
    however the variation can be a number of msecs, which is not real time
    behavior. When using Xenomai (or other RT-Linux versions) this
    variation is still around 20 usec.

    > I had this discussion with one of my coworkers and I insisted on that
    > this solution would not be a good Idea since the Linux kernel operates
    > and handles the CPU hardware such as the interrupt controller. Writing
    > specific code outside the the Linux address space accessing some sort
    > of shared memory (for data transfer) and shared hardware resources
    > such as the interrupt controller would in my naive opinion introduce
    > some conflicts and would require some "tweaking" or modifications of
    > the Linux kernel? - Is this totally of track and if so....why?


    Xenomai is part of the Linux kernel, so the drivers exist within the
    kernel. This means that you have access to all the resources of the
    kernel. You are also using the same address scheme as Linux. If you
    want you can even write multimode drivers: both RT and non-RT drivers
    combined into one driver.
    Your applications are also running as normal Linux application, only
    with some restrictions: as long as you don't do standard Linux system
    calls your application works as a realtime application. You can also
    have a thread in an application run as real time thread, while others
    are running as Linux threads. As these are thread they share the same
    address space, so you have access to the same memory, and can use this
    to communicate between RT and non-RT.

    > Another question comes to my mind. If an ordinary Linux distribution
    > is optimized for soft real time applications how is the hardware of
    > for example a 1Gbit Ethernet mac then serviced ? On high loads holding
    > relevant packets the Linux kernel (or device driver ?) must service
    > the MAC hardware very often to offload the data and prevent loss of
    > packets and data - How is this done fast enough in in a ordinary
    > Linux?


    The interrupt routine will be called, but the processing of the data
    will be suspended until no more realtime tasks are running. This means
    that if the buffer between the interrupt routine and driver is not
    large enough you might loose data.

    Kind regards,
    Johan Borkhuis

  5. Re: Embedded Linux Vs. Real time Linux

    Hey Ulf,


    > Why bother with Montavista, if you just want ordinary Linux?www.kernel.org?


    We are considering montavista because of the support that they supply
    - we would like to use a kernel port that is fully supported. We are a
    small R&D and a even smaller SW team, therefore we would like to dodge
    the hard-core linux problems and concentrate on application
    development.

    > You are likely to run with a MMU enabled.
    > Your code and data needs to be in the virtual address space of a Linux
    > process.


    But still working as a totally independent part - not being a part of
    the Linux system in any way?

    > > If this is possible and no problem to implement - what is the use and
    > > idea of a Real Time Linux? As I understand the Real Timelinux kernel
    > > allows for low interrupt latency and preemptive behavior. Also it
    > > implements a defined interface to the Linux application via special
    > > FIFOs.

    >
    > Anything is possible, given the right interrupt controller, but
    > that does not mean that it is supported by Linux.
    > On the AT91, you could will get a vectorized interrupt
    > but I assume all vectors are the same in Linux.
    > Doing something else will require modifying the linux kernel.
    >
    > The key problem is probably the transfer of data between your
    > interrupt and the linux kernel.


    The right interrupt controller? In my world I need to have a
    possibility to mask the interrupt that I want to interrupt the Linux?
    Regarding the transfer between the ISR and the kernel - how can I do
    this when MMU is enabled and without needing to modify the kernel?


    Best Regards

    MMJ


  6. Re: Embedded Linux Vs. Real time Linux

    Morten M. Jørgensen wrote:
    > Will we still be able to write specific program code for some of the
    > hardware interrupts which still operates completely independant of the
    > linux kernel? For instance a DMA interrupt that needs real time
    > handling will it be possible for this interrupt to immediately "de-
    > schedule" the Linux kernel and service the DMA ISR and then return to
    > the linux kernel, without the Linux kernel ever knowing that this
    > interrupt happened?


    Why using a separate kernel for hard realtime, when you can get a whole hard
    realtime Linux kernel? Give RT Preeempt a try. This adds fully hard
    realtime feature to the Linux kernel (and most of it is already mainline).
    And: You can use the hard realtime feature also in userspace, to program
    hard realtime application with POSIX-API only.
    Refer: http://www.kernel.org/pub/linux/kernel/projects/rt/
    We are using this kernel patch for our x86, ARM and PowerPC boards.

    > If this is possible and no problem to implement - what is the use and
    > idea of a Real Time Linux? As I understand the Real Timelinux kernel
    > allows for low interrupt latency and preemptive behavior. Also it
    > implements a defined interface to the Linux application via special
    > FIFOs.
    >
    > I had this discussion with one of my coworkers and I insisted on that
    > this solution would not be a good Idea since the Linux kernel operates
    > and handles the CPU hardware such as the interrupt controller. Writing
    > specific code outside the the Linux address space accessing some sort
    > of shared memory (for data transfer) and shared hardware resources
    > such as the interrupt controller would in my naive opinion introduce
    > some conflicts and would require some "tweaking" or modifications of
    > the Linux kernel? - Is this totally of track and if so....why?


    With RT Preempt there is no need for such tricks. You can use all resources
    from Linux, your can write your drivers like all other drivers, you need no
    special knowledge about drivers in a separate RT kernel.

    JB

  7. Re: Embedded Linux Vs. Real time Linux

    borkhuis@gmail.com wrote:
    > On Jan 9, 7:25 pm, "Morten M. Jørgensen" wrote:
    >> We are on my job considering the use of Linux in the next generation
    >> of our product line. We are looking into either a ordinary Linux port
    >> (Montavista) or a Real Time port of Linux (Montavista or Wind River).

    >
    > Next to the commercial versions there are also some open source
    > versions, like Xenomai or RTAI.


    RTAI is depreciated. Don't use it for new projects.

    JB

  8. Re: Embedded Linux Vs. Real time Linux

    Juergen Beisert wrote:
    > borkhuis@gmail.com wrote:
    > > Next to the commercial versions there are also some open source
    > > versions, like Xenomai or RTAI.

    >
    > RTAI is depreciated. Don't use it for new projects.


    I don't know about that (I don't follow RTAI closely), but as far as I
    can see there is still development going on (a new test release was
    released this year), and the mailing list is quite active as well.

    Kind regards,
    Johan Borkhuis

  9. Re: Embedded Linux Vs. Real time Linux

    Hi Michael,

    > With any type of Linux you need to write a device driver to handle a
    > hardware interrupt (but a device driver is just a kind of program )


    Hehe...as I said I'm ultra noob into this brave new world :-D But is the
    device driver not a part of the Linux envrioment with defined ways of
    communications and scheduling together with the Linux kernel? What I am
    talking about is some totally independant code that is able to interrupt all
    Linux processes and complete it's own task before re-enabling the Linux
    execution.

    But how is the Linux/device driver interaction defined? Will a Linux device
    driver not make use of Linux system calls in some extent?

    > You need to decide if you need hard realtime (a (maybe even some 100 ms)
    > timeout needs to be met in any case) or a soft realtime specification
    > (e.g.: as an average, every years once a 100 msec timeout is allowed to be
    > missed). Kernel 2.6.x offers quite good soft realtime behavior. for hard
    > realtime, standard Linux is not applicable. Here you need commercial stuff
    > or add-ins (like RTAI).


    Take for examble my DMA interrupt. When this interrupt is raised I need to
    service the DMA and moveing some data from a circular buffer into the
    application area where the data will be processed and then trasmitted via
    ethernet. I cannot afford to miss data from the DMA since this will cause
    huge problems for our system.

    So as I see it (and do correct me if i'm the slightest wrong with this) we
    need either:

    - Some independant code outside the Linux enviroment to service the DMA ISR.
    The DMA interrupt will happen without Linux knowing and Linux will be 100%
    interrupted and resceduled after ISR completion.

    - A Real Time Linux system having a real time extension in the kernel
    including a defined interface between the real time part and the kernel.

    - Third option?

    > If you use Linux, you need to do everything "the Linux way". There are
    > lot's of specs that help and restrict.


    What would be the Linux way of the problem above?

    > I once heard about "realtime Ethernet", but I don't know much about this.
    > Linux Realtime solutions (e.g. RTAI or PikeOS) provide a basic OS and
    > Linux runs as a low priority task of same. So all realtime stuff has
    > priority above all Linux stuff (including Ethernet).


    That is exactly what we are considering - but will this be possible with a
    standard 2.6 kernel ?

    --
    MMJ



  10. Re: Embedded Linux Vs. Real time Linux

    borkhuis@gmail.com wrote:

    > Juergen Beisert wrote:
    >> borkhuis@gmail.com wrote:
    >> > Next to the commercial versions there are also some open source
    >> > versions, like Xenomai or RTAI.

    >>
    >> RTAI is depreciated. Don't use it for new projects.

    >
    > I don't know about that (I don't follow RTAI closely), but as far as I
    > can see there is still development going on (a new test release was
    > released this year), and the mailing list is quite active as well.


    Development for current kernels?

    JB

  11. Re: Embedded Linux Vs. Real time Linux



    Juergen Beisert wrote:
    > borkhuis@gmail.com wrote:
    >
    > > Juergen Beisert wrote:
    > >> RTAI is depreciated. Don't use it for new projects.

    > >
    > > I don't know about that (I don't follow RTAI closely), but as far as I
    > > can see there is still development going on (a new test release was
    > > released this year), and the mailing list is quite active as well.

    >
    > Development for current kernels?


    I did see references to 2.6.19 and 2.6.20 kernels, so that seems
    pretty current.

    Kind regards,
    Johan Borkhuis

  12. Re: Embedded Linux Vs. Real time Linux

    MMJ wrote:

    > What I am talking about is some totally independant code that is able to
    > interrupt all Linux processes and complete it's own task before
    > re-enabling the Linux execution.


    I don't understand why you would need to do this.

    You can however do whatever you like inside a Kernel device driver. At least
    on a single processor system it should still be possible to disable
    Interrupts alltogether and running your code exclusively.

    > Take for examble my DMA interrupt. When this interrupt is raised I need to
    > service the DMA and moveing some data from a circular buffer into the
    > application area where the data will be processed and then trasmitted via
    > ethernet.


    The generic Linux way would be to implement an Interrupt service routine in
    your device driver which will afterwords transfer your Data to userland.

    If speed is important you might be able to use mmap instead to prevent the
    data from getting transmitted between kernel and userland too often.

    > - Some independant code outside the Linux enviroment to service the DMA ISR.


    Again, I don't see any reason why this code need to run outside the Linux
    kernel enviroment.

    > The DMA interrupt will happen without Linux knowing


    Again, I don't see a reason, why this should be necessary

    > and Linux will be 100% interrupted and resceduled after ISR completion.


    This is possible to do with the standard Linux Kernel API.

    > - A Real Time Linux system having a real time extension in the kernel
    > including a defined interface between the real time part and the kernel.


    Some Real Time Linux systems (e.g. RTAI) do it this way.

    An ordinary Linux Kernel with Realtime Preemption patches will however
    provide ordinary Unix _Userland Applications_ with Realtime capabilities
    (http://rt.wiki.kernel.org/).

    Sven

    --
    TCP/IP: telecommunication protocol for imbibing pilsners
    (Man-page uubp(1C) on Debian/GNU Linux)

    /me is giggls@ircnet, http://sven.gegg.us/ on the Web

  13. Re: Embedded Linux Vs. Real time Linux

    Hello Juergen,

    > Why using a separate kernel for hard realtime, when you can get a whole
    > hard
    > realtime Linux kernel? Give RT Preeempt a try. This adds fully hard
    > realtime feature to the Linux kernel (and most of it is already mainline).
    > And: You can use the hard realtime feature also in userspace, to program
    > hard realtime application with POSIX-API only.
    > Refer: http://www.kernel.org/pub/linux/kernel/projects/rt/
    > We are using this kernel patch for our x86, ARM and PowerPC boards.


    > With RT Preempt there is no need for such tricks. You can use all
    > resources
    > from Linux, your can write your drivers like all other drivers, you need
    > no
    > special knowledge about drivers in a separate RT kernel.


    That sound really interesting. Exactly what I am looking for - a complete
    solution that allows for hard RT performance without forcing us to do
    experiments trying to integrate outside RT code. I'll look into that for
    sure

    --
    MMJ



  14. Re: Embedded Linux Vs. Real time Linux

    >> Why bother with Montavista, if you just want ordinary
    >> Linux?www.kernel.org?

    >
    > We are considering montavista because of the support that they supply
    > - we would like to use a kernel port that is fully supported. We are a
    > small R&D and a even smaller SW team, therefore we would like to dodge
    > the hard-core linux problems and concentrate on application
    > development.
    >
    >> You are likely to run with a MMU enabled.
    >> Your code and data needs to be in the virtual address space of a Linux
    >> process.

    >
    > But still working as a totally independent part - not being a part of
    > the Linux system in any way?
    >
    >> > If this is possible and no problem to implement - what is the use and
    >> > idea of a Real Time Linux? As I understand the Real Timelinux kernel
    >> > allows for low interrupt latency and preemptive behavior. Also it
    >> > implements a defined interface to the Linux application via special
    >> > FIFOs.

    >>
    >> Anything is possible, given the right interrupt controller, but
    >> that does not mean that it is supported by Linux.
    >> On the AT91, you could will get a vectorized interrupt
    >> but I assume all vectors are the same in Linux.
    >> Doing something else will require modifying the linux kernel.
    >>
    >> The key problem is probably the transfer of data between your
    >> interrupt and the linux kernel.

    >
    > The right interrupt controller? In my world I need to have a
    > possibility to mask the interrupt that I want to interrupt the Linux?
    > Regarding the transfer between the ISR and the kernel - how can I do
    > this when MMU is enabled and without needing to modify the kernel?



    If you have a prioritized interrupt controller like the AT91 AIC,
    then you can have one level of interrupts which will enter the
    Linux Interrupt routine, and other (higher) levels could
    be used to generate interrupt vectors to high priority interrupts,
    including the FIQ (Fast Interrupt).

    You will have to have your code in the linux kernel address space,
    but there is no need to link it with the kernel.

    Use of FIQ, will require you to have your non-linux code right
    after the exception vector table.

    --
    Best Regards,
    Ulf Samuelsson
    This is intended to be my personal opinion which may,
    or may not be shared by my employer Atmel Nordic AB



  15. Re: Embedded Linux Vs. Real time Linux

    Juergen Beisert wrote:
    > Morten M. Jørgensen wrote:
    >> Will we still be able to write specific program code for some of the
    >> hardware interrupts which still operates completely independant of the
    >> linux kernel? For instance a DMA interrupt that needs real time
    >> handling will it be possible for this interrupt to immediately "de-
    >> schedule" the Linux kernel and service the DMA ISR and then return to
    >> the linux kernel, without the Linux kernel ever knowing that this
    >> interrupt happened?

    >
    > Why using a separate kernel for hard realtime, when you can get a whole hard
    > realtime Linux kernel? Give RT Preeempt a try. This adds fully hard
    > realtime feature to the Linux kernel (and most of it is already mainline).
    > And: You can use the hard realtime feature also in userspace, to program
    > hard realtime application with POSIX-API only.
    > Refer: http://www.kernel.org/pub/linux/kernel/projects/rt/
    > We are using this kernel patch for our x86, ARM and PowerPC boards.
    >


    Also for PowerPC ?
    that's interesting. Last time I tried (2.6.19) things didn't seem to build/work
    for our MPC82xx based PowerPC boards.

    I you don't mind me asking, what kind of PowerPC CPUs/board you did successfully apply
    the RT patch for ? with what kernel version ?

    ---
    NvB

  16. Re: Embedded Linux Vs. Real time Linux

    Juergen Beisert wrote:
    > Morten M. Jørgensen wrote:
    >> Will we still be able to write specific program code for some of the
    >> hardware interrupts which still operates completely independant of the
    >> linux kernel? For instance a DMA interrupt that needs real time
    >> handling will it be possible for this interrupt to immediately "de-
    >> schedule" the Linux kernel and service the DMA ISR and then return to
    >> the linux kernel, without the Linux kernel ever knowing that this
    >> interrupt happened?

    >
    > Why using a separate kernel for hard realtime, when you can get a whole hard
    > realtime Linux kernel? Give RT Preeempt a try. This adds fully hard
    > realtime feature to the Linux kernel (and most of it is already mainline).
    > And: You can use the hard realtime feature also in userspace, to program
    > hard realtime application with POSIX-API only.
    > Refer: http://www.kernel.org/pub/linux/kernel/projects/rt/
    > We are using this kernel patch for our x86, ARM and PowerPC boards.
    >


    Also for PowerPC ?
    that's interesting. Last time I tried (2.6.19) things didn't seem to build/work
    for our MPC82xx based PowerPC boards.

    I you don't mind me asking, what kind of PowerPC CPUs/board you did successfully apply
    the RT patch for ? with what kernel version ?

    ---
    NvB

  17. Re: Embedded Linux Vs. Real time Linux

    Norbert van Bolhuis wrote:
    > Juergen Beisert wrote:
    >> Morten M. Jørgensen wrote:
    >>> Will we still be able to write specific program code for some of the
    >>> hardware interrupts which still operates completely independant of the
    >>> linux kernel? For instance a DMA interrupt that needs real time
    >>> handling will it be possible for this interrupt to immediately "de-
    >>> schedule" the Linux kernel and service the DMA ISR and then return to
    >>> the linux kernel, without the Linux kernel ever knowing that this
    >>> interrupt happened?

    >>
    >> Why using a separate kernel for hard realtime, when you can get a whole
    >> hard realtime Linux kernel? Give RT Preeempt a try. This adds fully hard
    >> realtime feature to the Linux kernel (and most of it is already
    >> mainline). And: You can use the hard realtime feature also in userspace,
    >> to program hard realtime application with POSIX-API only.
    >> Refer: http://www.kernel.org/pub/linux/kernel/projects/rt/
    >> We are using this kernel patch for our x86, ARM and PowerPC boards.
    >>

    >
    > Also for PowerPC ?
    > that's interesting. Last time I tried (2.6.19) things didn't seem to
    > build/work for our MPC82xx based PowerPC boards.
    >
    > I you don't mind me asking, what kind of PowerPC CPUs/board you did
    > successfully apply the RT patch for ? with what kernel version ?


    Freescale's MPC5200B with a 2.6.23.1 and currently 2.6.24.rc5. But the
    2.6.24.rc5 has still some regressions.

    JB

  18. Re: Embedded Linux Vs. Real time Linux


    > But is the
    > device driver not a part of the Linux envrioment with defined ways of
    > communications and scheduling together with the Linux kernel?


    Of course. But that is more of a benefit than a restriction.

    > What I am
    > talking about is some totally independant code that is able to interrupt all
    > Linux processes and complete it's own task before re-enabling the Linux
    > execution.


    The standard Linux Kernel will disable the interrupt now and then, so
    the interrupt will not be recognized by the processor. If your hardware
    allows multiple interrupt priorities, you could modify the Kernel to
    leave one level enabled for your DMA system, but if you do so, there is
    no decent possibility (other then a hardware FIFO or similar) to have
    your system communicate with the Linux system (to pass the acquired
    data), as you can't construct a non-spinning semaphore.

    For any decently constructed hardware that creates or needs data bytes
    in a speed that is slow enough for moving the stream via Ethernet, with
    a decent processor a DMA enabled device driver should be by far
    appropriate (otherwise the Ethernet driver would fail).

    If the hardware does not give the processor enough time to allow for
    some decent latency between two consecutive DMA actions, the hardware is
    erroneously constructed. It should contain some kind of FIFO, double
    buffers or a similar construct. With that the processor can react on the
    end of the previous DMA block while the next is running.

    -Michael

  19. Re: Embedded Linux Vs. Real time Linux


    > Of course. But that is more of a benefit than a restriction.


    Indeed it is - I my self would like to everything the right way keeping us
    from adding outside code and doing kernel modifications.

    > The standard Linux Kernel will disable the interrupt now and then, so the
    > interrupt will not be recognized by the processor. If your hardware allows
    > multiple interrupt priorities, you could modify the Kernel to leave one
    > level enabled for your DMA system, but if you do so, there is no decent
    > possibility (other then a hardware FIFO or similar) to have your system
    > communicate with the Linux system (to pass the acquired data), as you
    > can't construct a non-spinning semaphore.


    So what you are saying is that the Linux kernel WILL disable global
    interrupts from time to time. But I guees the interrupt still will be
    pending when the interrupts are reenabled by the kernel ?
    This causes a delay on the service time of the DMA and worst case is that
    the buffer overflows. Which parameter decides how long the kernel wil
    disable interrupts - CPU load? Is it posiible to make any estimation of this
    time?

    > If the hardware does not give the processor enough time to allow for some
    > decent latency between two consecutive DMA actions, the hardware is
    > erroneously constructed. It should contain some kind of FIFO, double
    > buffers or a similar construct. With that the processor can react on the
    > end of the previous DMA block while the next is running.


    I'll pass this on to the HW team :-D

    --
    MMJ



  20. Re: Embedded Linux Vs. Real time Linux

    > So what you are saying is that the Linux kernel WILL disable global
    > interrupts from time to time.


    AFAIK, this is correct (maybe depending on the CPU architecture). You
    need to inspect the Kernel sources to be sure.

    > But I guees the interrupt still will be
    > pending when the interrupts are reenabled by the kernel ?


    Right.

    > This causes a delay on the service time of the DMA and worst case is that
    > the buffer overflows. Which parameter decides how long the kernel wil
    > disable interrupts - CPU load? Is it posiible to make any estimation of this
    > time?


    As Linux is not meant to be a realtime OS there are no specs on this.
    But of course the time is rather short. But If you can live with that
    delay I'm quite sure that doing a standard interrupt driven Linux device
    driver will do the work, too.

    >
    > I'll pass this on to the HW team :-D
    >


    What kind of hardware do you (intend to) have ? If you do this with an
    FPGA, maybe the hardware can be done/changed appropriately. Anyway if
    designing hardware that is to communicate with a processor, the
    appropriate design rules should be followed.

    -Michael

+ Reply to Thread
Page 1 of 2 1 2 LastLast