[coreboot] USB problem with Haswell+LynxPointLP motherboards

[Matt DeVillier]

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 <
zoran.stojsavljevic at gmail.com> 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, Аладышев Константин <aladyshev at nicevt.ru>
> 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:rminnich at gmail.com]
>> *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 Аладышев Константин <aladyshev at nicevt.ru>
>> wrote:
>>
>> I've found one more parameter that helps me boot without USB problem:
>> 'noapictimer'
>>
>>
>> -----Original Message-----
>> From: Аладышев Константин [mailto:aladyshev at nicevt.ru]
>> 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: jwerner at google.com [mailto:jwerner at google.com] 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: coreboot at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171019/a0d69907/attachment.html>