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
