PB5.0: Difficulty cloning USB function client driver (ufnmdd.dll)

Hello all,

I am trying to clone the MDD code from the USB function client driver in
PUBLIC\COMMON to add a few things to pipe.cpp, and the various instructions
of Steve Maillet, Bruce Eitman, etc. published on the web don't seem to map
very well to this case. I've copied the contents of
C:\WINCE500\PUBLIC\COMMON\OAK\DRIVERS\USBFN\CONTROLLER\MDD to my platform,
modified SOURCES appropriately to write output to the platform, and verified
that UFNMDDBASE.LIB is built in the expected PLATFORM\FOO\LIB\ARMV4I\RETAIL
directory.

Problem is, the instructions to clone a driver seem to assume that all the
ingredients are contained in a folder which can be copied to the platform so
that sysgen_capture can be run. That isn't the case here; the product
UFNMDDBASE.LIB appears to be linked into UFNMDD.DLL by the following block in
the big cesysgen makefile at PUBLIC\COMMON\CESYSGEN\MAKEFILE:

ufnmdd:: ufnmddbase ceosutil defbuslib
@set TARGETNAME=$@
@set RELEASETYPE=OAK
@set SOURCELIBS=$(SG_OUTPUT_OAKLIB)\ufnmddbase.lib
$(SG_OUTPUT_SDKLIB)\ceosutil.lib $(SG_OUTPUT_OAKLIB)\defbuslib.lib
@set TARGETTYPE=LIBRARY
$(MAKECMD) /NOLOGO $(SG_OUTPUT_OAKLIB)\$@.lib

I am a little leery of the prospect of cloning this monster, or worse the
entire public\common trunk! But I am at an impasse here, and modifying
public\common code is looking like the only feasible way to modify this
stuff. Can anyone advise how to proceed before I "back it up and hack it up"?

Best regards,
Craig Blome

cblome
Wed Aug 20 15:17:01 PDT 2008

Obviously I ought to have written "usbmdd.lib" rather than "usbmdd.dll"
below. This library then gets linked into other DLL's further down the line
(and this is where I get really lost following the build)

"cblome" wrote:

> Hello all,
>
> I am trying to clone the MDD code from the USB function client driver in
> PUBLIC\COMMON to add a few things to pipe.cpp, and the various instructions
> of Steve Maillet, Bruce Eitman, etc. published on the web don't seem to map
> very well to this case. I've copied the contents of
> C:\WINCE500\PUBLIC\COMMON\OAK\DRIVERS\USBFN\CONTROLLER\MDD to my platform,
> modified SOURCES appropriately to write output to the platform, and verified
> that UFNMDDBASE.LIB is built in the expected PLATFORM\FOO\LIB\ARMV4I\RETAIL
> directory.
>
> Problem is, the instructions to clone a driver seem to assume that all the
> ingredients are contained in a folder which can be copied to the platform so
> that sysgen_capture can be run. That isn't the case here; the product
> UFNMDDBASE.LIB appears to be linked into UFNMDD.DLL by the following block in
> the big cesysgen makefile at PUBLIC\COMMON\CESYSGEN\MAKEFILE:
>
> ufnmdd:: ufnmddbase ceosutil defbuslib
> @set TARGETNAME=$@
> @set RELEASETYPE=OAK
> @set SOURCELIBS=$(SG_OUTPUT_OAKLIB)\ufnmddbase.lib
> $(SG_OUTPUT_SDKLIB)\ceosutil.lib $(SG_OUTPUT_OAKLIB)\defbuslib.lib
> @set TARGETTYPE=LIBRARY
> $(MAKECMD) /NOLOGO $(SG_OUTPUT_OAKLIB)\$@.lib
>
> I am a little leery of the prospect of cloning this monster, or worse the
> entire public\common trunk! But I am at an impasse here, and modifying
> public\common code is looking like the only feasible way to modify this
> stuff. Can anyone advise how to proceed before I "back it up and hack it up"?
>
> Best regards,
> Craig Blome

Bruce
Wed Aug 20 15:41:30 PDT 2008

Since that is just a LIB, not a dll, all you need to do is copy the folder
to your platform. Set the RElEASETYPE=PLATFORM.

Then change your dll sources to link with the three libs instead of the
single lib. Or create a new folder, similar to my example dll folder, to
link the three libs into one.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

