Would someone kindly ask my following question ?

Usually MPUs support low end (0x0000_0000) vector table location, but
processors like some ARM processors support high end (0xFFFF_0000) vector
table location as well. It was said that the high end vector table location
is added for the requirement of OSs like CE. Must CE require this ? If a MPU
core only supports low end vector table location, what would happen to run CE
on it: CE can't work or there are some extra processing needed to do in CE so
reducing its performance, etc.

Thanks.

Re: location of CE's vector table by Ross

Ross
Fri Apr 06 18:17:47 CDT 2007

I asked our senior kernel developer and he said:

"It's not required if it doesn't require Virtual==Physical, and interrupt
vector corresponds to virtual address. Required otherwise."

-Ross

"gdj" <gdj@discussions.microsoft.com> wrote in message
news:403BF103-A4A9-4BC4-82A3-DA4273B1B1F6@microsoft.com...
> Would someone kindly ask my following question ?
>
> Usually MPUs support low end (0x0000_0000) vector table location, but
> processors like some ARM processors support high end (0xFFFF_0000) vector
> table location as well. It was said that the high end vector table
> location
> is added for the requirement of OSs like CE. Must CE require this ? If a
> MPU
> core only supports low end vector table location, what would happen to run
> CE
> on it: CE can't work or there are some extra processing needed to do in CE
> so
> reducing its performance, etc.
>
> Thanks.
>


Re: location of CE's vector table by gdj

gdj
Fri Apr 06 19:22:00 CDT 2007

Hello, Ross,

Thank you very much for your kindness and the quick reply.

Please allow me confirm my understanding:

CE uses the interrupt vector table at high-end (0xFFFF_0000) in virtual
address space. If there is MMU to perform Physical to Virtual address
mapping. It doesn't care where the actual location of the physical interrupt
vector table is. However, if there is no such kind of address space
transform, a support of the physical high-end(0xFFFF_0000) location of
interrupt vector table is required. Is this right ?

Thanks & regards.
gdj

"Ross Jordan [MSFT]" wrote:

> I asked our senior kernel developer and he said:
>
> "It's not required if it doesn't require Virtual==Physical, and interrupt
> vector corresponds to virtual address. Required otherwise."
>
> -Ross
>
> "gdj" <gdj@discussions.microsoft.com> wrote in message
> news:403BF103-A4A9-4BC4-82A3-DA4273B1B1F6@microsoft.com...
> > Would someone kindly ask my following question ?
> >
> > Usually MPUs support low end (0x0000_0000) vector table location, but
> > processors like some ARM processors support high end (0xFFFF_0000) vector
> > table location as well. It was said that the high end vector table
> > location
> > is added for the requirement of OSs like CE. Must CE require this ? If a
> > MPU
> > core only supports low end vector table location, what would happen to run
> > CE
> > on it: CE can't work or there are some extra processing needed to do in CE
> > so
> > reducing its performance, etc.
> >
> > Thanks.
> >
>
>

Re: location of CE's vector table by Dean

Dean
Mon Apr 09 08:34:48 CDT 2007

You MUST have an MMU. If you don't have one, you can't run CE. Moreover,
the cpu must be compatible with on of the supported types (ARM, MIPS, SH,
X86 etc). The interrupt vector table relocation is the least of your
problems.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"gdj" <gdj@discussions.microsoft.com> wrote in message
news:1B0F1850-E54C-44DB-8EFA-6FCC8E16CBB9@microsoft.com...
> Hello, Ross,
>
> Thank you very much for your kindness and the quick reply.
>
> Please allow me confirm my understanding:
>
> CE uses the interrupt vector table at high-end (0xFFFF_0000) in virtual
> address space. If there is MMU to perform Physical to Virtual address
> mapping. It doesn't care where the actual location of the physical
> interrupt
> vector table is. However, if there is no such kind of address space
> transform, a support of the physical high-end(0xFFFF_0000) location of
> interrupt vector table is required. Is this right ?
>
> Thanks & regards.
> gdj
>
> "Ross Jordan [MSFT]" wrote:
>
>> I asked our senior kernel developer and he said:
>>
>> "It's not required if it doesn't require Virtual==Physical, and interrupt
>> vector corresponds to virtual address. Required otherwise."
>>
>> -Ross
>>
>> "gdj" <gdj@discussions.microsoft.com> wrote in message
>> news:403BF103-A4A9-4BC4-82A3-DA4273B1B1F6@microsoft.com...
>> > Would someone kindly ask my following question ?
>> >
>> > Usually MPUs support low end (0x0000_0000) vector table location, but
>> > processors like some ARM processors support high end (0xFFFF_0000)
>> > vector
>> > table location as well. It was said that the high end vector table
>> > location
>> > is added for the requirement of OSs like CE. Must CE require this ? If
>> > a
>> > MPU
>> > core only supports low end vector table location, what would happen to
>> > run
>> > CE
>> > on it: CE can't work or there are some extra processing needed to do in
>> > CE
>> > so
>> > reducing its performance, etc.
>> >
>> > Thanks.
>> >
>>
>>



