Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards

[Zoran Stojsavljevic]

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, Аладышев Константин 
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:[e-mail]]
> *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 Аладышев Константин 
> wrote:
>
> I've found one more parameter that helps me boot without USB problem:
> 'noapictimer'
>
> -----Original Message-----
> From: Аладышев Константин [mailto:[e-mail]]
> 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:
> 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.
> 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.
> 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: [e-mail] [mailto:[e-mail]] 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).