View Single Post
  #6  
Old October 21st 15, 12:39 AM posted to alt.comp.periphs.mainboard.gigabyte,alt.windows7.general
Bob F
external usenet poster
 
Posts: 153
Default GA-Z68MX-UD2H-B3 USB 3.0 port will not open USB 2.0 storage devices

Bob F wrote:
Paul wrote:
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.


At second inspection, this firmware seems to be for the Ej188 rather
than the Ej168A which is on my board. I assume that won't work for
me. I haven't found any discussion to suggest otherwise.

I did find a .119 driver on that same site. I currently have .118.
I'll give that a try.


No change with .119 driver








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