Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacBookPro 15,1/2? #71

Open
aunali1 opened this Issue Aug 13, 2018 · 50 comments

Comments

Projects
None yet
@aunali1
Copy link
Contributor

commented Aug 13, 2018

Any support/documentation for the refreshed 2018 MacBook Pros?

I have one and I'll be willing to help with tinkering stuff especially since they are using the new T2 chips.

@roadrunner2

This comment has been minimized.

Copy link
Contributor

commented Aug 13, 2018

Is the keyboard and touchbar (using the drivers at my clone of macbook12-spi-driver) working for you? I've had reports so far that at least the keyboard doesn't. Assuming that's true, help would be appreciated in trying to debug the issue (and in which case please open an issue for this specifically).

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Aug 13, 2018

So I went ahead and custom built a Arch Linux live image with @roadrunner2's driver. (Archiso releng profile + macbook12-spi-driver-dkms from AUR)

While the driver successfully loads, the keyboard fails to function and the touchbar remains blank.

EDIT:
A link to the image for reference

@Dunedan

This comment has been minimized.

Copy link
Owner

commented Aug 13, 2018

Any support/documentation for the refreshed 2018 MacBook Pros?

You're the first person here who got one, so you might be the one being able to provide information. 😄

As there are some significant differences compared to the previous models, mainly due to the introduction of Apple's T2-chip, I suspect fewer components will work for now.

As a start a PR with the output of the get-info.sh script would be really good.

And you can of course follow the instructions for the 2016/2017 models and have a look which components work and which don't. For example I expect that Linux won't have access to the sensors previously exposed by the system management controller (SMC), as that's now handled by the T2-chip. Same for access to the disk via NVMe. While I expect that this works, it might require a kernel patch as did the controller for the 2016 and 2017 models.

But as said: a PR with the information from the get-info.sh would be a great start and much appreciated. 👍

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Aug 14, 2018

Well the SSD doesn't work at all, same with WIFI, looks like a new chip BCM4464 (nothing on google.)

I also attempted manually specifying the SSD PCI ID (106B:2005 - ANS2 NVME Controller) with the following,

$ modprobe nvme
$ echo 106b 2005 > /sys/bus/pci/drivers/nvme/new_id

after which lsblk showed a basic nvme dev, then after about 10 seconds the screen instantly went black alongside which the fans spun up to full speed, lasting for about a second, then the MacBook rebooted into macOS.

Not sure what went wrong, prob the T2 crashed or smth? I did receive a crash report after booting macOS with BridgeOS reporting a recoverable ANS2 failure.

FYI, sending in a PR with the info from get-info.sh soon.

@Dunedan

This comment has been minimized.

Copy link
Owner

commented Aug 15, 2018

Lots of interesting bits in the dumps. The obvious ones:

  • no iBridge device shown in lsusb (which might explain why the Touch Bar doesn't work. Because of that I also expect the iSight webcam to not work as well)
  • two unknown PCI-devices Apple Inc. Device [106b:1801] and Apple Inc. Device [106b:1802] (maybe that's what the T2-chip exposes for Touch Bar and iSight webcam?)
  • applesmc failing to read stuff (kind of expected as the T2-chip includes the SMC functionality now)
@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Aug 15, 2018

@Dunedan Would a dump from system_profiler on macOS be helpful?

@Dunedan

This comment has been minimized.

Copy link
Owner

commented Aug 16, 2018

Sure. More information is always good. 😄

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Aug 17, 2018

Pastebin was complaining about file size so I just uploaded to here. (2.7 MB)

Of particular interest are the following,

  • IOBC@0,1 matching [106b:1801] above (Bridge Controller?)
  • SEPM@0,2 matching [106b:1802] above (Secure Enclave Processor?)

It seems that Apple is emulating a HCI controller through the IOBC to interface with the iBridge devices as USB, as evidenced by the recurring AppleUSBVHCIPorts and AppleUSBVHCIBCE virtual controller.

@wsy2220

This comment has been minimized.

Copy link

commented Aug 20, 2018

The biggest problem on my 15,1 is applesmc module, it refused to load with these messages:

[ 1124.528835] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1124.528837] applesmc: #KEY: read arg fail
[ 1124.719729] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1124.719732] applesmc: #KEY: read arg fail
[ 1124.907593] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1124.907595] applesmc: #KEY: read arg fail
[ 1125.095762] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1125.095764] applesmc: #KEY: read arg fail
[ 1125.283551] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1125.283553] applesmc: #KEY: read arg fail
[ 1125.471537] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1125.471539] applesmc: #KEY: read arg fail
[ 1125.659650] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1125.659652] applesmc: #KEY: read arg fail
[ 1125.847437] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1125.847439] applesmc: #KEY: read arg fail
[ 1126.035669] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1126.035671] applesmc: #KEY: read arg fail
[ 1126.223667] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1126.223668] applesmc: #KEY: read arg fail
[ 1126.411547] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1126.411549] applesmc: #KEY: read arg fail
[ 1126.599665] applesmc: send_byte(0x10, 0x0304) fail: 0xff
[ 1126.599667] applesmc: #KEY: read arg fail

