[coreboot] USB problem with Haswell+LynxPointLP motherboards

[ron minnich]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171019/0e032aca/attachment.html>