Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Joel Sherrill]

On Thu, Aug 9, 2018 at 1:13 PM, Amaan Cheval  wrote:

> Haha, my tc_frequency was set all wrong, causing the date to be wonky.
>
> The dispatching issue turned out to be a (potential) QEMU bug where
> "decq" wouldn't set the ZF in EFLAGS even if it resulted in a 0 value,
> causing the "jne" to always be taken.
>
> Anyway, here's where we're at now:
>
> Start @ 0x1027f9 ...
> EFI framebuffer information:
> addr, size 0x8000, 0x1d4c00
> dimensions 800 x 600
> stride 800
> masks  0x00ff, 0xff00, 0x00ff, 0xff00
> Filling 512 page tables
> 1gib pages not supported!
> maxphysaddr = 48
> sidt = ff f a8 39 34 0 0 0 0 0
> us_per_tick = 1
> Desired frequency = 100 irqs/sec
> APIC was at fee0
> APIC is now at fee0
> APIC ID at *fee00020=0
> APIC spurious vector register *fee000f0=10f
> APIC spurious vector register *fee000f0=1ff
> CPU frequency: 0x57c60
> APIC ticks/sec: 0x57c6qemu-system-x86_64: warning: I/O thread spun for
> 1000 iterations
>
>
> *** BEGIN OF TEST CLOCK TICK ***
> *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
> TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
> TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:05   12/31/1988
> TA2  - rtems_clock_get_tod - 09:00:10   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:10   12/31/1988
> TA3  - rtems_clock_get_tod - 09:00:15   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:15   12/31/1988
> TA2  - rtems_clock_get_tod - 09:00:20   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:20   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:25   12/31/1988
> TA3  - rtems_clock_get_tod - 09:00:30   12/31/1988
> TA2  - rtems_clock_get_tod - 09:00:30   12/31/1988
> TA1  - rtems_clock_get_tod - 09:00:30   12/31/1988
>
> *** END OF TEST CLOCK TICK ***
>
>
+1

>
> *** FATAL ***
> fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
> fatal code: 0 (0x)
> RTEMS version: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
> RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> executing thread ID: 0x08a010002
> executing thread name: TA1
> qemu-system-x86_64: terminating on signal 2
>
> -
>
> 2 issues:
> - It isn't reliably this way - sometimes it may start at 9:00:01 (and
> then the rest are 6, 11, etc.). I'm using a very naive timecounter
> (number of IRQs occurred so far) right now - I'll have it account for
> the ticks since the last IRQ too, which I imagine may help with this?
>

Some of the simulators are odd this way. But I would expect this to
behave better. It is probably a calibration issue. There should be more
than enough time to do the prints and handle the tick ISRs. On some
simulators, it isn't that way.

The initialization should program it to get an interrupt based on the
configured microseconds per tick. You need the calibration or truth
speed to do this. I assume that calibration that would work on real
HW would work on qemu.


> - It is much slower than IRL time - I'm not sure if this is just due
> to QEMU or perhaps from ISRs piling over each other due to the handler
> taking too long. I'm not quite sure how to find out either.
>

This is expected. I recall it is ~2x IRL time for pc386 ticker.


>
> Let me know if you have any suggestions!
>
> Patches incoming soon too, so I'd appreciate reviews! :)
>

Nearly working is a great sign!


>
> On Thu, Aug 9, 2018 at 8:12 PM, Joel Sherrill  wrote:
> >
> >
> > On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval 
> wrote:
> >>
> >> Addition to status: it doesn't seem like the RTEMS Interrupt's call to
> >> _Thread_Dispatch functions either - ticker.exe has outputs like the
> >> following (yeah, the counter is running too quickly right now):
> >>
> >> *** BEGIN OF TEST CLOCK TICK ***
> >> *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb
> 93a425fc83-modified
> >> *** TEST STATE: EXPECTED-PASS
> >> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> >> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> >> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> >> TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
> >> TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
> >> TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990
> >
> >
> > Congratulations! But why is the date 5/12/1990? I think it is supposed
> > to be 12/31/1989. :)
> >>
> >>
> >> (And then the _Thread_Idle_body is never preempted due to the
> >> interrupt dispatching a new thread - not sure if it just thinks it's
> >> "too late" to even bother or if simply never even tries. I'll keep
> >> investigating.)
> >
> >
> > This means your "outer" assembly language _ISR_Handler does not
> 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

Haha, my tc_frequency was set all wrong, causing the date to be wonky.

The dispatching issue turned out to be a (potential) QEMU bug where
"decq" wouldn't set the ZF in EFLAGS even if it resulted in a 0 value,
causing the "jne" to always be taken.

Anyway, here's where we're at now:

Start @ 0x1027f9 ...
EFI framebuffer information:
addr, size 0x8000, 0x1d4c00
dimensions 800 x 600
stride 800
masks  0x00ff, 0xff00, 0x00ff, 0xff00
Filling 512 page tables
1gib pages not supported!
maxphysaddr = 48
sidt = ff f a8 39 34 0 0 0 0 0
us_per_tick = 1
Desired frequency = 100 irqs/sec
APIC was at fee0
APIC is now at fee0
APIC ID at *fee00020=0
APIC spurious vector register *fee000f0=10f
APIC spurious vector register *fee000f0=1ff
CPU frequency: 0x57c60
APIC ticks/sec: 0x57c6qemu-system-x86_64: warning: I/O thread spun for
1000 iterations


*** BEGIN OF TEST CLOCK TICK ***
*** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
*** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:05   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:10   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:10   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:15   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:15   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:20   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:20   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:25   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:30   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:30   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:30   12/31/1988

*** END OF TEST CLOCK TICK ***


*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x)
RTEMS version: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
RTEMS tools: 7.3.0 20180125 (RTEMS 5, RSB
25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
executing thread ID: 0x08a010002
executing thread name: TA1
qemu-system-x86_64: terminating on signal 2

-

2 issues:
- It isn't reliably this way - sometimes it may start at 9:00:01 (and
then the rest are 6, 11, etc.). I'm using a very naive timecounter
(number of IRQs occurred so far) right now - I'll have it account for
the ticks since the last IRQ too, which I imagine may help with this?
- It is much slower than IRL time - I'm not sure if this is just due
to QEMU or perhaps from ISRs piling over each other due to the handler
taking too long. I'm not quite sure how to find out either.

Let me know if you have any suggestions!

Patches incoming soon too, so I'd appreciate reviews! :)

On Thu, Aug 9, 2018 at 8:12 PM, Joel Sherrill  wrote:
>
>
> On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval  wrote:
>>
>> Addition to status: it doesn't seem like the RTEMS Interrupt's call to
>> _Thread_Dispatch functions either - ticker.exe has outputs like the
>> following (yeah, the counter is running too quickly right now):
>>
>> *** BEGIN OF TEST CLOCK TICK ***
>> *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
>> *** TEST STATE: EXPECTED-PASS
>> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
>> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
>> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
>> TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
>> TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
>> TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990
>
>
> Congratulations! But why is the date 5/12/1990? I think it is supposed
> to be 12/31/1989. :)
>>
>>
>> (And then the _Thread_Idle_body is never preempted due to the
>> interrupt dispatching a new thread - not sure if it just thinks it's
>> "too late" to even bother or if simply never even tries. I'll keep
>> investigating.)
>
>
> This means your "outer" assembly language _ISR_Handler does not
> yet deal with "needs dispatch". On the 5 second tick, a task is unblocked
> and set up to preempt. The end of the ISR path has to be right to
> make this work.
>
> --joel
>>
>>
>> On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval 
>> wrote:
>> > Hi everyone!
>> >
>> > Good news! The APIC timer _does_ work now (after implementing 1GiB
>> > pages)! I see Clock_isr_ticks increasing steadily, though I don't have
>> > tc_get_timecount implemented yet - I've yet to figure out the
>> > specifics of the clock driver (how
>> > rtems_configuration_get_microseconds_per_tick influences the
>> > counter_ticks, specifically).
>> >
>> > I suspect we'll barely just make ticker.exe work by EOD tomorrow,
>> > leaving just the weekend for me to clean the patches up and Monday to
>> > actually merge them.
>> >
>> > Would someone be willing to have a meeting on 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Joel Sherrill]

On Thu, Aug 9, 2018 at 7:43 AM, Amaan Cheval  wrote:

> Addition to status: it doesn't seem like the RTEMS Interrupt's call to
> _Thread_Dispatch functions either - ticker.exe has outputs like the
> following (yeah, the counter is running too quickly right now):
>
> *** BEGIN OF TEST CLOCK TICK ***
> *** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
> *** TEST STATE: EXPECTED-PASS
> *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
> *** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
> 25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
> TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
> TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
> TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990
>

Congratulations! But why is the date 5/12/1990? I think it is supposed
to be 12/31/1989. :)

>
> (And then the _Thread_Idle_body is never preempted due to the
> interrupt dispatching a new thread - not sure if it just thinks it's
> "too late" to even bother or if simply never even tries. I'll keep
> investigating.)
>

This means your "outer" assembly language _ISR_Handler does not
yet deal with "needs dispatch". On the 5 second tick, a task is unblocked
and set up to preempt. The end of the ISR path has to be right to
make this work.

--joel

>
> On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval 
> wrote:
> > Hi everyone!
> >
> > Good news! The APIC timer _does_ work now (after implementing 1GiB
> > pages)! I see Clock_isr_ticks increasing steadily, though I don't have
> > tc_get_timecount implemented yet - I've yet to figure out the
> > specifics of the clock driver (how
> > rtems_configuration_get_microseconds_per_tick influences the
> > counter_ticks, specifically).
> >
> > I suspect we'll barely just make ticker.exe work by EOD tomorrow,
> > leaving just the weekend for me to clean the patches up and Monday to
> > actually merge them.
> >
> > Would someone be willing to have a meeting on Hangouts (or whatever)
> > with me to speed up the process of (1) upstreaming my patches and (2)
> > checking that my "work package" looks good enough at any convenient
> > time on Monday?
> >
> > (I'm a bit busy on Monday, so I'd really prefer to have this whole
> > thing done by EOD Monday for me.)
> >
> > On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom  wrote:
> >> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval 
> wrote:
> >>> Status update: The code is at a point where the APIC timer _should_
> >>> work, but doesn't (it never starts ticking away, so when calibrating
> >>> with the PIT, and later starting the APIC timer to generate IRQs,
> >>> pretty much nothing happens).
> >>>
> >>> I suspect the cause being the APIC base relocation not working (the
> >>> APIC is located at 0xfee0 in physical memory by default, and in
> >>> the code we write to an MSR to relocate it, because the page-mapping
> >>> scheme FreeBSD setup doesn't let us access such high physical memory -
> >>> only the first 1GiB of physical memory).
> >>>
> >>> On QEMU, the MSR accepts our write for the relocation and happily
> >>> spits it back out when read, but given the unresponsiveness of the
> >>> APIC timer despite enabling all the right bits, I suspect it's just a
> >>> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
> >>> changes to the APIC configuration either, supporting this theory).
> >>> QEMU _does_ reflect changes to the APIC by other operating systems
> >>> which don't relocate it, so I don't suspect its emulation being a
> >>> problem.
> >>>
> >>> On VirtualBox, the MSR simply silently swallows the write, and upon a
> >>> read, returns the original 0xfee0 value again. This means that if
> >>> we can't relocate it, we can't access it at the moment either.
> >>>
> >>> The only real way to work around this is to have a paging scheme that
> >>> lets us access physical address 0xfee0 - in that case, we could
> >>> support page-faults and dynamically map pages in, _or_ have static
> >>> pages that are absurdly large (such as 1GiB), letting the virtual
> >>> address do the heavy-lifting in terms of finding the
> >>> virtual-to-physical mapping.
> >>>
> >>
> >> I recommend a few static super pages to get it working. It is simple
> >> and fits the prevailing RTEMS model.
> >>
> >>> Either way, I think this issue this close to the deadline basically
> >>> means the APIC timer won't be functional and make it upstream.
> >>>
> >>> I'll clean things up and send patches tomorrow for everything so far,
> >>> including all the stub-code which will become usable once our paging
> >>> scheme works fine.
> >>>
> >>> If anyone has any last-minute swooping ideas on how to save the APIC
> >>> timer, let me know! (Interrupts aren't masked, and as far as I can
> >>> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
> >>> don't have any ideas as to what else the problem could be.)
> >>>
> >>> In my final report, I'll make sure I document what's remaining in
> >>> clearer terms than I have in this 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

Addition to status: it doesn't seem like the RTEMS Interrupt's call to
_Thread_Dispatch functions either - ticker.exe has outputs like the
following (yeah, the counter is running too quickly right now):

*** BEGIN OF TEST CLOCK TICK ***
*** TEST VERSION: 5.0.0.2f10634899719c2857e2c8dd5088fb93a425fc83-modified
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
*** TEST TOOLS: 7.3.0 20180125 (RTEMS 5, RSB
25f4db09c85a52fb1640a29f9bdc2de8c2768988, Newlib 3.0.0)
TA1  - rtems_clock_get_tod - 11:34:12   05/12/1990
TA2  - rtems_clock_get_tod - 11:34:12   05/12/1990
TA3  - rtems_clock_get_tod - 11:34:12   05/12/1990

(And then the _Thread_Idle_body is never preempted due to the
interrupt dispatching a new thread - not sure if it just thinks it's
"too late" to even bother or if simply never even tries. I'll keep
investigating.)

On Thu, Aug 9, 2018 at 6:03 PM, Amaan Cheval  wrote:
> Hi everyone!
>
> Good news! The APIC timer _does_ work now (after implementing 1GiB
> pages)! I see Clock_isr_ticks increasing steadily, though I don't have
> tc_get_timecount implemented yet - I've yet to figure out the
> specifics of the clock driver (how
> rtems_configuration_get_microseconds_per_tick influences the
> counter_ticks, specifically).
>
> I suspect we'll barely just make ticker.exe work by EOD tomorrow,
> leaving just the weekend for me to clean the patches up and Monday to
> actually merge them.
>
> Would someone be willing to have a meeting on Hangouts (or whatever)
> with me to speed up the process of (1) upstreaming my patches and (2)
> checking that my "work package" looks good enough at any convenient
> time on Monday?
>
> (I'm a bit busy on Monday, so I'd really prefer to have this whole
> thing done by EOD Monday for me.)
>
> On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom  wrote:
>> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval  wrote:
>>> Status update: The code is at a point where the APIC timer _should_
>>> work, but doesn't (it never starts ticking away, so when calibrating
>>> with the PIT, and later starting the APIC timer to generate IRQs,
>>> pretty much nothing happens).
>>>
>>> I suspect the cause being the APIC base relocation not working (the
>>> APIC is located at 0xfee0 in physical memory by default, and in
>>> the code we write to an MSR to relocate it, because the page-mapping
>>> scheme FreeBSD setup doesn't let us access such high physical memory -
>>> only the first 1GiB of physical memory).
>>>
>>> On QEMU, the MSR accepts our write for the relocation and happily
>>> spits it back out when read, but given the unresponsiveness of the
>>> APIC timer despite enabling all the right bits, I suspect it's just a
>>> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
>>> changes to the APIC configuration either, supporting this theory).
>>> QEMU _does_ reflect changes to the APIC by other operating systems
>>> which don't relocate it, so I don't suspect its emulation being a
>>> problem.
>>>
>>> On VirtualBox, the MSR simply silently swallows the write, and upon a
>>> read, returns the original 0xfee0 value again. This means that if
>>> we can't relocate it, we can't access it at the moment either.
>>>
>>> The only real way to work around this is to have a paging scheme that
>>> lets us access physical address 0xfee0 - in that case, we could
>>> support page-faults and dynamically map pages in, _or_ have static
>>> pages that are absurdly large (such as 1GiB), letting the virtual
>>> address do the heavy-lifting in terms of finding the
>>> virtual-to-physical mapping.
>>>
>>
>> I recommend a few static super pages to get it working. It is simple
>> and fits the prevailing RTEMS model.
>>
>>> Either way, I think this issue this close to the deadline basically
>>> means the APIC timer won't be functional and make it upstream.
>>>
>>> I'll clean things up and send patches tomorrow for everything so far,
>>> including all the stub-code which will become usable once our paging
>>> scheme works fine.
>>>
>>> If anyone has any last-minute swooping ideas on how to save the APIC
>>> timer, let me know! (Interrupts aren't masked, and as far as I can
>>> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
>>> don't have any ideas as to what else the problem could be.)
>>>
>>> In my final report, I'll make sure I document what's remaining in
>>> clearer terms than I have in this email, so it's easier for other
>>> contributors to pick it up too, if any are interested.
>>>
>>> 
>>>
>>> On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns  wrote:
 On 07/08/2018 09:27, Joel Sherrill wrote:
> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval  > wrote:
>
> Thanks for all the help! I have a simple test using the RTEMS
> interrupt manager working successfully (tested by calling
> rtems_interrupt_handler_install for vector 0, and then triggering a
> divide-by-0 exception).
>
> 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

Hi everyone!

Good news! The APIC timer _does_ work now (after implementing 1GiB
pages)! I see Clock_isr_ticks increasing steadily, though I don't have
tc_get_timecount implemented yet - I've yet to figure out the
specifics of the clock driver (how
rtems_configuration_get_microseconds_per_tick influences the
counter_ticks, specifically).

I suspect we'll barely just make ticker.exe work by EOD tomorrow,
leaving just the weekend for me to clean the patches up and Monday to
actually merge them.

Would someone be willing to have a meeting on Hangouts (or whatever)
with me to speed up the process of (1) upstreaming my patches and (2)
checking that my "work package" looks good enough at any convenient
time on Monday?

(I'm a bit busy on Monday, so I'd really prefer to have this whole
thing done by EOD Monday for me.)

On Thu, Aug 9, 2018 at 7:03 AM, Gedare Bloom  wrote:
> On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval  wrote:
>> Status update: The code is at a point where the APIC timer _should_
>> work, but doesn't (it never starts ticking away, so when calibrating
>> with the PIT, and later starting the APIC timer to generate IRQs,
>> pretty much nothing happens).
>>
>> I suspect the cause being the APIC base relocation not working (the
>> APIC is located at 0xfee0 in physical memory by default, and in
>> the code we write to an MSR to relocate it, because the page-mapping
>> scheme FreeBSD setup doesn't let us access such high physical memory -
>> only the first 1GiB of physical memory).
>>
>> On QEMU, the MSR accepts our write for the relocation and happily
>> spits it back out when read, but given the unresponsiveness of the
>> APIC timer despite enabling all the right bits, I suspect it's just a
>> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
>> changes to the APIC configuration either, supporting this theory).
>> QEMU _does_ reflect changes to the APIC by other operating systems
>> which don't relocate it, so I don't suspect its emulation being a
>> problem.
>>
>> On VirtualBox, the MSR simply silently swallows the write, and upon a
>> read, returns the original 0xfee0 value again. This means that if
>> we can't relocate it, we can't access it at the moment either.
>>
>> The only real way to work around this is to have a paging scheme that
>> lets us access physical address 0xfee0 - in that case, we could
>> support page-faults and dynamically map pages in, _or_ have static
>> pages that are absurdly large (such as 1GiB), letting the virtual
>> address do the heavy-lifting in terms of finding the
>> virtual-to-physical mapping.
>>
>
> I recommend a few static super pages to get it working. It is simple
> and fits the prevailing RTEMS model.
>
>> Either way, I think this issue this close to the deadline basically
>> means the APIC timer won't be functional and make it upstream.
>>
>> I'll clean things up and send patches tomorrow for everything so far,
>> including all the stub-code which will become usable once our paging
>> scheme works fine.
>>
>> If anyone has any last-minute swooping ideas on how to save the APIC
>> timer, let me know! (Interrupts aren't masked, and as far as I can
>> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
>> don't have any ideas as to what else the problem could be.)
>>
>> In my final report, I'll make sure I document what's remaining in
>> clearer terms than I have in this email, so it's easier for other
>> contributors to pick it up too, if any are interested.
>>
>> 
>>
>> On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns  wrote:
>>> On 07/08/2018 09:27, Joel Sherrill wrote:
 On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval >>> > wrote:

 Thanks for all the help! I have a simple test using the RTEMS
 interrupt manager working successfully (tested by calling
 rtems_interrupt_handler_install for vector 0, and then triggering a
 divide-by-0 exception).

 Yeah!

 Could someone shed any light on why the i386 only hooks the first 17
 vectors as "RTEMS interrupts"?

 You are making me feel very old especially since I have the real
 IBM manual in my office which corresponds to the answer.
>>>
>>> Grandchildren, grey hair or Sebastian posting he is feeling old do not make 
>>> you
>>> feel old? Interesting! ;) :)
>>>
> I feel old, too.
>
 It is dated Sept 1985. In fairness, I saved it from the garbage heap
 years later when someone was cleaning out their office. :)
