6 ms·

The three primary issues here are: 1) The input devices are on SPI, not USB. Apple's ACPI tables don't provide the GPIO mappings for these things via the stand

by mjg59 10y ago

The three primary issues here are: 1) The input devices are on SPI, not USB. Apple's ACPI tables don't provide the GPIO mappings for these things via the standard mechanisms, so the chipset driver won't bind. You then still need another driver for the SPI controller, and there's an out of tree one at https://github.com/cb22/macbook12-spi-driver/ https://github.com/cb22/macbook12-spi-driver/ . Longer term, the kernel needs to be able to parse Apple's ACPI tables and that driver needs merging. 2) Apple's NVME hardware uses the wrong PCI device class, possibly because it's not entirely NVME compatible (trying to read 64 bits of mmio register space in one go will fail, for instance). Linux has a specific entry for the older Apple NVME devices, and that may need to be broadened. 3) Having source ID checking enabled when doing IRQ remapping results in the system hanging on boot. It's unclear what the underlying problem is. Windows works fine because Apple provide drivers for (1) and (2). (3) is unclear - Windows may be setting up interrupt remapping differently, or it may never enable source ID verification. These issues are far from unusual when dealing with Apple hardware ((1) was true for the new Macbook, (2) has been true since Apple introduced NVME, (3) is the kind of weirdness that we've seen on Apple hardware ever since they went Intel), and this particular set of breakage is unsurprising. I spend some time while I was at Red Hat trying to keep Apple hardware working (https://mjg59.dreamwidth.org/12037.html https://mjg59.dreamwidth.org/12037.html is an example of what we had to do), but I don't know that anybody's really working terribly hard on it these days.

ndesaulniers 10y ago
Thanks for the link to the WIP driver. Since you have a lot of experience in this area, I'm curious: 1. What's the __1e6 alignment? [0] I've never heard of that. 2. How is the driver author going about writing that driver? Some of the comments seem to allude to analyzing what the Windows driver is doing. Do you think they're disassembling the Windows driver and trying to re-implement a Linux compatible driver in C? I don't see how anyone could implement a driver like this off the bat without some data sheet or existing code to look at. Edit: thanks to people pointing out it's __le16, not __1e6. I need to change my font; even now I can barely tell the 1 and l apart. [0] https://github.com/cb22/macbook12-spi-driver/blob/master/applespi.c#L63 https://github.com/cb22/macbook12-spi-driver/blob/master/app...
- DannyBee 10y ago
  it's not 1e6, it's le16 Little endian 16 bit As for the driver itself, the spi interfaces are not too hard to understand. It's unlikely anyone is disassembling anything. The normal way to figure out the packets the touchpad uses are to look at the datasheets/etc you can find on whoever made the touchpad. In this case, it's a bcm5974, and if you look at that driver, you'll see the packet format is the same. Otherwise, you write a packet dumper and start pushing things
  - ndesaulniers 10y ago
    ah, there's also an interesting discussion in an GH issue. They reference the data sheets of the parts mentioned from an iFixit teardown. There's also discussion of disassembling the OSX driver. And here's info on how the author sniffed SPI traffic on Windows. [1] [0] https://github.com/cb22/macbook12-spi-driver/pull/1#issuecomment-238819981 https://github.com/cb22/macbook12-spi-driver/pull/1#issuecom... [1] https://github.com/cb22/macbook12-spi-driver/issues/3#issuecomment-248405522 https://github.com/cb22/macbook12-spi-driver/issues/3#issuec...
- detaro 10y ago
  1.) It is __le16 with an L, not __1e16, and it means that it is a little endian field for bitflags, the tooling makes sure it is properly handled (not mixed with numbers or fields in the wrong endianess). See this Stack Overflow post and especially the links in the accepted answer: https://stackoverflow.com/questions/9680399/what-does-typedef-u16-bitwise-le16-mean-in-linux-kernel https://stackoverflow.com/questions/9680399/what-does-typede...
