My USB book is coming along well. However, I need help
with the tests. I have a few test machines, but to make
a thorough and accurate test base, I need a much larger
test base.
If you feel that you are willing to help with a few tests,
please have a look at
http://www.frontiernet.net/~fys/usb_help.htm
As I continue to research and verify my findings, I will
add more tests.
Thank you for all your help,
Ben
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
http://www.frontiernet.net/~fys/collections.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some assembly required.
Hi Ben,
Is a USB 1.0 system an acceptable system?
Is the floppy self-bootable, so I don't actually require a pcDos?
Thxs,
Steve
>Hi Ben,
>
>Is a USB 1.0 system an acceptable system?
>
>Is the floppy self-bootable, so I don't actually require a pcDos?
>
>Thxs,
>
>Steve
Hi Steve,
A USB 1.0 system could be a UHCI or an OHCI, though most are
now USB 1.1 compatible. However, the version of the USB,
whether it be 1.0, 1.1, 2.0, or 3.0 has nothing to do with the
controller. The USB specs are different than the controller
specs.
What kind of controller do you have?
Yes, the floppy will self boot to FreeDOS. When you boot
the floppy, run the OHCI.EXE file. If you have an ohci
controller, it will display some information. If you do not,
it will gracefully exit telling you that you don't have
an OHCI controller.
Thanks,
Ben
> Hi everyone,
> My USB book is coming along well. However, I need help
> with the tests. I have a few test machines, but to make
> a thorough and accurate test base, I need a much larger
> test base.
> If you feel that you are willing to help with a few tests,
> please have a look at
> http://www.frontiernet.net/~fys/usb_help.htm
> As I continue to research and verify my findings, I will
> add more tests.
> Thank you for all your help,
> Ben
Hello Ben,
looking forward to see your USB-story.
I got an older AMD with a Floppy and an OHCI, so I dnloaded your
image and may give it try.
But if your code want to write the test result to the first partition
of my harddisk it will need some modification because the filesystem
there is quite uncommon (I could do this with your help).
__
wolfgang
Hi wolfgang,
No, the result is actually printed to the screen. This way
you can see what it does. Then the second time, I ask that
you redirect it to a file (on the floppy). Then send that
file to me, or copy/paste between the "cut here" lines, and
email the results to me.
Thanks.
Ben
Hi Ben,
>
> A USB 1.0 system could be a UHCI or an OHCI, though most are
> now USB 1.1 compatible. However, the version of the USB,
> whether it be 1.0, 1.1, 2.0, or 3.0 has nothing to do with the
> controller. The USB specs are different than the controller
> specs.
>
I see. I was guessing USB 1.0 would've been UHCI and 2.0 OHCI...
> What kind of controller do you have?
Good question 8-/
>
> Yes, the floppy will self boot to FreeDOS. When you boot
> the floppy, run the OHCI.EXE file. If you have an ohci
> controller, it will display some information. If you do not,
> it will gracefully exit telling you that you don't have
> an OHCI controller.
>
OK.
I guess I don't have one. These all showed negative:
Compaq Presario, vintage MMX Pent. I, 2 legacy USB ports. Win95.
Dell Latitude laptop, vintage MMX Pent. I, 1 legacy USB port. Win98.
Dell Dimension XPS T850r, Pentium III class, Win98 vintage, 2 USB
ports.
Dell Dimention 8250, Pentium 4, XP, 2 USB ports on front, 6 USB ports
in rear.
I kinda was expecting the last one to show positive. I guess I need
your book. :)
Steve
> Thanks,
> Ben- Hide quoted text -
>
> - Show quoted text -
Ben wrote:
> Yes, the floppy will self boot to FreeDOS. When you boot
> the floppy, run the OHCI.EXE file. If you have an ohci
> controller, it will display some information. If you do not,
> it will gracefully exit telling you that you don't have
> an OHCI controller.
Steve wrote:
>OK.
>I guess I don't have one. These all showed negative:
>
>Compaq Presario, vintage MMX Pent. I, 2 legacy USB ports. Win95.
>Dell Latitude laptop, vintage MMX Pent. I, 1 legacy USB port. Win98.
>Dell Dimension XPS T850r, Pentium III class, Win98 vintage, 2 USB
>ports.
>Dell Dimention 8250, Pentium 4, XP, 2 USB ports on front, 6 USB ports
>in rear.
I have found that OHCI is very much less common than UHCI.
Even the EHCI controllers that I have have UHCI companion
controllers. I guess since the EHCI is an Intel card,
it would have the Intel companion controller :-)
I don't know, maybe in different area's, different environments,
OHCI is more dominate.
>I kinda was expecting the last one to show positive. I guess I need
>your book. :)
Great :-), now if we can just get everyone else to think so :-)
Thanks for your efforts, I will still include your name if
you would like. Reply here with the name you would like
or personally via email (instructions below).
Thanks,
In non-Intel chipsets.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
> No, the result is actually printed to the screen. This way
> you can see what it does. Then the second time, I ask that
> you redirect it to a file (on the floppy). Then send that
> file to me, or copy/paste between the "cut here" lines, and
> email the results to me.
I have a slight problem here. My PVR system has an Nvidia chipset and
hence OHCI, but there's no floppy and the hard disk isn't DOS
accessible. So while I can easily boot your floppy image from DVD,
getting the data out is a little harder.
>> looking forward to see your USB-story.
>> I got an older AMD with a Floppy and an OHCI, so I dnloaded your
>> image and may give it try.
>> But if your code want to write the test result to the first partition
>> of my harddisk it will need some modification because the filesystem
>> there is quite uncommon (I could do this with your help).
> Hi wolfgang,
> No, the result is actually printed to the screen. This way
> you can see what it does.
yeah, but only the trailing end of it ... :)
> Then the second time, I ask that you redirect it to a file
> (on the floppy).
Yes, but it produced just a single byte file when I named the
destination 'ohci.txt', so I tried 'ohci2.txt' and it worked.
> Then send that file to me, ....
no secrets within my hardware, so I post the few bytes here:
only two of the four USB-ports are in use:
* printer(passive yet)
* external HUB with four ports
(I connected an USB2.0 extender, even it can only run slow)
where only on one port were a multifunction decive yet.
Chipset: AMD-756
*****
OHCI.EXE v1.00.00
Found a OHCI compatible device.
Bus = 0, device = 7, function = 4 IO Base: 0xEA001000
Vendor = 0x1022 Device = 0x740C rev = 0x06
Register contents after reset:
00: 0x00000110
04: 0x000006C0
08: 0x00000000
0C: 0x00000040
10: 0x00000000
14: 0x00000000
18: 0x00000000
1C: 0x00000000
20: 0x00000000
24: 0x00000000
28: 0x00000000
2C: 0x00000000
30: 0x00000000
34: 0x00002EDF
38: 0x00002EB7
3C: 0x00000000
40: 0x00000000
44: 0x00000628
48: 0x01000304
4C: 0x00000000
50: 0x00000000
Port 0: 0x00010101
Port 1: 0x00010101
Port 2: 0x00000100
Port 3: 0x00000100
HcHCCA register returns 0xFFFFFF00 for the alignment check.
********* Copy ends here
it reports the same values (except for the running frame counter)
as I see in my memory dump-view, hope this helps.
__
wolfgang
That's what I figured.
Thanks,
Ben
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
news:h8acit$21l9$1...@news.mtu.ru...
>> No, the result is actually printed to the screen. This way
>> you can see what it does.
>
> yeah, but only the trailing end of it ... :)
More, just to see that it actually works. If I downloaded
an .EXE and it didn't do anything but write to the disk, I
would be a little concerned. Even though I trusted the
source, I still would be a little concerned since I didn't
see anything actually being done. The print to the screen
on the first round is simply for ease of mind.
>> Then the second time, I ask that you redirect it to a file
>> (on the floppy).
>
> Yes, but it produced just a single byte file when I named the
> destination 'ohci.txt', so I tried 'ohci2.txt' and it worked.
You got me there. I did erase the ohci.txt file from the floppy
just before I got the image from it. I wonder if FreeDOS has
an issue there.
>> Then send that file to me, ....
>
> no secrets within my hardware, so I post the few bytes here:
I was just thinking of bandwidth. No need to use up bandwidth
and space on news servers for a data print out that will probably
be useless to anyone else.
> only two of the four USB-ports are in use:
> * printer(passive yet)
> * external HUB with four ports
> (I connected an USB2.0 extender, even it can only run slow)
> where only on one port were a multifunction decive yet.
> Chipset: AMD-756
>
> *****
> OHCI.EXE v1.00.00
Would you please get the current version and try again.
Sorry to post a new release so soon, to make you do it again.
I appreciate it grately.
> it reports the same values (except for the running frame counter)
> as I see in my memory dump-view, hope this helps.
What do you mean it reports the same values? The frame counter
should not be incrementing since the controller should be in the
Suspend state.
Again, thanks for your help. I do appreciate it.
Ben
I was thinking about this a few days ago. To remedy this, I
thought of making a USB stick (Thumb Drive) image. If you
don't have a USB port for a Thumb drive, the test would do
me no good anyway.
I will see what I can do.
Thanks,
Ben
> Would you please get the current version and try again.
> Sorry to post a new release so soon, to make you do it again.
> I appreciate it grately.
No problem, but it may not be ready before Sunday.
>> it reports the same values (except for the running frame counter)
>> as I see in my memory dump-view, hope this helps.
> What do you mean it reports the same values?
The things I see when I watch memory contents with my hex-viewer,
updated on every keystroke, iow by the key-repeat-rate if I hold
down the spacebar.
> The frame counter should not be incrementing since the controller
> should be in the Suspend state.
My BIOS seem not to 'reset' the host, so I watch a running counter
until I stop it by writing to the cmd-reg.
> Again, thanks for your help. I do appreciate it.
> Ben
Don't mention, we are here to help each other ...
__
wolfgang
That will be just fine, thank you.
>>> it reports the same values (except for the running frame counter)
>>> as I see in my memory dump-view, hope this helps.
>
>> What do you mean it reports the same values?
>
> The things I see when I watch memory contents with my hex-viewer,
> updated on every keystroke, iow by the key-repeat-rate if I hold
> down the spacebar.
>
>> The frame counter should not be incrementing since the controller
>> should be in the Suspend state.
>
> My BIOS seem not to 'reset' the host, so I watch a running counter
> until I stop it by writing to the cmd-reg.
The new version resets the host *and* the root hub. :-)
Thanks again,
Ben
A 233MHz Intel (?) "Did not find any OHCI controllers..." I'd also like to
run it on a few other machines, but I don't know when or if I'll get the
chance to do so soon. Anyway, I also ran it on the Neo-F motherboard for
which I've been posting FYSOS debug.txt's:
******** Copy starting here *******************************************
OHCI.EXE v1.02.02
Found a OHCI compatible device.
Bus = 0, device = 2, function = 0 IO Base: 0xFBEBF000
Vendor = 0x10DE Device = 0x036C rev = 0xA1
Register contents after reset:
00: 0x00000110
04: 0x000007C0
08: 0x00000000
0C: 0x00000000
10: 0x00000000
14: 0x00000000
18: 0x00000000
1C: 0x00000000
20: 0x00000000
24: 0x00000000
28: 0x00000000
2C: 0x00000000
30: 0x00000000
34: 0x00002EDF
38: 0x00002E2F
3C: 0x00000000
40: 0x00000000
44: 0x00000628
48: 0x0100120A
4C: 0x00000000
50: 0x00000000
Port 0: 0x00000100
Port 1: 0x00000100
Port 2: 0x00000100
Port 3: 0x00000100
Port 4: 0x00000100
Port 5: 0x00000100
Port 6: 0x00000100
Port 7: 0x00000100
Port 8: 0x00000100
Port 9: 0x00000100
HcHCCA register returns 0xFFFFFF00 for the alignment check.
********* Copy ends here **********************************************
HTH,
Rod Pemberton
...
> If you feel that you are willing to help with a few tests,
> please have a look at
> http://www.frontiernet.net/~fys/usb_help.htm
>
> As I continue to research and verify my findings, I will
> add more tests.
On my new test box I have problems running ohci.exe. No idea why. Am I
running it correctly? There are currently the following files on the
floppy. The two geode ones were when trying to redirect output. I
guess the CMD0 file was generated when I tried to pipe the output to
"more".
C:\>dir a:
Volume in drive A is HDMECHANIC
Volume Serial Number is 290B-1A04
Directory of A:\
18/08/2006 04:58 45,341 KERNEL.SYS
28/08/2006 21:40 66,945 COMMAND.COM
11/09/2009 18:00 1 GEODE.TXT
01/10/2002 01:09 5,704 mouse.exe
11/09/2009 18:03 1 GEODE2.TXT
09/09/2009 17:55 98,816 ohci.exe
22/10/2000 12:55 20,125 CWSDPMI.EXE
08/09/2009 14:32 17 autoexec.bat
11/09/2009 18:08 1 CMD0
9 File(s) 236,951 bytes
0 Dir(s) 1,217,536 bytes free
C:\>
When I ran "ohci" without redirecting its output it scrolled off the
top of the screen but did find something to report on. However, it
didn't return to a command prompt. Instead of
A:\>
I got
A:\
and the machine hung. Other commands - mouse and a reexecution of
command.com & exit do return to a command prompt.
I ran "ohci > geode.txt" and pressed Y. It wrote one byte to the file,
a formfeed, 0x0c.
Sorry for the bad news. If I'm doing something wrong let me know.
James
Thanks Rod. You have always been a great help.
Ben
"James Harris" <james.h...@googlemail.com> wrote in message
news:2bd66f8a-0e03-4dde...@k19g2000yqc.googlegroups.com...
On 8 Sep, 23:25, "Benjamin David Lunt" <zf...@frontiernet.net> wrote:
...
> If you feel that you are willing to help with a few tests,
> please have a look at
> http://www.frontiernet.net/~fys/usb_help.htm
>
> As I continue to research and verify my findings, I will
> add more tests.
James wrote:
>On my new test box I have problems running ohci.exe. No idea why. Am I
>running it correctly? There are currently the following files on the
>floppy. The two geode ones were when trying to redirect output. I
>guess the CMD0 file was generated when I tried to pipe the output to
>"more".
>
>When I ran "ohci" without redirecting its output it scrolled off the
>top of the screen but did find something to report on. However, it
>didn't return to a command prompt. Instead of
>
> A:\>
>
>I got
>
> A:\
>
>and the machine hung. Other commands - mouse and a reexecution of
>command.com & exit do return to a command prompt.
>
>I ran "ohci > geode.txt" and pressed Y. It wrote one byte to the file,
>a formfeed, 0x0c.
>
>Sorry for the bad news. If I'm doing something wrong let me know.
>
>James
Hi James,
I think it has to do with FreeDOS. I did some more tests, and
FreeDOS is acting up when there is a deleted ohci.txt file
already on the disk. I will see if I can get another version,
or brand of a freely legal distributed DOS and let you know.
Thanks for your help, sorry it didn't work right.
Ben
Okay, I have a different version of FreeDOS installed on
the floppy image. If you were having errors before, please
try this image instead, included at the link above.
Thank you all for your help,
Ben
P.S. You must choose the boot option #2, 'FreeDOS Safe Mode'
at boot time, then type RUN at the DOS prompt.
This still doesn't work on my test PC. I started option 2 and typed
run. The commands executed. On the first ohci after I pressed Y it
detected something, scrolled the head of it off the screen and then
hung round about where it would have presented the command prompt.
Again, if I run it manually and try to pipe the output to a file it
creates a file with just one byte, 0x0c.
If it helps the end of the screen report includes a line which says
Found a OHCI controller using Port I/O addressing????
The question marks are as they appear. Feel free to ignore my report
if you wish. Maybe there's some incompatibility with the hardware.
James
Additional: I've since noticed that if I leave it long enough - about
35 seconds - the rest of the command prompt does appear. It is a USB
floppy. Could that have something to do with it?
Given that the command prompt does eventually reappear when ohci is
run on its own I reran it piping the output to a file. The command
prompt did reappear after a while but the file still contained only
one byte, 0x0c.
> I was thinking about this a few days ago. To remedy this, I
> thought of making a USB stick (Thumb Drive) image. If you
> don't have a USB port for a Thumb drive, the test would do
> me no good anyway.
Right, but booting from and accessing a memory stick from DOS either
needs BIOS support or USB storage drivers for DOS and my old
motherboard has only USB keyboard support in the BIOS... The
motherboard is Asus A7N8X Deluxe, Nvidia Nforce2 chipset. Well, of
course there'd be plenty of space on a thumb drive.
Anyways, I used a null modem cable to my old Thinkpad and got the
following:
OHCI.EXE v1.02.02
Found a OHCI compatible device.
Bus = 0, device = 2, function = 0 IO Base: 0xEB087000
Vendor = 0x10DE Device = 0x0067 rev = 0xA3
Register contents after reset:
00: 0x00000110
04: 0x000006C0
08: 0x00000000
0C: 0x00000000
10: 0x00000000
14: 0x00000000
18: 0x00000000
1C: 0x00000000
20: 0x00000000
24: 0x00000000
28: 0x00000000
2C: 0x00000000
30: 0x00000000
34: 0x00002EDF
38: 0x00002DDB
3C: 0x00000001
40: 0x00000000
44: 0x00000628
48: 0x01000203
4C: 0x00000000
50: 0x00000000
Port 0: 0x00000100
Port 1: 0x00000100
Port 2: 0x00000100
HcHCCA register returns 0xFFFFFF00 for the alignment check.
Found a OHCI compatible device.
Bus = 0, device = 2, function = 1 IO Base: 0xEB082000
Vendor = 0x10DE Device = 0x0067 rev = 0xA3
Register contents after reset:
00: 0x00000110
04: 0x000006C0
08: 0x00000000
0C: 0x00000000
10: 0x00000000
14: 0x00000000
18: 0x00000000
1C: 0x00000000
20: 0x00000000
24: 0x00000000
28: 0x00000000
2C: 0x00000000
30: 0x00000000
34: 0x00002EDF
38: 0x00002DDF
3C: 0x00000001
40: 0x00000000
44: 0x00000628
48: 0x01000203
4C: 0x00000000
50: 0x00000000
Port 0: 0x00000100
Port 1: 0x00000100
Port 2: 0x00000100
Thank you for taking the trouble to do the extra work.
I was thinking about the usb stick version. How could I
get it to execute my tests and still leave the BIOS stable
to write back to the stick? I don't know if it is worth
the test :-)
Anyway, thanks for the effort. It is much appreciated.
Ben
James wrote:
>This still doesn't work on my test PC. I started option 2 and typed
>run. The commands executed. On the first ohci after I pressed Y it
>detected something, scrolled the head of it off the screen and then
>hung round about where it would have presented the command prompt.
>
>Again, if I run it manually and try to pipe the output to a file it
>creates a file with just one byte, 0x0c.
>
>If it helps the end of the screen report includes a line which says
>
> Found a OHCI controller using Port I/O addressing????
This is a first. The OHCI specs say that it will not be Port I/O
addressing. However, with all the other errors in the specs,
this doesn't really surprise me too much.
>The question marks are as they appear. Feel free to ignore my report
>if you wish. Maybe there's some incompatibility with the hardware.
>
>James
>
>Additional: I've since noticed that if I leave it long enough - about
>35 seconds - the rest of the command prompt does appear. It is a USB
>floppy. Could that have something to do with it?
Being a USB floppy, as soon as my tests are run, the floppy drive
will be in the default state, where the BIOS will think it is still
in the address state. It probably tests the bus every so often,
and re-enumerates the bus if needed.
The test will run fine, the write to the floppy will not :-)
Thanks for the effort though. I do appreciate it greatly.
Ben
Uh, I'm curious. What do you mean by that, exactly?... Linux ext2, ext3,
ReiserFS? MS NTFS? FATX? exFAT? HPFS?
With the links below, there might be a few solutions depending on what the
specific issue is.
E.g., if you can boot a CD/DVR with a DOS floppy image, and also have a USB
device, you might be able to use one of the DOS USB drivers to allow
read/write access to the USB device. I.e., once booted, format USB, copy
OHCI.exe to USB, run OCHI.exe on USB device and redirect to it. You should
be able to insert USB device into another machine which can read it.
E.g., if you can boot a CD/DVR with a DOS floppy image, and also have a
Linux partition on the hardisk, you might be able to boot the floppy image,
start a DOS ramdisk (needs to be inserted into image first... as well as
copy or xcopy etc.), run OCHI redirected to ramdisk, and use LTOOLS to copy
output to Linux partition.
You could use Multi-DOS below, or possibly use DOSEMU in Linux. IIRC, Ben
said OHCI.exe wouldn't work from a v86 environment... (?)
Except for perhaps MS' exFAT and FATX, many partition formats are
(supposedly) accessible from DOS:
LTOOLS
http://www.it.fht-esslingen.de/~zimmerma/software/ltools.html
-claims to read Linux ext2, ext3, ReiserFS from DOS or Windows
description of Multi DOS
http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.MultiDOS
- claims DR-DOS based
- claims NTFS, EXT2, EXT3, FAT32, FAT16, HPFS access
description of various NTFS drivers for DOS
http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.NTFS
description of various USB drivers for DOS
http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/index.php?n=Main.USB
Also, these might help to construct a solution:
Plop
http://www.plop.at/en/bootmanager.html
- claims CD/DVD boot w/out BIOS support
- claims USB boot w/out BIOS support
loadlin
http://youpibouh.thefreecat.org/loadlin/
- allows loading of Linux from DOS
Rod Pemberton
[...]
here we go, the only differences to the previous v1.00.00 are:
OHCI.EXE v1.02.02
38: 0x00002EDD ;seems it counted two steps
3C: 0x00000001
Port 0: 0x00000100 (0x00110103)
Port 1: 0x00010101 (0x00110103)
> The new version resets the host *and* the root hub. :-)
And also port 0 but not port 1 ?,
I cannot check anything after your test because it now corrupts
the MCB-chain and needs reboot.
__
wolfgang
> "Anssi Saari" <a...@sci.fi> wrote in message news:vg33a6v...@sci.fi...
>>
>> hard disk isn't DOS accessible
>>
>
> Uh, I'm curious. What do you mean by that, exactly?... Linux ext2, ext3,
> ReiserFS? MS NTFS? FATX? exFAT? HPFS?
Just ext3 and NTFS, so not accessible by vanilla DOS. I could've
reformatted the NTFS to FAT and used that. There's even free space I
could've used for a FAT partition at the end of the disk.
Thanks for the links, they might be useful someday. I did consider
LTOOLS and NTFS4DOS and USB and network drivers for DOS, but I don't
know any of these and didn't want to spend too much time with this. In
addition, LTOOLS is a fairly large package and I didn't know which
files I'd need exactly.
NTFS4DOS on the other hand comes in a 2MB exe file, which looks like a
win32 installer of some sort. Seems crazy to me to distribute a DOS
tool like that, so I didn't want to bother with it. I did take another
look, it looks like a Nullsoft installer. p7zip is supposed to be able
to extract those, but apparently not this one.
So, there are many possibilities, but as it turned out, for the serial
port solution it was enough to add just mode.com to the boot disk. I'm
not sure if even that was necessary, but probably. I needed to test my
null modem cable and also the Thinkpad's serial port. It's in the dock
and I've never used it before. Both worked well, so I got something
useful out of this as well.
> I was thinking about the usb stick version. How could I
> get it to execute my tests and still leave the BIOS stable
> to write back to the stick? I don't know if it is worth
> the test :-)
I kind of wondered about that, but you didn't seem worried so I
assumed the tests would work anyway :)
I am wondering if your BIOS see's the reset and quickly
tries to re-establish contact with the drive, rather than
waiting until first access after the reset. The HcRemaining
register should not be counting down after the reset.
> And also port 0 but not port 1 ?,
> I cannot check anything after your test because it now corrupts
> the MCB-chain and needs reboot.
I don't know why it would corrupt the MCB. I didn't
allocate any memory below 1Meg.
Also, I think your timer tick may be incrementing faster
than normal. Maybe your BIOS has a higher timer tick
rate. The following line
> Port 0: 0x00000100 (0x00110103)
is due to a timer counting down to fast. The first
dword displayed should have showed a connection, but
hasn't yet, then the second dword shown reads the same
register again and does show the connection.
After powering a port, you must wait 2 times the
POTPGT field in milliseconds. If your BIOS's timer tick
is faster than what I think it is, then this will happen.
Currently, I use clock() for timing in the test you used.
I need to make a better timer routine. I want to calculate
a good delay using the RDTSC instruction, but the 386 and
some 486's don't support this instruction.
Do you know of a good millisecond delay() routine
that works on 386's and up, completely independent
of the underlining operating system?
Thanks,
Ben
Thanks and thanks to everyone who has helped so far.
I appreciate the efforts, it has allowed me to verify
some of my research.
Thank you,
Ben
> I am wondering if your BIOS see's the reset and quickly
> tries to re-establish contact with the drive, rather than
> waiting until first access after the reset. The HcRemaining
> register should not be counting down after the reset.
This old BIOS haven't got a boot option for USB, so I think
it just keeps the USB-host in the poweron/reset state.
>> And also port 0 but not port 1 ?,
>> I cannot check anything after your test because it now corrupts
>> the MCB-chain and needs reboot.
> I don't know why it would corrupt the MCB. I didn't
> allocate any memory below 1Meg.
a bug in termination of ohci.exe ?
> Also, I think your timer tick may be incrementing faster
> than normal. Maybe your BIOS has a higher timer tick rate.
No, the PIT got a standart X-tal.
Also the BIOS default setting is 18.2 Hz as expected.
> The following line
>> Port 0: 0x00000100 (0x00110103)
> is due to a timer counting down to fast. The first
> dword displayed should have showed a connection, but
> hasn't yet, then the second dword shown reads the same
> register again and does show the connection.
> After powering a port, you must wait 2 times the
> POTPGT field in milliseconds. If your BIOS's timer tick
> is faster than what I think it is, then this will happen.
Perhaps it's caused by the external (selfpowered) HUB ?
> Currently, I use clock() for timing in the test you used.
> I need to make a better timer routine. I want to calculate
> a good delay using the RDTSC instruction, but the 386 and
> some 486's don't support this instruction.
RDTSC may look more accurate, but I see too much overhead in
comparision with an interrupt driven timer.
> Do you know of a good millisecond delay() routine
> that works on 386's and up, completely independent
> of the underlining operating system?
I use the PIT, set to 04A9h, which seems close enough to produce
1 mSec IRQs, and I use my own IRQ0 handler where I have one
incrementing 32-bit and 15 32-bit 'down until zero' counters.
Also the DOS 55mS-timer (a bit inexact) is optional supported.
So my delays (inserted rather than called) look like:
mov [TimeOut1],delay ;either a contant or from ecx
;sti ;if it isn't enabled
L1: test[TimeOut1],-1
jnz L1
because this delay may vary +0/-1 by the start of the invocation
I usually synchronise critical code, like many hardware needs,
by a 'wait for timer-tick' with the above and a delay of 1.
__
wolfgang
I will double check my test code to make sure I got everything
right.
>>> And also port 0 but not port 1 ?,
>>> I cannot check anything after your test because it now corrupts
>>> the MCB-chain and needs reboot.
>
>> I don't know why it would corrupt the MCB. I didn't
>> allocate any memory below 1Meg.
>
> a bug in termination of ohci.exe ?
Again, I will make sure, but I doubt it.
>> After powering a port, you must wait 2 times the
>> POTPGT field in milliseconds. If your BIOS's timer tick
>> is faster than what I think it is, then this will happen.
>
> Perhaps it's caused by the external (selfpowered) HUB ?
Doubt it. A hub will not change the way the root hub
port works.
>> Currently, I use clock() for timing in the test you used.
>> I need to make a better timer routine. I want to calculate
>> a good delay using the RDTSC instruction, but the 386 and
>> some 486's don't support this instruction.
>
> RDTSC may look more accurate, but I see too much overhead in
> comparision with an interrupt driven timer.
>
>> Do you know of a good millisecond delay() routine
>> that works on 386's and up, completely independent
>> of the underlining operating system?
>
> I use the PIT, set to 04A9h, which seems close enough to produce
> 1 mSec IRQs, and I use my own IRQ0 handler where I have one
> incrementing 32-bit and 15 32-bit 'down until zero' counters.
> Also the DOS 55mS-timer (a bit inexact) is optional supported.
>
> So my delays (inserted rather than called) look like:
>
> mov [TimeOut1],delay ;either a contant or from ecx
> ;sti ;if it isn't enabled
> L1: test[TimeOut1],-1
> jnz L1
>
> because this delay may vary +0/-1 by the start of the invocation
> I usually synchronise critical code, like many hardware needs,
> by a 'wait for timer-tick' with the above and a delay of 1.
The timer I need will need to keep the BIOS's timer tick at
18.2Hz. Either I up the PIT, hook the interrupt, and keep the
value at 0x0046C myself, or find a different way to delay.
All I need to do is have a somewhat accurate delay, plus a
millisecond, no minus at all. i.e.: I must have some way
to know for sure that I have delayed a minimum of count
milliseconds.
If I use RDTSC, and calculate how many times it increments
per second, using the current PIT's count, then I can calculate
how many RDTSC ticks is a millisecond. That will be sufficient
for my needs. However, RDTSC does not work on a 386, or a
few older 486's. I don't know if I want to make the requirement
of a 586 or not, being the RDTSC would be the only thing for
this requirement.
Thanks for your comments and efforts. I will look over my
test code again to make sure I haven't missed something.
Thanks,
Ben
If you don't know, RDTSC doesn't work properly on all post-486 processors...
1) Efficeon cpu's don't throttle the TSC properly. They update the TSC
using _maximum_ cpu frequency which is independent of the actual cpu speed.
2) Also, multiple core cpu's should use RDTSCP, instead of RDTSC. AMD
indicates that even RDTSCP isn't completely accurate on multiple cores (K8)
because of power management events that cause TSC drift.
Rod Pemberton
Okay. I am a little embarrassed to say, but yes there was
a bug in my code. Took me a while to find it. I had updated
some code, but forgot to move one line below the newly updated
stuff. This was reeking havoc on my results in certain situations.
Anyway, would you please try again and let me know what you
find. The new version also uses a much better timer.
http://www.frontiernet.net/~fys/usb_help.htm
Thanks so much to all who have helped.
If you that have helped don't mind, would you please run the
new code. Those who haven't helped yet, why not? :-)
Thanks,
Ben
Hi Rod,
I new the 2nd issue, but not the 1st issue you mention.
Thanks,
Ben
Neo-F again with new OHCI test. Ignoring extra fluff, reg. 38 changed from
0x2E2F to 0x2E00.
******** Copy starting here *******************************************
OHCI.EXE v1.03.00
Found a OHCI compatible device. (0x0)
Bus = 0, device = 2, function = 0 IO Base: 0xFBEBF000
Vendor = 0x10DE Device = 0x036C rev = 0xA1
Register contents after reset:
00: 0x00000110 (HCRevision)
04: 0x000007C0 (HCControl)
08: 0x00000000 (HCCommandStatus)
0C: 0x00000000 (HCInterruptStatus)
10: 0x00000000 (HCInterruptEnable)
14: 0x00000000 (HCInterruptDisable)
18: 0x00000000 (HCHCCA)
1C: 0x00000000 (HCPeriodCurrentED)
20: 0x00000000 (HCControlHeadED)
24: 0x00000000 (HCControlCurrentED)
28: 0x00000000 (HCBulkHeadED)
2C: 0x00000000 (HCBulkCurrentED)
30: 0x00000000 (HCDoneHead)
34: 0x00002EDF (HCFmInterval)
38: 0x00002E00 (HCFmRemaining)
3C: 0x00000000 (HCFmNumber)
40: 0x00000000 (HCPeriodicStart)
44: 0x00000628 (HCLSThreshold)
48: 0x0100120A (HCRhDescriptorA)
4C: 0x00000000 (HCRhDescriptorB)
50: 0x00000000 (HCRhStatus)
Port 0: 0x00000100 (2)
Port 1: 0x00000100 (2)
Port 2: 0x00000100 (2)
Port 3: 0x00000100 (2)
Port 4: 0x00000100 (2)
Port 5: 0x00000100 (2)
Port 6: 0x00000100 (2)
Port 7: 0x00000100 (2)
Port 8: 0x00000100 (2)
Port 9: 0x00000100 (2)
HcHCCA register returns 0xFFFFFF00 for the alignment check.
********* Copy ends here **********************************************
Rod Pemberton
Hey, did you say what, if any, BIOS settings you wanted set/reset prior to
the test?
The Neo-F BIOS has a couple of USB options. One is legacy USB support which
can be auto/disable/enable. When enabled and my external harddisk is turned
on, reg. 3c changes to 1 (from 0). I didn't check the external harddisk on
auto, which is where I usually have it set. The drive was turned off for
the test. Also, 38 was 0x2e02, if that matters. I also have an option in
the BIOS to turn off USB 2.0 (enabled for the test). I'm assuming that
leaves 1.0 enabled... And, I have an option to disable USB completely
(enabled for the test). I didn't try these. Would you like these tested?
Rod Pemberton
3c is also 1 with auto legacy USB when harddisk is on. So, I guess that 3c
is the number of connected devices... (?)
> Also, 38 was 0x2e02, if that matters.
38 was 0x2e03 with auto legacy USB. Some slight variations in this
register.
> I also have an option in
> the BIOS to turn off USB 2.0 (enabled for the test). I'm assuming that
> leaves 1.0 enabled...
This produced differences in port 0 and port 2.
From:
Port 0: 0x00000100 (2)
Port 2: 0x00000100 (2)
To:
Port 0: 0x00010101 (2) (0x00110103) (10)
Port 2: 0x00010101 (2) (0x00110103) (10)
> And, I have an option to disable USB completely
> (enabled for the test).
No OHCI found... PS, it's not wise to do this with USB keyboard... Sigh.
Rod Pemberton
Hi Rod,
>> Hey, did you say what, if any, BIOS settings you wanted set/reset prior
>> to
>> the test?
>>
>> The Neo-F BIOS has a couple of USB options. One is legacy USB support
>> which can be auto/disable/enable. When enabled and my external harddisk
>> is turned on, reg. 3c changes to 1 (from 0). I didn't check the external
>> harddisk on auto, which is where I usually have it set.
>
> 3c is also 1 with auto legacy USB when harddisk is on. So, I guess that
> 3c
> is the number of connected devices... (?)
register 0x3C is the HcFmNumber register.
>> Also, 38 was 0x2e02, if that matters.
>
> 38 was 0x2e03 with auto legacy USB. Some slight variations in this
> register.
Register 0x38 is the HcFmRemainging register.
>> I also have an option in
>> the BIOS to turn off USB 2.0 (enabled for the test). I'm assuming that
>> leaves 1.0 enabled...
>
> This produced differences in port 0 and port 2.
>
> From:
> Port 0: 0x00000100 (2)
> Port 2: 0x00000100 (2)
>
> To:
> Port 0: 0x00010101 (2) (0x00110103) (10)
> Port 2: 0x00010101 (2) (0x00110103) (10)
I am guessing that when it means, turn off USB 2.0, it is disabling
the EHCI controller, and just allowing the OHCI (the EHCI's companion
controller) to operate.
If you have an EHCI controller, it has at least one OHCI or UCHI
companion controller. When the EHCI is enabled, it controls each
of the companion controllers. All USB ports are owned by the EHCI
until you tell it otherwise. Therefore, you must handoff the control
to the companion controllers if you are not going to use the EHCI.
When you disable the EHCI (actually, you are only disabling the BIOS
from using it), the BIOS is telling the EHCI to hand over all ports
to each companion OHCI controller. This is why, when you have
the EHCI enabled, the companion OHCI doesn't see a connection.
I haven't yet, but I plan on adding this function to the test.
I need to see if it has an EHCI, then "disable" it, so that
the OHCI controllers will behave as if they were self contained.
I haven't added this to it yet.
>> And, I have an option to disable USB completely
>> (enabled for the test).
>
> No OHCI found... PS, it's not wise to do this with USB keyboard... Sigh.
If you have USB devices plugged in to the OHCI controller during
the test, the test may be invalid due to the BIOS trying to
"reactivate" the controller during my test. I am fine with
that, as long as I know that is what happened. When the test
shows a connection, this tells me to be careful with the results.
However, if you are willing to do so, please disable all USB
in the CMOS setup before running the test. Thanks.
The test has been very helpful with my research so far. I will
soon have the UHCI and EHCI tests out so that I can verify
my findings of each of those controllers.
Thank you to all who have provided results,
Ben
Also note that EHCI can only support high-speed (480 Mbps) devices, and if the connected device is full- or low- speed, then the companion OHCI/UHCI controller handles it instead.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
You are right, I didn't mention it due to it wasn't relevant
to my post.
Though you make a good point for those who may disable the
EHCI and then wonder why their high speed devices no longer
work. :-)
If anyone changes the USB CMOS settings for my tests, please
restore them back to their original settings after the test
is complete. Thank you.
Ben
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
news:h8ojd8$21mq$1...@news.mtu.ru...
...
> Anyway, would you please try again and let me know what you
> find. The new version also uses a much better timer.
Yeah, Version 1.03 works:
...
38: 0x00002EB6 (HCFmRemaining) ;still in motion? :)
...
Port 0: 0x00010101 (2) (0x00110103) (10)
Port 1: 0x00010101 (2) (0x00110103) (10)
...
I wouldn't care a free running frame counter as long there are
no jobs assigned to it.
Hope your book is available soon.
I'm really curious how you install and handle the Busmasters for
all the needed buffers. I have 'some' real troubles with this.
__
wolfgang
Um... When disabled, no OHCI controller found. Nor was my USB keyboard...
I.e., I couldn't get back into the BIOS to re-enable USB without a PS/2
keyboard. It's just a warning for others.
> If you have USB devices plugged in to the OHCI controller during
> the test, the test may be invalid due to the BIOS trying to
> "reactivate" the controller during my test. I am fine with
> that, as long as I know that is what happened.
Um... 0x3C HcFmNumber goes from zero to one... That's the only diff. I
think I mentioned that previously too. ;)
Otherwise, the rest of the snipped explanation on EHCI was informative. :-)
Rod Pemberton
Hi everyone,
I have added a few more tests. The OHCI has not changed,
but I have added the UCHI and EHCI tests.
These two simply display the initial register values after
reset, nothing more. However, these will help wonderfully.
I will add to these tests as I need to.
Thank you,
Ben
Neo-F motherboard. UHCI and EHCI. OHCI is in another reply.
******** Copy starting here *******************************************
UHCI.EXE v1.00.00
Did not find any UHCI controllers...
********* Copy ends here **********************************************
******** Copy starting here *******************************************
EHCI.EXE v1.00.00
Found a EHCI compatible device. (0x0)
Bus = 0, device = 2, function = 1 IO Base: 0xFBEBEC00
Vendor = 0x10DE Device = 0x036D rev = 0xA2
Capability Registers:
0x00: 0x20 (CAPLENGTH)
0x01: 0x00 (reserved)
0x02: 0x0100 (HCIVERSION)
0x04: 0x00101A8A (HCSPARAMS)
0x08: 0x0000A086 (HCCPARAMS)
0x0C: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
The Light Host Controller Reset is implemented for this controller
Register contents after reset:
20: 0x00080B00 (USBCMD)
24: 0x00001000 (USBSTS)
28: 0x00000000 (USBINTR)
2C: 0x00000000 (FRINDEX)
30: 0x00000000 (CTRLDSSEGMENT)
34: 0x00000000 (PERIODICLISTBASE)
38: 0x00000000 (ASYNCLISTADDR)
3C: 0x00000000 (Reserved)
40: 0x00000000 (Reserved)
44: 0x00000000 (Reserved)
48: 0x00000000 (Reserved)
4C: 0x00000000 (Reserved)
50: 0x00000000 (Reserved)
54: 0x00000000 (Reserved)
58: 0x00000000 (Reserved)
5C: 0x00000000 (Reserved)
60: 0x00000000 (CONFIGFLAG)
Port 0: 0x00001803 (0x00001005)
Port 1: 0x00001000
Port 2: 0x00001000
Port 3: 0x00001000
Port 4: 0x00001000
Port 5: 0x00001000
Port 6: 0x00001000
Port 7: 0x00001000
Port 8: 0x00001000
Port 9: 0x00001000
Thanks again, Rod. I appreciate it.
Ben
Yeah, I'll try to make an effort this week to test some other machines...
RP
Thank you. I will be looking for them.
Thanks,
Ben
Hello Ben,
To be clear, I installed each test on its own floppy, and ran them
from
power on reset or ctrl-alt-del reset.
< Dell Dimension 8250, Pentium 4, OS: XP >
Running of both EHCI and UHCI tests yields the error:
'Can't open C:\CWSDPMI.SWP'
Running the OCHI test doesn't give this error. OCHI Controller not
found.
I don't know.. maybe the hard drive is read only from floppy until XP
is loaded?
But the Dell Dimension 850r doesn't have CWSDPMI.SWP on C:\ either,
and it
performs the tests.
-----------
Older gear; Compaq Presario -win95, Dell Dimension 850r -win98,
Dell Latitude CPi -win98, preform these tests ok. All those three
show a UHCI Controller. All those three show negative for EHCI,
and OCHI.
=============
Latitude CPi
=============
Dell Latitude CPi laptop. Pentium MMX. 1 USB port. -win98 vintage.
******** Copy starting here
*******************************************
UHCI.EXE v1.00.01
Found a UHCI compatible device. (0x1)
Bus = 0, device = 1, function = 2 IO Base: 0x0000ECE0
Vendor = 0x8086 Device = 0x7112 rev = 0x01
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0x7F6CD000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT1 (0x0080)
14: 0x0000 PORT2 not present
********* Copy ends here
**********************************************
================================================
Compaq Presario 4770 Pentium MMX. -win95 vintage
================================================
******** Copy starting here
*******************************************
UHCI.EXE v1.00.01
Found a UHCI compatible device. (0x1)
Bus = 0, device = 1, function = 2 IO Base: 0x00001000
Vendor = 0x8086 Device = 0x7020 rev = 0x01
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0x000EF000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT1 (0x0080)
14: 0x0000 PORT2 not present
********* Copy ends here
**********************************************
=========================================================
Dell Dimension 850r Pentium III 850mhz, BIOS version A09
PhoenixBios 4.0 Release 6.0
Legacy USB Enabled. (in the bios setup). -win98 vintage
=========================================================
******** Copy starting here
*******************************************
UHCI.EXE v1.00.01
Found a UHCI compatible device. (0x1)
Bus = 0, device = 7, function = 2 IO Base: 0x00001440
Vendor = 0x8086 Device = 0x7112 rev = 0x01
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0x000E1000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT1 (0x0080)
14: 0x0000 PORT2 not present
********* Copy ends here
**********************************************
hth,
Steve
;; -=eof=-
>Hello Ben,
>To be clear, I installed each test on its own floppy, and ran them
>from power on reset or ctrl-alt-del reset.
>
>< Dell Dimension 8250, Pentium 4, OS: XP >
>
>Running of both EHCI and UHCI tests yields the error:
>'Can't open C:\CWSDPMI.SWP'
It is trying to open a swap file. The swap file is not
needed. If you don't specifically run the DPMI server
first, the tests will try to load it for you.
If you run the DPMI first, using
cwsdpmi -p -s- <enter key>
Then it won't try to open a swap file.
>Running the OCHI test doesn't give this error. OCHI Controller not
>found.
>
>I don't know.. maybe the hard drive is read only from floppy until XP
>is loaded?
>But the Dell Dimension 850r doesn't have CWSDPMI.SWP on C:\ either,
>and it performs the tests.
<snip data>
>hth,
>
>Steve
It does very much, thank you.
Ben
You're right. The now the tests run. None of the three tests find a
respective controller however. 8-/
The Bios setup settings under the heading of 'Integrated Devices
(Legacy Select Options)' say:
USB emulation [on]
USB Controller [on]
This system has a USB keyboard and mouse, so I'd expect the UHCI test
to report something.
Steve
>You're right. The now the tests run. None of the three tests find a
>respective controller however. 8-/
>
>The Bios setup settings under the heading of 'Integrated Devices
>(Legacy Select Options)' say:
>USB emulation [on]
>USB Controller [on]
>
>This system has a USB keyboard and mouse, so I'd expect the UHCI test
>to report something.
I wonder why. I will update the UHCI test with a command line
parameter to display all PCI functions. Then we can see
if one of them is a UHCI controller that I have just missed.
Thanks. Please watch for the next version by tomorrow afternoon.
Thanks again,
Ben
> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
> news:%QApm.16790$nP6....@newsfe25.iad...
>> Hi everyone,
>>
>> If you feel that you are willing to help with a few tests,
>> please have a look at
>> http://www.frontiernet.net/~fys/usb_help.htm
>>
>> As I continue to research and verify my findings, I will
>> add more tests.
>
> Hi everyone,
>
> I have added a few more tests. The OHCI has not changed,
> but I have added the UCHI and EHCI tests.
Here're mine again, A7N8X Deluxe, Nforce2 chipset.
OHCI.EXE v1.03.00
Found a OHCI compatible device. (0x0)
Bus = 0, device = 2, function = 0 IO Base: 0xEB087000
Vendor = 0x10DE Device = 0x0067 rev = 0xA3
Register contents after reset:
00: 0x00000110 (HCRevision)
04: 0x000007C0 (HCControl)
08: 0x00000000 (HCCommandStatus)
0C: 0x00000000 (HCInterruptStatus)
10: 0x00000000 (HCInterruptEnable)
14: 0x00000000 (HCInterruptDisable)
18: 0x00000000 (HCHCCA)
1C: 0x00000000 (HCPeriodCurrentED)
20: 0x00000000 (HCControlHeadED)
24: 0x00000000 (HCControlCurrentED)
28: 0x00000000 (HCBulkHeadED)
2C: 0x00000000 (HCBulkCurrentED)
30: 0x00000000 (HCDoneHead)
34: 0x00002EDF (HCFmInterval)
38: 0x00002D89 (HCFmRemaining)
3C: 0x00000001 (HCFmNumber)
40: 0x00000000 (HCPeriodicStart)
44: 0x00000628 (HCLSThreshold)
48: 0x01000203 (HCRhDescriptorA)
4C: 0x00000000 (HCRhDescriptorB)
50: 0x00000000 (HCRhStatus)
Port 0: 0x00000100 (2)
Port 1: 0x00000100 (2)
Port 2: 0x00000100 (2)
HcHCCA register returns 0xFFFFFF00 for the alignment check.
Found a OHCI compatible device. (0x0)
Bus = 0, device = 2, function = 1 IO Base: 0xEB082000
Vendor = 0x10DE Device = 0x0067 rev = 0xA3
Register contents after reset:
00: 0x00000110 (HCRevision)
04: 0x000007C0 (HCControl)
08: 0x00000000 (HCCommandStatus)
0C: 0x00000000 (HCInterruptStatus)
10: 0x00000000 (HCInterruptEnable)
14: 0x00000000 (HCInterruptDisable)
18: 0x00000000 (HCHCCA)
1C: 0x00000000 (HCPeriodCurrentED)
20: 0x00000000 (HCControlHeadED)
24: 0x00000000 (HCControlCurrentED)
28: 0x00000000 (HCBulkHeadED)
2C: 0x00000000 (HCBulkCurrentED)
30: 0x00000000 (HCDoneHead)
34: 0x00002EDF (HCFmInterval)
38: 0x00002D9A (HCFmRemaining)
3C: 0x00000001 (HCFmNumber)
40: 0x00000000 (HCPeriodicStart)
44: 0x00000628 (HCLSThreshold)
******** Copy starting here *******************************************
EHCI.EXE v1.00.02
Found a EHCI compatible device. (0x0)
Bus = 0, device = 2, function = 2 IO Base: 0xEB083000
Vendor = 0x10DE Device = 0x0068 rev = 0xA3
Capability Registers:
0x00: 0x20 (CAPLENGTH)
0x01: 0x00 (reserved)
0x02: 0x0100 (HCIVERSION)
0x04: 0x00102486 (HCSPARAMS)
0x08: 0x0000A082 (HCCPARAMS)
0x0C: 0 0 1 1 0 1 0 0 0 0 0 0 0 0 0 0
The Light Host Controller Reset is *not* implemented for this controller
Register contents after reset:
20: 0x00080000 (USBCMD)
24: 0x00001004 (USBSTS)
28: 0x00000000 (USBINTR)
2C: 0x00000000 (FRINDEX)
30: 0x00000000 (CTRLDSSEGMENT)
34: 0x00000000 (PERIODICLISTBASE)
38: 0x00000000 (ASYNCLISTADDR)
3C: 0x00000000 (Reserved)
40: 0x00000000 (Reserved)
44: 0x00000000 (Reserved)
48: 0x00000000 (Reserved)
4C: 0x00000000 (Reserved)
50: 0x00000000 (Reserved)
54: 0x00000000 (Reserved)
58: 0x00000000 (Reserved)
5C: 0x00000000 (Reserved)
60: 0x00000000 (CONFIGFLAG)
Port 0: 0x00001000
Thank you Anssi. I appreciate it greatly.
Ben
Steve,
I have added the -v parameter to the tests. If you will
try again and use the -v parameter, it will display all
PCI devices.
Thank you,
Ben
Ok, I've got two for you today. The first has USB. AFAICT, the second
doesn't have any physical signs of USB. There are no USB ports or USB
pin-headers. But, your program and Win98SE both recognize a USB
controller...
I've got a few other machines, but I'm not going to make any promises. A
few are packed away and/or pre-USB, and another I'm working to "fix"
electrical issues. I do recall one machine had a defective USB. It was
released just prior to standardization of USB 1.0. I think it was an HP,
perhaps Compaq...
#1)
Micron (model unknown), PII 450MHz, PhoenixBios 4.0 Rel. 6.0
Intel 82371 AB/EB UHCI controller
- no OHCI
- no EHCI
- yes UHCI:
******** Copy starting here *******************************************
UHCI.EXE v1.00.00
Found a UHCI compatible device. (0x1)
Bus = 0, device = 7, function = 2 IO Base: 0x00001020
Vendor = 0x8086 Device = 0x7112 rev = 0x01
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0x000E1000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0083 PORT2 (0x0083)
14: 0x0000 PORT2 not present
********* Copy ends here **********************************************
#2)
Pentium-MMX 233Mhz
Intel 82371SB UHCI controller
- no OHCI
- no EHCI
- yes UHCI:
******** Copy starting here *******************************************
UHCI.EXE v1.00.00
Found a UHCI compatible device. (0x1)
Bus = 0, device = 7, function = 2 IO Base: 0x00006000
Vendor = 0x8086 Device = 0x7020 rev = 0x01
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0xF9B5F000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT2 (0x0080)
14: 0x0000 PORT2 not present
********* Copy ends here **********************************************
Rod Pemberton
I am not exactly sure yet, but I think the reason why is that the
mobo has the controller on it, but the computer manufacture wanted
to save money by not adding the physical ports, cables, etc.
I have a machine here that shows a UHCI but no physical USB ports.
> I've got a few other machines, but I'm not going to make any promises. A
> few are packed away and/or pre-USB, and another I'm working to "fix"
> electrical issues. I do recall one machine had a defective USB. It was
> released just prior to standardization of USB 1.0. I think it was an HP,
> perhaps Compaq...
I appreciate your help. Thanks so much.
Ben
-= Dell Dimension 8250, Pentium 4 HT, OS: XP =-
actually the current configuration is USB mouse, ps2 keyboard
connected, USB 2wire pcport (DSL Modem).
******** Copy starting here
*******************************************
UHCI.EXE v1.02.00
* Bus = 0, device = 0, function = 0, type = 0x060000
* Vendor = 0x8086 Device = 0x2530 rev = 0x04
* Bus = 0, device = 1, function = 0, type = 0x060400
* Vendor = 0x8086 Device = 0x2532 rev = 0x04
* Bus = 0, device = 30, function = 0, type = 0x060400
* Vendor = 0x8086 Device = 0x244E rev = 0x04
* Bus = 0, device = 31, function = 0, type = 0x060100
* Vendor = 0x8086 Device = 0x2440 rev = 0x04
* Bus = 0, device = 31, function = 1, type = 0x010180
* Vendor = 0x8086 Device = 0x244B rev = 0x04
* Bus = 0, device = 31, function = 3, type = 0x0C0500
* Vendor = 0x8086 Device = 0x2443 rev = 0x04
* Bus = 1, device = 0, function = 0, type = 0x030000
* Vendor = 0x1002 Device = 0x4E45 rev = 0x00
* Bus = 1, device = 0, function = 1, type = 0x038000
* Vendor = 0x1002 Device = 0x4E65 rev = 0x00
Did not find any UHCI controllers...
>-= Dell Dimension 8250, Pentium 4 HT, OS: XP =-
>actually the current configuration is USB mouse, ps2 keyboard
>connected, USB 2wire pcport (DSL Modem).
>
>******** Copy starting here *******************************
> UHCI.EXE v1.02.00
>
> * Bus = 0, device = 0, function = 0, type = 0x060000
> * Vendor = 0x8086 Device = 0x2530 rev = 0x04
bridge controller / host processor
> * Bus = 0, device = 1, function = 0, type = 0x060400
> * Vendor = 0x8086 Device = 0x2532 rev = 0x04
bridge controller / PCI
> * Bus = 0, device = 30, function = 0, type = 0x060400
> * Vendor = 0x8086 Device = 0x244E rev = 0x04
bridge controller / PCI
> * Bus = 0, device = 31, function = 0, type = 0x060100
> * Vendor = 0x8086 Device = 0x2440 rev = 0x04
bridge controller / ISA bridge
> * Bus = 0, device = 31, function = 1, type = 0x010180
> * Vendor = 0x8086 Device = 0x244B rev = 0x04
mass storage / EDI / 80h
> * Bus = 0, device = 31, function = 3, type = 0x0C0500
> * Vendor = 0x8086 Device = 0x2443 rev = 0x04
serial bus controller / System Managment BUS / 00h
Could this be the controller controlling the USB devices,
but being another protocol. I don't know the
System Management BUS too well, and haven't looked at it
too much. So your guess is as good as mine.
> * Bus = 1, device = 0, function = 0, type = 0x030000
> * Vendor = 0x1002 Device = 0x4E45 rev = 0x00
display controller / vga / 00h
> * Bus = 1, device = 0, function = 1, type = 0x038000
> * Vendor = 0x1002 Device = 0x4E65 rev = 0x00
display controller / Other / 00h
> Did not find any UHCI controllers...
> ********* Copy ends here *******************************
Thanks.
Ben
Thxs, here's a couple more:
Dell XPS D300, Pentium II, OS`Win95, Bios Vers. A05.
******** Copy starting here
*******************************************
UHCI.EXE v1.02.00
* Bus = 0, device = 0, function = 0, type = 0x060000
* Vendor = 0x8086 Device = 0x7180 rev = 0x03
* Bus = 0, device = 1, function = 0, type = 0x060400
* Vendor = 0x8086 Device = 0x7181 rev = 0x03
* Bus = 0, device = 7, function = 0, type = 0x060100
* Vendor = 0x8086 Device = 0x7110 rev = 0x01
* Bus = 0, device = 7, function = 1, type = 0x010180
* Vendor = 0x8086 Device = 0x7111 rev = 0x01
* Bus = 0, device = 7, function = 2, type = 0x0C0300
* Vendor = 0x8086 Device = 0x7112 rev = 0x01
Found a UHCI compatible device. (0x1)
Bus = 0, device = 7, function = 2 IO Base: 0x0000FCA0
Vendor = 0x8086 Device = 0x7112 rev = 0x01
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0xAFDFF000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT1 (0x0080)
14: 0x0000 PORT2 not present
* Bus = 0, device = 7, function = 3, type = 0x068000
* Vendor = 0x8086 Device = 0x7113 rev = 0x01
* Bus = 0, device = 14, function = 0, type = 0x070304
* Vendor = 0x134D Device = 0x7890 rev = 0x02
* Bus = 1, device = 0, function = 0, type = 0x030000
* Vendor = 0x12D2 Device = 0x0018 rev = 0x10
********* Copy ends here
**********************************************
- - - -
Dell Dimension 8400 Pentium 4 HT, OS`XP
******** Copy starting here
*******************************************
UHCI.EXE v1.02.00
* Bus = 0, device = 0, function = 0, type = 0x060000
* Vendor = 0x8086 Device = 0x2584 rev = 0x04
* Bus = 0, device = 1, function = 0, type = 0x060400
* Vendor = 0x8086 Device = 0x2585 rev = 0x04
* Bus = 0, device = 28, function = 0, type = 0x060400
* Vendor = 0x8086 Device = 0x2660 rev = 0x03
* Bus = 0, device = 28, function = 1, type = 0x060400
* Vendor = 0x8086 Device = 0x2662 rev = 0x03
* Bus = 0, device = 29, function = 0, type = 0x0C0300
* Vendor = 0x8086 Device = 0x2658 rev = 0x03
Found a UHCI compatible device. (0x1)
Bus = 0, device = 29, function = 0 IO Base: 0x0000FF80
Vendor = 0x8086 Device = 0x2658 rev = 0x03
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0x7FE92000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT1 (0x0080)
14: 0x0000 PORT2 not present
* Bus = 0, device = 29, function = 1, type = 0x0C0300
* Vendor = 0x8086 Device = 0x2659 rev = 0x03
Found a UHCI compatible device. (0x1)
Bus = 0, device = 29, function = 1 IO Base: 0x0000FF60
Vendor = 0x8086 Device = 0x2659 rev = 0x03
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0x7FE93000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT1 (0x0080)
14: 0x0000 PORT2 not present
* Bus = 0, device = 29, function = 2, type = 0x0C0300
* Vendor = 0x8086 Device = 0x265A rev = 0x03
Found a UHCI compatible device. (0x1)
Bus = 0, device = 29, function = 2 IO Base: 0x0000FF40
Vendor = 0x8086 Device = 0x265A rev = 0x03
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0x7FE94000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT1 (0x0080)
14: 0x0000 PORT2 not present
* Bus = 0, device = 29, function = 3, type = 0x0C0300
* Vendor = 0x8086 Device = 0x265B rev = 0x03
Found a UHCI compatible device. (0x1)
Bus = 0, device = 29, function = 3 IO Base: 0x0000FF20
Vendor = 0x8086 Device = 0x265B rev = 0x03
Register contents after reset:
00: 0x0000 USBCMD (USB Command)
02: 0x0020 USBSTS (USB Status)
04: 0x0000 USBINTR (USB Interrupt)
06: 0x0000 FRNUM (Frame Number)
08: 0x7FE95000 FRBASEADD (Frame Base Address)
0C: 0x40 SOFMOD (Start of Frame Modify)
0D: 0x00 Unknown
0E: 0x00 Unknown
0F: 0x00 Unknown
10: 0x0080 PORT0 (0x0080)
12: 0x0080 PORT1 (0x0080)
14: 0x0000 PORT2 not present
* Bus = 0, device = 29, function = 7, type = 0x0C0320
* Vendor = 0x8086 Device = 0x265C rev = 0x03
* Bus = 0, device = 30, function = 0, type = 0x060401
* Vendor = 0x8086 Device = 0x244E rev = 0xD3
* Bus = 0, device = 30, function = 2, type = 0x040100
* Vendor = 0x8086 Device = 0x266E rev = 0x03
* Bus = 0, device = 31, function = 0, type = 0x060100
* Vendor = 0x8086 Device = 0x2640 rev = 0x03
* Bus = 0, device = 31, function = 1, type = 0x01018A
* Vendor = 0x8086 Device = 0x266F rev = 0x03
* Bus = 0, device = 31, function = 2, type = 0x010601
* Vendor = 0x8086 Device = 0x2652 rev = 0x03
* Bus = 0, device = 31, function = 3, type = 0x0C0500
* Vendor = 0x8086 Device = 0x266A rev = 0x03
* Bus = 1, device = 0, function = 0, type = 0x030000
* Vendor = 0x1002 Device = 0x5B60 rev = 0x00
* Bus = 1, device = 0, function = 1, type = 0x038000
* Vendor = 0x1002 Device = 0x5B70 rev = 0x00
********* Copy ends here
**********************************************
Steve
<s_dub...@yahoo.com> wrote in message
news:dfdadaa3-f3fc-4c98...@g6g2000vbr.googlegroups.com...
On Sep 22, 8:12 pm, "Benjamin David Lunt" <zf...@frontiernet.net>
wrote:
> <s_dubrov...@yahoo.com> wrote in message
>
Thxs, here's a couple more: