![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59I've temporarily got hold of a Retina Macbook Pro. Fedora 17 boots fine on it with the following kernel arguments: nointremap drm_kms_helper.poll=0 video=eDP-1:2880x1800@45e, although you'll want an updated install image. The nointremap requirement is fixed by this patch, and the others are being tracked here. The gmux chip that controls the multiple graphics chipsets has changed - patches here. That just leaves Thunderbolt.
Thunderbolt is, to a first approximation, PCIe tunnelled over a Displayport connector. It's a high-bandwidth protocol for connecting external devices. Things are complicated by it also supporting Displayport over the same connection, which I'm sure will be hilarious when we get yet another incompatible display protocol. But anyway. I picked up a Thunderbolt ethernet adapter and started poking.
Booting with the device connected looked promising - an ethernet device appeared. Pulling it out resulted in the pcie hotplug driver noticing that it was missing and cleaning up, although the b44 ethernet driver sat around looking puzzled for a while. So far so good. Unfortunately plugging it in again didn't work, and rebooting without any Thunderbolt devices connected not only did nothing on hotplug, it also meant that the Thunderbolt controller didn't show up in lspci at all.
It turns out that there's several problems at play here. The first is the missing Thunderbolt controller. The problem here is the following code in Apple's ACPI tables:
Fixing that is as easy as adding Darwin to the list of operating systems Linux claims to be. So, now I could boot without a connected device and still see the controller. Since ACPI seemed to be important here, I started looking at the other ACPI methods associated with the device. The first one that drew attention was Name(_GPE, 0x14). The _GPE method (not to be confused with the _GPE object at the top of the global ACPI namespace) is defined as providing the ACPI general purpose event associated with the device. Unfortunately, it's only defined as doing this for embedded controllers - Apple's use of it on a PCI device is massively non-standard. But, still, easy enough to handle. Intel chipsets map GPE 0x10 to 0x1f to GPIO lines 0-15, so this GPE is associated with GPIO 4. Looking through the ACPI code showed a bunch of other references to GP04, and it turns out that if the chip is powered down (via setting GP23 to 0) then plugging a device in to the port will generate a GPE. This makes sense - a powered down controller isn't going to notice hotplug events itself, so you need some kind of out of band notification mechanism. There's also another ACPI method that flips the polarity of the GPIO line so it doesn't keep generating events for the entire time a device is connected. It didn't take long to come up with a stub driver that would power down the controller if nothing was connected at boot, and then wake it up again on a hotplug event.
Unfortunately that's as far as I've got. I'd been hoping that everything beyond this was just PCIe hotplug, but it seems not. Apple's Thunderbolt driver is rather too large to just be handling ACPI events, and this document on Apple's website makes it pretty clear that there's OS involvement in events and device configuration. Booting with a device connected means that the firmware does the setup, but if you want to support hotplug then the OS needs to know how to do that - and Linux doesn't.
Getting this far involved rather a lot of irritation at Apple for conspiring to do things in a range of non-standard ways, but it turns out that the real villains of the piece are Intel. The Thunderbolt controller in the Apples is an Intel part - the 82524EF, according to Apple. Given Intel's enthusiasm for Linux and their generally high levels of engagement with the Linux development community, it's disappointing[1] to discover that this controller has been shipping for over a year with (a) no Linux driver and (b) no documentation that would let anyone write such a driver. It's not even mentioned on Intel's website. So, thanks Intel. You're awful.
Anyway. This was my attempt to spend a few days doing something more relaxing than secure boot, and all I ended up with was eczema and liver pain. Lesson learned, hardware vendors hate you even more than firmware vendors do.
[1] By which I mean grotesquely infuriating
Thunderbolt is, to a first approximation, PCIe tunnelled over a Displayport connector. It's a high-bandwidth protocol for connecting external devices. Things are complicated by it also supporting Displayport over the same connection, which I'm sure will be hilarious when we get yet another incompatible display protocol. But anyway. I picked up a Thunderbolt ethernet adapter and started poking.
Booting with the device connected looked promising - an ethernet device appeared. Pulling it out resulted in the pcie hotplug driver noticing that it was missing and cleaning up, although the b44 ethernet driver sat around looking puzzled for a while. So far so good. Unfortunately plugging it in again didn't work, and rebooting without any Thunderbolt devices connected not only did nothing on hotplug, it also meant that the Thunderbolt controller didn't show up in lspci at all.
It turns out that there's several problems at play here. The first is the missing Thunderbolt controller. The problem here is the following code in Apple's ACPI tables:
Method (RMCR, 0, Serialized)
{
If (LNot (OSDW))
{
If (LAnd (LEqual (\_SB.PCI0.PEG1.UPSB.DSB1.UPS0.AVND, 0xFFFF),
LEqual (\_SB.PCI0.PEG1.UPSB.DSB2.UPS0.AVND, 0xFFFF)))
{
Store ("RMCR: Disable Link and Power Off Cactus Ridge Chip",
Debug)
Store (0x01, \_SB.PCI0.PEG1.LDIS)
Sleep (0x07D0)
Store (0x00, GP23)
}
}
}This checks if the system claims to be Darwin (the core of OS X). If not, it checks whether two PCIe bridges have been configured. If both are still in an unconfigured state, it cuts the PCIe link to the upstream PCIe link and then sets GP23 to 0. Looking further, GP23 turns out to be a GPIO line. Setting it to 0 appears to cut power to the Thunderbolt controller. In summary, unless your OS claims to be OS X, booting without an attached Thunderbolt device will result in the chipset being powered down so hard that it's entirely invisible to the OS.Fixing that is as easy as adding Darwin to the list of operating systems Linux claims to be. So, now I could boot without a connected device and still see the controller. Since ACPI seemed to be important here, I started looking at the other ACPI methods associated with the device. The first one that drew attention was Name(_GPE, 0x14). The _GPE method (not to be confused with the _GPE object at the top of the global ACPI namespace) is defined as providing the ACPI general purpose event associated with the device. Unfortunately, it's only defined as doing this for embedded controllers - Apple's use of it on a PCI device is massively non-standard. But, still, easy enough to handle. Intel chipsets map GPE 0x10 to 0x1f to GPIO lines 0-15, so this GPE is associated with GPIO 4. Looking through the ACPI code showed a bunch of other references to GP04, and it turns out that if the chip is powered down (via setting GP23 to 0) then plugging a device in to the port will generate a GPE. This makes sense - a powered down controller isn't going to notice hotplug events itself, so you need some kind of out of band notification mechanism. There's also another ACPI method that flips the polarity of the GPIO line so it doesn't keep generating events for the entire time a device is connected. It didn't take long to come up with a stub driver that would power down the controller if nothing was connected at boot, and then wake it up again on a hotplug event.
Unfortunately that's as far as I've got. I'd been hoping that everything beyond this was just PCIe hotplug, but it seems not. Apple's Thunderbolt driver is rather too large to just be handling ACPI events, and this document on Apple's website makes it pretty clear that there's OS involvement in events and device configuration. Booting with a device connected means that the firmware does the setup, but if you want to support hotplug then the OS needs to know how to do that - and Linux doesn't.
Getting this far involved rather a lot of irritation at Apple for conspiring to do things in a range of non-standard ways, but it turns out that the real villains of the piece are Intel. The Thunderbolt controller in the Apples is an Intel part - the 82524EF, according to Apple. Given Intel's enthusiasm for Linux and their generally high levels of engagement with the Linux development community, it's disappointing[1] to discover that this controller has been shipping for over a year with (a) no Linux driver and (b) no documentation that would let anyone write such a driver. It's not even mentioned on Intel's website. So, thanks Intel. You're awful.
Anyway. This was my attempt to spend a few days doing something more relaxing than secure boot, and all I ended up with was eczema and liver pain. Lesson learned, hardware vendors hate you even more than firmware vendors do.
[1] By which I mean grotesquely infuriating
Corporate IT
Date: 2012-08-14 04:48 am (UTC)Re: Corporate IT
Date: 2012-08-14 05:31 am (UTC)Re: Corporate IT
Date: 2012-08-14 09:01 am (UTC)Reviews are obviously required: not just to make sure there is actually no confidential content, but also to make sure there is no copyright problem, no quality problem, etc. Big companies unfortunately cannot afford to "just release" stuff, especially not when their bank account is well in the black. Sorry.
Re: Corporate IT
Date: 2012-08-14 07:00 am (UTC)They have the support of the manufacturer, though (like e-mails and phones).
Re: Corporate IT
Date: 2012-08-14 07:23 am (UTC)In reality, the information is much more likely to be scattered throughout dozens of individual specification documents that can't be released - not out of malice or desire for control, but simply because nobody has spent the time to gather all that information into something usable by an outsider.
Re: Corporate IT
Date: 2012-08-17 01:00 am (UTC)It is just as with our software: Many times there is (next to) no documentation on the inner workings available, developers find writing such boring (and it is suprisingly difficult to explain what you know inside-out to strangers that can't ask back). Sure, you can eventually figure out C code by staring at it long enough, while staring at your average device won't help; but the forces at work are much the same.
Re: Corporate IT
Date: 2012-08-18 07:03 am (UTC)And then the application and marketing teams get involved. They don't want to document everything I've documented (including waveforms and corner conditions), and they want to simplify the overall narrative. That doesn't help.
I'd love to be able to point the end engineers that use our products at my documentation--it's complete, it's thorough, it's well written (so I'm told)--but marketing and management insist we thin things out between what we architect and what we sell.
And since I'm busy working on the next product, it's hard for me to go back and make sure what we share with customers is actually useful after all the deletions. *sigh*
Anyway, that's my $0.02. I'm not sure it's kicked in with the latest MPB Retina Display Macs, but I know it's happened with other products I've been a part of (and are likely part of most of the cell phone calls you make these days..).
no subject
Date: 2012-08-14 05:34 am (UTC)no subject
Date: 2012-08-16 08:18 am (UTC)no subject
Date: 2012-08-25 10:48 pm (UTC)Sony: same issues?
Date: 2012-08-14 06:32 am (UTC)And BTW linux cannot read the BIOS from the Radeon card that is in the Sony dock station, see https://bugs.freedesktop.org/show_bug.cgi?id=41265 - is there anything we can do for debugging? How does linux read the VBIOS on a Mac (or, if the second video card is not on the remote side of Thunderbolt, please ignore the question).
Is there anything I can do in order to help reverse-engineer this Sony problem?
Re: Sony: same issues?
Date: 2012-08-14 06:55 am (UTC)See http://www.theverge.com/2011/10/14/2490694/how-sony-accidentally-did-the-right-thing-with-light-peak for the full story.
executive summary: probably best off buying the one without the dock thingy....
Re: Sony: same issues?
Date: 2012-08-14 01:32 pm (UTC)Re: Sony: same issues?
Date: 2012-08-14 05:07 pm (UTC)Mwraf
Date: 2012-08-14 09:03 am (UTC)They (Intel) want to create a new high bandwidth connector, so they decide it will use optical fibers. But optical fiber systems are expensive, so they start with copper. LOL#1: from a very modern design, this has just been switched to a common one. They will then switch to optical fibers later. Perhaps. So they say. Read: never. This is, and will stay copper.
They want this system to become universal. So they start shipping it with an exclusive partnership with Apple so that only them can use it. LOL#2: limiting the distribution of a technology you want to make universal‽ Seriously? This is going to be the new firewire, used by only some people, and anything but universal.
Oh, and by they way, although copper interface was only to bootstrap the system, they already shipped copper-based computers. The copper interface is there to stay, believe me. :-)
Now when you design a new protocol, it is only sensible to use a new physical interface so that people do not mix cables up, right? Guess what Intel did? Re-use the DisplayPort physical interface for that new protocol that is completely unrelated to display! Now, of course they are not /that/ stupid, so they added a compatibility with the DisplayPort protocol. LOL#3: I do not know if you were thinking about designing a simple, clean protocol, but this is starting to look quite monstruous now.
Now, everything is not that bad. At least they did not reproduce the error of Firewire, that does not include a reliable power line. And the error of eSATA, that does not include a power line at all. Thunderbolt may become universal if they really want it, while Firewire did not have any chance against USB (Firewire sticks cannot exist, for instance).
Re: Mwraf
Date: 2012-08-16 11:38 pm (UTC)If you search the web for teardowns of copper Thunderbolt cables you'll find they have a transceiver/signal conditioning chip at each end. The plan for optical Thunderbolt is simple: put an optical media transceiver chip in the cable connector backshell instead. Thunderbolt ports are somewhat like old-school AUI Ethernet ports with outboard media interface dongles, except now the dongle is so miniaturized it can be packed into the cable.
So yeah, the copper interface is here to stay, but the copper interface is the optical interface too. If optical Thunderbolt cabling is ever important to you, you'll be able to use it even with first generation 'copper' Thunderbolt ports. No LULZ here.
Next, DisplayPort. Thunderbolt is a packetized bus designed to efficiently encapsulate packets from other packet buses. Buses such as PCIe and DisplayPort. There's nothing special or ugly about the DisplayPort encapsulation that I've heard of. Your LOL translates to "Encapsulation protocol designed to encapsulate, TROLLOLOLOL???" You are the one who is being stupid here, not Intel.
Finally, Firewire sticks cannot exist? Whaaat? Assuming that by "stick" you mean "memory stick", how on earth do you come to that conclusion? That makes no sense at all.
Re: Mwraf
Date: 2012-08-18 03:01 pm (UTC)Display works
Date: 2012-08-14 11:43 am (UTC)P.S. The openID rejected my livejournal openID
--
Aigarius
QUOTE!!!!
Date: 2012-08-14 12:26 pm (UTC)Anyway. This was my attempt to spend a few days doing something more relaxing than secure boot, and all I ended up with was eczema and liver pain. Lesson learned, hardware vendors hate you even more than firmware vendors do.
Re: QUOTE!!!!
Date: 2012-08-14 06:54 pm (UTC)Seriously though, I'm confused; This sounds like it _was_ more relaxing than secure boot.....
Apple irritation
Date: 2012-08-14 03:59 pm (UTC)Thanks
Date: 2012-08-14 04:23 pm (UTC)Non Apple Hardware
Date: 2012-09-17 10:40 pm (UTC)Looking at OS support
Date: 2013-04-12 05:15 am (UTC)Re: Looking at OS support
Date: 2013-04-12 05:19 am (UTC)and Design Considerations, some specs were mentioned:
Intel® DSL3510L/DSL3310 Datasheet v6.52
Intel DSL3510L/DSL3310 Design Guide v1.2
Intel® DSL2210 Datasheet v1.3
Intel® DSL2210 Design Guide v1.0
NDA required.
Re: Looking at OS support
Date: 2013-05-04 04:29 pm (UTC)Where is this list?
Date: 2013-05-17 06:36 pm (UTC)How can I do this?
Re: Where is this list?
Date: 2013-11-01 08:28 pm (UTC)Thunderbolt support is in Kernel 3.12
Date: 2014-01-03 12:58 pm (UTC)Re: Thunderbolt support is in Kernel 3.12
Date: 2014-01-03 05:32 pm (UTC)Re: Thunderbolt support is in Kernel 3.12
Date: 2014-01-08 12:55 am (UTC)Re: Thunderbolt support is in Kernel 3.12
Date: 2014-04-04 06:18 am (UTC)Re: Thunderbolt support is in Kernel 3.12
Date: 2014-04-04 02:53 pm (UTC)