- leifliddy 10y ago
  The author details here what he did to debug the windows spi driver: https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51 https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51
  - leifliddy 10y ago
    "As an aside, for anyone interested in helping reverse engineer things: It's possible to get Windows to dump everything it sends on what it calls SPB - basically SPI & I2C. Open the Event Viewer and enable View -> Show Analytic and Debug Logs. Then head to Application and Services Logs -> Microsoft -> Windows -> SPB-ClassExtension. Right click on Analytic and enable it - all events will be logged. Disable it when done, and look for the 1023 events, and view the details tab - they'll give you the full buffer contents. Other events will let you know things like the direction of the transfer, etc."
mwambua 10y ago
Tangential Question: Would you say that Thinkpads are still the safest bet if you're looking for good RHEL/Fedora support & updates?
- hd4 10y ago
  Relevant: https://news.ycombinator.com/item?id=12911310 https://news.ycombinator.com/item?id=12911310
  - pritambaral 10y ago
    Those aren't ThinkPads. The ThinkPads are an semi-independent division within Lenovo.
- jsight 10y ago
  A lot of Red Hat employees (and engineers) use them. At least some of the models are very well supported.
- derekp7 10y ago
  For the Thinkpads, yes. Lenovo is one of the companies that maintains a list such as this: https://support.lenovo.com/us/en/documents/pd031426 https://support.lenovo.com/us/en/documents/pd031426 (This is a list of computers that they have certified one or more Linux distros against -- typically RHEL and Ubuntu). Any of the problems that you usually hear are typically on their non-Thinkpad lines.
  - dotancohen 10y ago
    Unfortunately, currently that supported machines list is empty!
    - derekp7 10y ago
      It isn't when I bring it up -- I wonder if there is a javascript issue that is causing a problem (such as with noscript, or an adblocker?) I'm seeing about 25 pages of systems. For current systems, I'm seeing the T460, T460p (with Ubuntu 14.04), and T460s with both Ubuntu and RHEL 7.2. Also seeing the X1 carbon, and X1 carbon yoga with Ubuntu certification. For the X260, for example, it has these links: https://access.redhat.com/ecosystem/hardware/2199571 https://access.redhat.com/ecosystem/hardware/2199571 http://www.ubuntu.com/certification/hardware/201511-20298/ http://www.ubuntu.com/certification/hardware/201511-20298/
yuhong 10y ago
I wonder if _OSI(Darwin) has to do with it
noobermin 10y ago
Actually, (2) has been fixed for the 2015 Macbook, I suppose that can help for the Macbook Pro. We have been trying to fix the SPI issue for a while, see this[0] As I've posted before, I am so happy now the Macbook Pro is out because we desperately need help on this issue. [0] https://bugzilla.kernel.org/show_bug.cgi?id=108331 https://bugzilla.kernel.org/show_bug.cgi?id=108331
userbinator 10y ago
The input devices are on SPI, not USB Things like this make me wonder if Apple is deliberately going for proprietariness as a sort of vendor-lock-in, because I can't see any other compelling reasons for coming up with a completely different interface for such basic and existing devices. USB and PS/2 are standardised to the point that hardware and software for them are widely available and cheap. They're also extensible, so one does not have to reinvent everything to add additional features. I still remember when the first "Intel Macbooks" came out with nearly identical hardware to a PC laptop of the same era, i.e. keyboard and trackpad looked like standard PS/2 devices. Later models of PCs and Macs started using USB internally (which is in some ways more complex, since the existing PS/2 interface was provided by the EC via LPC whereas USB may require an additional controller and definitely requires routing additional signals between it and one of the USB ports on the chipset), but at least they would still work relatively standardly. Personally, I'm all for new features but implemented in backwards-compatible or relatively standard ways. Apple doesn't seem to be a fan of that.
- emgeee 10y ago
  Just an FYI SPI is a pretty standard interface in the embedded world
  - userbinator 10y ago
    True, but SPI is really just referring to the physical layer protocol while the layers above can vary considerably and be proprietary. The only thing that's constant is that it is a synchronous serial protocol. It's not like USB which defines device classes and the higher-level layers of the stack, or PS/2 where e.g. all PS/2 keyboards or mice are expected to have an identical basic set of functionality and behaviour. There are certainly proprietary "vendor-specific" extensions to those, but e.g. it's almost a given that if you plug in a USB keyboard, all the standard QWERTY keys should work effortlessly; and while there may be extensions like displays and touchbars that require specific drivers, the core functionality doesn't change. If I understand correctly, what Apple did here is invent their own protocol for the keyboard which is completely different from what any PC or earlier Macs have, thus the lack of any functionality from Linux. And given how crucial a keyboard is to being able to do anything with the computer, it's no wonder this has caused much consternation. I think many people are used to the idea that even if the OS does not provide drivers for specific devices, basic functionality like keyboard, mouse, and video (even if it's something like a VGA 640x480 16 colours mode) should still be present --- partly to enable "bootstrapping" into more functionality by installing and troubleshooting the drivers.

