Re: HW registers shared by OAL and user-mode device driver
- From: "Michel Verhagen (eMVP)" <michel@xxxxxxxxxx>
- Date: Thu, 12 Jun 2008 19:08:19 +1200
Now you know why it is important to specify such information ;o)
Yes, I was talking about the new memory architecture in CE 6. Windows
Mobile 6 is indeed based on CE 5, so you need this link:
http://msdn.microsoft.com/en-us/library/ms836325.aspx (link is for CE
4.x but nothing changed till CE 6).
My apologies for the confusion I may have caused.
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.
Sung-Taek Lim wrote:
It seems like we are talking about different OS. I am working on.
Windows Mobile 6 which is based on Windows CE 5.0 kernel. You are
based on CE 6.0, right?
On 6월12일, 오전11시54분, "Michel Verhagen (eMVP)" <mic...@xxxxxxxxxx>
wrote:
You don't seem to quite understand it yet, let me try to explain:
A Kernel mode driver is a driver that is loaded by the device manager
(or GWES) inside the kernel mode process nk.exe in the kernel mode
address space (so the upper 2 GB of address space). In other words: a
kernel mode driver runs in the context of the one and only kernel
process; nk.exe
There is separate device manager process (device.exe besides gwes.exe)
which runs in user-mode. Therefore every driver loaded by device.exe
runs also in user-mode unless we force 'full-kernel mode' which is
prohibited by MS Logo test.
Drivers are loaded by the device manager as user mode drivers only if
the DEVFLAGS_LOAD_AS_USERMODE flag is set in the registry settings for
the driver. User mode drivers run in the lower 2GB address space in the
context of a user mode process and are therefore, with some exceptions,
restricted from calling kernel-only APIs and accessing kernel memory
There's no such flag and user-mode driver sees only 1 slot (32MB)
unless addition permission is given.
A stream interface driver (kernel mode driver -or- user mode driver) can
implement the XXX_IOControl function so applications (user mode) and
other drivers (user -or- kernel mode) can call into this driver using
DeviceIoControl (besides using the Write/Read/Seek system calls).
XXX_IOControl implemented by a stream interface driver cannot be
called from OAL.
The functions that can be called using KernelIoControl are NOT
implemented in a driver. They are implemented in the OAL.
The OAL is the "glue" between the core kernel functions and the
hardware. It is NOT a driver (although you can think of it as a "driver"
for core kernel functionality).
I know that and that is the reason why I had hard time to understand
the expression 'kernel-mode driver'.
Functions that you call with KernelIoControl are, as the name suggests,
always in kernel address space.
Memory architecture info can be found here:http://msdn.microsoft.com/en-us/library/bb331824.aspx
I hope it's all clear now...
Good luck,
Anyway, it is my fault that I did not specify exact OS. Thank you for
all your replies.
Michel Verhagen, eMVP
Check out my blog:http://GuruCE.com/blog
GuruCE Ltd.
Microsoft Embedded Partner
http://GuruCE.com
Consultancy, training and development services.
Sung-Taek Lim wrote:
Michel, I think the meaning of 'kernel mode driver' that you have said- 따온 텍스트 보기 -
and found between the articles of the blog you listed above just
conforms to what I am already understanding about 'kernel mode'.
And my assertion that 'kernel mode driver' == 'the functions called by
KernelIoControl' seems to be true here because those functions should
meet following conditions:
- OEM can implement them (to let them access GPIO registers)
- They can be called by both kernel code and user-mode driver code
On 6월10일, 오전11시14분, "Michel Verhagen (eMVP)" <mic...@xxxxxxxxxx>
wrote:
Browse through the posts here to gain a better understanding:http://blogs.msdn.com/ce_base/
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.
Sung-Taek Lim wrote:
Please forgive my ignorance. Then what are 'kernel mode drivers'?- 따온 텍스트 보기 -- 따온 텍스트 숨기기 -
Where can I get any information about them?
And I have additional question. Among OAL functions, some will run in
'process context' and some will run in 'interrupt context'.
I guess OEMIdle or OEMInterruptHandler will run in 'interrupt
context'. Those functions will not be preempted because all interrupts
are masked.
Did Microsoft document which OAL functions run in 'interrupt context'?
On 5월27일, 오후12시07분, "Michel Verhagen (eMVP)" <mic...@xxxxxxxxxx>
wrote:
No, KernelIoControl has nothing to do with kernel mode drivers.
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.
Sung-Taek Lim wrote:
On 5월24일, 오전7시48분, "Michel Verhagen (eMVP)" <mic...@xxxxxxxxxx> wrote:- 따온 텍스트 보기 -- 따온 텍스트 숨기기 -
Of course, if multiple processes access those functions a criticalDo you mean, by 'kernel mode driver', those functions called by
section won't do. A named Mutex would do the trick then.
IMHO you should write a kernel mode driver and serialize access using a
CRITICAL_SECTION. You can still use SetGPIO/ClearGPIO/etc functions but
those function will use the driver internally (so that all access is
serialized within the driver).
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.
KernelIoControl?
Luca Calligaris wrote:
I do not know how your code access the GPIO's: if you want to synchronize
the access you could write a library
with functions like SetGpio/ClearGpio/etc and protect that code with (for
example) critical sections. The problem
is that you would have to rewrite all the code to use those functions if you
want to sync correctly. A design similar
to the one I have just described is stubbed xllp_serialization.* in
%_WINCEROOT%\PLATFORM\COMMON\SRC\SOC\PXA27X_MS_V1\XLLP- 따온 텍스트 숨기기 -
- References:
- Re: HW registers shared by OAL and user-mode device driver
- From: Sung-Taek Lim
- Re: HW registers shared by OAL and user-mode device driver
- From: Michel Verhagen (eMVP)
- Re: HW registers shared by OAL and user-mode device driver
- From: Sung-Taek Lim
- Re: HW registers shared by OAL and user-mode device driver
- From: Michel Verhagen (eMVP)
- Re: HW registers shared by OAL and user-mode device driver
- From: Sung-Taek Lim
- Re: HW registers shared by OAL and user-mode device driver
- Prev by Date: Re: About kdbg and the interrupt
- Next by Date: Re: wince equivalent of jiffies_to_usecs(this is in linux 2.6)
- Previous by thread: Re: HW registers shared by OAL and user-mode device driver
- Next by thread: TLBMissHandler referenced :A migrating BSP from Wince500 to Wince600 Question?
- Index(es):
Relevant Pages
|
