Jump to content

Patched LaCie USB 3.0 driver

Zenith432

By Zenith432,
in Other Peripheral Devices

 Share
20 posts in this topic

Recommended Posts

Zenith432
Zenith432
Posted
Posted

The USB 3.0 NEC/Renesas chipset driver recently published by LaCie floods syslog with status messages during boot. It has a high logging level set by default. I've bin-patched it to reduce the logging level back to sanity.

Attached is the patched kext.

 

Diff of a binary dump of the change (loglevel bitmask changed from 7 to 1)

7729c7729
< 001e300: 0700 0000 5058 4843 4420 0000 0000 0000 ....PXHCD ......
---
> 001e300: 0100 0000 5058 4843 4420 0000 0000 0000 ....PXHCD ......
19219c19219
< 004b120: 0000 0000 0700 0000 5058 4843 4420 0000 ........PXHCD ..
---
> 004b120: 0000 0000 0100 0000 5058 4843 4420 0000 ........PXHCD ..

 

Edit (Dec 2nd, 2012) - Attachment removed, see post #7 by shiecldk for combined patch that fixes log flooding + enables super-speed for non-LaCie devices.

  • Like 3
Link to comment
Share on other sites
shiecldk
shiecldk
Posted
Posted

Awesome!

 

Do you know how to remove LaCie's USB 3.0 device check?

 

Modbin's patch works, but the device speed is showed as 480 Mb/sec in system info.

Also, the transfer speed is slow at the beginning, which is about 35mb/s, because the device is recognized as USB 2.0 device.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted

Honestly, I haven't a clue what you're talking about. I searched the web for Modbin's patch, and it's dated 11 November 2010 and talks about "removing security". My patch is for LaCie v1.0.11 which was released 22 October 2012 (see link in my post). I have no idea what "security" needs to be removed.

 

The driver matches statically on the exact NEC/Renesas chip in Info.plist

  <key>IOPCIClassMatch</key>
  <string>0x0c033000</string>
  <key>IOPCIPrimaryMatch</key>
  <string>0x01941033</string>

Now, 0x0c033000 is the universal PCI class code for XHCI USB 3.0 controllers. OTOH, 0x01941033 is the specific ID for Renesas. If you remove the IOPCIPrimaryMatch from Info.plist, it will match on any XHCI controller. Whether the driver code will actually work with other XHCI controllers I haven't a clue. I only searched the code for the logging issue, not completely reverse-engineer it !.

  • Like 1
Link to comment
Share on other sites
shiecldk
shiecldk
Posted
Posted

Honestly, I haven't a clue what you're talking about. I searched the web for Modbin's patch, and it's dated 11 November 2010 and talks about "removing security". My patch is for LaCie v1.0.11 which was released 22 October 2012 (see link in my post). I have no idea what "security" needs to be removed.

 

The driver matches statically on the exact NEC/Renesas chip in Info.plist

<key>IOPCIClassMatch</key>
<string>0x0c033000</string>
<key>IOPCIPrimaryMatch</key>
<string>0x01941033</string>

Now, 0x0c033000 is the universal PCI class code for XHCI USB 3.0 controllers. OTOH, 0x01941033 is the specific ID for Renesas. If you remove the IOPCIPrimaryMatch from Info.plist, it will match on any XHCI controller. Whether the driver code will actually work with other XHCI controllers I haven't a clue. I only searched the code for the logging issue, not completely reverse-engineer it !.

Sorry, I should have mentioned it in my post...

 

This is Modbin's patch:

9F 05 74 --> 9F 05 EB

 

If you don't apply this patch, only USB2.0 drives can be connected.

 

I know by removing IOPCIPrimaryMatch can make all XHCI controller identified.

I have one uPD720202 identified in system info, but it can't work (no response when any drive is connected).

While my uPD720200 works fine.

  • Like 1
Link to comment
Share on other sites
  • 3 weeks later...
Zenith432
Zenith432
Posted
  • Author
Posted
Modbin's patch works, but the device speed is showed as 480 Mb/sec in system info. Also, the transfer speed is slow at the beginning, which is about 35mb/s, because the device is recognized as USB 2.0 device.

FYI, PXHCD.kext does not support super-speed at all. All super-speed capable devices run at high-speed. Modbin's patch simply allows it to work with non-Lacie devices.
  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted

The result on my setup (Maximus V Formula + 10.6.8)

Notice the line
Vitesse: Jusqua 480 Mb/s
The drive is being operated at high speed. For super-speed it would say 5 Gb/s. I'm not sure which Transcend Jetflash you have, but some of them are super-speed. PXHCD operates all super-speed capable drives at high-speed. There's no programming in it to support super-speed mode on a device.

 

This is what it should look like for super-speed

98ff237f52c6daf820c234d82058747302e3b48224798cdb2827852064abab6f6g.jpg

  • Like 1
Link to comment
Share on other sites
shiecldk
shiecldk
Posted
Posted

Notice the line

The drive is being operated at high speed. For super-speed it would say 5 Gb/s. I'm not sure which Transcend Jetflash you have, but some of them are super-speed. PXHCD operates all super-speed capable drives at high-speed. There's no programming in it to support super-speed mode on a device.

 

This is what it should look like for super-speed

That explains why the speed sometimes stucks at 40mb/s.

Dose AppleUSBXHCI.kext work well with uPD720200? Have you tried the new driver in OS X 10.8.3?

 

 

Btw, these are the results with PXHCD.kext:

 

System info:

 

 

727pq.png

 

 

 

Sometime the USB 3.0 drive can't be mounted on the USB 3.0 port.

When it mounts, kernel log shows these (with the alignment error):

