<div dir="ltr">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?<div><br></div><div>ref: <a href="https://github.com/MattDevo/coreboot/commit/30cd1f345b0497d1465eb9cc1d924bf644d324b9">https://github.com/MattDevo/coreboot/commit/30cd1f345b0497d1465eb9cc1d924bf644d324b9</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 19, 2017 at 1:20 PM, Zoran Stojsavljevic <span dir="ltr"><<a href="mailto:zoran.stojsavljevic@gmail.com" target="_blank">zoran.stojsavljevic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I guess, Konstantin... My take on this investigation. ;-)<div><br></div><div>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.</div><div><br></div><div>And you, GOOGLE guys... Should think a bit beyond Reality. You should...</div><div><br></div><div>(I am damn serious)!</div><span class="HOEnZb"><font color="#888888"><div>Zoran Stojsavljevic</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 19, 2017 at 4:56 PM, Аладышев Константин <span dir="ltr"><<a href="mailto:aladyshev@nicevt.ru" target="_blank">aladyshev@nicevt.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="RU" link="blue" vlink="purple"><div class="m_-5156927944439458825m_2523009402187706610WordSection1"><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">No, unfortunately this option by itself doesn’t help.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I guess my minimal hammer is ‘noapictimer’<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">But I wonder how these 3 boot parameters (‘noapictimer’ ‘nolapic’ and ‘acpi=off’) separately help to solve my issue.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Coreboot has straightforward: 0-0, 1-1, 2-2, 3-3.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">But original BIOS has: 1-0, 2-2, 3-1, 4-3<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I wonder if it means something?<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> ron minnich [mailto:<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>] <br><b>Sent:</b> Thursday, October 19, 2017 5:29 PM<br><b>To:</b> Аладышев Константин; Julius Werner</span></p><div><div class="m_-5156927944439458825h5"><br><b>Cc:</b> Coreboot<br><b>Subject:</b> Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards<u></u><u></u></div></div><p></p><div><div class="m_-5156927944439458825h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">we had a similar problem and we set <u></u><u></u></p><div><p class="MsoNormal">pci=nocrs<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">which means 'ignore what ACPI tells you and probe it again"<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">It's much less of a big hammer than 'acpi=off' :-)<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Oct 19, 2017 at 7:22 AM Аладышев Константин <<a href="mailto:aladyshev@nicevt.ru" target="_blank">aladyshev@nicevt.ru</a>> wrote:<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">I've found one more parameter that helps me boot without USB problem: 'noapictimer'<br><br><br>-----Original Message-----<br>From: Аладышев Константин [mailto:<a href="mailto:aladyshev@nicevt.ru" target="_blank">aladyshev@nicevt.ru</a>]<br>Sent: Wednesday, October 18, 2017 3:58 PM<br>To: 'Julius Werner'<br>Cc: 'Coreboot'<br>Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards<br><br>Ok, I've done some investigations about what can be the source of my problem:<br><br>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.<br><br>2) SMI<br>There are special registers for EHCI controller SMIs in its pci config space:<br>-USB EHCI Legacy Support Extended<br>-Intel Specific USB 2.0 SMI<br>But in both of them SMIs are disabled as in coreboot+seabios image as in original bios.<br><br>3) ACPI<br>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.<br><br>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!<br>Also it disappears when I boot with 'nolapic' parameter<br><br>What do they have in common??<br><br><br><br><br>-----Original Message-----<br>From: <a href="mailto:jwerner@google.com" target="_blank">jwerner@google.com</a> [mailto:<a href="mailto:jwerner@google.com" target="_blank">jwerner@google.com</a>] On Behalf Of Julius Werner<br>Sent: Tuesday, October 10, 2017 5:56 AM<br>To: Аладышев Константин<br>Cc: Coreboot<br>Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards<br><br>> And now I'm kinda stuck. The effect of this commit doesn't seem to<br>> interface with bios for me. So how does original IBASE/DFI bios can<br>> overcome code error before this commit?<br>><br>> What can be the source of my problem? What should I investigate more<br>> precise based on result that I've got?<br><br>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.<br><br>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).<br><br><br>--<br>coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br><a href="https://mail.coreboot.org/mailman/listinfo/coreboot" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a><u></u><u></u></p></blockquote></div></div></div></div></div><br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/mail<wbr>man/listinfo/coreboot</a><br></blockquote></div><br></div>
</div></div><br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br></blockquote></div><br></div>