Re: location of CE's vector table
- From: gdj <gdj@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 17 Apr 2007 21:48:03 -0700
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@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0C6C8C14-608F-4690-B488-074D9B45F2A7@xxxxxxxxxxxxxxxx
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
- References:
- Re: location of CE's vector table
- From: Ross Jordan [MSFT]
- Re: location of CE's vector table
- From: Dean Ramsier
- Re: location of CE's vector table
- From: gdj
- Re: location of CE's vector table
- From: Dean Ramsier
- Re: location of CE's vector table
- From: gdj
- Re: location of CE's vector table
- From: Dean Ramsier
- Re: location of CE's vector table
- From: gdj
- Re: location of CE's vector table
- From: Dean Ramsier
- Re: location of CE's vector table
- From: Dean Ramsier
- Re: location of CE's vector table
- Prev by Date: Re: DrWatson kernel support
- Next by Date: Re: DrWatson kernel support
- Previous by thread: Re: location of CE's vector table
- Next by thread: Re: GIISR.DLL timestamp of module does not match timestamp of local mo
- Index(es):
Relevant Pages
|
