> From: Brad Hards [mailto:[EMAIL PROTECTED]]
>
> "Dunlap, Randy" wrote:
> [snip]
> > 3. There's a new (additional) USB compliance spec (at usb.org)
> > which addresses power management in more detail.
> Is this the IAPC stuff, the droop/drop stuff or something else?
IAPC stuff I thought, until I looked again.
In the Members section, there's a new Compliance Doc dated
2000-May-15, Rev. 0.9, titled "Universal Serial Bus
Implementers Forum Compliance Test Procedure" (70 pages,
pdf file).
> > 4. USB 2.0 Technical Overview:
> [snip]
> > . Same software interfaces (USBDI) (N/A)
> Was there any discussion of this? Is anyone doing it at all?
It was just a blanket statement implying that the Windows
driver API is not changing. Whether it is USBDI or not was
not discussed or even relevant to that discussion.
There is a USBDI Device Working Group headed by Janet Schank
of Compaq (formerly DEC). Here's its Mission Statement:
The Open USB Driver Interface (OpenUSBDI)
specification allows USB device drivers, such as vendor
unique drivers and USB class drivers, to be 100% source
code portable between operation systems which
provide OpenUSBDI support. Involved in the
development of this specification are representatives
from the major UNIX operating system vendors,
embedded system vendors, and other non-UNIX
operating systems.
It's not clear to me how much adoption and usage they are seeing.
> [snip]
> > . Same cables & connectors (mostly; low-speed devices with
> > unshielded captive/attached cables are not compliant)
> Any reason for this?
I think it has to do with not being able to guarantee that
these devices can meet the required timings, but it may be
noise-related instead. Here's what the presenter's slide says:
. Compliant USB 1.1 devices will generally be USB 2.0 compliant.
. Exception: Low-speed devices with unshielded, captive cables.
. USB 2.0 requires foil and drain wire in low-speed captive cables.
. This is a Compliance issue -- It doesn't affect 1.1/2.0
interoperability.
> [snip]
> > . USB 2.0 high-speed devices are required to support full-speed
> > signaling at least for enumeration, preferably for some
> > (reduced) backward compatibility; high-speed devices must not
> > support low-speed signaling.
> Err, does this mean that a USB 2.0 hub doesn't _need_ to work when
> attached to a USB 1.[0,1] host - all it needs to do is enumerate?
Good question. "high-speed devices" here means function/endpoint
devices, i.e., not hubs. I haven't seen or heard your question
discussed, but I would expect a USB 2.0 hub to work fine with a
1.1 HC. It will just have lots of extra intelligence that it won't
use. The last phrase (high-speed devices must not support low-speed
signaling) would also kill hubs that have to work at all 3 speeds.
> [snip]
> > . The USB 2.0 compliance program is being strengthened and a
> > "compliance" logo is being added.
> Any talk about anyone else doing compliance work?
Anyone else in what sense? USB-IF is beginning to license some
"agencies" to perform USB compliance work because there's not
enough bandwidth at USB PlugFests to do it all and to provide
secrecy to those companies that don't want to expose their
product at a PlugFest. There are 2 or 3 of these already
operating (or ready to operate).
> [snip]
> > 6. EHCI (Enhanced Host Controller Interface) and PDK:
> >
> > . Rev. 0.95 of the ECHI spec for discrete HCs will be the first
> > public version (Q3/2000). Gated by validation of 2 discrete
> > HCs. Rev. 1.00 to be available in 2001.
> > . Developed by Intel with contributions from NEC, Lucent,
> > Philips, Compaq, & Microsoft.
> Is this the only 2.0 host controller? No more alternate
> [O,U]HCI issues?
> Also, is the validation on the silicon, or using a real driver stack
> (presumably Win 2000 based).
The USB 2.0 Promoters group hopes that this is the only USB 2.0
HC although they can't guarantee that. It blends the best features
of OHCI & UHCI into EHCI.
As for silicon validation, I don't know the exact plans.
I would expect it to be done several ways (test vectors, simulation,
silicon verification software (non-driver stack, or put another way,
its own driver stack, and the Windows 2000 driver stack).
An OS driver stack doesn't really provide verification the
way that I've seen it done.
> [snip]
> > . PDKs (Peripheral Development Kits) are planned for late June
> > availability. They contain a PCI/USB 2.0 addin card, a USB
> > 2.0 software stack for Windows 2000, and USB 2.0 transaction
> > generator software.
> > . There is also a USB 2.0 Compliance Device that is planned for
> > July/2000.
> Any idea who is making these? Or approximate cost?
AFAIK they are coming from Intel, but it could be from other
sources also. Prices weren't available yet. They (device/price
announcements) will be posted at usb.org when available.
> > 7. Phoenix Technologies has a BIOS that will boot from USB
> > floppy or Zip drives, working on CD-ROM and LS-120, others
> > to follow as needed.
> > . To support topology changes, Phoenix wants to see consumer
> > pressure on floppy vendors to add serial numbers.
> Very cool. Was this a system they planned to ship, or a demo?
They didn't have a demo. Since most BIOSes are configurable,
I expect that this is just a config option that a system board OEM
can choose when saying what they want in their system's BIOS.
[snip]
~Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
