|
Eric Patrizi(deleted)
|
Gaining acces to interrupt descriptor memory
|
|
Eric Patrizi(deleted)
10/09/2012 8:43 PM
post96167
|
Gaining acces to interrupt descriptor memory
I need to be able to read the interrupt vector (descriptor) table memory in order to periodically perform a CRC
calculation to verify the table has not been corrupted. Getting the address of the table seems to work at any privilege
level.
BYTE idt[6];
__asm__("sidt %0"
: "=m"(idt)
);
However, I get a seg fault when I try to access the memory. Understandable when done from user code. I attempted to
access the memory from a timer interrupt (via timer_create() and SIGALRM) thinking that would allow (put me in ring 0)
the access, but still get the seg fault.
Anyone have any ideas how to get access to this memory? Do I need to map it in? Is code executed in the timer
interrupt executed at ring 0?
I am using QNX 6.3.2.
Thanks,
|
|
|
|
|
|
Mario Charest
|
RE: Gaining acces to interrupt descriptor memory
|
|
Mario Charest
10/09/2012 9:02 PM
post96168
|
RE: Gaining acces to interrupt descriptor memory
You need to map it first I would think, then you may or may not need ring 0 to read this, I don`t know. SIGALRM is NOT
an interrupt, nor is timer_create. You would need to install a real ISR.
-----Message d'origine-----
De : Eric Patrizi [mailto:community-noreply@qnx.com]
Envoyé : Tuesday, October 09, 2012 8:44 PM
À : ostech-core_os
Objet : Gaining acces to interrupt descriptor memory
I need to be able to read the interrupt vector (descriptor) table memory in order to periodically perform a CRC
calculation to verify the table has not been corrupted. Getting the address of the table seems to work at any privilege
level.
BYTE idt[6];
__asm__("sidt %0"
: "=m"(idt)
);
However, I get a seg fault when I try to access the memory. Understandable when done from user code. I attempted to
access the memory from a timer interrupt (via timer_create() and SIGALRM) thinking that would allow (put me in ring 0)
the access, but still get the seg fault.
Anyone have any ideas how to get access to this memory? Do I need to map it in? Is code executed in the timer
interrupt executed at ring 0?
I am using QNX 6.3.2.
Thanks,
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post96167
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
|
|
|
Mario Charest
|
RE: Gaining acces to interrupt descriptor memory
|
|
Mario Charest
10/09/2012 9:00 PM
post96169
|
RE: Gaining acces to interrupt descriptor memory
My guess is, if this gets corrupted you would not be able to check it, the machine would go bye bye. Don`t know about
your application but I don`t think it`s wise to assume this doesn`t change. I doubt it does but I never read anything
about it NOT changing.
-----Message d'origine-----
De : Eric Patrizi [mailto:community-noreply@qnx.com]
Envoyé : Tuesday, October 09, 2012 8:44 PM
À : ostech-core_os
Objet : Gaining acces to interrupt descriptor memory
I need to be able to read the interrupt vector (descriptor) table memory in order to periodically perform a CRC
calculation to verify the table has not been corrupted. Getting the address of the table seems to work at any privilege
level.
BYTE idt[6];
__asm__("sidt %0"
: "=m"(idt)
);
However, I get a seg fault when I try to access the memory. Understandable when done from user code. I attempted to
access the memory from a timer interrupt (via timer_create() and SIGALRM) thinking that would allow (put me in ring 0)
the access, but still get the seg fault.
Anyone have any ideas how to get access to this memory? Do I need to map it in? Is code executed in the timer
interrupt executed at ring 0?
I am using QNX 6.3.2.
Thanks,
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post96167
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
|
|
|
Eric Patrizi(deleted)
|
Re: RE: Gaining acces to interrupt descriptor memory
|
|
Eric Patrizi(deleted)
10/09/2012 9:58 PM
post96170
|
Re: RE: Gaining acces to interrupt descriptor memory
Yes, most of the error checking we are required (Nuclear industry) to do is only valid on working hardware. Any failure
and the most likely scenario is a dead processor.
I tried using a software interrupt "INT $0x41", but my ISR was never called. I will put a little more effort into that.
I picked 0x41 out of thin air, not sure what software interrupts the OS is using . Would a software interrupt ISR
execute in ring 0? Would you expect the IDTR to have a physical memory address or virtual? I was assuming physical,
but the address was a little odd.
|
|
|
|
|
|
Mario Charest
|
RE: RE: Gaining acces to interrupt descriptor memory
|
|
Mario Charest
10/09/2012 10:27 PM
post96171
|
RE: RE: Gaining acces to interrupt descriptor memory
Interrupt 0x41 ? You can`t randomly pick an interrupt. Your best bet is to connect to the timer interrupt, however
what it is depends on the machine, on some it`s 0 on other it`s 2. Check InterruptAttach() to install your ISR.
Everything in QNX is virtual, even when running in the context of an ISR, so you must take your physical address and map
it to a virtual address via mmap()
-----Message d'origine-----
De : Eric Patrizi [mailto:community-noreply@qnx.com]
Envoyé : Tuesday, October 09, 2012 9:58 PM
À : ostech-core_os
Objet : Re: RE: Gaining acces to interrupt descriptor memory
Yes, most of the error checking we are required (Nuclear industry) to do is only valid on working hardware. Any failure
and the most likely scenario is a dead processor.
I tried using a software interrupt "INT $0x41",
but my ISR was never called. I will put a little more effort into that. I picked 0x41 out of thin air, not sure what
software interrupts the OS is using . Would a software interrupt ISR execute in ring 0? Would you expect the IDTR to
have a physical memory address or virtual? I was assuming physical, but the address was a little odd.
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post96170
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: Gaining acces to interrupt descriptor memory
|
|
Armin Steinhoff
10/10/2012 3:11 AM
post96173
|
Re: Gaining acces to interrupt descriptor memory
Eric,
access to ring 0 isn't supported !
--Armin
Eric Patrizi wrote:
> I need to be able to read the interrupt vector (descriptor) table memory in order to periodically perform a CRC
calculation to verify the table has not been corrupted. Getting the address of the table seems to work at any privilege
level.
>
> BYTE idt[6];
>
> __asm__("sidt %0"
> : "=m"(idt)
> );
>
> However, I get a seg fault when I try to access the memory. Understandable when done from user code. I attempted to
access the memory from a timer interrupt (via timer_create() and SIGALRM) thinking that would allow (put me in ring 0)
the access, but still get the seg fault.
>
> Anyone have any ideas how to get access to this memory? Do I need to map it in? Is code executed in the timer
interrupt executed at ring 0?
>
> I am using QNX 6.3.2.
>
> Thanks,
>
>
>
> _______________________________________________
>
> OSTech
> http://community.qnx.com/sf/go/post96167
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
>
|
|
|
|
|
|
Eric Patrizi(deleted)
|
Re: Gaining acces to interrupt descriptor memory
|
|
Eric Patrizi(deleted)
10/10/2012 10:53 AM
post96187
|
Re: Gaining acces to interrupt descriptor memory
Ring 0 access may not be necessary. I was hoping someone might know the answer to that. When I execute
BYTE idt[6];
__asm__("sidt %0"
: "=m"(idt)
);
I get
p /x idt = (0xf, 0x2, 0x38, 0x1d, 0xd1, 0xfe)
The limit 0x20f could make sense (QNX only supporting 0x42 interrupts, and it is supposed to be a multiple of 8 minus 1)
. However, the address 0xfed11d38 does not appear to be a physical address as my x86 board only has 512 MB installed.
mmap() allows me to map this address, but all I read are 0xffffffff's. If 0xfed11d38 is a virtual address, I don't
think mmap can be used. Does anyone know (or have an idea) how to map access to it?
|
|
|
|
|
|
Mario Charest
|
RE: Gaining acces to interrupt descriptor memory
|
|
Mario Charest
10/10/2012 11:52 AM
post96196
|
RE: Gaining acces to interrupt descriptor memory
Try with mmap64,
-----Message d'origine-----
De : Eric Patrizi [mailto:community-noreply@qnx.com]
Envoyé : Wednesday, October 10, 2012 10:53 AM
À : ostech-core_os
Objet : Re: Gaining acces to interrupt descriptor memory
Ring 0 access may not be necessary. I was hoping someone might know the answer to that. When I execute
BYTE idt[6];
__asm__("sidt %0"
: "=m"(idt)
);
I get
p /x idt = (0xf, 0x2, 0x38, 0x1d, 0xd1, 0xfe)
The limit 0x20f could make sense (QNX only supporting 0x42 interrupts, and it is supposed to be a multiple of 8 minus 1)
. However, the address 0xfed11d38 does not appear to be a physical address as my x86 board only has 512 MB installed.
mmap() allows me to map this address, but all I read are 0xffffffff's. If 0xfed11d38 is a virtual address, I don't
think mmap can be used. Does anyone know (or have an idea) how to map access to it?
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post96187
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
|
|
|
Eric Patrizi(deleted)
|
Re: RE: Gaining acces to interrupt descriptor memory
|
|
Eric Patrizi(deleted)
10/11/2012 4:18 PM
post96266
|
Re: RE: Gaining acces to interrupt descriptor memory
mmap64 did not appear to work. I connected to the timer ISR and was able to access the IDT memory without mapping in
the memory. I am guessing the address stored in the IDT register is a kernel virtual address and the timer ISR is
executing from kernel space, it has access to that memory.
Anyway, now my problem is sharing some data between my ISR and task. Some posts seemed to indicate the ISR would be
able to access a global variable or use the communication area pointer passed in to the interruptAttach() function.
However, neither would work for me.
I am okay with writing a resource manager or device driver if that is required, just do not want to do the work unless I
know it is needed.
|
|
|
|
|
|
