[personal profile] mjg59
I'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:
        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)
From: (Anonymous)
It has always been confusing to me as to why getting access to information about hardware (and I guess firmware too) is so hard. Surely this information exists, otherwise the engineering people behind the scenes would be working in the dark all the time. It is really that hard to make it accessible? Or is this another one of those counter intuitive benefits "intellectual property" apparently brings to society?

Re: Corporate IT

Date: 2012-08-14 05:31 am (UTC)
From: (Anonymous)
You're thinking like an Open Source developer, by saying "Is there a good reason to keep this secret? If not, it should be shared.". Most tech companies don't think that way; to the extent they think about it at all, they think "Is there a good reason to open this? If not it should be secret.".

Re: Corporate IT

Date: 2012-08-14 09:01 am (UTC)
From: (Anonymous)
Not opening something means not having to review it. This saves time, which means money.

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)
From: (Anonymous)
Guess what: the "engineering people behind the scenes" _are_ working in the dark all the time. Speaking as one of them: the proprietary secret-sacred documentation only seldom better then none at all.

They have the support of the manufacturer, though (like e-mails and phones).

Re: Corporate IT

Date: 2012-08-14 07:23 am (UTC)
From: (Anonymous)
You're assuming that not only does the information exist, it exists in a nice usable form that the company could release as "Manual for Programming an 82524EF Controller".

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)
From: (Anonymous)
Many times the only documentation available is cornering one of the engineers and grilling them. I've seen cases where the official documentation is a few neatly typed pages, with handwritten corrections by several hands and no explanation whatsoever.

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)
From: (Anonymous)
I'm one of the engineers that produces the documentation as an architecture spec to the designers. I try to write my documents to be a complete and accurate guide to my blocks. That said, to understand it fully, you need docs to other blocks.

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..).

Date: 2012-08-14 05:34 am (UTC)
From: (Anonymous)
Rather than claiming to be Darwin, which might well cause other excitement in ACPI, could you just toggle that GPIO line back on? Does the controller show up if you do that?

Date: 2012-08-16 08:18 am (UTC)
From: (Anonymous)
I imagine '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.' was an attempt to do exactly that, in order that the Darwin hack need not persist.

Date: 2012-08-25 10:48 pm (UTC)
From: (Anonymous)
I'm not sure that's correct. It seems like the only way to make the device accessible post boot is to either appear to be Darwin, or configure one of two pcie devices. Though it seems that you should be able to toggle its state through the appropriate gpio address, though I'm not sure gpio works unless the device is registered at boot. If you can toggle post boot then I don'tdon't know why he bothered with the os spoofing unless he was simply fixing problems as he came upon them.

Sony: same issues?

Date: 2012-08-14 06:32 am (UTC)
From: (Anonymous)
I don't know how Thunderbold looks like, but Sony VAIO Z2 series also use some strange connector (it looks like USB3, accepts USB2/3 devices and a Sony proprietary dock station containing some PCIe hardware). It also does not hot-plug properly and panics the kernel on hot-unplug. Is this related?

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)
From: (Anonymous)
Related? Well...yes. Simple? Haha, ahahaha, hahahaahahahaha (gin).

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 05:07 pm (UTC)
From: (Anonymous)
Attached the dump to the bug.

Mwraf

Date: 2012-08-14 09:03 am (UTC)
From: (Anonymous)
I have always found Thunderbolt's design quite hilarious.

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)
From: (Anonymous)
There were many facepalm moments reading your post.

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)
From: [personal profile] makomk
Putting aside the added complexity at the controller end from encapsulating DisplayPort for the moment, most monitors with DisplayPort connectors don't speak DisplayPort encapsulated in Thunderbolt, they just speak normal DisplayPort. Which means that Thunderbolt host ports not only have to speak both, but Thunderbolt devices presumably need to be able to de-encapsulate it and output DisplayPort in order to support device chaining. Then the host needs to know how to configure all this and the associated display routing.

Display works

Date: 2012-08-14 11:43 am (UTC)
From: (Anonymous)
Funny thing is that plugging a display into that port just works. Have a MacBook Air with Ubuntu installed and had to do a presentation without much time to pre-test if the adapter thingie will work. To my amazement it did, without any issues.

P.S. The openID rejected my livejournal openID

--
Aigarius

QUOTE!!!!

Date: 2012-08-14 12:26 pm (UTC)
From: (Anonymous)
For the LWN weekly quote :

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)
From: (Anonymous)
+1

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)
From: (Anonymous)
Just because Intel supplies the part doesn't mean Apple isn't involved in the specifications.

Thanks

Date: 2012-08-14 04:23 pm (UTC)
From: (Anonymous)
Thanks for doing this. I can't believe I was so stupid to buy a macbook and a thunderbolt display thinking I would play around with osx for a few weeks and then switch to linux. Shit will be obsolete before the drivers are there. But you have gotten farther than anyone else I've found on the internet. Cheers to you sir.

Non Apple Hardware

Date: 2012-09-17 10:40 pm (UTC)
From: (Anonymous)
Hello have you tested hot plug on non apple hardware such as something like the Z77MX-QUO-AOS

Looking at OS support

Date: 2013-04-12 05:15 am (UTC)
From: (Anonymous)
From the Thunderbolt session at IDF 2013, someone complained they could not find Windows driver for Thunderbolt devices, and Intel engineers told like only 30 devices have just got their Windows driver start working. So the situation isn't too optimistic for Windows either.

Re: Looking at OS support

Date: 2013-04-12 05:19 am (UTC)
From: (Anonymous)
About documentation, also from IDF 2013, ThunderboltTM Technology Update
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)
From: (Anonymous)
Excuse me, can be Intel ® DSL2210 Datasheet v1.3 mail to me,54538003@qq.com

Where is this list?

Date: 2013-05-17 06:36 pm (UTC)
From: (Anonymous)
"Fixing that is as easy as adding Darwin to the list of operating systems Linux claims to be. "

How can I do this?

Re: Where is this list?

Date: 2013-11-01 08:28 pm (UTC)
From: (Anonymous)
acpi_osi="Dawrin"

Thunderbolt support is in Kernel 3.12

Date: 2014-01-03 12:58 pm (UTC)
From: (Anonymous)
Works on every thunderbolt I had (Acer S5 & Intel NUC) but Apple systems.

Re: Thunderbolt support is in Kernel 3.12

Date: 2014-01-08 12:55 am (UTC)
From: (Anonymous)
Yes BIOS (the firmware) did the resource allocation, which is very complicated and only specific to Thunderbolt hot-plug. But what's the difference to ASL code, which took care of platform specific implementation and provides abstracted (and not well documented) function call to OS?

Re: Thunderbolt support is in Kernel 3.12

Date: 2014-04-04 06:18 am (UTC)
From: (Anonymous)
Actually, according to various sources (including http://www.linuxfoundation.org/news-media/blogs/browse/2013/06/hardware-past-present-and-future-0) This is exactly how it's suppose to be done. BIOS handles allocation and passes the os a standard pci interface. When not dealing with mac, this makes OS implementation unnecessary,so long as pci hot-plug exists.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags