my solution to the flakiness of EHCI on Haswell ChromeOS devices was to route everything to the XHCI controller / use XHCI finalization (CONFIG_FINALIZE_USB_ROUTE_XHCI=y), and to use Broadwell's XHCI init code. Obv doesn't help if you need ECHI debug (eg), but perhaps a a slightly different hammer?
ref: https://github.com/MattDevo/coreboot/commit/30cd1f345b0497d1465eb9cc1d924bf644d324b9 On Thu, Oct 19, 2017 at 1:20 PM, Zoran Stojsavljevic < [email protected]> wrote: > I guess, Konstantin... My take on this investigation. ;-) > > I recommend to you to apply to be deployed/employed with INTEL IOTG PED > directorate in USA (Chandler)... But not less than grade 9/10 (initial base > salary in USA perhaps $200K USD per annum). Everything else will be more > than insult. > > And you, GOOGLE guys... Should think a bit beyond Reality. You should... > > (I am damn serious)! > Zoran Stojsavljevic > > On Thu, Oct 19, 2017 at 4:56 PM, Аладышев Константин <[email protected]> > wrote: > >> No, unfortunately this option by itself doesn’t help. >> >> >> >> I guess my minimal hammer is ‘noapictimer’ >> >> >> >> But I wonder how these 3 boot parameters (‘noapictimer’ ‘nolapic’ and >> ‘acpi=off’) separately help to solve my issue. >> >> What part is wrong in ACPI and correct in MP-table? Maybe the problem is >> in ACPI MADT table? But it doesn’t really have much info that can be wrong. >> The one strangeness I found compared to original BIOS is mapping between >> ProcID and APIC ID in lapic entries. >> >> >> >> Coreboot has straightforward: 0-0, 1-1, 2-2, 3-3. >> >> But original BIOS has: 1-0, 2-2, 3-1, 4-3 >> >> >> >> I wonder if it means something? >> >> >> >> >> >> *From:* ron minnich [mailto:[email protected]] >> *Sent:* Thursday, October 19, 2017 5:29 PM >> *To:* Аладышев Константин; Julius Werner >> >> *Cc:* Coreboot >> *Subject:* Re: [coreboot] USB problem with Haswell+LynxPointLP >> motherboards >> >> >> >> we had a similar problem and we set >> >> pci=nocrs >> >> >> >> which means 'ignore what ACPI tells you and probe it again" >> >> >> >> It's much less of a big hammer than 'acpi=off' :-) >> >> >> >> On Thu, Oct 19, 2017 at 7:22 AM Аладышев Константин <[email protected]> >> wrote: >> >> I've found one more parameter that helps me boot without USB problem: >> 'noapictimer' >> >> >> -----Original Message----- >> From: Аладышев Константин [mailto:[email protected]] >> Sent: Wednesday, October 18, 2017 3:58 PM >> To: 'Julius Werner' >> Cc: 'Coreboot' >> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards >> >> Ok, I've done some investigations about what can be the source of my >> problem: >> >> 1) last value of COMMAND register from BIOS I've dumped all EHCI >> registers (pci and memory) at the beginning of linux kernel EHCI >> initialization. And to my surprise pretty all memory registers in original >> BIOS look like almost uninitialized compared to my coreboot+seabios image. >> I don't really know how to work with EHCI controller, but seabios do it >> through periodic and async schedule and their enable bits (in COMMAND >> register from commit!) aren't active in original BIOS. I've tried to >> disable ehci initialization in seabios and after that registers dump >> started to look almost the same, compared to original bios, but it didn't >> solve my issue. Also without them USB doesn't work in grub. So it doesn't >> seem like BIOS last value of COMMAND register really matter. >> >> 2) SMI >> There are special registers for EHCI controller SMIs in its pci config >> space: >> -USB EHCI Legacy Support Extended >> -Intel Specific USB 2.0 SMI >> But in both of them SMIs are disabled as in coreboot+seabios image as in >> original bios. >> >> 3) ACPI >> In original BIOS ACPI doesn't do anything to EHCI COMMAND register from >> commit. It doesn't have a name for it or declare it in some region. Anyway >> I've copied almost all asl EHCI controller code, but it didn't help. >> >> BUT! I've provided MP-table and PIRQ table to coreboot and I can say that >> the problem disappears when I boot with 'acpi=off' parameter! >> Also it disappears when I boot with 'nolapic' parameter >> >> What do they have in common?? >> >> >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Julius >> Werner >> Sent: Tuesday, October 10, 2017 5:56 AM >> To: Аладышев Константин >> Cc: Coreboot >> Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards >> >> > And now I'm kinda stuck. The effect of this commit doesn't seem to >> > interface with bios for me. So how does original IBASE/DFI bios can >> > overcome code error before this commit? >> > >> > What can be the source of my problem? What should I investigate more >> > precise based on result that I've got? >> >> My gut feeling would be to blame ACPI. The Linux patch is about caching a >> host controller register in the kernel, and in some cases (e.g. >> ehci_reset()), the patch re-reads the cached version from the hardware >> whereas the previous code didn't. If some BIOS ACPI mucks with that >> register, it's possible that this got the kernel's cached copy out of sync >> before this patch, but with the patch the kernel will re-read it from the >> hardware at the right time. Maybe only coreboot's ACPI routines touch the >> register in that path, or maybe the vendor BIOS' routines were more careful >> to restore the original state afterwards. >> >> Besides ACPI this could also be in SMM code, I guess (especially if the >> problem occurs around system suspend/resume, although it sounds like it >> doesn't for you). >> >> >> -- >> coreboot mailing list: [email protected] >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >> -- >> coreboot mailing list: [email protected] >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
