Re[2]: 1394: second device of same type not detected

NTDEV
1

> %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1

The “a35” is the OUI, but what about the “&1”. I thought that would be
the device type id somehow. You said the other 48 bit are split between
device type id and device instance. The other 48 bit are set to 0xea68
in my case (chip id high = 0). At the moment I don’t know where to find
the .inf-file equivalent of the device type in the config ROM .
Thanks
Uwe

Well, you caught me. It turns out that I don’t understand this as much
as I thought but as I have to come to grips with it in the near future
I did some tests. The DDK docs says the following:

DDK---------------------------------------------------------
Identifiers for 1394 Devices
The 1394 bus driver constructs these identifiers for a device:

1394\VendorName&ModelName

1394\UnitSpecId&UnitSwVersion

where VendorName is the name of the hardware vendor, ModelName
identifies the device, UnitSpecId identifies the software
specification authority, and UnitSwVersion identifies the software
specification. The information used to construct these identifiers
comes from the device’s configuration ROM.

If a device has vendor and model name strings, the 1394 bus driver
uses the first identifier as both, the device ID and the hardware ID,
and the second identifier as the compatible ID. If a device lacks a
vendor or model name string, the bus driver uses the second identifier
as both, the device ID and the compatible ID, and returns double NULL
if queried for the hardware ID. Thus, the IEEE1394 bus driver, under
certain circumstances, supplies a device ID but no hardware ID. This
is an exception to the general rule that the device ID is one of the
hardware IDs.

The device ID for a camera on a IEEE1394 might appear as follows

1394\SONY&CCM-DS250_1.08

It turns out that my inf file uses a string like the first case:
1394\VendorName&ModelName

If I remove this string it will use an entry like your:
%DEVSDESCRIPTION%=DriverInstall, 1394\a35&1

I have verified that the first number (a35) is the 24 bit vendor id
(without leading 0s). I thought the second part (1)came from the 64
bit unique id as well but that appears not to be the case. There is a
Module_SW_Version entry in the Configuration ROM but I can’t verify
at the moment if that is what is being used. Maybe there is someone
else out there who understands all this in more detail.

Rob
xxxxx@telusplanet.net

2

For DID I mean the Version Number of device descriptor.

Please, what do you mean for “unique serial number” ?

Thank you,
PaoloC

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 06, 2004 4:47 PM
Subject: RE: [ntdev] 1394: second device of same type not detected

Not sure what you mean by DID, but here is the general gist:

if your device has a serial number and 2 devices are plugged in with the
same serial number, the second will not be reported to the OS or the
machine will bugcheck (depends on the version of the USB stack). If
your device does not have a unique serial number, then for each port the
device is plugged into, it will be treated as a new device and there can
be as many of your device as there are ports.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
Sent: Tuesday, January 06, 2004 7:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394: second device of same type not detected

Does anybody know if the same problem (unique device ID) exists for USB
devices too ?
I am working on a USB driver & I am not able to load 2 devices with the
same
VID+PID+DID !

Best regards & happy new year,
PaoloC

----- Original Message -----
From: “uwe kirst”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 06, 2004 5:59 PM
Subject: Re: [ntdev] 1394: second device of same type not detected

> Robert Newton wrote:
>
> >>I developing a WDM driver for a firewire device. I used the 1394Diag
> >>example form the ddk as a starting point.
> >>I’m having some trouble detecting more than one device of the same
type
> >>(a device with same vendor and device id). The second device is
simply
> >>not detected. I’m getting a bus reset if the cable is plugged, but
thats
> >>all. The add_device function is not called.
> >>
> >>
> >
> >I’m not completely sure what id’s you’re working with. The
> >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> >vendor_id, chip_id_hi and chip_id_low.
> >
> >Vendor id should be an
> >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> >choose (split between device type id and device instance) however at
> >the end of the day, each device must have a unique number. (Although
I
> >have never experimented with giving 2 devices the same id so I can’t
> >say what happens when you do this.)
> >
> >Doing this I have never had any trouble getting multiple instances of
> >a device to show up at the same time.
> >
> >Rob
> >xxxxx@telusplanet.net
> >
> >
> Thank you for your clarification. It seems that the second device with
> the same id is not detected and that is what should happen because the
> ids must be unique.
> But what about the .inf file of a driver. My .inf file looks like
this:
> …
> [DeviceList]
> %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> …
> The “a35” is the OUI, but what about the “&1”. I thought that would be
> the device type id somehow. You said the other 48 bit are split
between
> device type id and device instance. The other 48 bit are set to
0xea68
> in my case (chip id high = 0). At the moment I don’t know where to
find
> the .inf-file equivalent of the device type in the config ROM .
> Thanks
> Uwe
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@tin.it
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@tin.it
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Read the USB 1.1 core specification. It is a special string descriptor.
Given that you don’t know what it is, I doubt your device has one.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
Sent: Tuesday, January 06, 2004 12:43 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394: second device of same type not detected

