-
Jmicron Linux Drivers For Mac
- The 'JMicronATA.kext' in S/L/E is an old 32-bit only driver for the JMicron JMB368 chip. Your motherboard uses the JMicron JMB362 for IDE and additional SATA which my drivers support.
- My motherboard is an ASUS P7P55D E-LX model. My 2 dvd-rw drives & hard drive are connected to the 3 SATA connectors but none connected to the JMicron JMB361 IDE Connector & the driver's installed.
The is a 2-port SATA + 1-port PATA controller chip often found embedded in motherboards and in low-cost add-on cards. The chip supports operating in IDE, AHCI, and RAID controller modes. Motherboard BIOSes allow choosing the operating mode, but add-on cards are stuck in RAID mode. The problem with RAID mode is that standard AHCI drivers cannot be used. A JMicron-specific driver is available only for Windows.
Sep 22, 2018 - -d sat[,16]; -d sat,12, requires '-d sat[,16]', Older Linux kernels may require '-d sat,12'. JMicron ATA pass-through, JMicron JM20329, JM20335-39, Prolific. The OS X SAT SMART Driver provides access to SMART data for.
Some OSes (Linux, drivers/pci/quirks.c) set a PCI configuration register to put the controller into AHCI+IDE mode after booting and use standard drivers. Other OSes (Mac OS X) do nothing and can’t use the card.
I attempt to solve this problem by hacking the JMB363 option ROM to put the card into AHCI mode, with partial success. The two SATA ports work in OS X, including hot-plugging, but I could not get the parallel ATA enabled, and I had to bypass loading the option ROM (thus, can’t boot from the SATA ports anymore). The patched ROM might also be useful for other OSes that don’t have Linux-style PCI quirks. Option ROMs. Patch three uses of PCI configuration register 0xdf1:0 to read 2’b10. This seems to put the controller in AHCI mode. Also patch two uses of 0xdf6 to read 1’b1 and writes 0xa1 to configuration register 0x41.
This bypasses the option ROM and keeps the SATA ports enabled. Hacking the Option ROM I used the newest version of the option ROM (1.07.24) posted at JMicron’s. Some hints about the configuration of the JMB363 can be found in JMicron’s, particularly about PCI configuration register 0xdf. The release notes hints at the existence of a newer 1.07.28, but it wasn’t posted. Linux’s drivers/pci/quirks.c gave some hints about the meaning of PCI configuration register 0x40-43. Configuration Register 0xDF PCI configuration register 0xdf seems to be intended for main BIOS to communicate its settings to the option ROM, rather than having a direct effect on the hardware. Bits 1:0 seem to indicate controller mode.
Bits 7:6 and 5:4 look like they control two instances of the same thing because the code that parses them is structured the same way. The release notes say bit 6 is used to put the chip into “multi-function” mode with the option ROM disabled, which feels a little bit like a hack to me. Bits 3:2 don’t appear to be used.
Df6 df1:0 Result 0 00 Default, RAID mode 0 01 IDE device (class 0101) 0 10 AHCI device (class 0106) 0 11 IDE device (class 0101) 1 00 RAID device (class 0104), no option ROM 1 01 AHCI device (class 0106), no option ROM 1 10 AHCI device (class 0106), no option ROM 1 11 AHCI device (class 0106), no option ROM It seems like bits 1:0 select the card mode (RAID, IDE, AHCI, IDE?), with the value 2’b11 probably not intended to be used (the option ROM code only distinguishes between 2’b00, 2’b01, and other). Since setting df6 causes “jump out of Option ROM, do nothing” (See release notes for v1.03), it is no longer possible to boot from any disks attached to the chip. In no case did setting 0xdf6 cause the JMB363 to become a multi-function device.
I speculate its purpose is to disable the option ROM, allowing the main BIOS to set up the rest of the device configuration without interference. Register df6 is used by the option ROM code at offset 0x3517. Registers df7:6 and df5:4 are used at offsets 0x372d and 0x3756, respectively. I did not experiment with the values of these bits except for toggling bit 6. They seem important, causing PCI config register bits 0xed5:2 and 0xcd5:2 to be set when df7:6 and df5:4, respectively, is 2’b01 or 2’b10. Register df1:0 is used in the option ROM at offset 0x3553, 0x3574, and 0x37c1 Configuration Register 0x40-43 These configuration registers seem to control the hardware directly.
The option ROM sets them but doesn’t read them. Register Function 43 Defaults to 0x80.
Unknown purpose. 42 Seems to take values of 0xc2 or 0x82. Bits 1:0 depends on 0xdf1:0, with a special case when 0xdf6 is set. Unknown purpose. 41 Bits 7:4 affect the SATA ports with 7:6 controlling SATA1, 5:4 controlling SATA0.
Jmicron Jmb36x Driver Windows 10
Bits 3:0 unknown. Option ROM sets this to either 0xf1 or 0x51. 40 Bit 1 appears to control whether the second PCI function is enabled. Other bits unknown. Linux (drivers/pci/quirks.c) modifies this configuration register, which results in 0x80c2a1bf on my card.
I tried modifying the option ROM to also configure register 0x40-43 to this value, but had many problems booting. Either I’m getting some of the other configuration bytes wrong or this value is intended only to be used after booting the system. Problems Only modifying register df1:0 to value 2’b10 seems to put the controller into AHCI mode (with no IDE PCI function, but PATA drives are still detected by the option ROM). The option ROM loads, correctly reports connected drives, and allows booting from them. However, OS X does not detect hard drives that were detected by the option ROM at boot time.
If SATA drives are not attached until after the option ROM loads, they are detected by the OS and can be hot-plugged. Therefore, I chose to set register df6 to cause the option ROM to quit without detecting drives. A side-effect is that without the option ROM, the computer can’t boot from the disks. The problems with configuration register 0x40-43 are more problematic. Linux sets register 0x41 to 0xa1, while the option ROM will set it to 0xf1 or 0x51. 0x51 appears to disable hot-plugging the disks on the SATA channels entirely. 0xa1 causes a hang for several minutes at boot, seemingly trying and failing to find a disk, while using 0xf1 boots normally.
Trying with 0xb1 and 0xe1 shows the same behaviour as for 0xa1, but hangs only if a disk is not present on SATA0 or SATA1, respectively. Thus it seems like setting 0x417:6 or 0x415:4 to 2’b10 causes the option ROM to assert that a disk must be present at boot time for that channel.
The hang does not occur if the option ROM is skipped by setting 0xdf6, so I use 0xa1 to be closer to what Linux does, although I notice no other differences between 0xf1 and 0xa1. Linux sets register 40 bit 2 (to enable the IDE port?). Trying to do that in the option ROM causes a several-minute hang during boot when loading the option ROM (again, seemingly waiting for a disk and giving up), even when a PATA disk is present. With df6 set, the option ROM does not detect any disks, despite spending several minutes. Final configuration.
PATA not enabled because turning it on causes a hang during boot. Option ROM not enabled by setting df6, so the disks are not bootable. SATA drives working in OS X with the standard AHCI driver, including hot-plugging. PCICFG v1.24 (c) Copyright 1997,1998 Ralf Brown Modified by Datapath based on V1.19 - PCI bus 04 device 00 function 00: Header Type 'non-bridge' (single-func) Vendor: 197B???
Device: 2363??? Class: 01 disk Revision: 10 SubClass: 06??? I don’t understand. Which three instances of 0xb1, and why change to 0x91? Is tricking the option ROM into seeing register df6=0, df1:0=01 the result you want? (and letting the option ROM decide how to set the other configuration registers) If so, I would start with the first patched ROM (the one that sets df1:0 to 10), and change that to 01.
I made changes at three locations: offset 0x3556, 0x3577, and 0x37c4. I replaced 3 bytes with (b1 02 90): b1 02 mov cl, 0x02 90 nop Those three bytes used to be a function call to a function that would read a byte from the PCI configuration space register (di), and return the result in cl. Maybe i missed something, i started with the ahci file, and did a simple hex compare to the original (i dont have proper tools for dis), i found only the 3 differences you wrote about (though my hex editor has a slightly different addy) so i started looking at the binary values, b1 (10110001 binary) seemed to be the bytes that referred to the bits 1:0 so i just changed them to read 01 (10010001 binary) converted back to hex which came out to 91 instead of b1. So i changed the strings to read 91 02 90. I assumed this would put 01 in the cfg register and set ide/legacy mode. Though now i am thinking i need to change it instead to 01110001 or 71h. Hopefully you could shed a bit more light on the subject.
Unfortunately, it’s a little more complicated than that 🙂 The edits are in x86 machine code. They’re not register values. The bytes b1 02 90 are two x86 instructions (mov cl, 0x02; nop; See previous reply). The original bytes were e8 xx xx, where e8 is the opcode for the CALL instruction, and the 16-bit immediate operand is the relative branch target. I’m not changing the configurations registers, I’m modifying the code that reads the registers. You’d probably need a disassembler to understand the code. Many thanks for the modded ROM.
I have programmed the first modded one into two JMB 363 cards with SST flashable chip and everything has gone OK. It puts the controller into AHCI mode (0106 class, original was 0104 class) and it is bootable (tested actually, with only SATA drives). Anyway, you can erase the flash chip, so that no option ROM is executed and the card is rendered non-bootable anymore.
Even with no option ROM loaded, the card is still recognized under the Windows OS as a generic AHCI controller (0106 class). Hello Pablo, Could you pass on a link please of your setup? I’m not savvy with configuring things, but i can use that command flashing tool, i would like to simply use the card as a sata controller.
That can boot, but my bios only shows it as a raid adapter, and the drivers during windows 7 install fails. I feel it is because i am only using one drive with this card. And it is ment for Raid setups.
Could your bios config allow me to use ahci to boot my one drive (through sata) and allow for windows install? If so please post your config. Its frustrating me that my computer wont allow an OS install.
I had some help from the option ROM, which gave some hints as to what the PCI config registers do (or at least, supposed to do after being interpreted by the option ROM). You might try looking through the Linux kernel sources to see if the driver for the 88SE9128 gives any clues as to how the chip works The second part of the problem is to modify the option ROM given you already know how to configure the chip. This was done by disassembling the option ROM (it’s real mode x86 code) to figure out what it does.
The bytes that were changed here are x86 code that reads the PCI configuration register and does something with the value. It is not a data table containing some form of initial register values. Hello, Sorry to bother you Henry, I know you do not have this card anymore. But I would still ask for some support. I’ve bought the jmb363 version of this card, with 2 sata ports, and no IDE ports. It seems to be fixed to Raid, and the bios sees the drive connected as a raid controller.
During a windows fresh setup, i cannot get past the copying and expanding files without errors. (i believe the drivers are not compatible with the raid configuration) i only have one drive i wish to use on the card.
Jmicron Card Reader Driver
(and a sata dvd writer on the other port) and want to be able to use the card as a boot device to boot windows, and to avoid using my onboard sata controller. Bios is able to see the card and drive, but windows after using the drivers still error out. The drive is sound, and the DVD of windows is original and has been used before to istall, even using the onboard sata port i can install without problems, so i know the issue is not the DVD, or the DVD drive (The install drive is IDE and i’m using the onboard ide for the installation) or the HDD, as all these have been correctly tested to be working. I understand of your busy, if you could direct me to a Bios i could flash that will allow my drive to be usable as a boot device through the JMB363, i would be forever grateful.
It seems the setup that Pablo above has is what i’m looking for but i’m unsure of this. Kind Regards Duufus. It sounds like Pablo was using the first of the two patched option ROMs I posted, though I’m not entirely sure. I didn’t spend much time testing them for booting because I didn’t need the drives to be bootable, so I really don’t know how well booting from the card works.
It’s strange you would get errors during file copying. Normally with RAID controllers, either you don’t have a driver (and drives are not detected), or they work properly Why do you want to avoid the on-board SATA controller? If the on-board controller is 3 Gbps, it’s usually faster than an external chip attached to PCIe x1 (2.5 Gbps in total for both ports). I have no idea. Also, I haven’t looked at this in years The first thing that’s different with the on-motherboard controllers is that the option ROM is usually packaged into the system BIOS, rather than being on its own flash chip. So at minimum, you’d probably need to extract and insert the option ROM and flash your system BIOS, rather than using the flashing procedure for the add-on card.
Other than that, I’m not certain if the option ROMs are the same for both on-motherboard and add-on card devices. They might be similar enough you could replace one with the other, but they also might not be.