spamme0 said:
Paul said:
spamme0 said:
Paul wrote:
spamme0 wrote:
Paul wrote:
spamme0 wrote:
Nope, I don't...that was George's system.
OK, so start with a hardware inventory of your ZX-5360.
What chipset does it use ? What does Everest tell you ?
*******
OK, I can see your system here.
http://www.fryssupport.net/ZX-5360.cfm
VIA K8N800+VT8235M-CE
4- USB 2.0 ports [would be on VT8235M-CE]
Check with Everest, and see if it agrees.
HTH,
Paul
Do programs like Everest actually interrogate the hardware?
Or do they just ask the OS what it installed?
I downloaded the Everest trial and will install it.
I've been using SIW and PC Wizard
SIW gives me these answers:
Under USB ports it finds Via Rev 5 or greater 1106/3038
Under hardware info, it says it's a K8M400 CPU to PCI bridge
and VT8235 PCI to ISA bridge.
Under PCI, it claims to have a VT82xxxxx UHCI USB 1.1 Controller
(All VIA chipsets)
Fry's and SIW disagree over what USB support is provided.
mike
I was not able to find a specific product page for VT8235M-CE.
What I did do, is check the specs for a few other things
that use VT8235M-CE, and they claim to have 4 USB2 ports as
well.
OK, I went back to the Fry's site, and they've already
answered this question
Have a look.
http://www.fryssupport.net/supportZX5360.cfm
"please make sure the “Legacy USB support” option in
the bios advance setup is set to AUTO"
Yes, that was the first thing I tried.
I previously said that I'd tried that more than once. Tried on/off/auto
nothing works.
Still haven't had a chance to retry deleting drivers in safe mode.
I'll get on it.
I'm wondering if I might have to set the legacy support to auto mode
BEFORE windows gets installed.
PITA to try it, but I don't have a better idea.
mike
HTH,
Paul
There is no point deleting the USB stack just yet.
I believe you should be able to see "pci\ven_1106&dev_3104", the
identity of the USB2, in Everest, even before a driver is installed.
There would not be much point in trying to install it, unless it
claims to be present. This is the Everest I use (it is old, but
for newer hardware which isn't identified, I can still use the ven/dev
info).
http://majorgeeks.com/download4181.html
For example, on my VIA chipset, if I look in Devices
CI Devices,
I can see the VIA USB 2.0 Enhanced Host Controller, with Device ID
1106-3104. If I saw that, then I'd know that efforts to install
it could succeed. If the device is still not listed, then the
problem (as described by Fry's), is still in the BIOS.
Also, have a look in "setupapi.log" file, and search for "3104".
See if at any point, the OS has attempted to deal with that hardware.
Maybe a partial explanation is already in setupapi.log.
Paul
Ok, I blew away windows and did a fresh install of XPHomeSP3.
I installed everest 220.
It gives me more detail of the same info.
The USB Controller is pci/ven_1106&dev_3038&SUBSYS_0F601019&REV_80
PCI Devidce is VIA VT83C572 PCI-USB Controller
IRQ is 21
There are three instances of USB host controller sharing INT21. Nothing
else.
Port is E400-E41F
The chipset now shows as VIA K8M800/K8N800 Chipset
Still no mention of "enhanced" in device manager.
Still get "this device can perform faster..." when inserting
my flash drive.
I searched setupapi.log for 3104. No hits.
I get many instances of 3038 in the usb section.
Searching for "enhanced" gets two hits in the keyboard section.
No hits on "ehci".
Your comments suggest that the device ID's are read from the bios
and not the chips themselves??? That gets me back to my very first
question. Is there any way to override that info and FORCE windows
to use the enhanced driver? I've already blown away the OS. As long
as I don't actually write anything to CMOS, I've got nothing to lose.
I guess I should mention that I did find a BIOS update for the ECS-536.
I'm afraid to apply it lest I brick the Fry's variant 536S.
I'd rather have a working computer with USB1.1.
If the Fry's machine shipped with USB2.0, the existing BIOS should at
least load the right drivers. I tried to edit the hardware ID strings
in regedit, but it won't let me. Probably just as well ;-)
Color me frustrated...
I also feel like I'm wasting a bunch of your time.
I appreciate the effort.
Any other ideas?
Thanks, mike
Enumerations are read directly from the hardware. Or at least I hope they
are, because it would be pretty useless if Everest was just mining
WinXP for info.
In the lab, on embedded computers, our startup code probes each PCI
slot address, and says "anybody home ?". If a device responds, and
further probes in the config space, extract information, then you know
there is a device present. A methodical probing, checking everywhere,
ensures that everything that can be detected, is detected.
A number of hardware buses support that kind of probing. Some bus
standards provide less info than others (which makes it a bit harder
to be sure what is sitting on the bus - an example is the kind of
thing Speedfan does, when it looks for fan controllers - the enumeration
recipe is rather complicated).
Your evidence suggests, the Fry's BIOS is leaving USB2 disabled. Hardware
devices may have a mechanism, where the BIOS can set a bit in the registers
of the device, to prevent it from responding to later probes. The Fry's
BIOS could be doing that. And that could be why the "3104" is not responding.
Having the BIOS fiddle with the controls, is not absolute. For example,
on my motherboard, I can disable the IDE devices in the BIOS (in an attempt
to make my hard drive invisible), and Linux can still find the disk drives.
So Linux could turn the interfaces back on again, which I didn't want.
In the case of the Windows ATI video driver, the ATI software is able to change
AGP settings on the fly (so attempts to set the BIOS to AGP 4X, could be
met by the ATI driver setting the AGP slot to AGP 8X). It is not, like
what the BIOS is doing, is absolute. If that bit is flipped later,
and the hardware rescanned, the hardware could then be discovered.
My conclusion at this point, is the BIOS is to blame. I don't see this
as a hardware problem as such.
There are other methods, for the BIOS to pass info about hardware, to the
operating system. For example, for "standard" hardware devices, the BIOS
passes "ACPI objects" via ACPI data tables. At least some of the Everest
entries you see, will be of that type. Your USB entries however, are
sitting on the bus (sort of a PCI bus, but internal to the
chipset), and they should be detectable via bus probes that
return four instances of 1106-3038 and one instance of 1106-3104.
The fact that the 1106-3038 is fully working, suggests the problem
is that 1106-3104 is turned off by the BIOS.
Is there a tool to fix this ? Yes, there is.
A number of years ago, people used WPCREDIT by H.Oda, to change
the registers in their chipset. You need someone to map out the
chipset for you, and tell you *exactly* which byte to change.
Changing any adjacent bytes, can cause the computer to crash
instantly. So there is a tool -- but it is a lot like playing
with dynamite in a dark room. You would flip a bit to turn
on USB2, then rescan in Device Manager and see if new hardware
was detected. That would be the basic method.
http://hp.vector.co.jp/authors/VA002374/img/soft/wpcredit.jpg
http://hp.vector.co.jp/authors/VA002374/src/download.html
http://www.h-oda.com/
Example of hacking with WPCREDIT, back in the day.
http://www.sudhian.com/index.php?/articles/show/VIA_Apollo_Pro_memory_tweak_guide/
http://www.sudhian.com/index.php?/articles/show/VIA_Apollo_Pro_memory_tweak_guide/page_2
(There is a companion tool called WPCRSET, to apply the changes each
time the OS starts up. It is mentioned in this article. This isn't important
right now, because you're not likely to get a PCR file with register
definitions to make editing in WPCREDIT easy.)
http://www.myplc.com/sony/agp_aperture.htm
Modern OSes make this kind of hacking more difficult, by requiring
something to punch through "Ring 0" protection, so you can edit
the hardware values. As a consequence, I wouldn't want to guess as
to which OSes WPCREDIT currently works with. If the program
is prepared for this possibility, it may have a copy of "giveio" or
the like, to allow the program to edit hardware. Normally, software
programs don't control hardware directly, they go through restrictive
drivers.
The only danger from spontaneously crashing your OS, is the possibility
that the file system will be corrupted. As long as you have a good
backup plan, or recovery media, then you should be good-to-go. For example,
if you somehow wiped out the partition table on the hard drive, you'd want
a restoration method, which can put every byte of the hard drive, back
in place.
The level of danger, depends on the reliability of the chip register map
you've got to work with. Intel makes this simple, as Intel offers datasheets,
so you can do all the work yourself. Companies like VIA, don't give out
datasheets to just anyone. You need a business card, and a pesky
salesman will call on you, and so on...
*******
BIOS flashing is equally dangerous. It can be made less dangerous,
with devices such as "BIOS Savior" from ioss.com.tw . But for a laptop,
that isn't an option (no room physically).
Installing one of these, gives you an extra BIOS flash memory chip.
It allows flashing experimental BIOS files, and if the flash fails,
you flip a selector switch, and return to the "good working" BIOS chip.
This is how people used to work with Nforce2 boards, to test out BIOS
files. (Now that many desktop boards use smaller serial BIOS chips,
this product is physically no longer compatible. But in its time,
if you were a BIOS hacker, it was money well spent.)
http://www.ioss.com.tw/web/English/RD1BIOSSavior.html
*******
I get the impression, you know the Fry's machine is the same as some
ECS machine. You need to find a forum where people have experimented
with the machine, and know the ECS BIOS will "take" if you flash it.
You also need to know what the odds are of "bricking" the machine,
with the tools provided. At the very least, when playing with the BIOS,
your very first step, is to archive the existing BIOS contents, then
place that file somewhere, where you can find it in an emergency.
For example, a backup of my original motherboard BIOS, is sitting on the root
of my C:\ drive, (which I made a FAT32 volume on purpose). If necessary,
I can boot using my DOS floppy, and the original BIOS is there if I need
to flash back to factory conditions. So bare minimum, don't use any
flashing tool, unless it has an option to archive the existing BIOS
file. In some cases, once you flash the new BIOS (like the ECS), you
may not be able to go back to the "Fry's" BIOS. That depends on the
identity string. Some flasher tools have a "force" option, to flash
regardless of identity. If Fry's is simply shipping an ECS barebones,
with their name on it, it may be using the ECS BIOS provided with the
product, rather than rewriting or changing it. So it could just be
an ordinary ECS BIOS all along.
Note that, when you flash a BIOS, then restart the computer at least once,
the "image" inside the BIOS chip, won't match what you burned. A couple
small sections of the BIOS chip are writable at the startup of the computer,
and DMI/ESCD live there. Thus, if attempting to "compare" BIOS files,
remember that for two BIOS to be "equal", not all the bytes have to
match. Only the executable code sections would have to match, for the
BIOS to be "equal". Anything which is regularly updated, should not be
part of an equivalence check. I learned this the hard way, by
experimenting, and finding my new BIOS didn't seem to be the same
any more
Good luck,
Paul