>>>
>>> Ah the good old days before the internet and search engines!!
>>>
 The x86 architecture is really vectored and the original i386
 port actually used simple direct vectoring since the first BSP wasn't
 a PC. Imagine that!  Another board using an i386 which didn't
 look like a PC at all.

 For better or worse, the PC/AT (286) and later used two i8259 PICs
 in a master and slave configuration. The slave PIC cascaded off the

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Gedare Bloom]

On Wed, Aug 8, 2018 at 12:21 PM, Amaan Cheval  wrote:
> Status update: The code is at a point where the APIC timer _should_
> work, but doesn't (it never starts ticking away, so when calibrating
> with the PIT, and later starting the APIC timer to generate IRQs,
> pretty much nothing happens).
>
> I suspect the cause being the APIC base relocation not working (the
> APIC is located at 0xfee0 in physical memory by default, and in
> the code we write to an MSR to relocate it, because the page-mapping
> scheme FreeBSD setup doesn't let us access such high physical memory -
> only the first 1GiB of physical memory).
>
> On QEMU, the MSR accepts our write for the relocation and happily
> spits it back out when read, but given the unresponsiveness of the
> APIC timer despite enabling all the right bits, I suspect it's just a
> "fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
> changes to the APIC configuration either, supporting this theory).
> QEMU _does_ reflect changes to the APIC by other operating systems
> which don't relocate it, so I don't suspect its emulation being a
> problem.
>
> On VirtualBox, the MSR simply silently swallows the write, and upon a
> read, returns the original 0xfee0 value again. This means that if
> we can't relocate it, we can't access it at the moment either.
>
> The only real way to work around this is to have a paging scheme that
> lets us access physical address 0xfee0 - in that case, we could
> support page-faults and dynamically map pages in, _or_ have static
> pages that are absurdly large (such as 1GiB), letting the virtual
> address do the heavy-lifting in terms of finding the
> virtual-to-physical mapping.
>

I recommend a few static super pages to get it working. It is simple
and fits the prevailing RTEMS model.

> Either way, I think this issue this close to the deadline basically
> means the APIC timer won't be functional and make it upstream.
>
> I'll clean things up and send patches tomorrow for everything so far,
> including all the stub-code which will become usable once our paging
> scheme works fine.
>
> If anyone has any last-minute swooping ideas on how to save the APIC
> timer, let me know! (Interrupts aren't masked, and as far as I can
> tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
> don't have any ideas as to what else the problem could be.)
>
> In my final report, I'll make sure I document what's remaining in
> clearer terms than I have in this email, so it's easier for other
> contributors to pick it up too, if any are interested.
>
> 
>
> On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns  wrote:
>> On 07/08/2018 09:27, Joel Sherrill wrote:
>>> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval >> > wrote:
>>>
>>> Thanks for all the help! I have a simple test using the RTEMS
>>> interrupt manager working successfully (tested by calling
>>> rtems_interrupt_handler_install for vector 0, and then triggering a
>>> divide-by-0 exception).
>>>
>>> Yeah!
>>>
>>> Could someone shed any light on why the i386 only hooks the first 17
>>> vectors as "RTEMS interrupts"?
>>>
>>> You are making me feel very old especially since I have the real
>>> IBM manual in my office which corresponds to the answer.
>>
>> Grandchildren, grey hair or Sebastian posting he is feeling old do not make 
>> you
>> feel old? Interesting! ;) :)
>>
I feel old, too.

>>> It is dated Sept 1985. In fairness, I saved it from the garbage heap
>>> years later when someone was cleaning out their office. :)
>>
>> Ah the good old days before the internet and search engines!!
>>
>>> The x86 architecture is really vectored and the original i386
>>> port actually used simple direct vectoring since the first BSP wasn't
>>> a PC. Imagine that!  Another board using an i386 which didn't
>>> look like a PC at all.
>>>
>>> For better or worse, the PC/AT (286) and later used two i8259 PICs
>>> in a master and slave configuration. The slave PIC cascaded off the
>>> master PIC. This all fed into one CPU IRQ so many of the direct
>>> vectors were unused. The PIC arrangement is described here:
>>>
>>> https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)
>>>
>>> Here's what I'm aiming to get done before the GSoC deadline:
>>>
>>> - Remap PIC (masking/disabling the PIC doesn't stop it from generating
>>> spurious interrupts (IRQ7), which would look like exceptions to us)
>>> - Disable PIC
>>> - Enable APIC (done already, but confirm it plays well with the recent
>>> changes to the IDT)
>>> - Enable the PIT timer and use it to calibrate the APIC timer
>>> - Clock driver using the APIC timer - (1) generate interrupts on ticks
>>> and (2) tc_get_timecount function which calculates total time passed
>>> through calculating (number of IRQs occured * time_per_irq +
>>> time_passed_since_last_irq (through tick counter))
>>>
>>> This does seem a bit ambitious given 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

Status update: The code is at a point where the APIC timer _should_
work, but doesn't (it never starts ticking away, so when calibrating
with the PIT, and later starting the APIC timer to generate IRQs,
pretty much nothing happens).

I suspect the cause being the APIC base relocation not working (the
APIC is located at 0xfee0 in physical memory by default, and in
the code we write to an MSR to relocate it, because the page-mapping
scheme FreeBSD setup doesn't let us access such high physical memory -
only the first 1GiB of physical memory).

On QEMU, the MSR accepts our write for the relocation and happily
spits it back out when read, but given the unresponsiveness of the
APIC timer despite enabling all the right bits, I suspect it's just a
"fake" in that regard (QEMU's "info lapic" doesn't reflect any of our
changes to the APIC configuration either, supporting this theory).
QEMU _does_ reflect changes to the APIC by other operating systems
which don't relocate it, so I don't suspect its emulation being a
problem.

On VirtualBox, the MSR simply silently swallows the write, and upon a
read, returns the original 0xfee0 value again. This means that if
we can't relocate it, we can't access it at the moment either.

The only real way to work around this is to have a paging scheme that
lets us access physical address 0xfee0 - in that case, we could
support page-faults and dynamically map pages in, _or_ have static
pages that are absurdly large (such as 1GiB), letting the virtual
address do the heavy-lifting in terms of finding the
virtual-to-physical mapping.

Either way, I think this issue this close to the deadline basically
means the APIC timer won't be functional and make it upstream.

I'll clean things up and send patches tomorrow for everything so far,
including all the stub-code which will become usable once our paging
scheme works fine.

If anyone has any last-minute swooping ideas on how to save the APIC
timer, let me know! (Interrupts aren't masked, and as far as I can
tell, changing the "-cpu" flag on QEMU doesn't make a difference. I
don't have any ideas as to what else the problem could be.)

In my final report, I'll make sure I document what's remaining in
clearer terms than I have in this email, so it's easier for other
contributors to pick it up too, if any are interested.



On Tue, Aug 7, 2018 at 6:03 AM, Chris Johns  wrote:
> On 07/08/2018 09:27, Joel Sherrill wrote:
>> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval > > wrote:
>>
>> Thanks for all the help! I have a simple test using the RTEMS
>> interrupt manager working successfully (tested by calling
>> rtems_interrupt_handler_install for vector 0, and then triggering a
>> divide-by-0 exception).
>>
>> Yeah!
>>
>> Could someone shed any light on why the i386 only hooks the first 17
>> vectors as "RTEMS interrupts"?
>>
>> You are making me feel very old especially since I have the real
>> IBM manual in my office which corresponds to the answer.
>
> Grandchildren, grey hair or Sebastian posting he is feeling old do not make 
> you
> feel old? Interesting! ;) :)
>
>> It is dated Sept 1985. In fairness, I saved it from the garbage heap
>> years later when someone was cleaning out their office. :)
>
> Ah the good old days before the internet and search engines!!
>
>> The x86 architecture is really vectored and the original i386
>> port actually used simple direct vectoring since the first BSP wasn't
>> a PC. Imagine that!  Another board using an i386 which didn't
>> look like a PC at all.
>>
>> For better or worse, the PC/AT (286) and later used two i8259 PICs
>> in a master and slave configuration. The slave PIC cascaded off the
>> master PIC. This all fed into one CPU IRQ so many of the direct
>> vectors were unused. The PIC arrangement is described here:
>>
>> https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)
>>
>> Here's what I'm aiming to get done before the GSoC deadline:
>>
>> - Remap PIC (masking/disabling the PIC doesn't stop it from generating
>> spurious interrupts (IRQ7), which would look like exceptions to us)
>> - Disable PIC
>> - Enable APIC (done already, but confirm it plays well with the recent
>> changes to the IDT)
>> - Enable the PIT timer and use it to calibrate the APIC timer
>> - Clock driver using the APIC timer - (1) generate interrupts on ticks
>> and (2) tc_get_timecount function which calculates total time passed
>> through calculating (number of IRQs occured * time_per_irq +
>> time_passed_since_last_irq (through tick counter))
>>
>> This does seem a bit ambitious given how short we are on time - I'll
>> finish this up even after the deadline if need be.
>>
>> What should our minimum deliverable be for this period? Should we try
>> to upstream the interrupt support before I finish the clock driver? (I
>> think we can have this discussion on Wednesday or so, since by then

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Chris Johns]

On 07/08/2018 09:27, Joel Sherrill wrote:
> On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval  > wrote:
> 
> Thanks for all the help! I have a simple test using the RTEMS
> interrupt manager working successfully (tested by calling
> rtems_interrupt_handler_install for vector 0, and then triggering a
> divide-by-0 exception).
> 
> Yeah! 
> 
> Could someone shed any light on why the i386 only hooks the first 17
> vectors as "RTEMS interrupts"?
> 
> You are making me feel very old especially since I have the real
> IBM manual in my office which corresponds to the answer.

Grandchildren, grey hair or Sebastian posting he is feeling old do not make you
feel old? Interesting! ;) :)

> It is dated Sept 1985. In fairness, I saved it from the garbage heap
> years later when someone was cleaning out their office. :)

Ah the good old days before the internet and search engines!!

> The x86 architecture is really vectored and the original i386
> port actually used simple direct vectoring since the first BSP wasn't
> a PC. Imagine that!  Another board using an i386 which didn't
> look like a PC at all. 
> 
> For better or worse, the PC/AT (286) and later used two i8259 PICs 
> in a master and slave configuration. The slave PIC cascaded off the 
> master PIC. This all fed into one CPU IRQ so many of the direct
> vectors were unused. The PIC arrangement is described here:
> 
> https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)
> 
> Here's what I'm aiming to get done before the GSoC deadline:
> 
> - Remap PIC (masking/disabling the PIC doesn't stop it from generating
> spurious interrupts (IRQ7), which would look like exceptions to us)
> - Disable PIC
> - Enable APIC (done already, but confirm it plays well with the recent
> changes to the IDT)
> - Enable the PIT timer and use it to calibrate the APIC timer
> - Clock driver using the APIC timer - (1) generate interrupts on ticks
> and (2) tc_get_timecount function which calculates total time passed
> through calculating (number of IRQs occured * time_per_irq +
> time_passed_since_last_irq (through tick counter))
> 
> This does seem a bit ambitious given how short we are on time - I'll
> finish this up even after the deadline if need be.
> 
> What should our minimum deliverable be for this period? Should we try
> to upstream the interrupt support before I finish the clock driver? (I
> think we can have this discussion on Wednesday or so, since by then
> I'll likely know how much progress on the clock driver remains.)
> 
> We could but do you think it is likely to have major changes based 
> on getting the tick working?
> 
> Try to see what gets done and post what you can by the end of GSoC.
> 
> Then we will all wait patiently for you to get it working if it isn't then.

I think this BSP code in our repo is the best place for it to be worked on.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Joel Sherrill]

On Mon, Aug 6, 2018 at 8:13 AM, Amaan Cheval  wrote:

> Thanks for all the help! I have a simple test using the RTEMS
> interrupt manager working successfully (tested by calling
> rtems_interrupt_handler_install for vector 0, and then triggering a
> divide-by-0 exception).
>

Yeah!

>
> Could someone shed any light on why the i386 only hooks the first 17
> vectors as "RTEMS interrupts"?
>

You are making me feel very old especially since I have the real
IBM manual in my office which corresponds to the answer.
It is dated Sept 1985. In fairness, I saved it from the garbage heap
years later when someone was cleaning out their office. :)

The x86 architecture is really vectored and the original i386
port actually used simple direct vectoring since the first BSP wasn't
a PC. Imagine that!  Another board using an i386 which didn't
look like a PC at all.

For better or worse, the PC/AT (286) and later used two i8259 PICs
in a master and slave configuration. The slave PIC cascaded off the
master PIC. This all fed into one CPU IRQ so many of the direct
vectors were unused. The PIC arrangement is described here:

https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)


>
> Here's what I'm aiming to get done before the GSoC deadline:
>
> - Remap PIC (masking/disabling the PIC doesn't stop it from generating
> spurious interrupts (IRQ7), which would look like exceptions to us)
> - Disable PIC
> - Enable APIC (done already, but confirm it plays well with the recent
> changes to the IDT)
> - Enable the PIT timer and use it to calibrate the APIC timer
> - Clock driver using the APIC timer - (1) generate interrupts on ticks
> and (2) tc_get_timecount function which calculates total time passed
> through calculating (number of IRQs occured * time_per_irq +
> time_passed_since_last_irq (through tick counter))
>
> This does seem a bit ambitious given how short we are on time - I'll
> finish this up even after the deadline if need be.
>
> What should our minimum deliverable be for this period? Should we try
> to upstream the interrupt support before I finish the clock driver? (I
> think we can have this discussion on Wednesday or so, since by then
> I'll likely know how much progress on the clock driver remains.)
>

We could but do you think it is likely to have major changes based
on getting the tick working?

Try to see what gets done and post what you can by the end of GSoC.

Then we will all wait patiently for you to get it working if it isn't then.

You do need to do a final report.


>
> Sorry about the rush near the deadline - getting the APIC functioning
> had a bunch more yak-shaving style issues than I anticipated.
>

The x86 architecture is years of hack upon hack.


>
> On Wed, Aug 1, 2018 at 10:51 PM, Joel Sherrill  wrote:
> > I have started to reply twice but you jumped in ahead. :)
> >
> > On Wed, Aug 1, 2018 at 12:12 PM, Amaan Cheval 
> > wrote:
> >>
> >> If my previous email _is_ in fact correct, could someone confirm?
> >> Because this excerpt in the documentation here seems to contradict it
> >> (which was what lead to the confusion in the first place):
> >>
> >>
> >> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#
> establishing-an-isr
> >>
> >> With my emphasis:
> >>
> >> > The rtems_interrupt_catch directive establishes an ISR for the system.
> >> > The address of the ISR and its associated CPU vector number are
> specified to
> >> > this directive. This directive installs the **RTEMS interrupt wrapper
> in the
> >> > processor’s Interrupt Vector Table and the address of the user’s ISR
> in the
> >> > RTEMS’ Vector Table**. This directive returns the previous contents
> of the
> >> > specified vector in the RTEMS’ Vector Table.
> >
> >
> > Almost but Gedare and I left out a detail. rtems_interrupt_catch is ONLY
> > used on pure simple vectored architectures which do not use the
> > bsp_interrupt_*
> > or  interfaces. Some embedded MCUs are so simple and have
> > plenty of vectors so you don't need the complexity of supporting a PIC.
> For
> > example, the m68k family had 256 direct vectors and I don't recall ever
> > seeing
> > a PIC.[1]
> >
> > You should assume that you can ignore rtems_interrupt_catch and simple
> > vectored support for x86_64. See cpukit/rtems/intrcatch.c and I hope you
> > see an ifdef that results in the code disappearing on your port. Simple
> > vectored is FACE is your cpu.h. :)
> >
> > [1] Disclaimer: The support for the  interfaces is critical
> to
> > the
> > libbsd stack. We haven't discussed it but any architecture that is
> > sufficient
> > to run the new stack will have to support this interface. If someone
> wants
> > the
> > new stack on a 68040 VME board or a Coldfire board, we will have to find
> > the simplest, non-bloated way to support this. When doing the MIPS Malta,
> > we just converted the MIPS architecture away from simple vectored.
> >
> > So support the bsp_interrupt_* infrastructure. :)
> >
> > --joel
> >
> >>
> >>
> >> On 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

Thanks for all the help! I have a simple test using the RTEMS
interrupt manager working successfully (tested by calling
rtems_interrupt_handler_install for vector 0, and then triggering a
divide-by-0 exception).

Could someone shed any light on why the i386 only hooks the first 17
vectors as "RTEMS interrupts"?

Here's what I'm aiming to get done before the GSoC deadline:

- Remap PIC (masking/disabling the PIC doesn't stop it from generating
spurious interrupts (IRQ7), which would look like exceptions to us)
- Disable PIC
- Enable APIC (done already, but confirm it plays well with the recent
changes to the IDT)
- Enable the PIT timer and use it to calibrate the APIC timer
- Clock driver using the APIC timer - (1) generate interrupts on ticks
and (2) tc_get_timecount function which calculates total time passed
through calculating (number of IRQs occured * time_per_irq +
time_passed_since_last_irq (through tick counter))

This does seem a bit ambitious given how short we are on time - I'll
finish this up even after the deadline if need be.

What should our minimum deliverable be for this period? Should we try
to upstream the interrupt support before I finish the clock driver? (I
think we can have this discussion on Wednesday or so, since by then
I'll likely know how much progress on the clock driver remains.)

Sorry about the rush near the deadline - getting the APIC functioning
had a bunch more yak-shaving style issues than I anticipated.

On Wed, Aug 1, 2018 at 10:51 PM, Joel Sherrill  wrote:
> I have started to reply twice but you jumped in ahead. :)
>
> On Wed, Aug 1, 2018 at 12:12 PM, Amaan Cheval 
> wrote:
>>
>> If my previous email _is_ in fact correct, could someone confirm?
>> Because this excerpt in the documentation here seems to contradict it
>> (which was what lead to the confusion in the first place):
>>
>>
>> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#establishing-an-isr
>>
>> With my emphasis:
>>
>> > The rtems_interrupt_catch directive establishes an ISR for the system.
>> > The address of the ISR and its associated CPU vector number are specified 
>> > to
>> > this directive. This directive installs the **RTEMS interrupt wrapper in 
>> > the
>> > processor’s Interrupt Vector Table and the address of the user’s ISR in the
>> > RTEMS’ Vector Table**. This directive returns the previous contents of the
>> > specified vector in the RTEMS’ Vector Table.
>
>
> Almost but Gedare and I left out a detail. rtems_interrupt_catch is ONLY
> used on pure simple vectored architectures which do not use the
> bsp_interrupt_*
> or  interfaces. Some embedded MCUs are so simple and have
> plenty of vectors so you don't need the complexity of supporting a PIC. For
> example, the m68k family had 256 direct vectors and I don't recall ever
> seeing
> a PIC.[1]
>
> You should assume that you can ignore rtems_interrupt_catch and simple
> vectored support for x86_64. See cpukit/rtems/intrcatch.c and I hope you
> see an ifdef that results in the code disappearing on your port. Simple
> vectored is FACE is your cpu.h. :)
>
> [1] Disclaimer: The support for the  interfaces is critical to
> the
> libbsd stack. We haven't discussed it but any architecture that is
> sufficient
> to run the new stack will have to support this interface. If someone wants
> the
> new stack on a 68040 VME board or a Coldfire board, we will have to find
> the simplest, non-bloated way to support this. When doing the MIPS Malta,
> we just converted the MIPS architecture away from simple vectored.
>
> So support the bsp_interrupt_* infrastructure. :)
>
> --joel
>
>>
>>
>> On Wed, Aug 1, 2018 at 10:39 PM, Amaan Cheval 
>> wrote:
>> > Okay, I think I understand finally. Sorry about the rambling!
>> >
>> > When rtems_interrupt_catch is called, that's installing a "raw" ISR by
>> > modifying the processor specific table itself, so _ISR_Handler is
>> > never called, but the user ISR is.
>> >
>> > When rtems_interrupt_handler_install is called, that's an "RTEMS
>> > interrupt", and we go through the _ISR_Handler -> dispatch route I
>> > laid out earlier, leading to eventually the user's ISR.
>> >
>> > Thank you for letting me rubber-duck with you, everyone (let me know
>> > if anything above sounds off, though!) :P
>> >
>> > On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval 
>> > wrote:
>> >> Thanks for the background!
>> >>
>> >> Let's use the gen5200 as the ongoing example - my confusion arises
>> >> here (correct me if any of the following points is incorrect!). In
>> >> overly simplified call chains:
>> >>
>> >> Register interrupt handler:
>> >> -  bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec,
>> >> C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] =
>> >> C_dispatch_irq_handler
>> >>
>> >> Interrupt handler called:
>> >> - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch
>> >> (irq-generic.h) -> bsp_interrupt_handler_table[index].handler()
>> >>
>> >> What I'm confused about is how 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Joel Sherrill]

I have started to reply twice but you jumped in ahead. :)

On Wed, Aug 1, 2018 at 12:12 PM, Amaan Cheval 
wrote:

> If my previous email _is_ in fact correct, could someone confirm?
> Because this excerpt in the documentation here seems to contradict it
> (which was what lead to the confusion in the first place):
>
> https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#
> establishing-an-isr
>
> With my emphasis:
>
> > The rtems_interrupt_catch directive establishes an ISR for the system.
> The address of the ISR and its associated CPU vector number are specified
> to this directive. This directive installs the **RTEMS interrupt wrapper in
> the processor’s Interrupt Vector Table and the address of the user’s ISR in
> the RTEMS’ Vector Table**. This directive returns the previous contents of
> the specified vector in the RTEMS’ Vector Table.
>

Almost but Gedare and I left out a detail. rtems_interrupt_catch is ONLY
used on pure simple vectored architectures which do not use the
bsp_interrupt_*
or  interfaces. Some embedded MCUs are so simple and have
plenty of vectors so you don't need the complexity of supporting a PIC. For
example, the m68k family had 256 direct vectors and I don't recall ever
seeing
a PIC.[1]

You should assume that you can ignore rtems_interrupt_catch and simple
vectored support for x86_64. See cpukit/rtems/intrcatch.c and I hope you
see an ifdef that results in the code disappearing on your port. Simple
vectored is FACE is your cpu.h. :)

[1] Disclaimer: The support for the  interfaces is critical to
the
libbsd stack. We haven't discussed it but any architecture that is
sufficient
to run the new stack will have to support this interface. If someone wants
the
new stack on a 68040 VME board or a Coldfire board, we will have to find
the simplest, non-bloated way to support this. When doing the MIPS Malta,
we just converted the MIPS architecture away from simple vectored.

So support the bsp_interrupt_* infrastructure. :)

--joel


>
> On Wed, Aug 1, 2018 at 10:39 PM, Amaan Cheval 
> wrote:
> > Okay, I think I understand finally. Sorry about the rambling!
> >
> > When rtems_interrupt_catch is called, that's installing a "raw" ISR by
> > modifying the processor specific table itself, so _ISR_Handler is
> > never called, but the user ISR is.
> >
> > When rtems_interrupt_handler_install is called, that's an "RTEMS
> > interrupt", and we go through the _ISR_Handler -> dispatch route I
> > laid out earlier, leading to eventually the user's ISR.
> >
> > Thank you for letting me rubber-duck with you, everyone (let me know
> > if anything above sounds off, though!) :P
> >
> > On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval 
> wrote:
> >> Thanks for the background!
> >>
> >> Let's use the gen5200 as the ongoing example - my confusion arises
> >> here (correct me if any of the following points is incorrect!). In
> >> overly simplified call chains:
> >>
> >> Register interrupt handler:
> >> -  bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec,
> >> C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] =
> >> C_dispatch_irq_handler
> >>
> >> Interrupt handler called:
> >> - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch
> >> (irq-generic.h) -> bsp_interrupt_handler_table[index].handler()
> >>
> >> What I'm confused about is how the bsp_interrupt_handler_table is
> >> updated at all - I just haven't found the link between how the entries
> >> in the two tables are synchronized, where the tables are:
> >>
> >> 1) the ppc_exc_handler_table (the processor IDT) and
> >> 2) the bsp_interrupt_handler_table (the RTEMS interrupt table)
> >>
> >> 
> >> Another similar chain of confusion for i386 is:
> >> - rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h)
> >> -> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector]
> >> updated
> >>
> >> But the i386 dispatch code chain is:
> >> - _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) ->
> >> bsp_interrupt_handler_dispatch (irq-generic.h) ->
> >> bsp_interrupt_handler_table[index].handler()
> >>
> >> But I don't see any updates to bsp_interrupt_handler_table that would
> >> let this work.
> >> -
> >>
> >> Would you happen to know what that "missing link" is?
> >>
> >> On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill  wrote:
> >>>
> >>>
> >>> On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom 
> wrote:
> 
>  On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval 
>  wrote:
>  > That's definitely very illuminating, thank you so much for all the
>  > details!
>  >
>  > A few more questions that have arisen for me. Feel free to skip over
>  > them (I'll likely figure them out given enough time, so I'm only
>  > asking in case any of them are obvious to anyone):
>  >
>  > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

