OSDev.org

Hello Octocontrabass

"According to the MADT, the default is PIC mode. You must call the _PIC method to switch to APIC mode"

how do i call this (my limited understanding is these methods don't setup anything, they will only provide information )

i am working in bare-metal environment

The way we are working is Slimboot loader boots up after that we take up the control and set up the resources(which i am trying now, in assembly ) for our own RTOS

i am new to ACPI stuff but i did read MADT table that how i was able to set up IOAPIC, got know redirection of PIT timer and made the scheduler tick , other than that i have limited exposure to ACPI tables

Thanks

Use an AML interpreter. You can write one yourself or port one like ACPICA or LAI. Or, if you only need your code to work on one board, you can rewrite the AML into a custom board driver.


The _PIC method does not provide information. It tells the firmware to set up whichever interrupt mode you've chosen.

Ok thanks i will try to do it

i the mean while as per experience, what might be a happing in case as you best guess(considering timer is working)

thanks
Ravi

The only thing I can think of is maybe you have the IOAPIC set to the wrong polarity. (PCI interrupt lines are active-low.)

Have you tried your UART driver with any other hardware?

Sorry for delayed response, i was trying hard to fix it(was critical)

finally i had to configure the IOAPIC to edge triggered /active low to fix it, which is exactly opposite to Elkhart lake data sheet for UART it states level triggered and active highs, any thoughts on this?

thank you for answering my questions
Ravi

if you happen to know how to know()
1) which core i am running
2) what is speed of the core i am running

thanks again

You should configure the IOAPIC to level triggered active low, same as any other PCI interrupt. Since it's level triggered, you need to acknowledge the interrupt in the UART before you send an EOI to the APIC. Which datasheet says it's active high?


CPUID leaf 1 reports the APIC ID in the high byte of EBX. CPUID leaf 0xB (any valid sub-leaf) reports the x2APIC ID in EDX.


CPUID leaf 0x15 reports the source clock frequency and base multiplier. (CPUID leaf 0x16 reports the nominal base clock in EAX, but Intel says that number is less accurate than calculating it from leaf 0x15.) IA32_MPERF counts at a fixed frequency relative to the base clock while the core is active. IA32_APERF counts at a fixed frequency relative to the core clock while the core is active. You can periodically sample IA32_MPERF and IA32_APERF and calculate (base clock) * (APERF count) / (MPERF count) to get the core speed while the core is running. This calculation excludes idle periods when you've halted the core.

On your CPU, IA32_MPERF should count at the same speed as the TSC, so you can calculate (base clock) * (APERF count) / (TSC count) to get the overall core speed including idle periods.

Hello
sorry i should have include it

https://www.intel.com/content/www/us/en ... ume-1.html
Intel Atom® x6000E Series, and Intel® Pentium® and Celeron® N and J Series Processors for IoT Applications
Datasheet, Volume 1

18.1.11 Interrupts
All interrupts are active high and their behavior is level interrupt. Controller interrupts
are enabled using the IER (Interrupt Enable Register) and read using the IIR (Interrupt
Identification Register)

yeah that was the issue when i configured as level triggered(either active or low), i get continuous interrupts uncontrolled (IIR/MSR reads no interrupts, and LSR indicates device busy in transmitting, when i check these registers while have come to ISR), i tired all the 4 combination Edge/level & Active-high/only, only thing that's working is edge triggered active low(when i enter the ISR, IIR reflects buffer empty INTR, and able to transmit the without any loss huge chunk of data),, i think level trigger is right way, i need to understand this behavior ASAP even though its working

"you need to acknowledge the interrupt in the UART before you send an EOI to the APIC"
here is what i do

when i first enter the ISR

Read IIR
Read MSR(no reason)
Read PCI status register

check if anything is pending in the buffer to be sent, if yes then put the next char in the THR

EOI IOAPIC
EOI APIC

IRET

Thanks for taking your time to answer my query
Ravi

This isn't the first time one of Intel's datasheets have been wrong. They probably didn't notice the mistake because existing OSes (that use level triggered active low for PCI interrupts) didn't need any changes to work.


You're not supposed to do anything with the IOAPIC for EOI.

Yeah, my initial impression was the same,,,,,,,nothing is suppose to be done to EOI IOAPIC

then i found this link https://github.com/intel/CODK-A-X86/blo ... pic_intr.c

which says EOI to IOAPIC (IOAPIC base address + 0x40) = 0xIRQ of the device(which would help it track multiple interrupts), i tried hard to find this information in any document but unable to find any.


Thanks
Ravi

It's covered in the SDM, volume 3A chapter 11. If bit 24 of the local APIC version register is set, you can suppress the local APIC's EOI broadcast to the IOAPIC by setting bit 12 of the spurious interrupt vector register. As long as you don't do that, the local APIC automatically sends an EOI to the IOAPIC.

Thanks I will investigate that

Thanks
Ravi