On Lenovo Thinkpad Tablet 2, when not adding noefi to kernel command line parameters, the boot up process will just stall as soon as efi_phys_call is being executed. When disabling the EFI services the system will start up fine, but will not detect devices like the USB host controller. Please find attached the log of the boot up process.
Created attachment 134011 [details] dmesg with efi table dmesg when just commenting the efi call in init/main.c
Created attachment 134021 [details] acpidump The extracted ACPI tables
Created attachment 134031 [details] defconfig the defconfig used to make it boot with unpatched kernel
(cc/ing ACPI folks for [ 0.323509] pnp 00:01: Plug and Play ACPI device, IDs PNP0103 (active) [ 0.323760] pnp 00:02: unknown resource type 18 in _CRS [ 0.323777] pnp 00:02: can't evaluate _CRS: 1 )
[ 0.000000] Warning only 895MB will be used. [ 0.000000] Use a HIGHMEM enabled kernel. David, could you try enabling CONFIG_HIGHMEM?
(In reply to Matt Fleming from comment #5) > [ 0.000000] Warning only 895MB will be used. > [ 0.000000] Use a HIGHMEM enabled kernel. > > David, could you try enabling CONFIG_HIGHMEM? Doesn't make a difference. Even with HIGHMEM enabled the earlyprintk on efifb just stops after efi_phys_call and the device is stalled (doesn't do *anything* anymore)
(In reply to Alan from comment #4) > (cc/ing ACPI folks for > > [ 0.323509] pnp 00:01: Plug and Play ACPI device, IDs PNP0103 (active) > [ 0.323760] pnp 00:02: unknown resource type 18 in _CRS > [ 0.323777] pnp 00:02: can't evaluate _CRS: 1 > > ) I tried to boot while overwriting the BIOS DSDT by a customized ACPI table which didn't generate compilation errors when being converted into a .hex file by iasl. But even after eliminating all the errors within the DSDT source code the system still fails the same way. Maybe I'm "fixing" it wrong?
There is another bug with this EFI loader of Lenovos. If you are booting with earlyprintk=efi and do not comment pr_notice lines which produce output longer than ~80 characters (or so), like linux_banner and "Kernel command line" efifb will refuse to print any further output and the boot process will stall as well.
Would also be useful to know what lspci -vvxxx says I would expect the USB controller may well be ACPI enumerated.
Created attachment 134201 [details] lspci -v
Thanks. So from that I don't think the presence/absence of a USB controller is down to a PCI problem or probably to the UEFI failures.
(In reply to Alan from comment #11) > Thanks. So from that I don't think the presence/absence of a USB controller > is down to a PCI problem or probably to the UEFI failures. What might be the problem then? The USB host has been defined within the ACPI DSDT table as far as I can tell (given I understand the code correctly) please see line 4339 within the dsl file I'll attach.
Created attachment 134491 [details] dsdt.dsl fixed table with compilation through wrong WACOM hwid fixed (still no effect)
pnp 00:17: Plug and Play ACPI device, IDs INT33b6 (active) pnp 00:18: Plug and Play ACPI device, IDs INT33b9 (active) <-> dsdt: ... Device (SPH0) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "INT33B9") // _HID: Hardware ID Name (_CID, "ACPI\\PNP0D20") // _CID: Compatible ID Name (_UID, 0x03) // _UID: Unique ID Name (_HRV, 0x02) // _HRV: Hardware Revision Name (_DEP, Package (0x01) // _DEP: Dependencies ... Device (RHUB) { Name (_ADR, Zero) // _ADR: Address Device (PRT1) { Name (_ADR, One) // _ADR: Address Name (_UPC, Package (0x04) // _UPC: USB Port Capabilities { Zero, 0xFF, Zero, Zero }) } } ... } But there is no USB host added... Kernel bug? Wrong configuration? And after all... entering virtual mode doesn't work either...
Difficult to say Clovertrail and its firmware were designed entirely for Windows. A lot of the platform hardware has no Linux driver of any kind. The ACPI also assumes you've got support for things like I2C opregions and the like. There are patches for that but they are not in the kernel yet. You'd need to produce GPIO drivers, PMIC drivers, power management drivers, thermal management drivers etc to get it to actually work usefully. Basically its a wintendo not a PC in the usual sense. Alan
Hi > Difficult to say Hmm > Clovertrail and its firmware were designed entirely for Windows. A lot of > the platform hardware has no Linux driver of any kind. The ACPI also assumes > you've got support for things like I2C opregions and the like. There are > patches for that but they are not in the kernel yet. When I enable the driver for baytrail gpio controller it detects an interrupt flood on gpio 1,32,65 and 96. So it manages to detect the gpio controller at least. > You'd need to produce GPIO drivers, PMIC drivers, power management drivers, > thermal management drivers etc to get it to actually work usefully. > Basically its a wintendo not a PC in the usual sense. David Cohen has already written most of these drivers, and there is already support for clovertrail in chipidea, so USB should be detected, but the ACPI pnp device never triggers the USB driver. I doubt David Cohen would bring disfunctional drivers upstream, so there *has* to be a bug somewhere else. -David
Created attachment 134671 [details] initial patch Adding initial support for PNP detection for z2760s USB host controller into Linux
David and a lot of other Intel folks did drivers for Clovertrail+, which is not *quite* the same thing (different GPU etc) and very different firmware (SFI versus EFI/ACPI) and for specific Android devices. The gpio isn't quite the same as Baytrail as I understand it but there *is* a dell 3.4 kernel image for the Venue 8 including source to all the kernel bits if you want to go fishing further. It also includes support for the clovertrail+ PMIC, although how that works out in an ACPI/EFI environment I'm not entirely sure. In some ways the ACPI should actually help - it'll describe the GPIO lines rather better when it comes to working out what power controls the bluetooth etc
> David and a lot of other Intel folks did drivers for Clovertrail+, which is > not *quite* the same thing (different GPU etc) and very different firmware > (SFI versus EFI/ACPI) and for specific Android devices. Ouch... I was already afraid that David might had written the code for Clovertrail+ and not for my z2760... > The gpio isn't quite the same as Baytrail as I understand it but there *is* > a dell 3.4 kernel image for the Venue 8 including source to all the kernel > bits if you want to go fishing further. It also includes support for the > clovertrail+ PMIC, although how that works out in an ACPI/EFI environment > I'm not entirely sure. The GPIO controller is detected when enabled and even reports GPIO interrupts, allthough there are some dedicated special pins which - when not ignored - lead to an interrupt flood and as a result, a stall of the operating system. > In some ways the ACPI should actually help - it'll describe the GPIO lines > rather better when it comes to working out what power controls the bluetooth > etc Ok. I will track that down a little bit further, but now that I realized that Davids code actually *isn't* for the z2760 but for "another" CloverTrail I understand that I first have to integrate the driver for the PMIC within the z2760 in order to get USB working properly.
> The gpio isn't quite the same as Baytrail as I understand it but there *is* > a dell 3.4 kernel image for the Venue 8 including source to all the kernel > bits if you want to go fishing further. It also includes support for the > clovertrail+ PMIC, although how that works out in an ACPI/EFI environment > I'm not entirely sure. Could you please point me to the correct kernel sources here? (After a day of googling I wasn't able to find it.) I will then port the missing drivers to mainline and hand them in to the mailinglist for review. Maybe mainline receives z2760 support after all :-)
Hi I've tried to port ULPI support from the Android sources to mainline but don't seem to be able to make ULPI switch the hub into the correct mode. Enumeration of devices always fails... Could someone have a look at my ugly hacking and tell me what I'm doing wrong? http://git.o2s.ch/?p=linux-stable.git;a=shortlog;h=refs/heads/v3.15-z2760 I know, that it looks ugly, but cleanup comes afterwards :-)
David, is this still a problem on recent kernel versions?
Hi all, I've also faced with the same problem. Recent 3.17-rc7 kernel doesnt detect USB controller at all on Acer ICONIA W510. With David's patches (http://git.o2s.ch/?p=linux-stable.git;a=shortlog;h=refs/heads/v3.15-z2760) the cotroller is seen, but device enumeration fails. Same thing with earlier (3.15 and 3.16) kernels. If someone have any ideas on this to try I'm ready to test. Below you may find relevant part from /var/log/messages: ACPI: bus type USB registered usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.10 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.17-rc7-i386 ehci_hcd usb usb1: SerialNumber: ci_hdrc.0 hub 1-0:1.0: USB hub found ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2 ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.10 usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: EHCI Host Controller usb usb2: Manufacturer: Linux 3.17-rc7-i386 ehci_hcd usb usb2: SerialNumber: ci_hdrc.1 hub 2-0:1.0: USB hub found usb 2-1: new high-speed USB device number 2 using ci_hdrc usb 2-1: device descriptor read/64, error -11 usb 2-1: device descriptor read/64, error -11 usb 2-1: new high-speed USB device number 3 using ci_hdrc usb 2-1: device descriptor read/64, error -11 usb 2-1: device descriptor read/64, error -11 usb 2-1: new high-speed USB device number 4 using ci_hdrc usb 2-1: device not accepting address 4, error -11 usb 2-1: new high-speed USB device number 5 using ci_hdrc usb 2-1: device not accepting address 5, error -11 hub 2-0:1.0: unable to enumerate USB device on port 1
Is anyone still seeing this issue? If not I'm going to close this bug.
Closing. If anyone hits this in the future feel free to re-open this bug.