If my previous email _is_ in fact correct, could someone confirm?
Because this excerpt in the documentation here seems to contradict it
(which was what lead to the confusion in the first place):

https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#establishing-an-isr

With my emphasis:

> The rtems_interrupt_catch directive establishes an ISR for the system. The 
> address of the ISR and its associated CPU vector number are specified to this 
> directive. This directive installs the **RTEMS interrupt wrapper in the 
> processor’s Interrupt Vector Table and the address of the user’s ISR in the 
> RTEMS’ Vector Table**. This directive returns the previous contents of the 
> specified vector in the RTEMS’ Vector Table.

On Wed, Aug 1, 2018 at 10:39 PM, Amaan Cheval  wrote:
> Okay, I think I understand finally. Sorry about the rambling!
>
> When rtems_interrupt_catch is called, that's installing a "raw" ISR by
> modifying the processor specific table itself, so _ISR_Handler is
> never called, but the user ISR is.
>
> When rtems_interrupt_handler_install is called, that's an "RTEMS
> interrupt", and we go through the _ISR_Handler -> dispatch route I
> laid out earlier, leading to eventually the user's ISR.
>
> Thank you for letting me rubber-duck with you, everyone (let me know
> if anything above sounds off, though!) :P
>
> On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval  wrote:
>> Thanks for the background!
>>
>> Let's use the gen5200 as the ongoing example - my confusion arises
>> here (correct me if any of the following points is incorrect!). In
>> overly simplified call chains:
>>
>> Register interrupt handler:
>> -  bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec,
>> C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] =
>> C_dispatch_irq_handler
>>
>> Interrupt handler called:
>> - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch
>> (irq-generic.h) -> bsp_interrupt_handler_table[index].handler()
>>
>> What I'm confused about is how the bsp_interrupt_handler_table is
>> updated at all - I just haven't found the link between how the entries
>> in the two tables are synchronized, where the tables are:
>>
>> 1) the ppc_exc_handler_table (the processor IDT) and
>> 2) the bsp_interrupt_handler_table (the RTEMS interrupt table)
>>
>> 
>> Another similar chain of confusion for i386 is:
>> - rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h)
>> -> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector]
>> updated
>>
>> But the i386 dispatch code chain is:
>> - _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) ->
>> bsp_interrupt_handler_dispatch (irq-generic.h) ->
>> bsp_interrupt_handler_table[index].handler()
>>
>> But I don't see any updates to bsp_interrupt_handler_table that would
>> let this work.
>> -
>>
>> Would you happen to know what that "missing link" is?
>>
>> On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill  wrote:
>>>
>>>
>>> On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom  wrote:

 On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval 
 wrote:
 > That's definitely very illuminating, thank you so much for all the
 > details!
 >
 > A few more questions that have arisen for me. Feel free to skip over
 > them (I'll likely figure them out given enough time, so I'm only
 > asking in case any of them are obvious to anyone):
 >
 > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it
 > stores some of the data onto the stack?
 >
 the interrupt frame structure was introduced during 4.11 development.
 probably i386 never got updated to use a struct to encapsulate the
 interrupt frame. the interrupt frame should contain the registers that
 are preserved by the interrupt entry code I believe.
>>>
>>>
>>> +1
>>>
>>> Historically, there was no structure to represent the set of
>>> registers and information saved on interrupt entry. Over time
>>> this has been added.
>>>
>>> i386  also is missing the SMP synchronization check in the
>>> middle of the context which ensures it is safe for a thread to
>>> be migrated.
>>>

 > - There used to be defines in cpu.h regarding hardware/software based
 > interrupt stacks, and how they'd be setup, which were made
 > superfluous[1] - I'm not quite sure how these are meant to work - I
 > see references to "stack high" and "stack low" and I'm not quite sure
 > what the code is referencing when using those.
 >

 a hardware interrupt stack is one that the hardware switches to during
 an interrupt. i think m68k has such.

 most interrupt stacks in RTEMS are software-managed, meaning that
 RTEMS explicitly switches the stack region off the task stack and to
 an interrupt stack region.

 some stacks start high and grow down, and some stacks start 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

Okay, I think I understand finally. Sorry about the rambling!

When rtems_interrupt_catch is called, that's installing a "raw" ISR by
modifying the processor specific table itself, so _ISR_Handler is
never called, but the user ISR is.

When rtems_interrupt_handler_install is called, that's an "RTEMS
interrupt", and we go through the _ISR_Handler -> dispatch route I
laid out earlier, leading to eventually the user's ISR.

Thank you for letting me rubber-duck with you, everyone (let me know
if anything above sounds off, though!) :P

On Wed, Aug 1, 2018 at 10:20 PM, Amaan Cheval  wrote:
> Thanks for the background!
>
> Let's use the gen5200 as the ongoing example - my confusion arises
> here (correct me if any of the following points is incorrect!). In
> overly simplified call chains:
>
> Register interrupt handler:
> -  bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec,
> C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] =
> C_dispatch_irq_handler
>
> Interrupt handler called:
> - C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch
> (irq-generic.h) -> bsp_interrupt_handler_table[index].handler()
>
> What I'm confused about is how the bsp_interrupt_handler_table is
> updated at all - I just haven't found the link between how the entries
> in the two tables are synchronized, where the tables are:
>
> 1) the ppc_exc_handler_table (the processor IDT) and
> 2) the bsp_interrupt_handler_table (the RTEMS interrupt table)
>
> 
> Another similar chain of confusion for i386 is:
> - rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h)
> -> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector]
> updated
>
> But the i386 dispatch code chain is:
> - _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) ->
> bsp_interrupt_handler_dispatch (irq-generic.h) ->
> bsp_interrupt_handler_table[index].handler()
>
> But I don't see any updates to bsp_interrupt_handler_table that would
> let this work.
> -
>
> Would you happen to know what that "missing link" is?
>
> On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill  wrote:
>>
>>
>> On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom  wrote:
>>>
>>> On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval 
>>> wrote:
>>> > That's definitely very illuminating, thank you so much for all the
>>> > details!
>>> >
>>> > A few more questions that have arisen for me. Feel free to skip over
>>> > them (I'll likely figure them out given enough time, so I'm only
>>> > asking in case any of them are obvious to anyone):
>>> >
>>> > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it
>>> > stores some of the data onto the stack?
>>> >
>>> the interrupt frame structure was introduced during 4.11 development.
>>> probably i386 never got updated to use a struct to encapsulate the
>>> interrupt frame. the interrupt frame should contain the registers that
>>> are preserved by the interrupt entry code I believe.
>>
>>
>> +1
>>
>> Historically, there was no structure to represent the set of
>> registers and information saved on interrupt entry. Over time
>> this has been added.
>>
>> i386  also is missing the SMP synchronization check in the
>> middle of the context which ensures it is safe for a thread to
>> be migrated.
>>
>>>
>>> > - There used to be defines in cpu.h regarding hardware/software based
>>> > interrupt stacks, and how they'd be setup, which were made
>>> > superfluous[1] - I'm not quite sure how these are meant to work - I
>>> > see references to "stack high" and "stack low" and I'm not quite sure
>>> > what the code is referencing when using those.
>>> >
>>>
>>> a hardware interrupt stack is one that the hardware switches to during
>>> an interrupt. i think m68k has such.
>>>
>>> most interrupt stacks in RTEMS are software-managed, meaning that
>>> RTEMS explicitly switches the stack region off the task stack and to
>>> an interrupt stack region.
>>>
>>> some stacks start high and grow down, and some stacks start low and
>>> grow up. maybe this is what the "stack high" and "stack low" you
>>> mention are in relation to?
>>
>>
>> They are used to denote the top and bottom of the memory reserved
>> for the interrupt stack. One important use is in
>> cpukit/libmisc/stackchk/check.c
>> to report on usage.
>>
>>>
>>>
>>> > - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include
>>> > irq-sources.am, by the way (this is part of why I used to think a lot
>>> > of what your email mentioned was unnecessary, until you...ahem,
>>> > pre-empted that line of thought and helped clarify it :P). Should I
>>> > add a ticket to update the no_bsp code to be more in line with current
>>> > use?
>>> >
>>> Sure. I don't know that anyone is in particular maintaining
>>> no_cpu/no_bsp since we can't compile it, it is basically best effort
>>> stuff that sometimes we miss updating.
>>
>>
>> +1
>>
>> Also there are variations 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Amaan Cheval]

Thanks for the background!

