View Single Post
  #4  
Old October 20th 15, 06:29 PM posted to alt.comp.periphs.mainboard.gigabyte,alt.windows7.general
Paul
external usenet poster
 
Posts: 13,364
Default GA-Z68MX-UD2H-B3 USB 3.0 port will not open USB 2.0 storagedevices

Bob F wrote:


This seems to be replacement firmware for the etron chip. Have you actually
installed this? I get a little nervous about replacing such firmware.

Would it then work with the 2013 driver from gigabyte's site?


I don't have an EJ168 chip here, and have no first hand experience
with it.

All I can tell you, is there were lots of comments about the
first Etron driver materials and how well they were working.
Leading some to suggest maybe the chip wasn't compliant with
USB3 or something. But later, I saw less comments about
Etron. Either people stopped using it, or, the driver/firmware
or whatever, improved.

I can't say any more than that.

Lots of stuff has firmware, and one intention of such things,
is to allow field repair or behavioral changes to hardware.
I can't imagine an 8 bit processor in there trying to keep
up with the packet rate of a 500MB/sec stream, but they must
have put firmware there for a reason.

There are a couple kinds of processing elements they could
use. Because I've used these in my own designs. You can design
"state-machine-like" things, which are primitive processors
with crude branching capabilities. Those run synchronous to
the hardware, and handle incoming packets and so on. But the
other kind, is the "management processor", which could be
the equivalent of an 8085 processor. I have no idea in this
case, what type it would be, as I don't see how an 8085 style
processor would be of much usage.

On things like wireless chips, it's a bit more predictable.
If you want features such as wake-on-lan on Wifi, there is a
processor to manage the MAC. Or, maybe the Wifi is to be
run in "keep alive" mode, where the wifi chip transmits
occasionally, to keep the router from timing out a connection.
When the computer sleeps, the processor inside the Wifi chip
may be powered and continue to run. And that would be a
reason for the Wifi chip to have "firmware", code to
define the behavior, patch bugs and so on.

I would hope the firmware and driver code would be a consistent
set carried inside the same installer file, but what do I know.
When Promise Technologies would release code for Promise IDE
cards (UltraATA 133), the code and driver were released as a
set, with the idea that they would be compatible. And that's
because the developers simply cannot resist the temptation to
change data structures or otherwise make the driver and firmware
behavior "mismatch". It seems only old-school developers know
how to freeze an interface spec.

Paul