Re: [ECOS] IRQs mapping in PC platform

Re: [ECOS] IRQs mapping in PC platform

[Boris V. Guzhov]

In my last letter there is a infidelity.
>But there is one more bug:  in the  cyg_drv_interrupt_(un)mask().
>I think that right similarly to following (it is written on the "C" only
>for a example):

It means HAL_INTERRUPT_(UN)MASK, instead of  cyg_drv_interrupt_(un)mask().

--
Boris Guzhov,
St.Petersburg, Russia

Re: [ECOS] IRQs mapping in PC platform

[Boris V. Guzhov]

> > > For cyg_drv_interrupt_mask() is similarly.
>
> I would like to disagree with this last remark about  the mask function.
If
> you meant similarly as: "mask IRQ2 when maksing irq 8 or above" that
would,
> I think, mean that all IRQs above 8 are masked when we mask an IRQ above
8.
>

Yes, that's right.

> More generally I think that IRQ 2 should never be masked unless
> intentionnaly with the cyg_interrupt_mask. If it was the case, then mask
and
> unmask function should have worked correctly.
> And I think too that IRQ2 should be unmasked at PIC initialisation.
>
> Anyway it is still a good idea to unmask IRQ2 when unmasking an IRQ above
8.
>
 > Thanks
>
> --
> Fabrice Gautier
> fabrice_gautier@sdesigns.com
>

Thanks
--
Boris Guzhov,
St.Petersburg, Russia

RE: [ECOS] IRQs mapping in PC platform

[Fabrice Gautier]

> -----Original Message-----
> From: Nick Garnett [ mailto:nickg@cygnus.co.uk ]
> Subject: Re: [ECOS] IRQs mapping in PC platform
> 
> 
> "Boris V. Guzhov" <borg@int.spb.ru> writes:
> 
> > 
> > But there is one more bug:  in the  cyg_drv_interrupt_(un)mask().
> > I think that right similarly to following (it is written on 
> the "C" only
> > for a example):
> > 
> > void cyg_drv_interrupt_unmask(cyg_vector_t vector)
> > {
> >   if ( vector < 0x28 )  // for master
> >     pc_outb(0x21, pc_inb(0x21) & ~(1<<(vector-0x20)));
> >   else           // for slave
> >   {
> >     pc_outb(0x21, pc_inb(0x21) & ~(1<<2));    //  unmask master IRQ2
> >     pc_outb(0xA1, pc_inb(0xA1) & ~(1<<(vector-0x28)));
> >   }
> > }
> > 
> > For cyg_drv_interrupt_mask() is similarly.

I would like to disagree with this last remark about  the mask function. If
you meant similarly as: "mask IRQ2 when maksing irq 8 or above" that would,
I think, mean that all IRQs above 8 are masked when we mask an IRQ above 8.

More generally I think that IRQ 2 should never be masked unless
intentionnaly with the cyg_interrupt_mask. If it was the case, then mask and
unmask function should have worked correctly.
And I think too that IRQ2 should be unmasked at PIC initialisation.

Anyway it is still a good idea to unmask IRQ2 when unmasking an IRQ above 8.

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 

Re: [ECOS] IRQs mapping in PC platform

[Nick Garnett]

"Boris V. Guzhov" <borg@int.spb.ru> writes:

> >
> >
> > [bug in HAL_INTERRUPT_ACKNOWLEDGE()]
> >


> Ok.  There is one remark:
> 
>   .macro hal_intc_ack vector
>  # Use any registers you like.
>  movl \vector, %edx
>  movb $0x20, %al
>  cmpl $0x20, %edx
>  jl 8f
>  cmpl $0x28, %edx    ; <--- line changed
>  jl 9f
>  outb %al, $0xA0
>  9: outb %al, $0x20
>  8: nop
>  .endm

Oops, yes, I think you are right. 


> 
> But there is one more bug:  in the  cyg_drv_interrupt_(un)mask().
> I think that right similarly to following (it is written on the "C" only
> for a example):
> 
> void cyg_drv_interrupt_unmask(cyg_vector_t vector)
> {
>   if ( vector < 0x28 )  // for master
>     pc_outb(0x21, pc_inb(0x21) & ~(1<<(vector-0x20)));
>   else           // for slave
>   {
>     pc_outb(0x21, pc_inb(0x21) & ~(1<<2));    //  unmask master IRQ2
>     pc_outb(0xA1, pc_inb(0xA1) & ~(1<<(vector-0x28)));
>   }
> }
> 
> For cyg_drv_interrupt_mask() is similarly.
> I tested it. And it worked properly.
>

Yes, that's right. It's been a few years since I did PC interrupt stuff,
but all these improvements are reminding me of what I did then. Maybe
I should dig out my old code and compare it sometime...


I'll get these changes put into our repository.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] IRQs mapping in PC platform

[Boris V. Guzhov]

>
>
> [bug in HAL_INTERRUPT_ACKNOWLEDGE()]
>
> >
> > Is that right?
> >
>
> Yes, that is right. However, looking at the code, I see that this
> macro is not actually used, but instead the hal_intc_ack assembly
> macro in platform.inc is actually used. This has the same bug.
>
> So that macro should change to this (I think, I have not been able to
> test it):
>
> .macro hal_intc_ack vector
> # Use any registers you like.
> movl \vector, %edx
> movb $0x20, %al
> cmpl $0x20, %edx
> jl 8f
> cmpl $0x30, %edx
> jl 9f
> outb %al, $0xA0
> 9: outb %al, $0x20
> 8: nop
> .endm
>
> I'll make these two changes to our sources for the next anoncvs
> release.
>
> --
> Nick Garnett, eCos Kernel Architect
> Red Hat, Cambridge, UK
>

Ok.  There is one remark:

  .macro hal_intc_ack vector
 # Use any registers you like.
 movl \vector, %edx
 movb $0x20, %al
 cmpl $0x20, %edx
 jl 8f
 cmpl $0x28, %edx    ; <--- line changed
 jl 9f
 outb %al, $0xA0
 9: outb %al, $0x20
 8: nop
 .endm

But there is one more bug:  in the  cyg_drv_interrupt_(un)mask().
I think that right similarly to following (it is written on the "C" only
for a example):

void cyg_drv_interrupt_unmask(cyg_vector_t vector)
{
  if ( vector < 0x28 )  // for master
    pc_outb(0x21, pc_inb(0x21) & ~(1<<(vector-0x20)));
  else           // for slave
  {
    pc_outb(0x21, pc_inb(0x21) & ~(1<<2));    //  unmask master IRQ2
    pc_outb(0xA1, pc_inb(0xA1) & ~(1<<(vector-0x28)));
  }
}

For cyg_drv_interrupt_mask() is similarly.
I tested it. And it worked properly.

--
Boris Guzhov,
St.Petersburg, Russia

Re: [ECOS] IRQs mapping in PC platform

[Nick Garnett]

"Boris V. Guzhov" <borg@int.spb.ru> writes:


[bug in HAL_INTERRUPT_ACKNOWLEDGE()]

> 
> Is that right?
> 

Yes, that is right. However, looking at the code, I see that this
macro is not actually used, but instead the hal_intc_ack assembly
macro in platform.inc is actually used. This has the same bug.

So that macro should change to this (I think, I have not been able to
test it):

	.macro hal_intc_ack vector
	# Use any registers you like.
	movl	\vector, %edx
	movb	$0x20, %al
	cmpl	$0x20, %edx
	jl	8f
	cmpl	$0x30, %edx
	jl	9f
	outb	%al, $0xA0
9:	outb	%al, $0x20
8:	nop
	.endm

I'll make these two changes to our sources for the next anoncvs
release.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] IRQs mapping in PC platform

[Boris V. Guzhov]

> "Boris V. Guzhov" <borg@int.spb.ru> writes:
>
> > Hi,
> > I have tested it.  And my device (3c509 EtherLink3 ISA card)
> >  worked properly with 5 and 7 IRQ
> > It corresponds to  5+PC_HARDWARE_IRQ_OFFSET  and
> > 7+PC_HARDWARE_IRQ_OFFSET vectors and here is
> > used master interrupt controller.
> > But it did not work with 10 and 11 IRQ (they are connected to slave
> > interrupt controller).   Why?
> >
>
> There may well be some problems with the second PIC and propogation of
> interrupts through the master controller. I am not sure that this has
> ever been tested - the only interrupting devices use so far are the
> timer and serial lines, all of which are on the master.
>
> --
> Nick Garnett, eCos Kernel Architect
> Red Hat, Cambridge, UK

