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

2018-08-09 Thread 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

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

2018-08-09 Thread 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 @

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

2018-08-09 Thread 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

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

2018-08-09 Thread 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:

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

2018-08-09 Thread 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

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

2018-08-08 Thread 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). > >

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

2018-08-08 Thread 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

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

2018-08-06 Thread 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 >

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

2018-08-06 Thread 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

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

2018-08-06 Thread 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

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

2018-08-01 Thread 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

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

2018-08-01 Thread 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

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

2018-08-01 Thread 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

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

2018-08-01 Thread 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,

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

2018-08-01 Thread 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

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

2018-08-01 Thread 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

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

2018-08-01 Thread 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

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

2018-08-01 Thread Amaan Cheval
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