For DID I mean the Version Number of device descriptor.

Please, what do you mean for “unique serial number” ?

Thank you,
PaoloC

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 06, 2004 4:47 PM
Subject: RE: [ntdev] 1394: second device of same type not detected

Not sure what you mean by DID, but here is the general gist:

if your device has a serial number and 2 devices are plugged in with the
same serial number, the second will not be reported to the OS or the
machine will bugcheck (depends on the version of the USB stack). If
your device does not have a unique serial number, then for each port the
device is plugged into, it will be treated as a new device and there can
be as many of your device as there are ports.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of PaoloC
Sent: Tuesday, January 06, 2004 7:13 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] 1394: second device of same type not detected

Does anybody know if the same problem (unique device ID) exists for USB
devices too ?
I am working on a USB driver & I am not able to load 2 devices with the
same
VID+PID+DID !

Best regards & happy new year,
PaoloC

----- Original Message -----
From: “uwe kirst”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, January 06, 2004 5:59 PM
Subject: Re: [ntdev] 1394: second device of same type not detected

> Robert Newton wrote:
>
> >>I developing a WDM driver for a firewire device. I used the 1394Diag
> >>example form the ddk as a starting point.
> >>I’m having some trouble detecting more than one device of the same
type
> >>(a device with same vendor and device id). The second device is
simply
> >>not detected. I’m getting a bus reset if the cable is plugged, but
thats
> >>all. The add_device function is not called.
> >>
> >>
> >
> >I’m not completely sure what id’s you’re working with. The
> >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> >vendor_id, chip_id_hi and chip_id_low.
> >
> >Vendor id should be an
> >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> >choose (split between device type id and device instance) however at
> >the end of the day, each device must have a unique number. (Although
I
> >have never experimented with giving 2 devices the same id so I can’t
> >say what happens when you do this.)
> >
> >Doing this I have never had any trouble getting multiple instances of
> >a device to show up at the same time.
> >
> >Rob
> >xxxxx@telusplanet.net
> >
> >
> Thank you for your clarification. It seems that the second device with
> the same id is not detected and that is what should happen because the
> ids must be unique.
> But what about the .inf file of a driver. My .inf file looks like
this:
> …
> [DeviceList]
> %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> …
> The “a35” is the OUI, but what about the “&1”. I thought that would be
> the device type id somehow. You said the other 48 bit are split
between
> device type id and device instance. The other 48 bit are set to
0xea68
> in my case (chip id high = 0). At the moment I don’t know where to
find
> the .inf-file equivalent of the device type in the config ROM .
> Thanks
> Uwe
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@tin.it
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@tin.it
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

A couple of things I forgot to mention. Vendor and model leaves are
optional, so your device may not have them. unit directories on the other
hand are mandatory. Each unit directory is enumerated by the Windows 1394
stack as a unique PnP device. Also, if you have vendor and model leaves and
wish to extract the vendor and model strings from them, be aware that the
CSR architecture allows them to be either ASCII or UNICODE. There are bits
in the leaves that tell you which convention is being used, again check the
CSR specs. If your device doesn’t supply these leaves/strings, it really
should as it provides Windows with friendly names to attach to your device
even before any software is loaded.

–
Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashua/patches/utility.htm

“Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> > The “a35” is the OUI, but what about the “&1”. I thought that would be
> > the device type id somehow. You said the other 48 bit are split between
> > device type id and device instance. The other 48 bit are set to 0xea68
> > in my case (chip id high = 0). At the moment I don’t know where to find
> > the .inf-file equivalent of the device type in the config ROM .
>
> The IDs in the INF file are typically setup in a couple of different ways.
> For instance I have a 1394 camera called an IBot camera made by
OrangeMicro.
> I can setup the INF file manufacturer’s section to either look for the
> vendor name/model name of the camera as so:
>
> [MyMfg]
> %MyDeviceDesc%=MyDDI, 1394\ORANGE_MICRO&IBOT
>
> And/or I can have the manufacturer’s section look for the Unit Spec
ID/Unit
> SwVersion as so:
>
> %MyDeviceDesc%=MyDDI, 1394\A02D&100
>
> The vendor name (ORANGE MICRO) will be contained in a VendorLeaf in the
> device’s configuration ROM (note that blanks in the vendor name are
replaced
> with underscores in the INF). The model name (IBOT) will be contained in
a
> ModelLeaf. The Unit Spec ID (A02D) and Unit SwVersion (100) are contained
> in a UnitDirectory.
>
> For more information on the content and layout of vendor leaves, model
> leaves, and unit directories see the IEEE 1394 specification, and the IEEE
> 1212 CSR specifications.
>
> Be aware that a single device can have muliple functions, thus multiple
unit
> directories, leaves and such.
>
> For more information on 1394 identifiers in INF files see the topic
> “Identifiers for 1394 Devices” in the help documentation for a late model
> DDK.
>
> –
> Bill McKenzie
> Compuware Corporation
> Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
> http://frontline.compuware.com/nashua/patches/utility.htm
>
>
>
> “uwe kirst” wrote in message news:xxxxx@ntdev…
> > Robert Newton wrote:
> >
> > >>I developing a WDM driver for a firewire device. I used the 1394Diag
> > >>example form the ddk as a starting point.
> > >>I’m having some trouble detecting more than one device of the same
type
> > >>(a device with same vendor and device id). The second device is simply
> > >>not detected. I’m getting a bus reset if the cable is plugged, but
thats
> > >>all. The add_device function is not called.
> > >>
> > >>
> > >
> > >I’m not completely sure what id’s you’re working with. The
> > >configuration ROM of each device needs a UNIQUE 64 bit id made up of
> > >vendor_id, chip_id_hi and chip_id_low.
> > >
> > >Vendor id should be an
> > >Organizationally Unique Identifier (OUI) purchased from IEEE. The
> > >other 48 bits (less if you purchase IAB instead or OUI) are yours to
> > >choose (split between device type id and device instance) however at
> > >the end of the day, each device must have a unique number. (Although I
> > >have never experimented with giving 2 devices the same id so I can’t
> > >say what happens when you do this.)
> > >
> > >Doing this I have never had any trouble getting multiple instances of
> > >a device to show up at the same time.
> > >
> > >Rob
> > >xxxxx@telusplanet.net
> > >
> > >
> > Thank you for your clarification. It seems that the second device with
> > the same id is not detected and that is what should happen because the
> > ids must be unique.
> > But what about the .inf file of a driver. My .inf file looks like this:
> > …
> > [DeviceList]
> > %DEVSDESCRIPTION%=DriverInstall, 1394\a35&1
> > …
> > The “a35” is the OUI, but what about the “&1”. I thought that would be
> > the device type id somehow. You said the other 48 bit are split between
> > device type id and device instance. The other 48 bit are set to 0xea68
> > in my case (chip id high = 0). At the moment I don’t know where to find
> > the .inf-file equivalent of the device type in the config ROM .
> > Thanks
> > Uwe
> >
> >
>
>
>

5

Bill McKenzie wrote:

>The “a35” is the OUI, but what about the “&1”. I thought that would be
>the device type id somehow. You said the other 48 bit are split between
>device type id and device instance. The other 48 bit are set to 0xea68
>in my case (chip id high = 0). At the moment I don’t know where to find
>the .inf-file equivalent of the device type in the config ROM .
>
>

The IDs in the INF file are typically setup in a couple of different ways.
For instance I have a 1394 camera called an IBot camera made by OrangeMicro.
I can setup the INF file manufacturer’s section to either look for the
vendor name/model name of the camera as so:

[MyMfg]
%MyDeviceDesc%=MyDDI, 1394\ORANGE_MICRO&IBOT

And/or I can have the manufacturer’s section look for the Unit Spec ID/Unit
SwVersion as so:

%MyDeviceDesc%=MyDDI, 1394\A02D&100

The vendor name (ORANGE MICRO) will be contained in a VendorLeaf in the
device’s configuration ROM (note that blanks in the vendor name are replaced
with underscores in the INF). The model name (IBOT) will be contained in a
ModelLeaf. The Unit Spec ID (A02D) and Unit SwVersion (100) are contained
in a UnitDirectory.

For more information on the content and layout of vendor leaves, model
leaves, and unit directories see the IEEE 1394 specification, and the IEEE
1212 CSR specifications.

Hello,
My device has no VendorLeaf, but it has a UnitDirectory. That explains
the .inf file format a35&1. “1” is the SwVersion.
Thanks,
Uwe