Re: location of CE's vector table by gdj

gdj
Mon Apr 09 10:06:03 CDT 2007

Hello, Dean,

Thank you for your comment.

I asked this question because we are developing an ARM type processor on
which windows CE is the target OS. The original specification of the ARM
processor support the high-end location (0xFFFF_0000) of interrupt vector
table as well as ordinary low-end location(0x0000_0000). Our hardware design
engineer want to support the low-end location only. However, we need to know
how does this influence the windows CE.

If there is an MMU and windows CE doesn't require high-end location of
interrupt vector table (Physical address != Virtual address), I am puzzled
why the ARM processors (such as ARM926EJ-S, etc.) provide the high-end
location support as an option although it was said for windows CE. It will be
very kind of you if you could give a little more explanation on this.

Thanks & regards.
-gdj

"Dean Ramsier" wrote:

> You MUST have an MMU. If you don't have one, you can't run CE. Moreover,
> the cpu must be compatible with on of the supported types (ARM, MIPS, SH,
> X86 etc). The interrupt vector table relocation is the least of your
> problems.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "gdj" <gdj@discussions.microsoft.com> wrote in message
> news:1B0F1850-E54C-44DB-8EFA-6FCC8E16CBB9@microsoft.com...
> > Hello, Ross,
> >
> > Thank you very much for your kindness and the quick reply.
> >
> > Please allow me confirm my understanding:
> >
> > CE uses the interrupt vector table at high-end (0xFFFF_0000) in virtual
> > address space. If there is MMU to perform Physical to Virtual address
> > mapping. It doesn't care where the actual location of the physical
> > interrupt
> > vector table is. However, if there is no such kind of address space
> > transform, a support of the physical high-end(0xFFFF_0000) location of
> > interrupt vector table is required. Is this right ?
> >
> > Thanks & regards.
> > gdj
> >
> > "Ross Jordan [MSFT]" wrote:
> >
> >> I asked our senior kernel developer and he said:
> >>
> >> "It's not required if it doesn't require Virtual==Physical, and interrupt
> >> vector corresponds to virtual address. Required otherwise."
> >>
> >> -Ross
> >>
> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
> >> news:403BF103-A4A9-4BC4-82A3-DA4273B1B1F6@microsoft.com...
> >> > Would someone kindly ask my following question ?
> >> >
> >> > Usually MPUs support low end (0x0000_0000) vector table location, but
> >> > processors like some ARM processors support high end (0xFFFF_0000)
> >> > vector
> >> > table location as well. It was said that the high end vector table
> >> > location
> >> > is added for the requirement of OSs like CE. Must CE require this ? If
> >> > a
> >> > MPU
> >> > core only supports low end vector table location, what would happen to
> >> > run
> >> > CE
> >> > on it: CE can't work or there are some extra processing needed to do in
> >> > CE
> >> > so
> >> > reducing its performance, etc.
> >> >
> >> > Thanks.
> >> >
> >>
> >>
>
>
>

Re: location of CE's vector table by Dean

Dean
Mon Apr 09 10:26:52 CDT 2007

It isn't an option.

WindowsCE requires that the exception vectors for ARM be located at virtual
address 0xffff0000. The CPU design dictates what the cpu does when an
exception occurs, but it must be coherent with the software expectations.
When an exception occurs, the cpu must vector to whatever memory corresponds
to this virtual address. If you're going to only support one address range,
then pick the high one because it is required.