12/23/12 3:19:25.000 PM kernel[0]: USBF: 9976. 5 Endpoint 0x81 of the USB device "Backup+ Desk" at location 0x3c200000: converting Bulk MPS from 1024 to 512 (USB 2.0 Spec section 5.8.3)
12/23/12 3:19:25.000 PM kernel[0]: USBF: 9976. 5 Endpoint 0x2 of the USB device "Backup+ Desk" at location 0x3c200000: converting Bulk MPS from 1024 to 512 (USB 2.0 Spec section 5.8.3)
12/23/12 3:19:25.000 PM kernel[0]: disk6s3: alignment error.

When it doesn't mount:

12/23/12 3:21:45.000 PM kernel[0]: USBF: 10115.590 Endpoint 0x81 of the USB device "Backup+ Desk" at location 0x3c200000: converting Bulk MPS from 1024 to 512 (USB 2.0 Spec section 5.8.3)
12/23/12 3:21:45.000 PM kernel[0]: USBF: 10115.590 Endpoint 0x2 of the USB device "Backup+ Desk" at location 0x3c200000: converting Bulk MPS from 1024 to 512 (USB 2.0 Spec section 5.8.3)

 

Speed Tests:

 

It always performed like USB2.0 at the beginning when the USB3.0 drive was connected:

hW8au.png

 

After a few tests, it became more like USB 3.0:

PUINo.png

 

 

 

The write speed was 60mb/s at the beginning. Then it became to 150mb/s within 10 seconds:

NwHoI.jpg

 

 

  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted
Btw, these are the results with PXHCD.kext:
It's possible PXHCD is reporting the device as high-speed to IOUSBFamily, but running it at super-speed at the port. IOUSBFamily doesn't restrict the speed of bulk transfers, so they can go above the 'official' limit.
  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted
Dose AppleUSBXHCI.kext work well with uPD720200?
I did a 2GB sequential read test with 4K blocks.

Didn't do a write test because the filesystem is not HFS. The read test was raw data off the drive.

  • In Windows, various benchmarks give about 70 MB/s for a read test.
  • In Linux, I got 72 MB/s for above test.
  • With patched AppleUSBXHCI (on Renesas port) I got 28 MB/s for above test.
  • With AppleUSBEHCI on a USB 2.0 port I got 11 MB/s for above test.
  • With PXHCD (on Renesas port) I got 4 MB/s for above test.

Go figure... :|

 

[bTW I tried 1KB and 2MB block sizes, and it didn't make much difference.]

  • Like 1
Link to comment
Share on other sites
shiecldk
shiecldk
Posted
Posted

I did a 2GB sequential read test with 4K blocks.

Didn't do a write test because the filesystem is not HFS. The read test was raw data off the drive.

  • In Windows, various benchmarks give about 70 MB/s for a read test.
  • In Linux, I got 72 MB/s for above test.
  • With patched AppleUSBXHCI (on Renesas port) I got 28 MB/s for above test.
  • With AppleUSBEHCI on a USB 2.0 port I got 11 MB/s for above test.
  • With PXHCD (on Renesas port) I got 4 MB/s for above test.

Go figure... strong>ression.gif

 

[bTW I tried 1KB and 2MB block sizes, and it didn't make much difference.]

Could you share your patch method for AppleUSBXHCI?

Did you just add device-id and vendor-id into the kext?

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted

Could you share your patch method for AppleUSBXHCI?

Ha? It's in the other thread. If your question is what the patch does, there are 4 changes
  1. Inhibit a check if the xhci chip is either Intel Panther Point or Fresco Logic.
  2. Inhibit a check if xhci version is >= 1.0 (Renesas says 0.96).
  3. Disable option to use PCI messaged interrupts, as this doesn't work with Renesas (PXHCD uses legacy pin interrupt as well.) Strangely Renesas' Windows driver does use messaged interrupts. I guess the Apple code dosn't handle MSI right.
  4. Disable one place where it reads an Intel-specific PCI register (0xD0) that isn't found in other chipsets. Strangely, other places in the code that access these Intel-specific registers do check if the chipset is Intel first. I guess it's an oversight.

Looks like I'm going to have to patch more stuff in the sleep code.

  • Like 1
Link to comment
Share on other sites
shiecldk
shiecldk
Posted
Posted

Ha? It's in the other thread. If your question is what the patch does, there are 4 changes

  1. Inhibit a check if the xhci chip is either Intel Panther Point or Fresco Logic.
     
  2. Inhibit a check if xhci version is >= 1.0 (Renesas says 0.96).
     
  3. Disable option to use PCI messaged interrupts, as this doesn't work with Renesas (PXHCD uses legacy pin interrupt as well.) Strangely Renesas' Windows driver does use messaged interrupts. I guess the Apple code dosn't handle MSI right.
     
  4. Disable one place where it reads an Intel-specific PCI register (0xD0) that isn't found in other chipsets. Strangely, other places in the code that access these Intel-specific registers do check if the chipset is Intel first. I guess it's an oversight.

Looks like I'm going to have to patch more stuff in the sleep code.

Awesome.....

I'll give it a try!

Link to comment
Share on other sites
  • 3 months later...
marcelol
marcelol
Posted
Posted

This is the patched 1.0.11 driver with the removed info.plist entry, just as in 1.0.10.

While it DOES now see a root USB 3.0 HUB, it DOES NOT, however, see any drives attached to the HUB itself. Therefore, one step forward,

1/2 step back.

 

It DOES generate more logging information ( which could prove useful to some ). At this point, perhaps once the Generic UHCI driver gets more stable,

it might be worth it to switch to it, but I don't see LaCie updating this one much further, boys and girls.

 

Enjoy.

PXHCD_1.0.11.kext.zip

Link to comment
Share on other sites
  • 2 years later...
  • 8 months later...
 Share
Go to topic listing
×
×
  • Create New...