I think that there is a bug in  hal/i386/pc/version/include/var_intr.h.

In the file there is  the macros:
#define HAL_INTERRUPT_ACKNOWLEDGE( _vector_ )   \
CYG_MACRO_START                                         \
    int x = (_vector_) - PC_HARDWARE_IRQ_OFFSET;    \
    if ((x >= 8) && (x < 16))              \
    {                                                   \
        asm(                                          \
            "movb $0x20, %%al;"           \
            "outb %%al, $0xA0;"             \
            :   /* No outputs. */                \
            :   /* No inputs. */                  \
            :   "eax"                                  \
            );                                          \
    }                                                   \
    if ((x >= 0) && (x < 8))                     \
    {                                                   \
        asm(                                            \
            "movb $0x20, %%al;"                         \
            "outb %%al, $0x20;"                         \
            :   /* No outputs. */                       \
            :   /* No inputs. */                        \
            :   "eax"                                   \
            );                                          \
    }                                                   \
CYG_MACRO_END

Here for the connected to slave controller devices issue EOI  only for
the slave.  But it is necessary to issue EOI for slave AND
for master:

#define HAL_INTERRUPT_ACKNOWLEDGE( _vector_ )           \
CYG_MACRO_START                                         \
    int x = (_vector_) - PC_HARDWARE_IRQ_OFFSET;        \
    if ((x >= 8) && (x < 16))                           \
    {                                                   \
        asm(                                            \
            "movb $0x20, %%al;"                         \
            "outb %%al, $0xA0;"                         \
            :   /* No outputs. */                       \
            :   /* No inputs. */                        \
            :   "eax"                                   \
            );                                          \
    }                                                   \
    if ((x >= 0) && (x < 16))    \     <----  line changed
    {                                                   \
        asm(                                            \
            "movb $0x20, %%al;"                         \
            "outb %%al, $0x20;"                         \
            :   /* No outputs. */                       \
            :   /* No inputs. */                        \
            :   "eax"                                   \
            );                                          \
    }                                                   \
CYG_MACRO_END

Is that right?

--
Boris Guzhov,
St.Petersburg, Russia

Re: [ECOS] IRQs mapping in PC platform

[Nick Garnett]

"Boris V. Guzhov" <borg@int.spb.ru> writes:

> Hi,
> I have tested it.  And my device (3c509 EtherLink3 ISA card)
>  worked properly with 5 and 7 IRQ
> It corresponds to  5+PC_HARDWARE_IRQ_OFFSET  and
> 7+PC_HARDWARE_IRQ_OFFSET vectors and here is
> used master interrupt controller.
> But it did not work with 10 and 11 IRQ (they are connected to slave
> interrupt controller).   Why?
> 

There may well be some problems with the second PIC and propogation of
interrupts through the master controller. I am not sure that this has
ever been tested - the only interrupting devices use so far are the
timer and serial lines, all of which are on the master.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [ECOS] IRQs mapping in PC platform

[Boris V. Guzhov]

Hi,
I have tested it.  And my device (3c509 EtherLink3 ISA card)
 worked properly with 5 and 7 IRQ
It corresponds to  5+PC_HARDWARE_IRQ_OFFSET  and
7+PC_HARDWARE_IRQ_OFFSET vectors and here is
used master interrupt controller.
But it did not work with 10 and 11 IRQ (they are connected to slave
interrupt controller).   Why?

Thanks in advance.
--
Boris Guzhov,
St.Petersburg, Russia

> Hi,
>
> it seems that in the PC platform, IRQs are mapped to vectors 32 to 47.
> Is that right ?
>  (I didn't find any confirmation of that in the documentations)
>
> Thanks
>
> A+
> --
> Fabrice Gautier
> fabrice_gautier@sdesigns.com
>

[ECOS] IRQs mapping in PC platform

[Fabrice Gautier]

Hi,

it seems that in the PC platform, IRQs are mapped to vectors 32 to 47.
Is that right ?
 (I didn't find any confirmation of that in the documentations)

Thanks

A+
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com