Also, don't think that you have the option of deviating from the basic ARM
specifications. The kernel is provided by MS, and that component does all
the low level core configuration/accesses. If your cpu isn't compatible
with the ARM basic specifications then it won't be compatible with the
Windows CE kernel code.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"gdj" <gdj@discussions.microsoft.com> wrote in message
news:A10872E5-A495-44D4-9653-9AB1B3928CFF@microsoft.com...
> Hello, Dean,
>
> Thank you for your comment.
>
> I asked this question because we are developing an ARM type processor on
> which windows CE is the target OS. The original specification of the ARM
> processor support the high-end location (0xFFFF_0000) of interrupt vector
> table as well as ordinary low-end location(0x0000_0000). Our hardware
> design
> engineer want to support the low-end location only. However, we need to
> know
> how does this influence the windows CE.
>
> If there is an MMU and windows CE doesn't require high-end location of
> interrupt vector table (Physical address != Virtual address), I am puzzled
> why the ARM processors (such as ARM926EJ-S, etc.) provide the high-end
> location support as an option although it was said for windows CE. It will
> be
> very kind of you if you could give a little more explanation on this.
>
> Thanks & regards.
> -gdj
>
> "Dean Ramsier" wrote:
>
>> You MUST have an MMU. If you don't have one, you can't run CE.
>> Moreover,
>> the cpu must be compatible with on of the supported types (ARM, MIPS, SH,
>> X86 etc). The interrupt vector table relocation is the least of your
>> problems.
>>
>> --
>> Dean Ramsier - eMVP
>> BSQUARE Corporation
>>
>>
>> "gdj" <gdj@discussions.microsoft.com> wrote in message
>> news:1B0F1850-E54C-44DB-8EFA-6FCC8E16CBB9@microsoft.com...
>> > Hello, Ross,
>> >
>> > Thank you very much for your kindness and the quick reply.
>> >
>> > Please allow me confirm my understanding:
>> >
>> > CE uses the interrupt vector table at high-end (0xFFFF_0000) in virtual
>> > address space. If there is MMU to perform Physical to Virtual address
>> > mapping. It doesn't care where the actual location of the physical
>> > interrupt
>> > vector table is. However, if there is no such kind of address space
>> > transform, a support of the physical high-end(0xFFFF_0000) location of
>> > interrupt vector table is required. Is this right ?
>> >
>> > Thanks & regards.
>> > gdj
>> >
>> > "Ross Jordan [MSFT]" wrote:
>> >
>> >> I asked our senior kernel developer and he said:
>> >>
>> >> "It's not required if it doesn't require Virtual==Physical, and
>> >> interrupt
>> >> vector corresponds to virtual address. Required otherwise."
>> >>
>> >> -Ross
>> >>
>> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
>> >> news:403BF103-A4A9-4BC4-82A3-DA4273B1B1F6@microsoft.com...
>> >> > Would someone kindly ask my following question ?
>> >> >
>> >> > Usually MPUs support low end (0x0000_0000) vector table location,
>> >> > but
>> >> > processors like some ARM processors support high end (0xFFFF_0000)
>> >> > vector
>> >> > table location as well. It was said that the high end vector table
>> >> > location
>> >> > is added for the requirement of OSs like CE. Must CE require this ?
>> >> > If
>> >> > a
>> >> > MPU
>> >> > core only supports low end vector table location, what would happen
>> >> > to
>> >> > run
>> >> > CE
>> >> > on it: CE can't work or there are some extra processing needed to do
>> >> > in
>> >> > CE
>> >> > so
>> >> > reducing its performance, etc.
>> >> >
>> >> > Thanks.
>> >> >
>> >>
>> >>
>>
>>
>>



Re: location of CE's vector table by gdj

gdj
Wed Apr 11 01:54:00 CDT 2007

Hello, Dean,

You are very appreciated for your detail explanation.

