pc386 IRQs not from i8259

Joel Sherrill joel.sherrill at OARcorp.com
Mon Apr 19 21:01:45 UTC 2010

On 04/19/2010 03:52 PM, Till Straumann wrote:
> Maybe it's the appropriate time to implement apic support.
> That might be better than kludging something onto the
> legacy i8259 stuff.
While this is a better solution long term,
I am trying to avoid the wide variety of deep deep
holes that could distract me.  My focus is on
the OS proper and its interface to the BSPs.
I want to get to a working baseline implementation
without spending years on tasks that can be left
as improvements.

This is really the first ugly thing I have encountered.
I already have a test program which can take from 1-32
core systems (according to qemu) from reset up to
a somewhat useful state and print their local CPU number.
Once I can generate an interprocessor interrupt, I can
return my focus to the OS issues proper.

I hope this makes sense. I would rather spend the time
right now on understanding SMP issues on multiple
architectures, the refactoring required, OS critical
sections, scheduling algorithms, etc.

> T.
> On 19/04/10 15:40, Joel Sherrill wrote:
>> Hi,
>> I am doing the groundwork for SMP support in RTEMS.
>> On the x86, an OS can generate Interprocessor Interrupts
>> (IPIs) to request that another CPU do something.
>> Unfortunately, it appears that the current IRQ
>> code is assuming that all interrupts are generated
>> from the i8259's.
>> The IPI can have any vector number.
>> My first thought is to use the first interrupt vector
>> after all the ones from the PICs and make things
>> work.
>> Any suggestions?
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

More information about the users mailing list