Let's use the gen5200 as the ongoing example - my confusion arises
here (correct me if any of the following points is incorrect!). In
overly simplified call chains:

Register interrupt handler:
-  bsp_interrupt_facility_initialize() -> ppc_exc_set_handler(vec,
C_dispatch_irq_handler) -> ppc_exc_handler_table[vec] =
C_dispatch_irq_handler

Interrupt handler called:
- C_dispatch_irq_handler -> dispatch -> bsp_interrupt_handler_dispatch
(irq-generic.h) -> bsp_interrupt_handler_table[index].handler()

What I'm confused about is how the bsp_interrupt_handler_table is
updated at all - I just haven't found the link between how the entries
in the two tables are synchronized, where the tables are:

1) the ppc_exc_handler_table (the processor IDT) and
2) the bsp_interrupt_handler_table (the RTEMS interrupt table)


Another similar chain of confusion for i386 is:
- rtems_interrupt_catch (intrcatch.c) -> _ISR_Install_vector (isr.h)
-> _CPU_ISR_install_vector (i386/idt.c) -> idt_entry_tbl[vector]
updated

But the i386 dispatch code chain is:
- _ISR_Handler (i386/irq_asm.S) -> BSP_dispatch_isr (i386/irq.c) ->
bsp_interrupt_handler_dispatch (irq-generic.h) ->
bsp_interrupt_handler_table[index].handler()

But I don't see any updates to bsp_interrupt_handler_table that would
let this work.
-

Would you happen to know what that "missing link" is?

On Wed, Aug 1, 2018 at 9:07 PM, Joel Sherrill  wrote:
>
>
> On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom  wrote:
>>
>> On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval 
>> wrote:
>> > That's definitely very illuminating, thank you so much for all the
>> > details!
>> >
>> > A few more questions that have arisen for me. Feel free to skip over
>> > them (I'll likely figure them out given enough time, so I'm only
>> > asking in case any of them are obvious to anyone):
>> >
>> > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it
>> > stores some of the data onto the stack?
>> >
>> the interrupt frame structure was introduced during 4.11 development.
>> probably i386 never got updated to use a struct to encapsulate the
>> interrupt frame. the interrupt frame should contain the registers that
>> are preserved by the interrupt entry code I believe.
>
>
> +1
>
> Historically, there was no structure to represent the set of
> registers and information saved on interrupt entry. Over time
> this has been added.
>
> i386  also is missing the SMP synchronization check in the
> middle of the context which ensures it is safe for a thread to
> be migrated.
>
>>
>> > - There used to be defines in cpu.h regarding hardware/software based
>> > interrupt stacks, and how they'd be setup, which were made
>> > superfluous[1] - I'm not quite sure how these are meant to work - I
>> > see references to "stack high" and "stack low" and I'm not quite sure
>> > what the code is referencing when using those.
>> >
>>
>> a hardware interrupt stack is one that the hardware switches to during
>> an interrupt. i think m68k has such.
>>
>> most interrupt stacks in RTEMS are software-managed, meaning that
>> RTEMS explicitly switches the stack region off the task stack and to
>> an interrupt stack region.
>>
>> some stacks start high and grow down, and some stacks start low and
>> grow up. maybe this is what the "stack high" and "stack low" you
>> mention are in relation to?
>
>
> They are used to denote the top and bottom of the memory reserved
> for the interrupt stack. One important use is in
> cpukit/libmisc/stackchk/check.c
> to report on usage.
>
>>
>>
>> > - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include
>> > irq-sources.am, by the way (this is part of why I used to think a lot
>> > of what your email mentioned was unnecessary, until you...ahem,
>> > pre-empted that line of thought and helped clarify it :P). Should I
>> > add a ticket to update the no_bsp code to be more in line with current
>> > use?
>> >
>> Sure. I don't know that anyone is in particular maintaining
>> no_cpu/no_bsp since we can't compile it, it is basically best effort
>> stuff that sometimes we miss updating.
>
>
> +1
>
> Also there are variations based on simple vectored and PIC vectored
> architectures.
>
> The architecture is responsible for the managing the minimal actions
> based on what the CPU does for an interrupt/exception. Logically
> a PIC is part of the BSP even if it comes integrated with the CPU as
> is common on x86 and SoCs. The PIC could fairly easily change
> and the architecture is harder to change.
>
>>
>>
>> > - My understanding of _ISR_Handler is that it'll be the handler for
>> > _all_ interrupt vectors by default - it'll then dispatch interrupts to
>> > user-handlers (or internal handlers, for the timer, for eg.). Is that
>> > right? (I don't quite understand its interaction with the RTEMS
>> > interrupt manager yet, but irq-generic's 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Joel Sherrill]

On Wed, Aug 1, 2018 at 10:11 AM, Gedare Bloom  wrote:

> On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval 
> wrote:
> > That's definitely very illuminating, thank you so much for all the
> details!
> >
> > A few more questions that have arisen for me. Feel free to skip over
> > them (I'll likely figure them out given enough time, so I'm only
> > asking in case any of them are obvious to anyone):
> >
> > - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it
> > stores some of the data onto the stack?
> >
> the interrupt frame structure was introduced during 4.11 development.
> probably i386 never got updated to use a struct to encapsulate the
> interrupt frame. the interrupt frame should contain the registers that
> are preserved by the interrupt entry code I believe.
>

+1

Historically, there was no structure to represent the set of
registers and information saved on interrupt entry. Over time
this has been added.

i386  also is missing the SMP synchronization check in the
middle of the context which ensures it is safe for a thread to
be migrated.


> > - There used to be defines in cpu.h regarding hardware/software based
> > interrupt stacks, and how they'd be setup, which were made
> > superfluous[1] - I'm not quite sure how these are meant to work - I
> > see references to "stack high" and "stack low" and I'm not quite sure
> > what the code is referencing when using those.
> >
>
> a hardware interrupt stack is one that the hardware switches to during
> an interrupt. i think m68k has such.
>
> most interrupt stacks in RTEMS are software-managed, meaning that
> RTEMS explicitly switches the stack region off the task stack and to
> an interrupt stack region.
>
> some stacks start high and grow down, and some stacks start low and
> grow up. maybe this is what the "stack high" and "stack low" you
> mention are in relation to?
>

They are used to denote the top and bottom of the memory reserved
for the interrupt stack. One important use is in
cpukit/libmisc/stackchk/check.c
to report on usage.


>
> > - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include
> > irq-sources.am, by the way (this is part of why I used to think a lot
> > of what your email mentioned was unnecessary, until you...ahem,
> > pre-empted that line of thought and helped clarify it :P). Should I
> > add a ticket to update the no_bsp code to be more in line with current
> > use?
> >
> Sure. I don't know that anyone is in particular maintaining
> no_cpu/no_bsp since we can't compile it, it is basically best effort
> stuff that sometimes we miss updating.
>

+1

Also there are variations based on simple vectored and PIC vectored
architectures.

The architecture is responsible for the managing the minimal actions
based on what the CPU does for an interrupt/exception. Logically
a PIC is part of the BSP even if it comes integrated with the CPU as
is common on x86 and SoCs. The PIC could fairly easily change
and the architecture is harder to change.


>
> > - My understanding of _ISR_Handler is that it'll be the handler for
> > _all_ interrupt vectors by default - it'll then dispatch interrupts to
> > user-handlers (or internal handlers, for the timer, for eg.). Is that
> > right? (I don't quite understand its interaction with the RTEMS
> > interrupt manager yet, but irq-generic's "bsp_interrupt_handler_table"
> > seems to be the RTEMS equivalent to the processor-specific vector
> > table, and "bsp_interrupt_handler_dispatch" seems to call the actual
> > handler within that table as appropriate. Accurate? (I just haven't
> > found how that table actually gets its handlers setup besides during
> > initialization, since rtems_interrupt_catch just calls
> > _CPU_install_vector, which updates the processor vector table, not the
> > RTEMS interrupt manager vector table.)
> >
>
> You have discovered a couple of different but related interrupt
> processing code bases.  I can see why you get confused.
>
> Basically, a CPU port should support two kinds of interrupts that may
> be installed, "RTEMS" and "Raw" interrupts. The "Raw" interrupts are
> installed directly in the processor's vector table. For processors
> that use simple vectored interrupts, the "RTEMS" interrupts install a
> call to the _ISR_Handler() function in the processor's vector table,
> and will put the user's isr function pointer in the
> _ISR_Vector_table(), which is the RTEMS Interrupt Manager's vector
> table.
>
> I'm not really familiar with the processors that use a different model
> for interrupt handling besides simple vectored. Probably, you will
> have to study one of them.
>
> This irq-generic bsp_interrupt_* code is used by the "IRQ Server" that
> builds from the CPU port capabilities to allow for some advanced
> features like chaining multiple isrs from the same source. I don't
> think you want to be focusing on those right now, but I could be
> mistaken. I haven't spent much time looking at the IRQ Server
> codebase.
>

For the most part, the 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Gedare Bloom]

On Wed, Aug 1, 2018 at 11:11 AM, Gedare Bloom  wrote:
> On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval  wrote:
>> That's definitely very illuminating, thank you so much for all the details!
>>
>> A few more questions that have arisen for me. Feel free to skip over
>> them (I'll likely figure them out given enough time, so I'm only
>> asking in case any of them are obvious to anyone):
>>
>> - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it
>> stores some of the data onto the stack?
>>
> the interrupt frame structure was introduced during 4.11 development.
> probably i386 never got updated to use a struct to encapsulate the
> interrupt frame. the interrupt frame should contain the registers that
> are preserved by the interrupt entry code I believe.
>
>> - There used to be defines in cpu.h regarding hardware/software based
>> interrupt stacks, and how they'd be setup, which were made
>> superfluous[1] - I'm not quite sure how these are meant to work - I
>> see references to "stack high" and "stack low" and I'm not quite sure
>> what the code is referencing when using those.
>>
>
> a hardware interrupt stack is one that the hardware switches to during
> an interrupt. i think m68k has such.
>
> most interrupt stacks in RTEMS are software-managed, meaning that
> RTEMS explicitly switches the stack region off the task stack and to
> an interrupt stack region.
>
> some stacks start high and grow down, and some stacks start low and
> grow up. maybe this is what the "stack high" and "stack low" you
> mention are in relation to?
>
>> - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include
>> irq-sources.am, by the way (this is part of why I used to think a lot
>> of what your email mentioned was unnecessary, until you...ahem,
>> pre-empted that line of thought and helped clarify it :P). Should I
>> add a ticket to update the no_bsp code to be more in line with current
>> use?
>>
> Sure. I don't know that anyone is in particular maintaining
> no_cpu/no_bsp since we can't compile it, it is basically best effort
> stuff that sometimes we miss updating.
>
>> - My understanding of _ISR_Handler is that it'll be the handler for
>> _all_ interrupt vectors by default - it'll then dispatch interrupts to
>> user-handlers (or internal handlers, for the timer, for eg.). Is that
>> right? (I don't quite understand its interaction with the RTEMS
>> interrupt manager yet, but irq-generic's "bsp_interrupt_handler_table"
>> seems to be the RTEMS equivalent to the processor-specific vector
>> table, and "bsp_interrupt_handler_dispatch" seems to call the actual
>> handler within that table as appropriate. Accurate? (I just haven't
>> found how that table actually gets its handlers setup besides during
>> initialization, since rtems_interrupt_catch just calls
>> _CPU_install_vector, which updates the processor vector table, not the
>> RTEMS interrupt manager vector table.)
>>
>
> You have discovered a couple of different but related interrupt
> processing code bases.  I can see why you get confused.
>
> Basically, a CPU port should support two kinds of interrupts that may
> be installed, "RTEMS" and "Raw" interrupts. The "Raw" interrupts are
> installed directly in the processor's vector table. For processors
> that use simple vectored interrupts, the "RTEMS" interrupts install a
> call to the _ISR_Handler() function in the processor's vector table,
> and will put the user's isr function pointer in the
> _ISR_Vector_table(), which is the RTEMS Interrupt Manager's vector
> table.
>
> I'm not really familiar with the processors that use a different model
> for interrupt handling besides simple vectored. Probably, you will
> have to study one of them.
>
> This irq-generic bsp_interrupt_* code is used by the "IRQ Server" that
> builds from the CPU port capabilities to allow for some advanced
> features like chaining multiple isrs from the same source. I don't
> think you want to be focusing on those right now, but I could be
> mistaken. I haven't spent much time looking at the IRQ Server
> codebase.
>

On second thought, it appears that maybe the non-simple vectored
processors do use some of this bsp_interrupt stuff. Keep digging. :)

> Gedare
>
>> - My understanding of the interaction between RTEMS' interrupt manager
>> (i.e. support for nested interrupts and thread dispatch once an
>> interrupt ends) and the BSP's processor-specific interrupt manager
>> (code to use the APIC and IDT in my case) is that they're tied
>> together through the use of irq-generic.c's "bsp_interrupt_initialize"
>> - is that right? (m68k never seems to call it, though, so perhaps
>> not?)
>>
>> Sorry about the rambling! To reiterate, I'll likely figure it out
>> given enough time, so if the answers aren't at the top of your head, I
>> can figure it out without wasting your time :)
>>
>> [1] https://devel.rtems.org/ticket/3459#comment:11
>>
>> On Wed, Aug 1, 2018 at 3:18 AM, Joel Sherrill  wrote:
>>>
>>>
>>> On Tue, Jul 31, 2018 at 3:05 PM, 