"cblome" <cblome@discussions.microsoft.com> wrote in message
news:DEC885F3-06C6-4BCB-B954-F68F8CE397C0@microsoft.com...
> Obviously I ought to have written "usbmdd.lib" rather than "usbmdd.dll"
> below. This library then gets linked into other DLL's further down the
> line
> (and this is where I get really lost following the build)
>
> "cblome" wrote:
>
>> Hello all,
>>
>> I am trying to clone the MDD code from the USB function client driver in
>> PUBLIC\COMMON to add a few things to pipe.cpp, and the various
>> instructions
>> of Steve Maillet, Bruce Eitman, etc. published on the web don't seem to
>> map
>> very well to this case. I've copied the contents of
>> C:\WINCE500\PUBLIC\COMMON\OAK\DRIVERS\USBFN\CONTROLLER\MDD to my
>> platform,
>> modified SOURCES appropriately to write output to the platform, and
>> verified
>> that UFNMDDBASE.LIB is built in the expected
>> PLATFORM\FOO\LIB\ARMV4I\RETAIL
>> directory.
>>
>> Problem is, the instructions to clone a driver seem to assume that all
>> the
>> ingredients are contained in a folder which can be copied to the platform
>> so
>> that sysgen_capture can be run. That isn't the case here; the product
>> UFNMDDBASE.LIB appears to be linked into UFNMDD.DLL by the following
>> block in
>> the big cesysgen makefile at PUBLIC\COMMON\CESYSGEN\MAKEFILE:
>>
>> ufnmdd:: ufnmddbase ceosutil defbuslib
>> @set TARGETNAME=$@
>> @set RELEASETYPE=OAK
>> @set SOURCELIBS=$(SG_OUTPUT_OAKLIB)\ufnmddbase.lib
>> $(SG_OUTPUT_SDKLIB)\ceosutil.lib $(SG_OUTPUT_OAKLIB)\defbuslib.lib
>> @set TARGETTYPE=LIBRARY
>> $(MAKECMD) /NOLOGO $(SG_OUTPUT_OAKLIB)\$@.lib
>>
>> I am a little leery of the prospect of cloning this monster, or worse the
>> entire public\common trunk! But I am at an impasse here, and modifying
>> public\common code is looking like the only feasible way to modify this
>> stuff. Can anyone advise how to proceed before I "back it up and hack it
>> up"?
>>
>> Best regards,
>> Craig Blome

Bruce
Wed Aug 20 21:12:10 PDT 2008

Craig:

I just went through the process and documented on my blog:
http://geekswithblogs.net/BruceEitman/archive/2008/08/21/platform-builder--cloning-an-mdd-lib.aspx

Although, it might be good for me to ask you why you want to do this? There
are valid reasons, but for some reason I get the feeling that you don't
necessarily need to do this.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

"Bruce Eitman [eMVP]" <bruce.eitman.nospam@EuroTech.com.nospam> wrote in
message news:%23Rl%23kXxAJHA.760@TK2MSFTNGP05.phx.gbl...
> Since that is just a LIB, not a dll, all you need to do is copy the folder
> to your platform. Set the RElEASETYPE=PLATFORM.
>
> Then change your dll sources to link with the three libs instead of the
> single lib. Or create a new folder, similar to my example dll folder, to
> link the three libs into one.
>
> --
> Bruce Eitman (eMVP)
> Senior Engineer
> Bruce.Eitman AT EuroTech DOT com
> My BLOG http://geekswithblogs.net/bruceeitman
>
> EuroTech Inc.
> www.EuroTech.com
>
> "cblome" <cblome@discussions.microsoft.com> wrote in message
> news:DEC885F3-06C6-4BCB-B954-F68F8CE397C0@microsoft.com...
>> Obviously I ought to have written "usbmdd.lib" rather than "usbmdd.dll"
>> below. This library then gets linked into other DLL's further down the
>> line
>> (and this is where I get really lost following the build)
>>
>> "cblome" wrote:
>>
>>> Hello all,
>>>
>>> I am trying to clone the MDD code from the USB function client driver in
>>> PUBLIC\COMMON to add a few things to pipe.cpp, and the various
>>> instructions
>>> of Steve Maillet, Bruce Eitman, etc. published on the web don't seem to
>>> map
>>> very well to this case. I've copied the contents of
>>> C:\WINCE500\PUBLIC\COMMON\OAK\DRIVERS\USBFN\CONTROLLER\MDD to my
>>> platform,
>>> modified SOURCES appropriately to write output to the platform, and
>>> verified
>>> that UFNMDDBASE.LIB is built in the expected
>>> PLATFORM\FOO\LIB\ARMV4I\RETAIL
>>> directory.
>>>
>>> Problem is, the instructions to clone a driver seem to assume that all
>>> the
>>> ingredients are contained in a folder which can be copied to the
>>> platform so
>>> that sysgen_capture can be run. That isn't the case here; the product
>>> UFNMDDBASE.LIB appears to be linked into UFNMDD.DLL by the following
>>> block in
>>> the big cesysgen makefile at PUBLIC\COMMON\CESYSGEN\MAKEFILE:
>>>
>>> ufnmdd:: ufnmddbase ceosutil defbuslib
>>> @set TARGETNAME=$@
>>> @set RELEASETYPE=OAK
>>> @set SOURCELIBS=$(SG_OUTPUT_OAKLIB)\ufnmddbase.lib
>>> $(SG_OUTPUT_SDKLIB)\ceosutil.lib $(SG_OUTPUT_OAKLIB)\defbuslib.lib
>>> @set TARGETTYPE=LIBRARY
>>> $(MAKECMD) /NOLOGO $(SG_OUTPUT_OAKLIB)\$@.lib
>>>
>>> I am a little leery of the prospect of cloning this monster, or worse
>>> the
>>> entire public\common trunk! But I am at an impasse here, and modifying
>>> public\common code is looking like the only feasible way to modify this
>>> stuff. Can anyone advise how to proceed before I "back it up and hack
>>> it up"?
>>>
>>> Best regards,
>>> Craig Blome
>
>