without applesmc, it's always very hot.

My kernel is

Linux version 4.17.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-28)) #1 SMP Debian 4.17.17-1 (2018-08-18)

I haven't tried to get keyboard/touchpad to work. I'd like to provide any information needed.

edit:
#70 solved the melting temperature, by adding 'acpi_mask_gpe=0x6e' kernel parameter

@mikeeq

This comment has been minimized.

Copy link

commented Aug 20, 2018

Have you tried to turn off secure boot? https://support.apple.com/en-us/HT208330
Maybe that's the reason why it doesn't see any NVMe devices.

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Aug 21, 2018

@mikeeq Yes, thats the only way I was able to boot the device.

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Aug 21, 2018

@wsy2220 Do you have FileVault enabled? If not it me be worthwhile to test the following commands I used to recognize the NVMe drive:

$ modprobe nvme
$ echo 106b 2005 > /sys/bus/pci/drivers/nvme/new_id

I have a hunch that with FileVault disabled it won't spontaneously crash like it did in my situation.

@wsy2220

This comment has been minimized.

Copy link

commented Aug 21, 2018

@aunali1 I have no FileVault. I tried those commands, and nvme device didn't show up, and the system got reset after about 10s.

@roadrunner2

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2018

Regarding the keyboard, looking at the provided pci listing and dsdt, I see two things:

  1. There does not appear to be any driver in the kernel for the SPI controller on these machines (pci id 8086:a324)
  2. I cannot find any info about the keyboard in the DSDT, so I don't think it's attached to the SPI bus/controller (in fact, according to the DSDT there's nothing attached the SPI bus/controller)

Looking at the ioreg info is more informative: it appears it's back on the USB bus, and hanging off the Bridge-Controller/T2-chip. But since it doesn't show up in lspci, I guess something needs to initialize the BridgeController first?

@AndreasAZiegler

This comment has been minimized.

Copy link

commented Oct 3, 2018

Did someone have any success with the nvme of the MacBook Pro 2018? I have the same problems as other people described earlier (keyboard and trackpad not working and nvme not visible). The not working keyboard and trackpad doesn't bother me that much as I'm anyway using an external keyboard and mouse most of the time. The not recognized nvme however bother me quite a lot.

@Dunedan

This comment has been minimized.

Copy link
Owner

commented Oct 3, 2018

@wsy2220 I don't expect applesmc to work anymore for the MacBook Pro 2018, as Apple moved the SMC-functionality into the T2-chip. We saw the first step already with devices with the T1-chip, where the ambient light sensor isn't handled by the SMC anymore, but probably by the T1-chip, using a different interface to access it (and so far nobody has figured out how that looks like).

@AndreasAZiegler The NVMe controller isn't recognized by default, because Apple screwed up and put a typo in the class code for the NVMe controller. So to get it automatically detected a patch for the Linux kernel is necessary (e.g. check out the patch I submitted for the MacBook Pro 2016: http://lists.infradead.org/pipermail/linux-nvme/2017-February/008323.html). Without the patch, you can manually discover the NVMe controller with the following commands (as already mentioned in the thread by @aunali1):

$ modprobe nvme
$ echo 106b 2005 > /sys/bus/pci/drivers/nvme/new_id

The problem then seems to be that this is causing system resets soon after as mentioned above as well.

I did receive a crash report after booting macOS with BridgeOS reporting a recoverable ANS2 failure.

@aunali1 Any chance you (or somebody else) can provide such a crash report? Maybe it contains some useful information.

Updating to the latest macOS version could also fix the system reset, if it was caused by a bug in BridgeOS (not likely, but worth a shot).

@KTRosenberg

This comment has been minimized.

Copy link

commented Oct 7, 2018

Hello all, I recently received this model of macbook pro, but it looks like unfortunately Linux is crippled on it. I would have liked to boot off an external drive, but if I understand correctly, the keyboard and trackpad don't work, and even worse, audio and wifi don't work at all. I suppose that brightness controls also don't work then? Has any headway been made towards making Linux usable on these machines?
Thanks.

@jboyens

This comment has been minimized.

Copy link

commented Oct 7, 2018

@KTRosenberg This entire Github project is designed to help you make it work on these laptops. I use it daily on a 14,3. There are compromises, but it's very useable.

@roadrunner2

This comment has been minimized.

Copy link
Contributor

commented Oct 7, 2018

Could somebody provide the output from sudo acpidump? On the MBP13,3 at least the entries for the iBridge are in one of supplementary tables, not the main DSDT. And I'm wondering if the new chip(s) need some sort of ACPI call to activate them, since they don't appear on the USB bus. Of course since they show up as pci devices it's also possible they need to be activated via PCI.

@Dunedan Might I suggest changing the get-info.sh script to get the full acpi info rather than just the DSDT?

@KTRosenberg

This comment has been minimized.

Copy link

commented Oct 7, 2018

@jboyens I see. But just to confirm--is it true that the wifi and audio are still unusuable beyond connecting external adapters and audio interfaces?

@jboyens

This comment has been minimized.

Copy link

commented Oct 7, 2018

@KTRosenberg it depends on the model. But yes, audio and WiFi are not working consistently without some compromises. I use a small WiFi dongle and USB headphones.

@KTRosenberg

This comment has been minimized.

Copy link

commented Oct 7, 2018

I was referring to the 2018 model, which seems to be less functional than the previous models due to the T2 chip-related changes.

@Dunedan

This comment has been minimized.

Copy link
Owner

commented Oct 7, 2018

@roadrunner2 Sure. Free free to open a PR and add what you think would be beneficial as well.

@AndreasAZiegler

This comment has been minimized.

Copy link

commented Oct 7, 2018

While trying around with the latest Arch Linux installer (2018.10) and the current Ubuntu Live System, I made the following observations. When I run
modprobe nvme
echo 106b 2005 > /sys/bus/pci/drivers/nvme/new_id

in the Ubuntu Live system sometimes the nvme drive appears and sometimes it doesn't. In both cases the system resets after around 10s as desribed by @wsy2220. In the Arch Linux installer neither does the drive appear nor does the system resets. Does anyone has some more success yet?

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Oct 7, 2018

@roadrunner2 I'll spin up a new Arch image and test out the command.
@Dunedan If the T2 crashes again, as it probably will, I'll post the dump of the report from macOS.
@AndreasAZiegler Odd. It always showed up for me before crashing on Arch.

@AndreasAZiegler

This comment has been minimized.

Copy link

commented Oct 7, 2018

@Dunedan I posted the dump of the report from macOS here https://pastebin.com/UtvGz403 (I hope that's right).

Just for clarification how this report was generated: I booted from the Ubuntu Live USB stick, modified the nvme driver, recompiled the driver, loaded the driver "modprobe nvme", then my laptop crashed after around 10s, in macOS the aforementioned report was presented to me.

@roadrunner2

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2018

Regarding the NVME related resets, there's this hack in the linux driver (drivers/nvme/host/pci.c line 2097 or thereabouts) for an older apple controller:

        /*
         * Temporary fix for the Apple controller found in the MacBook8,1 and
         * some MacBook7,1 to avoid controller resets and data loss.
         */
        if (pdev->vendor == PCI_VENDOR_ID_APPLE && pdev->device == 0x2001) {
                dev->q_depth = 2;
                dev_warn(dev->ctrl.device, "detected Apple NVMe controller, "
                        "set queue depth=%u to work around controller resets\n",
                        dev->q_depth);

Might be worth seeing if this is also needed for the new controller.

@wsy2220

This comment has been minimized.

Copy link

commented Oct 8, 2018

@roadrunner2

Could somebody provide the output from sudo acpidump?

Here is my acpidump on 15,1:
https://gist.github.com/wsy2220/dddb13f3a3649a5cb63bf88e98bde6f6

@AndreasAZiegler

This comment has been minimized.

Copy link

commented Oct 8, 2018

@roadrunner2 I tried this modification as well but I does not seem to work.

@AndreasAZiegler

This comment has been minimized.

Copy link

commented Oct 11, 2018

Any new insights?

@Dunedan

This comment has been minimized.

Copy link
Owner

commented Oct 12, 2018

Actually I have an insight, even though it's just a pretty small one:

The crash report includes secure boot?: YES. With enabled secure boot I wouldn't be surprised about those NVMe controller resets. So can you please confirm again that you did disable secure boot in macOS prior to trying to run Linux?

@roadrunner2

This comment has been minimized.

Copy link
Contributor

commented Oct 14, 2018

Thanks for the full acpidump. Looks like all of the iBridge2 relevant parts are in the DSDT after all.

I don't have a lot to add here, other than to summarize the device structure around the iBridge2/T2 device a bit. Parts of it have already been mentioned above.

These are the PCI devices exposed by the chip (from lspci):

02:00.0 Mass storage controller [0180]: Apple Inc. ANS2 NVMe Controller [106b:2005] (rev 01) (prog-if 02)
02:00.1 Non-VGA unclassified device [0000]: Apple Inc. Device [106b:1801] (rev 01)
02:00.2 Non-VGA unclassified device [0000]: Apple Inc. Device [106b:1802] (rev 01)
02:00.3 Multimedia audio controller [0401]: Apple Inc. Device [106b:1803] (rev 01)

In the DSDT the corresponding devices are (RP17 is the iBridge2 device itself, as evidenced not only by its children, but also the existence of a _DSM method that returns the "apple-coprocessor-version", just like the ASOC for the previous MBP's):

\_SB.PCI0.RP17
\_SB.PCI0.RP17.ANS2
\_SB.PCI0.RP17.IOBC
\_SB.PCI0.RP17.SEPM
\_SB.PCI0.RP17.ADIO

From the ioreg output this is an extract of the relevants parts of the tree in MacOS:

+-o Root  <class IORegistryEntry, id 0x100000100>
  +-o MacBookPro15,1  <class IOPlatformExpertDevice, id 0x100000114>
    +-o AppleACPIPlatformExpert  <class AppleACPIPlatformExpert, id 0x100000115>
    | +-o PCI0@0  <class IOACPIPlatformDevice, id 0x100000148> 
    | | +-o AppleACPIPCI  <class AppleACPIPCI, id 0x10000038b> 
    | |   +-o RP17@1B  <class IOPCIDevice, id 0x100000376> 
    | |   | +-o IOPP  <class IOPCI2PCIBridge, id 0x1000003c1> 
    | |   |   +-o ANS2@0  <class IOPCIDevice, id 0x100000377> 
    | |   |   | +-o AppleANS2Controller  <class AppleANS2Controller, id 0x1000003c6> 
    | |   |   |   +-o IONVMeBlockStorageDevice@1  <class IONVMeBlockStorageDevice, id 0x100000414> 
    | |   |   +-o IOBC@0,1  <class IOPCIDevice, id 0x100000378> 
    | |   |   | +-o IOBufferCopyController  <class IOBufferCopyController, id 0x1000003d5> 
    | |   |   |   +-o AppleUSBVHCIBCE@80000000  <class AppleUSBVHCIBCE, id 0x1000003ef> 
    | |   |   |   | +-o AppleUSBVHCIPort@80100000  <class AppleUSBVHCIPort, id 0x100000466> 
    | |   |   |   | | +-o iBridge@80100000  <class IOUSBHostDevice, id 0x1000010d0> 
    | |   |   |   | +-o AppleUSBVHCIPort@80200000  <class AppleUSBVHCIPort, id 0x100000467> 
    | |   |   |   | | +-o iBridge FaceTime HD Camera (Built-in)@80200000  <class IOUSBHostDevice, id 0x1000010d3> 
    | |   |   |   | +-o AppleUSBVHCIPort@80300000  <class AppleUSBVHCIPort, id 0x100000468> 
    | |   |   |   | | +-o iBridge ALS@80300000  <class IOUSBHostDevice, id 0x1000010d5> 
    | |   |   |   | +-o AppleUSBVHCIPort@80400000  <class AppleUSBVHCIPort, id 0x100000469> 
    | |   |   |   | | +-o Headset@80400000  <class IOUSBHostDevice, id 0x1000010d2> 
    | |   |   |   | +-o AppleUSBVHCIPort@80500000  <class AppleUSBVHCIPort, id 0x10000046a> 
    | |   |   |   | | +-o Apple Internal Keyboard / Trackpad@80500000  <class IOUSBHostDevice, id 0x100002af2> 
    | |   |   |   | +-o AppleUSBVHCIPort@80600000  <class AppleUSBVHCIPort, id 0x10000046b> 
    | |   |   |   | | +-o iBridge Display@80600000  <class IOUSBHostDevice, id 0x1000010d4> 
    | |   |   |   | +-o AppleUSBVHCIPort@80700000  <class AppleUSBVHCIPort, id 0x10000046c> 
    | |   |   |   | | +-o iBridge DFR brightness@80700000  <class IOUSBHostDevice, id 0x1000010d1> 
    | |   |   +-o SEPM@0,2  <class IOPCIDevice, id 0x100000379> 
    | |   |   | +-o AppleSEPIntelIOP  <class AppleSEPIntelIOP, id 0x1000003d6> 
    | |   |   +-o ADIO@0,3  <class IOPCIDevice, id 0x10000037a> 
    | |   |     +-o BridgeAudioControllerPCI  <class BridgeAudioControllerPCI, id 0x100000567> 

The IOBC device closely matches the old iBridge device (T1 chip), except that it now controls the keyboard and trackpad devices too, and instead of being a USB device hooked to a USB hub it's a PCI device that appears function as a USB hub. So it looks like that to get access to those devices (including the keyboard and trackpad in particular) somebody will need to reverse engineer and write a PCI driver for the IOBC that basically implements a USB VHCI.

@AndreasAZiegler

This comment has been minimized.

Copy link

commented Oct 17, 2018

@Dunedan I double checked the secure boot settings (turning on the MacBook and pressing Command + R) and secure boot is off. I created a new gist, the content is probably still the same
https://gist.github.com/AndreasAZiegler/e85a4ee473e4ddb9b24000d10e5c223f

@dvulricht

This comment has been minimized.

Copy link

commented Nov 29, 2018

@Dunedan I double checked the secure boot settings (turning on the MacBook and pressing Command + R) and secure boot is off. I created a new gist, the content is probably still the same
https://gist.github.com/AndreasAZiegler/e85a4ee473e4ddb9b24000d10e5c223f

You applied the patch to drivers/nvme/host/pci.c and booting the correct kernel ?
You can try to boot the kernel with the following additional arguments added manually to linux-image line in grub:
acpi_osi=! acpi_osi="Windows 2012"

@Dunedan

This comment has been minimized.

Copy link
Owner

commented Dec 8, 2018

@AndreasAZiegler If I'd look into the NVMe problems (unfortunately I don't have one of the latest MacBook Pros to do so), my next step would be to try to figure out if a certain NVMe command issued by Linux causes the system reset. We already know that the software on the T2 chip triggers an assertion shortly after enabling the NVMe controller, but we don't know why. If it is caused by a specific NVMe command, that'd narrow down the issue quite a bit. I'm afraid doing so is a bit of pita, because you'd need to compile your own kernel with additional logging and would need to capture the logs over network.

@MaxLeiter

This comment has been minimized.

Copy link

commented Dec 8, 2018

@Dunedan: how would I go about capturing the logs over the network? I’m comfortable enough with C that I think I can figure out the logging if the kernel already has the systems for it in place.

@Dunedan

This comment has been minimized.

Copy link
Owner

commented Dec 8, 2018

@maenpaa24

This comment has been minimized.

Copy link

commented Dec 13, 2018

I would like to share some experiences:

With the latest iso of arch linux as well as the latest stable release of kali linux adding the bootflag "nomodeset" so that it can boot properly, otherwise the screen goes black.

When I boot these isos the NVMe module is already loaded and the drive is shown in lspci. When I execute the command:

echo 106b 2005 > /sys/bus/pci/drivers/nvme/new_id

Nothing happens and the drive is not shown for example executing the command "lsblk". So I can not reproduce the issue with these two distros.

To reproduce the issue I have to make use of the iso linked by @aunali1. Then I can effectively issue the command "echo 106b..." And the drive shows up in "lsblk" and after a few seconds the fan goes crazy and the MacBook turns off.

By the way with the iso provided by aunali1 adding the bootflag "nomodeset" is not required.

@maenpaa24

This comment has been minimized.

Copy link

commented Dec 25, 2018

I have been trying to debug the issue through netconsole but the drivers of every wireless to usb or rj45 to usb adapter that I have do not support polling. Do you guys know about any that supoorts it?

@zhuowei

This comment has been minimized.

Copy link

commented Dec 29, 2018

@maenpaa24 Could pstore help get logs from the device?

pstore is a kernel module that stores kernel panics in EFI variables, so they would survive a reboot. mjg59 has a tutorial for enabling it. By default it logs all oops and panics.

You may need to modprobe efi-pstore before using it.

If EFI variables don't work, there's also ramoops, which stores oops/panics/optionally kernel logs in RAM.

There's a guide here.

Basically, boot with mem=2G on the kernel command line, then

modprobe ramoops mem_address=0x80000000 mem_size=0x100000 ecc=1 console_size=0x10000 record_size=0x10000 ftrace_size=0x10000 pmsg_size=0x10000

to enable recording panics to ram.

If you're compiling a kernel, you can also enable CONFIG_PSTORE_CONSOLE to store everything from the kernel console, not just on panic/oops.

I haven't tested these since I don't have a Macbook with a T2 chip, but I did try pstore with ramoops in a virtual machine, and the above modprobe seems to work. It's the same panic log mechanism that Android phones and Chromebooks use, so it should probably work on Macbooks.

@imbushuo

This comment has been minimized.

Copy link

commented Jan 5, 2019

BTW: StorNVMe.sys chokes at Apple T2 too (but Windows bugchecks instead of T2 crash). Boot Camp supplies a customized Apple SSD driver for Windows.

I believe RAM-based crashdump is not sufficient for this issue, kernel traces via external bus (ThunderBolt-based Ethernet?) or RAM will probably help understanding what happened with the NVMe controller and the driver.

@jantman

This comment has been minimized.

Copy link

commented Mar 11, 2019

I don't really like to be the one to bump a thread that I haven't been involved in, but I was wondering if there's been any progress on this in the last two months?

I just got a work-issued A1990 (brand new, according to the bottom of the box a 15.4) today and was rather shocked when I did some cursory Googling and found this issue... as I've been running Arch on my MacBooks for ~7 years and was running (quite painfully) Linux on them as far back as PowerPC.

I have the new laptop in my hands and can assist with investigation/dumps/etc... for some amount of time until my corporate IT department demands that I return one of my now-two laptops (I convinced them to let me keep old and new "for a day or two" to transfer things over without losing work time).

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Mar 13, 2019

@jantman I would suggest submitting a PR with the output of get-info.sh. The 15,4 variant might have some hardware differences that would warrant a dedicated directory.

EDIT: Can you also upload as a comment here the zip file generated from $ sudo sysdiagnose -c. I've noticed that there are some new T2 codenames, j780ap (iBridge2,4) and j174ap (iBridge2,5)

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Mar 13, 2019

@Dunedan @roadrunner2 I've been perusing dumps from sysdiagnose -c (undocumented) and there are some really interesting bits in the ioreg dumps. These are performed on the T2 itself and are used for Apple 's diagnostics. Here it is:
bridge_sysdiagnose_2019.03.13_04-26-03+0000_Bridge_OS_Bridge_16P2542.tar.gz

And the ioreg dumps for your convenience:
IODeviceTree.txt
IOPower.txt
IOService.txt

@Serizao

This comment has been minimized.

Copy link

commented Mar 15, 2019

Hello all i have 2018 MBP with T2 chip if you want result of test i wil be happy to help you

@FrozenDroid

This comment has been minimized.

Copy link

commented Mar 15, 2019

Same here, also have the 2018 MacBook Pro 15". How could I contribute?

@aunali1

This comment has been minimized.

Copy link
Contributor Author

commented Mar 18, 2019

Finally got a setup going to sniff the traces between the T2's Bridge Controller and a QEMU Windows 10 instance. Not an expert in PCI drivers but I have uploaded the traces for those interested, or willing to help.
trace.txt

@zhuowei

This comment has been minimized.

Copy link

commented Mar 18, 2019

@aunali1 It looks like the trace only logs reads/writes to the config area: maybe NVMe transactions are DMAed and thus not present in the trace?

I wonder if reverse engineering the Windows Boot Camp NVMe driver or the T2 firmware would be a better way to figure out what's going on.

@brianbeardall

This comment has been minimized.

Copy link

commented Apr 12, 2019

I also need to follow this. The keyboard, touchpad, touchbar, ssd, and anything touching the T2 chips is not working even with security disabled. At least the USB, AMD GPU, charging, cpu controls work on Linux 5.0. The laptop doesn't run any warmer for me than in OSX. So in order to get everything working will likely require some level of T2 setup to unlock the other devices.

@Bear-TheWolf312

This comment has been minimized.

Copy link

commented Apr 13, 2019

Is this still being looked at? How can I help. If I can locate a binary of the T2 driver would that help at all?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.