Hey all,

I am porting a 270 based platform from CE 5.0 to CE 6.0 and have found a
discrepancy with the defined value of IRQ_BULVERDE_MAX between the two
versions. In CE 5.0 it is defined as follows...

#define IRQ_BULVERDE_MAX IRQ_RTCALARM

...where IRQ_RTCALARM = 31.

In CE 6.0 it is defined as follows...

#define IRQ_BULVERDE_MAX 63 //icmr (32) + icmr2 (32)

Is there a reason this was changed? I am defining additional platform
specific IRQ values based off of the IRQ_BULVERDE_MAX value, but this
paradigm is broken in CE 6.0 because the OALIntrStaticTranslate() routine
(common lib, map.c) is comparing against the OAL_INTR_IRQ_MAXIMUM value which
is defined as 64 for both versions. What this causes is the IRQ translation
in CE 6.0 to be skipped because the compare fails, which in turn causes the
SYSINTR to be mapped to the IRQ init value of -1 and then breaks IRQ
dependent drivers.

Obviously, I can manage to work around the issue, but I just wanted to get
the reasoning behind the change to IRQ_BULVERDE_MAX.

Re: IRQ_BULVERDE_MAX CE 6.0 Question by Michel

Michel
Tue May 13 14:09:34 PDT 2008

So, you are basing your values of IRQ_BULVERDE_MAX, like
IRQ_BULVERDE_MAX + 1, IRQ_BULVERDE_MAX + 2, etc?

That seems to be a strange thing to do anyway... IRQ_BULVERDE_MAX
clearly indicates it is a MAXIMUM value for IRQ's, so +1 is not the
right thing to do, or am I missing something?


Good luck,

Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog

GuruCE Ltd.
Microsoft Embedded Partner
http://GuruCE.com
Consultancy, training and development services.

FoolBlah wrote:
> Hey all,
>
> I am porting a 270 based platform from CE 5.0 to CE 6.0 and have found a
> discrepancy with the defined value of IRQ_BULVERDE_MAX between the two
> versions. In CE 5.0 it is defined as follows...
>
> #define IRQ_BULVERDE_MAX IRQ_RTCALARM
>
> ....where IRQ_RTCALARM = 31.
>
> In CE 6.0 it is defined as follows...
>
> #define IRQ_BULVERDE_MAX 63 //icmr (32) + icmr2 (32)
>
> Is there a reason this was changed? I am defining additional platform
> specific IRQ values based off of the IRQ_BULVERDE_MAX value, but this
> paradigm is broken in CE 6.0 because the OALIntrStaticTranslate() routine
> (common lib, map.c) is comparing against the OAL_INTR_IRQ_MAXIMUM value which
> is defined as 64 for both versions. What this causes is the IRQ translation
> in CE 6.0 to be skipped because the compare fails, which in turn causes the
> SYSINTR to be mapped to the IRQ init value of -1 and then breaks IRQ
> dependent drivers.
>
> Obviously, I can manage to work around the issue, but I just wanted to get
> the reasoning behind the change to IRQ_BULVERDE_MAX.

Re: IRQ_BULVERDE_MAX CE 6.0 Question by foolblah

foolblah
Tue May 13 18:24:03 PDT 2008

You should probably have a look at this file...

\WINCE600\PLATFORM\MAINSTONEIII\SRC\INC\intr_fpga.h

The Mainstone III BSP does the same thing I am doing.

It really is not that out of the ordinary. From my point of view the MAX is
an indicator of the MAX number of IRQ sources on the 270 processor. So by
offsetting by the MAX for platform specific IRQs you ensure that you do not
accidentally map one of the primary 270 IRQ sources to the SYSINTR.

Thanks.

"Michel Verhagen (eMVP)" wrote:

> So, you are basing your values of IRQ_BULVERDE_MAX, like
> IRQ_BULVERDE_MAX + 1, IRQ_BULVERDE_MAX + 2, etc?
>
> That seems to be a strange thing to do anyway... IRQ_BULVERDE_MAX
> clearly indicates it is a MAXIMUM value for IRQ's, so +1 is not the
> right thing to do, or am I missing something?
>
>
> Good luck,
>
> Michel Verhagen, eMVP
> Check out my blog: http://GuruCE.com/blog
>
> GuruCE Ltd.
> Microsoft Embedded Partner
> http://GuruCE.com
> Consultancy, training and development services.
>
> FoolBlah wrote:
> > Hey all,
> >
> > I am porting a 270 based platform from CE 5.0 to CE 6.0 and have found a
> > discrepancy with the defined value of IRQ_BULVERDE_MAX between the two
> > versions. In CE 5.0 it is defined as follows...
> >
> > #define IRQ_BULVERDE_MAX IRQ_RTCALARM
> >
> > ....where IRQ_RTCALARM = 31.
> >
> > In CE 6.0 it is defined as follows...
> >
> > #define IRQ_BULVERDE_MAX 63 //icmr (32) + icmr2 (32)
> >
> > Is there a reason this was changed? I am defining additional platform
> > specific IRQ values based off of the IRQ_BULVERDE_MAX value, but this
> > paradigm is broken in CE 6.0 because the OALIntrStaticTranslate() routine
> > (common lib, map.c) is comparing against the OAL_INTR_IRQ_MAXIMUM value which
> > is defined as 64 for both versions. What this causes is the IRQ translation
> > in CE 6.0 to be skipped because the compare fails, which in turn causes the
> > SYSINTR to be mapped to the IRQ init value of -1 and then breaks IRQ
> > dependent drivers.
> >
> > Obviously, I can manage to work around the issue, but I just wanted to get
> > the reasoning behind the change to IRQ_BULVERDE_MAX.
>

Re: IRQ_BULVERDE_MAX CE 6.0 Question by Dean

Dean
Wed May 14 11:32:21 PDT 2008

I don't know why someone changed it, but keep in mind there are many more
than 64 potential interrupt sources on the PXA270. The CE code is setting
OAL_INTR_IRQ_MAX at 64 because that is the maximum number of resources the
Resource Manager will support.

The real limitation for IRQ is 255. It shows up in the APIs that are used
with installable interrupt handlers. SYSINTRs are limited to 64 in CE6, 32
in CE5.

To get around this you would need to not use the Resource manager, and
clone/modify the interrupt code in the common tree.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"FoolBlah" <foolblah@discussions.microsoft.com> wrote in message
news:56516439-E0FF-4ECA-95C6-43112BE912FA@microsoft.com...
> You should probably have a look at this file...
>
> \WINCE600\PLATFORM\MAINSTONEIII\SRC\INC\intr_fpga.h
>
> The Mainstone III BSP does the same thing I am doing.
>
> It really is not that out of the ordinary. From my point of view the MAX
> is
> an indicator of the MAX number of IRQ sources on the 270 processor. So by
> offsetting by the MAX for platform specific IRQs you ensure that you do
> not
> accidentally map one of the primary 270 IRQ sources to the SYSINTR.
>
> Thanks.
>
> "Michel Verhagen (eMVP)" wrote:
>
>> So, you are basing your values of IRQ_BULVERDE_MAX, like
>> IRQ_BULVERDE_MAX + 1, IRQ_BULVERDE_MAX + 2, etc?
>>
>> That seems to be a strange thing to do anyway... IRQ_BULVERDE_MAX
>> clearly indicates it is a MAXIMUM value for IRQ's, so +1 is not the
>> right thing to do, or am I missing something?
>>
>>
>> Good luck,
>>
>> Michel Verhagen, eMVP
>> Check out my blog: http://GuruCE.com/blog
>>
>> GuruCE Ltd.
>> Microsoft Embedded Partner
>> http://GuruCE.com
>> Consultancy, training and development services.
>>
>> FoolBlah wrote:
>> > Hey all,
>> >
>> > I am porting a 270 based platform from CE 5.0 to CE 6.0 and have found
>> > a
>> > discrepancy with the defined value of IRQ_BULVERDE_MAX between the two
>> > versions. In CE 5.0 it is defined as follows...
>> >
>> > #define IRQ_BULVERDE_MAX IRQ_RTCALARM
>> >
>> > ....where IRQ_RTCALARM = 31.
>> >
>> > In CE 6.0 it is defined as follows...
>> >
>> > #define IRQ_BULVERDE_MAX 63 //icmr (32) + icmr2 (32)
>> >
>> > Is there a reason this was changed? I am defining additional platform
>> > specific IRQ values based off of the IRQ_BULVERDE_MAX value, but this
>> > paradigm is broken in CE 6.0 because the OALIntrStaticTranslate()
>> > routine
>> > (common lib, map.c) is comparing against the OAL_INTR_IRQ_MAXIMUM value
>> > which
>> > is defined as 64 for both versions. What this causes is the IRQ
>> > translation
>> > in CE 6.0 to be skipped because the compare fails, which in turn causes
>> > the
>> > SYSINTR to be mapped to the IRQ init value of -1 and then breaks IRQ
>> > dependent drivers.
>> >
>> > Obviously, I can manage to work around the issue, but I just wanted to
>> > get
>> > the reasoning behind the change to IRQ_BULVERDE_MAX.
>>