Re: VMINI driver
- From: Valter Minute <v_a_l_t_e_r.m_i_n_u_t_e@xxxxxxxxxxxxx>
- Date: Wed, 09 Aug 2006 07:28:19 -0700
Ulrich Eckhardt <eckhardt@xxxxxxxxxxxxxx> wrote in
news:vc1pq3-6l1.ln1@xxxxxxxxxxxxxxxxxxxxxx:
[...]
As suggested, I'm now trying to integrate the VMINI driver into my
image, so I can use a normal network connection. Now, I stumbled
across a few things:
1. I have found a link[1] in the MSDN which I'm using as a base.
It talks about %_WINCEROOT%\<Hardware Platform
Name>\Src\Kernel\<Kernel Image> and that one should include the
vbridge.lib there. I have the subdirs KERN, KERNKITL and
KERNKITLPROF (and OAL, but that one's not meant here). I see that
all three build an executable (the kernel?) but when is either
included in the runtime image? Looking at the release dir, I see
that all are included, but how do I control which one is started?
I notice that common.bib seems to select either kernel, right?
Yes. Common.bib loads includes one of the 3 kernels, depending on
your platform settings.
The point is that the KERNKITL and KERNKITLPROF already include
the vbridge.lib and have some KITL libs linked in, too. Starting
the right one should therefore already do the job.
This should include the kernel part of VMINI support.
You need to load the VMINI driver through the registry.
2. Under the KERN subdir is a file kitl.c which includes the
functions OALKitl{Start, InitRegistry, PowerOff, PowerOn} and
OALIoCtlVBridge. All are empty, they do nothing or return a
default value. However, under the OAL subdir is another file
called kitl.c which provides OALKitl{Start, InitRegistry}.
First question is why this kernel that seems not to support KITL
then has a file called kitl.c with just stubs. Is the user
supposed to fill those in? Is this to prevent other definitions
from a real implementation to be linked? Or is it an oversight,
and rather the functions in OAL/kitl.c should be used?
Those stubs are simply there to allow you to build the release kernel
without including a KITL implementation. You don't have to change
anything there, since you don't need KITL when the KERN version of
the kernel is built.
I guess the stubs are created to link correctly but to prevent
KITL from working. Note that I'm working on a Db1100-based
platform. All Db* based platforms do it this way while Geode or
CEPC have a file there that is even called stubs.c.
The file naming is not coherent among different BSPs and also the
directory structure can be quite different.
3. Where do I find the function OEMIoControl that [1] says should
have some code added? Is it perhaps better to place the code in
the OALIoCtlVBridge function from the file with the stubs?
No. The stubs are linked with a kernel without KITL support.
Hmmm, after trying that, I found that OALIoCtlVBridge already
exists in the common part of the platforms BSPs and that it does
just that. So, linking in oal_kitl.lib should already do the right
thing.
Not for the release kernel!
OEMIoControl should be implemented by the OAL, included in the BSP.
The placement of this function depends on the BSP. Some BSPs places
those functions into a PUBLIC\COMMON\OAK\CSP subdir and allow the BSP
developers to extend the IoControl functions through an external
function (called after or before the default IOCTL codes has been
handled by the common code) or via a table that associates a IOCTL
with a function pointer.
I don't know your platform, so I can't help you much about this
issue.
4. I guess that (provided it really takes the right kernel) I
should already be outfitted with everything require to run the
VMINI driver, but now I wonder how I get that driver? The link[2]
says I should include vmini.dll in the runtime image. Am I
supposed to find the DLL manually and copy it to the release dir?
I guess not, in particular because some sysgen(?) variables need
to be set, too, AFAICT. However, in the catalog on the right side,
I can't detect anything with vmini or vbridge in the name! I'm
sure that I once saw something like that somewhere (maybe with
PB4.2?) though, and I can find the sources...strange.
VMINI is not in the catalog. IIRC you should set some environment
variables to _prevent_ the inclusion of VMINI in your OS image, it
should be included by default.
Check if the .bat file in your platform root directory don't set
BSP_NOSHAREETH or IMGNOSHAREETH to an empty string.
If it does, it maybe that there are some issues about VMINI/KITL
support on your BSP...
--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)
.
- References:
- VMINI driver
- From: Ulrich Eckhardt
- VMINI driver
- Prev by Date: Re: VMINI driver
- Next by Date: Re: Can you stop Part00 {only} on the HDD from being mounted
- Previous by thread: Re: VMINI driver
- Next by thread: SD detection without sending any commands
- Index(es):
Relevant Pages
|