cblome
Fri Aug 22 15:11:00 PDT 2008

Bruce,

Thanks much for your guidance...the process worked as advertised. It does
appear that ufnmdd.lib is a component linked into several DLL's for which the
reference to ufnmdd.lib would have to be replaced by its constituents in each
instance where modified DLL behavior is desired. I only was interested in
one DLL this time, so the process was simple.

You are correct in your hunch that I am messing about with something I
probably ought not. To make a long story short, we are sorting out issues
with a BSP which was initially outsourced to a firm who were in way over
their heads. KITL and the USB stack aren't getting on well enough to get a
successful connection, and attempts to enable KITL over serial have not born
fruit. Since getting KITL working properly isn't a priority versus fixing my
trouble ticket, I am sprinkling retailmsg macros in pipe.cpp to trace the
reasons for repeated "root port resets". I did not want to clean up the mess
from modifying the public tree directly, however.

Perhaps MS is subtly hinting that if I am having to work this hard at
something I should think about the right way to go about it. :)

Best regards,
Craig Blome

"Bruce Eitman [eMVP]" wrote:

> Craig:
>
> I just went through the process and documented on my blog:
> http://geekswithblogs.net/BruceEitman/archive/2008/08/21/platform-builder--cloning-an-mdd-lib.aspx
>
> Although, it might be good for me to ask you why you want to do this? There
> are valid reasons, but for some reason I get the feeling that you don't
> necessarily need to do this.
>

Bruce
Fri Aug 22 15:29:26 PDT 2008

Okay, sounds like you have a good reason to do what you are doing. I was
worried that you were pulling in more code than you needed, but I think that
you are doing what you need to do.

--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT EuroTech DOT com
My BLOG http://geekswithblogs.net/bruceeitman

EuroTech Inc.
www.EuroTech.com

"cblome" <cblome@discussions.microsoft.com> wrote in message
news:70BFC468-86C2-418F-BC7A-4748147B8346@microsoft.com...
> Bruce,
>
> Thanks much for your guidance...the process worked as advertised. It does
> appear that ufnmdd.lib is a component linked into several DLL's for which
> the
> reference to ufnmdd.lib would have to be replaced by its constituents in
> each
> instance where modified DLL behavior is desired. I only was interested in
> one DLL this time, so the process was simple.
>
> You are correct in your hunch that I am messing about with something I
> probably ought not. To make a long story short, we are sorting out issues
> with a BSP which was initially outsourced to a firm who were in way over
> their heads. KITL and the USB stack aren't getting on well enough to get
> a
> successful connection, and attempts to enable KITL over serial have not
> born
> fruit. Since getting KITL working properly isn't a priority versus fixing
> my
> trouble ticket, I am sprinkling retailmsg macros in pipe.cpp to trace the
> reasons for repeated "root port resets". I did not want to clean up the
> mess
> from modifying the public tree directly, however.
>
> Perhaps MS is subtly hinting that if I am having to work this hard at
> something I should think about the right way to go about it. :)
>
> Best regards,
> Craig Blome
>
> "Bruce Eitman [eMVP]" wrote:
>
>> Craig:
>>
>> I just went through the process and documented on my blog:
>> http://geekswithblogs.net/BruceEitman/archive/2008/08/21/platform-builder--cloning-an-mdd-lib.aspx
>>
>> Although, it might be good for me to ask you why you want to do this?
>> There
>> are valid reasons, but for some reason I get the feeling that you don't
>> necessarily need to do this.
>>
>