Re: [GSoC - x86_64] Interrupt manager and and port-specific glue - was Re: [GSoC - x86_64 - automake] Limit CFLAGS to specific source for librtemsbsp.a

[Gedare Bloom]

On Wed, Aug 1, 2018 at 9:15 AM, Amaan Cheval  wrote:
> That's definitely very illuminating, thank you so much for all the details!
>
> A few more questions that have arisen for me. Feel free to skip over
> them (I'll likely figure them out given enough time, so I'm only
> asking in case any of them are obvious to anyone):
>
> - The i386 doesn't use CPU_Interrupt_frame at all. It seems like it
> stores some of the data onto the stack?
>
the interrupt frame structure was introduced during 4.11 development.
probably i386 never got updated to use a struct to encapsulate the
interrupt frame. the interrupt frame should contain the registers that
are preserved by the interrupt entry code I believe.

> - There used to be defines in cpu.h regarding hardware/software based
> interrupt stacks, and how they'd be setup, which were made
> superfluous[1] - I'm not quite sure how these are meant to work - I
> see references to "stack high" and "stack low" and I'm not quite sure
> what the code is referencing when using those.
>

a hardware interrupt stack is one that the hardware switches to during
an interrupt. i think m68k has such.

most interrupt stacks in RTEMS are software-managed, meaning that
RTEMS explicitly switches the stack region off the task stack and to
an interrupt stack region.

some stacks start high and grow down, and some stacks start low and
grow up. maybe this is what the "stack high" and "stack low" you
mention are in relation to?

> - c/src/lib/libbsp/no_cpu/no_bsp/Makefile.am doesn't include
> irq-sources.am, by the way (this is part of why I used to think a lot
> of what your email mentioned was unnecessary, until you...ahem,
> pre-empted that line of thought and helped clarify it :P). Should I
> add a ticket to update the no_bsp code to be more in line with current
> use?
>
Sure. I don't know that anyone is in particular maintaining
no_cpu/no_bsp since we can't compile it, it is basically best effort
stuff that sometimes we miss updating.

> - My understanding of _ISR_Handler is that it'll be the handler for
> _all_ interrupt vectors by default - it'll then dispatch interrupts to
> user-handlers (or internal handlers, for the timer, for eg.). Is that
> right? (I don't quite understand its interaction with the RTEMS
> interrupt manager yet, but irq-generic's "bsp_interrupt_handler_table"
> seems to be the RTEMS equivalent to the processor-specific vector
> table, and "bsp_interrupt_handler_dispatch" seems to call the actual
> handler within that table as appropriate. Accurate? (I just haven't
> found how that table actually gets its handlers setup besides during
> initialization, since rtems_interrupt_catch just calls
> _CPU_install_vector, which updates the processor vector table, not the
> RTEMS interrupt manager vector table.)
>

You have discovered a couple of different but related interrupt
processing code bases.  I can see why you get confused.

Basically, a CPU port should support two kinds of interrupts that may
be installed, "RTEMS" and "Raw" interrupts. The "Raw" interrupts are
installed directly in the processor's vector table. For processors
that use simple vectored interrupts, the "RTEMS" interrupts install a
call to the _ISR_Handler() function in the processor's vector table,
and will put the user's isr function pointer in the
_ISR_Vector_table(), which is the RTEMS Interrupt Manager's vector
table.

I'm not really familiar with the processors that use a different model
for interrupt handling besides simple vectored. Probably, you will
have to study one of them.

This irq-generic bsp_interrupt_* code is used by the "IRQ Server" that
builds from the CPU port capabilities to allow for some advanced
features like chaining multiple isrs from the same source. I don't
think you want to be focusing on those right now, but I could be
mistaken. I haven't spent much time looking at the IRQ Server
codebase.

Gedare

> - My understanding of the interaction between RTEMS' interrupt manager
> (i.e. support for nested interrupts and thread dispatch once an
> interrupt ends) and the BSP's processor-specific interrupt manager
> (code to use the APIC and IDT in my case) is that they're tied
> together through the use of irq-generic.c's "bsp_interrupt_initialize"
> - is that right? (m68k never seems to call it, though, so perhaps
> not?)
>
> Sorry about the rambling! To reiterate, I'll likely figure it out
> given enough time, so if the answers aren't at the top of your head, I
> can figure it out without wasting your time :)
>
> [1] https://devel.rtems.org/ticket/3459#comment:11
>
> On Wed, Aug 1, 2018 at 3:18 AM, Joel Sherrill  wrote:
>>
>>
>> On Tue, Jul 31, 2018 at 3:05 PM, Amaan Cheval 
>> wrote:
>>>
>>> Hm, I'm not sure what to look for in the other ports specifically, really.
>>> The BSP porting documentation doesn't have a section on interrupts, so I'm
>>> doing this on more of an "as it comes up" basis.
>>>
>>> What I've got right now (the interrupt handlers in C) are what I need for
>>>