I am sorry that I don't clearly understand yet. According to Ross's reply,
CE only requires high-end (0XFFFF_0000) interrupt vector table at virtual
address space where it doesn't require (physical) high-end interrupt vactor
table location if there is an MMU to do the address space mapping (Note: this
is my understanding from Ross's reply). But according to your comments, it
seems that a high-end location is necessary for running CE on an ARM
processor. I wonder if this applies to other kinds of processors also. Please
tell me the points.

Thanks & regards.
-gdj

"Dean Ramsier" wrote:

> It isn't an option.
>
> WindowsCE requires that the exception vectors for ARM be located at virtual
> address 0xffff0000. The CPU design dictates what the cpu does when an
> exception occurs, but it must be coherent with the software expectations.
> When an exception occurs, the cpu must vector to whatever memory corresponds
> to this virtual address. If you're going to only support one address range,
> then pick the high one because it is required.
>
> Also, don't think that you have the option of deviating from the basic ARM
> specifications. The kernel is provided by MS, and that component does all
> the low level core configuration/accesses. If your cpu isn't compatible
> with the ARM basic specifications then it won't be compatible with the
> Windows CE kernel code.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "gdj" <gdj@discussions.microsoft.com> wrote in message
> news:A10872E5-A495-44D4-9653-9AB1B3928CFF@microsoft.com...
> > Hello, Dean,
> >
> > Thank you for your comment.
> >
> > I asked this question because we are developing an ARM type processor on
> > which windows CE is the target OS. The original specification of the ARM
> > processor support the high-end location (0xFFFF_0000) of interrupt vector
> > table as well as ordinary low-end location(0x0000_0000). Our hardware
> > design
> > engineer want to support the low-end location only. However, we need to
> > know
> > how does this influence the windows CE.
> >
> > If there is an MMU and windows CE doesn't require high-end location of
> > interrupt vector table (Physical address != Virtual address), I am puzzled
> > why the ARM processors (such as ARM926EJ-S, etc.) provide the high-end
> > location support as an option although it was said for windows CE. It will
> > be
> > very kind of you if you could give a little more explanation on this.
> >
> > Thanks & regards.
> > -gdj
> >
> > "Dean Ramsier" wrote:
> >
> >> You MUST have an MMU. If you don't have one, you can't run CE.
> >> Moreover,
> >> the cpu must be compatible with on of the supported types (ARM, MIPS, SH,
> >> X86 etc). The interrupt vector table relocation is the least of your
> >> problems.
> >>
> >> --
> >> Dean Ramsier - eMVP
> >> BSQUARE Corporation
> >>
> >>
> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
> >> news:1B0F1850-E54C-44DB-8EFA-6FCC8E16CBB9@microsoft.com...
> >> > Hello, Ross,
> >> >
> >> > Thank you very much for your kindness and the quick reply.
> >> >
> >> > Please allow me confirm my understanding:
> >> >
> >> > CE uses the interrupt vector table at high-end (0xFFFF_0000) in virtual
> >> > address space. If there is MMU to perform Physical to Virtual address
> >> > mapping. It doesn't care where the actual location of the physical
> >> > interrupt
> >> > vector table is. However, if there is no such kind of address space
> >> > transform, a support of the physical high-end(0xFFFF_0000) location of
> >> > interrupt vector table is required. Is this right ?
> >> >
> >> > Thanks & regards.
> >> > gdj
> >> >
> >> > "Ross Jordan [MSFT]" wrote:
> >> >
> >> >> I asked our senior kernel developer and he said:
> >> >>
> >> >> "It's not required if it doesn't require Virtual==Physical, and
> >> >> interrupt
> >> >> vector corresponds to virtual address. Required otherwise."
> >> >>
> >> >> -Ross
> >> >>
> >> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
> >> >> news:403BF103-A4A9-4BC4-82A3-DA4273B1B1F6@microsoft.com...
> >> >> > Would someone kindly ask my following question ?
> >> >> >
> >> >> > Usually MPUs support low end (0x0000_0000) vector table location,
> >> >> > but
> >> >> > processors like some ARM processors support high end (0xFFFF_0000)
> >> >> > vector
> >> >> > table location as well. It was said that the high end vector table
> >> >> > location
> >> >> > is added for the requirement of OSs like CE. Must CE require this ?
> >> >> > If
> >> >> > a
> >> >> > MPU
> >> >> > core only supports low end vector table location, what would happen
> >> >> > to
> >> >> > run
> >> >> > CE
> >> >> > on it: CE can't work or there are some extra processing needed to do
> >> >> > in
> >> >> > CE
> >> >> > so
> >> >> > reducing its performance, etc.
> >> >> >
> >> >> > Thanks.
> >> >> >
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

Re: location of CE's vector table by Dean

Dean
Wed Apr 11 09:02:52 CDT 2007

I'm not sure exactly what the person who provided a response to Ross meant
either, because it doesn't make sense. My guess is it was a theoretical
response based on misunderstanding the question. At the end of the day, CE
requires that the interrupt vectors be at 0xffff0000 and there isn't
anything you can do about it unless you rewrite the CE kernel.

Each processor architecture has it's own requirements, I'm only familiar
with ARM. The bottom line is that CE supports 4 architectures, and those
architectures are well defined. If you want to design a processor that will
support CE, then your processor must match one of those specifications. And
that probably means licensing a core from someone, not designing your own...

--
Dean Ramsier - eMVP
BSQUARE Corporation


"gdj" <gdj@discussions.microsoft.com> wrote in message
news:E933F58A-6517-45F3-A265-296F13AFB527@microsoft.com...
> Hello, Dean,
>
> You are very appreciated for your detail explanation.
>
> I am sorry that I don't clearly understand yet. According to Ross's reply,
> CE only requires high-end (0XFFFF_0000) interrupt vector table at virtual
> address space where it doesn't require (physical) high-end interrupt
> vactor
> table location if there is an MMU to do the address space mapping (Note:
> this
> is my understanding from Ross's reply). But according to your comments, it
> seems that a high-end location is necessary for running CE on an ARM
> processor. I wonder if this applies to other kinds of processors also.
> Please
> tell me the points.
>
> Thanks & regards.
> -gdj
>
> "Dean Ramsier" wrote:
>
>> It isn't an option.
>>
>> WindowsCE requires that the exception vectors for ARM be located at
>> virtual
>> address 0xffff0000. The CPU design dictates what the cpu does when an
>> exception occurs, but it must be coherent with the software expectations.
>> When an exception occurs, the cpu must vector to whatever memory
>> corresponds
>> to this virtual address. If you're going to only support one address
>> range,
>> then pick the high one because it is required.
>>
>> Also, don't think that you have the option of deviating from the basic
>> ARM
>> specifications. The kernel is provided by MS, and that component does
>> all
>> the low level core configuration/accesses. If your cpu isn't compatible
>> with the ARM basic specifications then it won't be compatible with the
>> Windows CE kernel code.
>>
>> --
>> Dean Ramsier - eMVP
>> BSQUARE Corporation
>>
>>
>> "gdj" <gdj@discussions.microsoft.com> wrote in message
>> news:A10872E5-A495-44D4-9653-9AB1B3928CFF@microsoft.com...
>> > Hello, Dean,
>> >
>> > Thank you for your comment.
>> >
>> > I asked this question because we are developing an ARM type processor
>> > on
>> > which windows CE is the target OS. The original specification of the
>> > ARM
>> > processor support the high-end location (0xFFFF_0000) of interrupt
>> > vector
>> > table as well as ordinary low-end location(0x0000_0000). Our hardware
>> > design
>> > engineer want to support the low-end location only. However, we need to
>> > know
>> > how does this influence the windows CE.
>> >
>> > If there is an MMU and windows CE doesn't require high-end location of
>> > interrupt vector table (Physical address != Virtual address), I am
>> > puzzled
>> > why the ARM processors (such as ARM926EJ-S, etc.) provide the high-end
>> > location support as an option although it was said for windows CE. It
>> > will
>> > be
>> > very kind of you if you could give a little more explanation on this.
>> >
>> > Thanks & regards.
>> > -gdj
>> >
>> > "Dean Ramsier" wrote:
>> >
>> >> You MUST have an MMU. If you don't have one, you can't run CE.
>> >> Moreover,
>> >> the cpu must be compatible with on of the supported types (ARM, MIPS,
>> >> SH,
>> >> X86 etc). The interrupt vector table relocation is the least of your
>> >> problems.
>> >>
>> >> --
>> >> Dean Ramsier - eMVP
>> >> BSQUARE Corporation
>> >>
>> >>
>> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
>> >> news:1B0F1850-E54C-44DB-8EFA-6FCC8E16CBB9@microsoft.com...
>> >> > Hello, Ross,
>> >> >
>> >> > Thank you very much for your kindness and the quick reply.
>> >> >
>> >> > Please allow me confirm my understanding:
>> >> >
>> >> > CE uses the interrupt vector table at high-end (0xFFFF_0000) in
>> >> > virtual
>> >> > address space. If there is MMU to perform Physical to Virtual
>> >> > address
>> >> > mapping. It doesn't care where the actual location of the physical
>> >> > interrupt
>> >> > vector table is. However, if there is no such kind of address space
>> >> > transform, a support of the physical high-end(0xFFFF_0000) location
>> >> > of
>> >> > interrupt vector table is required. Is this right ?
>> >> >
>> >> > Thanks & regards.
>> >> > gdj
>> >> >
>> >> > "Ross Jordan [MSFT]" wrote:
>> >> >
>> >> >> I asked our senior kernel developer and he said:
>> >> >>
>> >> >> "It's not required if it doesn't require Virtual==Physical, and
>> >> >> interrupt
>> >> >> vector corresponds to virtual address. Required otherwise."
>> >> >>
>> >> >> -Ross
>> >> >>
>> >> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
>> >> >> news:403BF103-A4A9-4BC4-82A3-DA4273B1B1F6@microsoft.com...
>> >> >> > Would someone kindly ask my following question ?
>> >> >> >
>> >> >> > Usually MPUs support low end (0x0000_0000) vector table location,
>> >> >> > but
>> >> >> > processors like some ARM processors support high end
>> >> >> > (0xFFFF_0000)
>> >> >> > vector
>> >> >> > table location as well. It was said that the high end vector
>> >> >> > table
>> >> >> > location
>> >> >> > is added for the requirement of OSs like CE. Must CE require this
>> >> >> > ?
>> >> >> > If
>> >> >> > a
>> >> >> > MPU
>> >> >> > core only supports low end vector table location, what would
>> >> >> > happen
>> >> >> > to
>> >> >> > run
>> >> >> > CE
>> >> >> > on it: CE can't work or there are some extra processing needed to
>> >> >> > do
>> >> >> > in
>> >> >> > CE
>> >> >> > so
>> >> >> > reducing its performance, etc.
>> >> >> >
>> >> >> > Thanks.
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>



Re: location of CE's vector table by gdj

gdj
Thu Apr 12 18:12:01 CDT 2007

Hi, Dean,

It's nice to discuss with you as you are familiar with both ARM and CE.

CE uses 0xFFFF_0000 virtual address as interruption vector table. If the OAL
(OEM Adaptation Layer) deals right MMU address mapping, CE kernel doesn't
require the physical 0xFFFF_0000 interruption vector table. This sounds
reasonable theoretically.

You said 0xFFFF_0000 is not an option to ARM processor, do you mean the
windows CE kernel has used this 0xFFFF_0000 as a must condition which can't
be solved by the OAL customerization ?

Our hardware engineer said some semiconductor ventors (Summsang ?) has
successfully manufactured the ARM processor which support windows CE but with
only low-end (0x0000_0000) interrupt vector table. Is this a truly fact ?

-gdj


"Dean Ramsier" wrote:

> I'm not sure exactly what the person who provided a response to Ross meant
> either, because it doesn't make sense. My guess is it was a theoretical
> response based on misunderstanding the question. At the end of the day, CE
> requires that the interrupt vectors be at 0xffff0000 and there isn't
> anything you can do about it unless you rewrite the CE kernel.
>
> Each processor architecture has it's own requirements, I'm only familiar
> with ARM. The bottom line is that CE supports 4 architectures, and those
> architectures are well defined. If you want to design a processor that will
> support CE, then your processor must match one of those specifications. And
> that probably means licensing a core from someone, not designing your own...
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "gdj" <gdj@discussions.microsoft.com> wrote in message
> news:E933F58A-6517-45F3-A265-296F13AFB527@microsoft.com...
> > Hello, Dean,
> >
> > You are very appreciated for your detail explanation.
> >
> > I am sorry that I don't clearly understand yet. According to Ross's reply,
> > CE only requires high-end (0XFFFF_0000) interrupt vector table at virtual
> > address space where it doesn't require (physical) high-end interrupt
> > vactor
> > table location if there is an MMU to do the address space mapping (Note:
> > this
> > is my understanding from Ross's reply). But according to your comments, it
> > seems that a high-end location is necessary for running CE on an ARM
> > processor. I wonder if this applies to other kinds of processors also.
> > Please
> > tell me the points.
> >
> > Thanks & regards.
> > -gdj
> >
> > "Dean Ramsier" wrote:
> >
> >> It isn't an option.
> >>
> >> WindowsCE requires that the exception vectors for ARM be located at
> >> virtual
> >> address 0xffff0000. The CPU design dictates what the cpu does when an
> >> exception occurs, but it must be coherent with the software expectations.
> >> When an exception occurs, the cpu must vector to whatever memory
> >> corresponds
> >> to this virtual address. If you're going to only support one address
> >> range,
> >> then pick the high one because it is required.
> >>
> >> Also, don't think that you have the option of deviating from the basic
> >> ARM
> >> specifications. The kernel is provided by MS, and that component does
> >> all
> >> the low level core configuration/accesses. If your cpu isn't compatible
> >> with the ARM basic specifications then it won't be compatible with the
> >> Windows CE kernel code.
> >>
> >> --
> >> Dean Ramsier - eMVP
> >> BSQUARE Corporation
> >>
> >>
> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
> >> news:A10872E5-A495-44D4-9653-9AB1B3928CFF@microsoft.com...
> >> > Hello, Dean,
> >> >
> >> > Thank you for your comment.
> >> >
> >> > I asked this question because we are developing an ARM type processor
> >> > on
> >> > which windows CE is the target OS. The original specification of the
> >> > ARM
> >> > processor support the high-end location (0xFFFF_0000) of interrupt
> >> > vector
> >> > table as well as ordinary low-end location(0x0000_0000). Our hardware
> >> > design
> >> > engineer want to support the low-end location only. However, we need to
> >> > know
> >> > how does this influence the windows CE.
> >> >
> >> > If there is an MMU and windows CE doesn't require high-end location of
> >> > interrupt vector table (Physical address != Virtual address), I am
> >> > puzzled
> >> > why the ARM processors (such as ARM926EJ-S, etc.) provide the high-end
> >> > location support as an option although it was said for windows CE. It
> >> > will
> >> > be
> >> > very kind of you if you could give a little more explanation on this.
> >> >
> >> > Thanks & regards.
> >> > -gdj
> >> >
> >> > "Dean Ramsier" wrote:
> >> >
> >> >> You MUST have an MMU. If you don't have one, you can't run CE.
> >> >> Moreover,
> >> >> the cpu must be compatible with on of the supported types (ARM, MIPS,
> >> >> SH,
> >> >> X86 etc). The interrupt vector table relocation is the least of your
> >> >> problems.
> >> >>
> >> >> --
> >> >> Dean Ramsier - eMVP
> >> >> BSQUARE Corporation
> >> >>
> >> >>
> >> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
> >> >> news:1B0F1850-E54C-44DB-8EFA-6FCC8E16CBB9@microsoft.com...
> >> >> > Hello, Ross,
> >> >> >
> >> >> > Thank you very much for your kindness and the quick reply.
> >> >> >
> >> >> > Please allow me confirm my understanding:
> >> >> >
> >> >> > CE uses the interrupt vector table at high-end (0xFFFF_0000) in
> >> >> > virtual
> >> >> > address space. If there is MMU to perform Physical to Virtual
> >> >> > address
> >> >> > mapping. It doesn't care where the actual location of the physical
> >> >> > interrupt
> >> >> > vector table is. However, if there is no such kind of address space
> >> >> > transform, a support of the physical high-end(0xFFFF_0000) location
> >> >> > of
> >> >> > interrupt vector table is required. Is this right ?
> >> >> >
> >> >> > Thanks & regards.
> >> >> > gdj
> >> >> >
> >> >> > "Ross Jordan [MSFT]" wrote:
> >> >> >
> >> >> >> I asked our senior kernel developer and he said:
> >> >> >>
> >> >> >> "It's not required if it doesn't require Virtual==Physical, and
> >> >> >> interrupt
> >> >> >> vector corresponds to virtual address. Required otherwise."
> >> >> >>
> >> >> >> -Ross
> >> >> >>
> >> >> >> "gdj" <gdj@discussions.microsoft.com> wrote in message
> >> >> >> news:403BF103-A4A9-4BC4-82A3-DA4273B1B1F6@microsoft.com...
> >> >> >> > Would someone kindly ask my following question ?
> >> >> >> >
> >> >> >> > Usually MPUs support low end (0x0000_0000) vector table location,
> >> >> >> > but
> >> >> >> > processors like some ARM processors support high end
> >> >> >> > (0xFFFF_0000)
> >> >> >> > vector
> >> >> >> > table location as well. It was said that the high end vector
> >> >> >> > table
> >> >> >> > location
> >> >> >> > is added for the requirement of OSs like CE. Must CE require this
> >> >> >> > ?
> >> >> >> > If
> >> >> >> > a
> >> >> >> > MPU
> >> >> >> > core only supports low end vector table location, what would
> >> >> >> > happen
> >> >> >> > to
> >> >> >> > run
> >> >> >> > CE
> >> >> >> > on it: CE can't work or there are some extra processing needed to
> >> >> >> > do
> >> >> >> > in
> >> >> >> > CE
> >> >> >> > so
> >> >> >> > reducing its performance, etc.
> >> >> >> >
> >> >> >> > Thanks.
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

Re: location of CE's vector table by Dean

Dean
Fri Apr 13 09:04:26 CDT 2007

> You said 0xFFFF_0000 is not an option to ARM processor, do you mean the
> windows CE kernel has used this 0xFFFF_0000 as a must condition which
> can't
> be solved by the OAL customerization ?

Correct. The interrupt vector table is hardcoded at the 0xFFFF0000 address,
and you can't change this without modifying the private code. Even if you
did, I don't think you could move it 0x0000000 because the OS has other uses
for that address range. For one, it is in the user mode area and two the OS
configures that area to generate an exception on access. You'd have to
rewrite a ton of private code, if it's even possible.

> Our hardware engineer said some semiconductor ventors (Summsang ?) has
> successfully manufactured the ARM processor which support windows CE but
> with
> only low-end (0x0000_0000) interrupt vector table. Is this a truly fact ?

I have no idea.

--
Dean Ramsier - eMVP
BSQUARE Corporation



Re: location of CE's vector table by gdj

gdj
Sat Apr 14 02:34:00 CDT 2007

Hi, Dean,

I noticed that you answered Jesse's question 'where is exception table ...'
on 4/9 that 0xFFFF0000 is an virtual address so that any physical address can
be mapped to it with MMU. Suppose a processor with MMU such as ARM926EJ-S
only supports interrupt vector table at physical address 0x00000000, if this
address is mapped to 0xFFFF0000 in the OAL porting, doesn't this solve the
problem ?

If this could be true, it seems that not much more private code need to be
rewritten, and there seems no enough reasons for ARM corporation to add
high-end (0XFFFF0000) location of vector table just for windows CE. But the
fact is they did.

With best regards.
-gdj


"Dean Ramsier" wrote:

> > You said 0xFFFF_0000 is not an option to ARM processor, do you mean the
> > windows CE kernel has used this 0xFFFF_0000 as a must condition which
> > can't
> > be solved by the OAL customerization ?
>
> Correct. The interrupt vector table is hardcoded at the 0xFFFF0000 address,
> and you can't change this without modifying the private code. Even if you
> did, I don't think you could move it 0x0000000 because the OS has other uses
> for that address range. For one, it is in the user mode area and two the OS
> configures that area to generate an exception on access. You'd have to
> rewrite a ton of private code, if it's even possible.
>
> > Our hardware engineer said some semiconductor ventors (Summsang ?) has
> > successfully manufactured the ARM processor which support windows CE but
> > with
> > only low-end (0x0000_0000) interrupt vector table. Is this a truly fact ?
>
> I have no idea.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
>

Re: location of CE's vector table by Dean

Dean
Mon Apr 16 08:39:30 CDT 2007

You don't have the opportunity to map the 0xFFFF0000 range as an OEM, MS
owns that area. Also, the memory around that address is also used - you
can't just map it to flash at the reset vector.

There may be ways to get something like this to work, I haven't given it all
that much thought. The point is it's not supported - your CPU has to be
compatible with one of the supported CE architectures, and the reset vector
at 0xFFFF0000 is one of the requirements for ARM.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"gdj" <gdj@discussions.microsoft.com> wrote in message
news:0C6C8C14-608F-4690-B488-074D9B45F2A7@microsoft.com...
> Hi, Dean,
>
> I noticed that you answered Jesse's question 'where is exception table
> ...'
> on 4/9 that 0xFFFF0000 is an virtual address so that any physical address
> can
> be mapped to it with MMU. Suppose a processor with MMU such as ARM926EJ-S
> only supports interrupt vector table at physical address 0x00000000, if
> this
> address is mapped to 0xFFFF0000 in the OAL porting, doesn't this solve the
> problem ?
>
> If this could be true, it seems that not much more private code need to be
> rewritten, and there seems no enough reasons for ARM corporation to add
> high-end (0XFFFF0000) location of vector table just for windows CE. But
> the
> fact is they did.
>
> With best regards.
> -gdj
>
>
> "Dean Ramsier" wrote:
>
>> > You said 0xFFFF_0000 is not an option to ARM processor, do you mean the
>> > windows CE kernel has used this 0xFFFF_0000 as a must condition which
>> > can't
>> > be solved by the OAL customerization ?
>>
>> Correct. The interrupt vector table is hardcoded at the 0xFFFF0000
>> address,
>> and you can't change this without modifying the private code. Even if
>> you
>> did, I don't think you could move it 0x0000000 because the OS has other
>> uses
>> for that address range. For one, it is in the user mode area and two the
>> OS
>> configures that area to generate an exception on access. You'd have to
>> rewrite a ton of private code, if it's even possible.
>>
>> > Our hardware engineer said some semiconductor ventors (Summsang ?) has
>> > successfully manufactured the ARM processor which support windows CE
>> > but
>> > with
>> > only low-end (0x0000_0000) interrupt vector table. Is this a truly fact
>> > ?
>>
>> I have no idea.
>>
>> --
>> Dean Ramsier - eMVP
>> BSQUARE Corporation
>>
>>
>>



Re: location of CE's vector table by gdj

gdj
Tue Apr 17 23:48:03 CDT 2007

I understood that the standard windows CE kernel cann't be adapted easily to
support a low-end interrupt processor. I don't know if it is possible to map
one whole page of virtual address space including 0xFFFF0000 to the one
including the reset vector in the physical address space and causes no other
conflicts in standard CE kernel.

"Dean Ramsier" wrote:

> You don't have the opportunity to map the 0xFFFF0000 range as an OEM, MS
> owns that area. Also, the memory around that address is also used - you
> can't just map it to flash at the reset vector.
>
> There may be ways to get something like this to work, I haven't given it all
> that much thought. The point is it's not supported - your CPU has to be
> compatible with one of the supported CE architectures, and the reset vector
> at 0xFFFF0000 is one of the requirements for ARM.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "gdj" <gdj@discussions.microsoft.com> wrote in message
> news:0C6C8C14-608F-4690-B488-074D9B45F2A7@microsoft.com...
> > Hi, Dean,
> >
> > I noticed that you answered Jesse's question 'where is exception table
> > ...'
> > on 4/9 that 0xFFFF0000 is an virtual address so that any physical address
> > can
> > be mapped to it with MMU. Suppose a processor with MMU such as ARM926EJ-S
> > only supports interrupt vector table at physical address 0x00000000, if
> > this
> > address is mapped to 0xFFFF0000 in the OAL porting, doesn't this solve the
> > problem ?
> >
> > If this could be true, it seems that not much more private code need to be
> > rewritten, and there seems no enough reasons for ARM corporation to add
> > high-end (0XFFFF0000) location of vector table just for windows CE. But
> > the
> > fact is they did.
> >
> > With best regards.
> > -gdj
> >
> >
> > "Dean Ramsier" wrote:
> >
> >> > You said 0xFFFF_0000 is not an option to ARM processor, do you mean the
> >> > windows CE kernel has used this 0xFFFF_0000 as a must condition which
> >> > can't
> >> > be solved by the OAL customerization ?
> >>
> >> Correct. The interrupt vector table is hardcoded at the 0xFFFF0000
> >> address,
> >> and you can't change this without modifying the private code. Even if
> >> you
> >> did, I don't think you could move it 0x0000000 because the OS has other
> >> uses
> >> for that address range. For one, it is in the user mode area and two the
> >> OS
> >> configures that area to generate an exception on access. You'd have to
> >> rewrite a ton of private code, if it's even possible.
> >>
> >> > Our hardware engineer said some semiconductor ventors (Summsang ?) has
> >> > successfully manufactured the ARM processor which support windows CE
> >> > but
> >> > with
> >> > only low-end (0x0000_0000) interrupt vector table. Is this a truly fact
> >> > ?
> >>
> >> I have no idea.
> >>
> >> --
> >> Dean Ramsier - eMVP
> >> BSQUARE Corporation
> >>
> >>
> >>
>
>
>