by mjg59 10y ago

ndesaulniers 10y ago

Thanks for the link to the WIP driver. Since you have a lot of experience in this area, I'm curious: 1. What's the __1e6 alignment? [0] I've never heard of that. 2. How is the driver author going about writing that driver? Some of the comments seem to allude to analyzing what the Windows driver is doing. Do you think they're disassembling the Windows driver and trying to re-implement a Linux compatible driver in C? I don't see how anyone could implement a driver like this off the bat without some data sheet or existing code to look at. Edit: thanks to people pointing out it's __le16, not __1e6. I need to change my font; even now I can barely tell the 1 and l apart. [0] https://github.com/cb22/macbook12-spi-driver/blob/master/applespi.c#L63 https://github.com/cb22/macbook12-spi-driver/blob/master/app...

DannyBee 10y ago
it's not 1e6, it's le16 Little endian 16 bit As for the driver itself, the spi interfaces are not too hard to understand. It's unlikely anyone is disassembling anything. The normal way to figure out the packets the touchpad uses are to look at the datasheets/etc you can find on whoever made the touchpad. In this case, it's a bcm5974, and if you look at that driver, you'll see the packet format is the same. Otherwise, you write a packet dumper and start pushing things
- ndesaulniers 10y ago
  ah, there's also an interesting discussion in an GH issue. They reference the data sheets of the parts mentioned from an iFixit teardown. There's also discussion of disassembling the OSX driver. And here's info on how the author sniffed SPI traffic on Windows. [1] [0] https://github.com/cb22/macbook12-spi-driver/pull/1#issuecomment-238819981 https://github.com/cb22/macbook12-spi-driver/pull/1#issuecom... [1] https://github.com/cb22/macbook12-spi-driver/issues/3#issuecomment-248405522 https://github.com/cb22/macbook12-spi-driver/issues/3#issuec...
detaro 10y ago
1.) It is __le16 with an L, not __1e16, and it means that it is a little endian field for bitflags, the tooling makes sure it is properly handled (not mixed with numbers or fields in the wrong endianess). See this Stack Overflow post and especially the links in the accepted answer: https://stackoverflow.com/questions/9680399/what-does-typedef-u16-bitwise-le16-mean-in-linux-kernel https://stackoverflow.com/questions/9680399/what-does-typede...
leifliddy 10y ago
The author details here what he did to debug the windows spi driver: https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51 https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51
- leifliddy 10y ago
  "As an aside, for anyone interested in helping reverse engineer things: It's possible to get Windows to dump everything it sends on what it calls SPB - basically SPI & I2C. Open the Event Viewer and enable View -> Show Analytic and Debug Logs. Then head to Application and Services Logs -> Microsoft -> Windows -> SPB-ClassExtension. Right click on Analytic and enable it - all events will be logged. Disable it when done, and look for the 1023 events, and view the details tab - they'll give you the full buffer contents. Other events will let you know things like the direction of the transfer, etc."

mwambua 10y ago

Tangential Question: Would you say that Thinkpads are still the safest bet if you're looking for good RHEL/Fedora support & updates?

hd4 10y ago
Relevant: https://news.ycombinator.com/item?id=12911310 https://news.ycombinator.com/item?id=12911310
- pritambaral 10y ago
  Those aren't ThinkPads. The ThinkPads are an semi-independent division within Lenovo.
jsight 10y ago
A lot of Red Hat employees (and engineers) use them. At least some of the models are very well supported.
derekp7 10y ago
For the Thinkpads, yes. Lenovo is one of the companies that maintains a list such as this: https://support.lenovo.com/us/en/documents/pd031426 https://support.lenovo.com/us/en/documents/pd031426 (This is a list of computers that they have certified one or more Linux distros against -- typically RHEL and Ubuntu). Any of the problems that you usually hear are typically on their non-Thinkpad lines.
- dotancohen 10y ago
  Unfortunately, currently that supported machines list is empty!
  - derekp7 10y ago
    It isn't when I bring it up -- I wonder if there is a javascript issue that is causing a problem (such as with noscript, or an adblocker?) I'm seeing about 25 pages of systems. For current systems, I'm seeing the T460, T460p (with Ubuntu 14.04), and T460s with both Ubuntu and RHEL 7.2. Also seeing the X1 carbon, and X1 carbon yoga with Ubuntu certification. For the X260, for example, it has these links: https://access.redhat.com/ecosystem/hardware/2199571 https://access.redhat.com/ecosystem/hardware/2199571 http://www.ubuntu.com/certification/hardware/201511-20298/ http://www.ubuntu.com/certification/hardware/201511-20298/

yuhong 10y ago

I wonder if _OSI(Darwin) has to do with it

noobermin 10y ago

Actually, (2) has been fixed for the 2015 Macbook, I suppose that can help for the Macbook Pro. We have been trying to fix the SPI issue for a while, see this[0] As I've posted before, I am so happy now the Macbook Pro is out because we desperately need help on this issue. [0] https://bugzilla.kernel.org/show_bug.cgi?id=108331 https://bugzilla.kernel.org/show_bug.cgi?id=108331

userbinator 10y ago

The input devices are on SPI, not USB Things like this make me wonder if Apple is deliberately going for proprietariness as a sort of vendor-lock-in, because I can't see any other compelling reasons for coming up with a completely different interface for such basic and existing devices. USB and PS/2 are standardised to the point that hardware and software for them are widely available and cheap. They're also extensible, so one does not have to reinvent everything to add additional features. I still remember when the first "Intel Macbooks" came out with nearly identical hardware to a PC laptop of the same era, i.e. keyboard and trackpad looked like standard PS/2 devices. Later models of PCs and Macs started using USB internally (which is in some ways more complex, since the existing PS/2 interface was provided by the EC via LPC whereas USB may require an additional controller and definitely requires routing additional signals between it and one of the USB ports on the chipset), but at least they would still work relatively standardly. Personally, I'm all for new features but implemented in backwards-compatible or relatively standard ways. Apple doesn't seem to be a fan of that.

emgeee 10y ago
Just an FYI SPI is a pretty standard interface in the embedded world
- userbinator 10y ago
  True, but SPI is really just referring to the physical layer protocol while the layers above can vary considerably and be proprietary. The only thing that's constant is that it is a synchronous serial protocol. It's not like USB which defines device classes and the higher-level layers of the stack, or PS/2 where e.g. all PS/2 keyboards or mice are expected to have an identical basic set of functionality and behaviour. There are certainly proprietary "vendor-specific" extensions to those, but e.g. it's almost a given that if you plug in a USB keyboard, all the standard QWERTY keys should work effortlessly; and while there may be extensions like displays and touchbars that require specific drivers, the core functionality doesn't change. If I understand correctly, what Apple did here is invent their own protocol for the keyboard which is completely different from what any PC or earlier Macs have, thus the lack of any functionality from Linux. And given how crucial a keyboard is to being able to do anything with the computer, it's no wonder this has caused much consternation. I think many people are used to the idea that even if the OS does not provide drivers for specific devices, basic functionality like keyboard, mouse, and video (even if it's something like a VGA 640x480 16 colours mode) should still be present --- partly to enable "bootstrapping" into more functionality by installing and troubleshooting the drivers.