coreboot October 2017

coreboot@coreboot.org

66 participants
140 discussions

Re: [coreboot] ast2400 / ast2500
by Taiidan＠gmx.com 21 Oct '17

21 Oct '17

On 10/20/2017 03:04 PM, Tirumalesh wrote: > Thanks for the reply, it is somewhat strange though. > > It means no server board runs fully with coreboot as firmware for both c86 and BMC. > > If this is not the case, what kind of bmc is used by all the supported boards, all of them are using different firmware for bmc and x86? As tim said the KGPE-D16 and KCMA-D8 have a fully open source libre init process on coreboot and support the libre OpenBMC for the AST BMC chip There aren't any other coreboot boards that support a BMC, and the only other device that has both fully open source firmware/init and an open source BMC off the shelf is the TALOS 2. Coreboot itself couldn't be ran on a BMC chip, well I suppose one could port it but there really wouldn't be a point to that as that isn't what it was designed for. PS welcome to the list :D

2 1

Re: [coreboot] ast2400 / ast2500
by Tirumalesh 20 Oct '17

20 Oct '17

I am trying to see if coreboot can be main firmware on bmc. Does coreboot supports any BMC chips in general? Thanks, Tirumalesh On Fri, Oct 20, 2017 at 11:42 AM, David Hendricks <[david.hendricks(a)gmail.com]("mailto:david.hendricks@gmail.com")> wrote: > On Fri, Oct 20, 2017 at 7:46 AM, Tirumalesh <[tirumalesh(a)chalamarla.com]("mailto:tirumalesh@chalamarla.com")> wrote: > >> Hi, >> >> Could some one please let me know, if corebott supports either AST2400/AST2500 (ASpeed BMC) >> If yes, how to test it with QEMU? > > What kind of support are you looking for? There is some support for interfacing with it in coreboot running on the host: [https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/aspeed]("https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/aspeed") > > I believe this was added as part of the Asus KGPE-D16 OpenBMC porting effort: [https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php]("https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php")

1 0

Re: [coreboot] ast2400 / ast2500
by Timothy Pearson 20 Oct '17

20 Oct '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/2017 01:42 PM, David Hendricks wrote: > > > On Fri, Oct 20, 2017 at 7:46 AM, Tirumalesh <tirumalesh(a)chalamarla.com > <mailto:tirumalesh@chalamarla.com>> wrote: > > Hi, > > Could some one please let me know, if corebott supports either > AST2400/AST2500 (ASpeed BMC) > If yes, how to test it with QEMU? > > > What kind of support are you looking for? There is some support for > interfacing with it in coreboot running on the > host: https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/aspeed > <https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/aspeed> > > I believe this was added as part of the Asus KGPE-D16 OpenBMC porting > effort: https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php > <https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php> While somewhat similar in terms of interfaces / functionality, that board uses the AST2050 which is a much less powerful chip. The AST2400 doesn't see much use on x86 coreboot-supported platforms as far as I am aware; SuperMicro likes to use it but it doesn't look like any of those boards are supported (there are no reports for any of those boards in the board status repository [1]). [1] https://www.coreboot.org/Supported_Motherboards - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJZ6kSxAAoJEK+E3vEXDOFbqncH/20yUT8Lwdr7TiexfU8V8mIn 5CU8qGFinO5gtOszHDxC5FUtWjSWHoQxXNMFgZrnvh63HZuyAr9+F4nj4gWcObey cKsW4/OnNG6e83lSIQ/s9XabH2r0Fq2Tjof5vluS3eHX4UtzU2YqdFOgLAe4lca1 0NXZ9mj760KBfYo8W3d6l/7TGAeN6D4DA2H7yoaWiy3ANXbuQOC1FYgVNrVEwuCq jU+7TzQflrYSSvxAINoLjihpf5wu8mDxFob3wFRI7UR4dZn1Vo5c12ykkcb2GAbu 7i8T1nn+zak04hwEdIEX4bvjuHA7Tqtpc2r8K+IhDZ8Y4WTKl4fNncMwUeHPuwk= =U/cT -----END PGP SIGNATURE-----

2 1

Re: [coreboot] ast2400 / ast2500
by David Hendricks 20 Oct '17

20 Oct '17

On Fri, Oct 20, 2017 at 7:46 AM, Tirumalesh <tirumalesh(a)chalamarla.com> wrote: > Hi, > > Could some one please let me know, if corebott supports either > AST2400/AST2500 (ASpeed BMC) > If yes, how to test it with QEMU? > What kind of support are you looking for? There is some support for interfacing with it in coreboot running on the host: https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/aspeed I believe this was added as part of the Asus KGPE-D16 OpenBMC porting effort: https://www.raptorengineering.com/coreboot/kgpe-d16- bmc-port-status.php

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 20 Oct '17

20 Oct '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 3 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 1381814: (BUFFER_SIZE) /src/soc/intel/cannonlake/chip.c: 253 in platform_fsp_silicon_init_params_cb() /src/soc/intel/cannonlake/chip.c: 255 in platform_fsp_silicon_init_params_cb() ________________________________________________________________________________________________________ *** CID 1381814: (BUFFER_SIZE) /src/soc/intel/cannonlake/chip.c: 253 in platform_fsp_silicon_init_params_cb() 247 248 /* PCI Express */ 249 for (i = 0; i < ARRAY_SIZE(config->PcieClkSrcUsage); i++) { 250 if (config->PcieClkSrcUsage[i] == 0) 251 config->PcieClkSrcUsage[i] = PCIE_CLK_NOTUSED; 252 } >>> CID 1381814: (BUFFER_SIZE) >>> You might overrun the 16 byte destination string "params->PcieClkSrcUsage" by writing the maximum 24 bytes from "config->PcieClkSrcUsage". 253 memcpy(params->PcieClkSrcUsage, config->PcieClkSrcUsage, 254 sizeof(config->PcieClkSrcUsage)); 255 memcpy(params->PcieClkSrcClkReq, config->PcieClkSrcClkReq, 256 sizeof(config->PcieClkSrcClkReq)); 257 258 /* eMMC and SD */ /src/soc/intel/cannonlake/chip.c: 255 in platform_fsp_silicon_init_params_cb() 249 for (i = 0; i < ARRAY_SIZE(config->PcieClkSrcUsage); i++) { 250 if (config->PcieClkSrcUsage[i] == 0) 251 config->PcieClkSrcUsage[i] = PCIE_CLK_NOTUSED; 252 } 253 memcpy(params->PcieClkSrcUsage, config->PcieClkSrcUsage, 254 sizeof(config->PcieClkSrcUsage)); >>> CID 1381814: (BUFFER_SIZE) >>> You might overrun the 16 byte destination string "params->PcieClkSrcClkReq" by writing the maximum 24 bytes from "config->PcieClkSrcClkReq". 255 memcpy(params->PcieClkSrcClkReq, config->PcieClkSrcClkReq, 256 sizeof(config->PcieClkSrcClkReq)); 257 258 /* eMMC and SD */ 259 params->ScsEmmcEnabled = config->ScsEmmcEnabled; 260 params->ScsEmmcHs400Enabled = config->ScsEmmcHs400Enabled; ** CID 1381813: Memory - corruptions (OVERRUN) /src/soc/intel/cannonlake/chip.c: 253 in platform_fsp_silicon_init_params_cb() ________________________________________________________________________________________________________ *** CID 1381813: Memory - corruptions (OVERRUN) /src/soc/intel/cannonlake/chip.c: 253 in platform_fsp_silicon_init_params_cb() 247 248 /* PCI Express */ 249 for (i = 0; i < ARRAY_SIZE(config->PcieClkSrcUsage); i++) { 250 if (config->PcieClkSrcUsage[i] == 0) 251 config->PcieClkSrcUsage[i] = PCIE_CLK_NOTUSED; 252 } >>> CID 1381813: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PcieClkSrcUsage" of 16 bytes by passing it to a function which accesses it at byte offset 23 using argument "24UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 253 memcpy(params->PcieClkSrcUsage, config->PcieClkSrcUsage, 254 sizeof(config->PcieClkSrcUsage)); 255 memcpy(params->PcieClkSrcClkReq, config->PcieClkSrcClkReq, 256 sizeof(config->PcieClkSrcClkReq)); 257 258 /* eMMC and SD */ ** CID 1381812: Memory - corruptions (OVERRUN) /src/soc/intel/cannonlake/chip.c: 255 in platform_fsp_silicon_init_params_cb() ________________________________________________________________________________________________________ *** CID 1381812: Memory - corruptions (OVERRUN) /src/soc/intel/cannonlake/chip.c: 255 in platform_fsp_silicon_init_params_cb() 249 for (i = 0; i < ARRAY_SIZE(config->PcieClkSrcUsage); i++) { 250 if (config->PcieClkSrcUsage[i] == 0) 251 config->PcieClkSrcUsage[i] = PCIE_CLK_NOTUSED; 252 } 253 memcpy(params->PcieClkSrcUsage, config->PcieClkSrcUsage, 254 sizeof(config->PcieClkSrcUsage)); >>> CID 1381812: Memory - corruptions (OVERRUN) >>> Overrunning array "params->PcieClkSrcClkReq" of 16 bytes by passing it to a function which accesses it at byte offset 23 using argument "24UL". [Note: The source code implementation of the function has been overridden by a builtin model.] 255 memcpy(params->PcieClkSrcClkReq, config->PcieClkSrcClkReq, 256 sizeof(config->PcieClkSrcClkReq)); 257 258 /* eMMC and SD */ 259 params->ScsEmmcEnabled = config->ScsEmmcEnabled; 260 params->ScsEmmcHs400Enabled = config->ScsEmmcHs400Enabled; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

ast2400 / ast2500
by Tirumalesh 20 Oct '17

20 Oct '17

Hi, Could some one please let me know, if corebott supports either AST2400/AST2500 (ASpeed BMC) If yes, how to test it with QEMU? Thanks for the help, Tirumalesh.

1 0

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Matt DeVillier 19 Oct '17

19 Oct '17

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/30cd1f345b0497d1465eb9cc1d924bf… On Thu, Oct 19, 2017 at 1:20 PM, Zoran Stojsavljevic < zoran.stojsavljevic(a)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(a)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@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(a)nicevt.ru> >> wrote: >> >> I've found one more parameter that helps me boot without USB problem: >> 'noapictimer' >> >> >> -----Original Message----- >> From: Аладышев Константин [mailto:aladyshev@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(a)google.com [mailto:jwerner@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(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Аладышев Константин 19 Oct '17

19 Oct '17

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@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(a)nicevt.ru> wrote: I've found one more parameter that helps me boot without USB problem: 'noapictimer' -----Original Message----- From: Аладышев Константин [mailto:aladyshev@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(a)google.com [mailto:jwerner@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(a)coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] Recommendation for Flashing Clips / mass order
by Trammell Hudson 19 Oct '17

19 Oct '17

On Wed, Oct 18, 2017 at 07:27:50PM -0400, [799] via coreboot wrote: > I like that idea, I think I'll just choose a cheap one and in case it > breaks I just use another one. I've tried the really cheap ones and found that they do not work very well at all. Even brand new this one required wiggling to get it to seat and make contact: https://www.amazon.com/gp/product/B015W4PKR6 The breadboard adapter has been quite useful, but I can't recommend the clip. My recommendation is to buy the Pomona. Unless you are clipping hundreds of times per week, it will last a long time. -- Trammell

1 0

Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
by Аладышев Константин 19 Oct '17

19 Oct '17

I've found one more parameter that helps me boot without USB problem: 'noapictimer' -----Original Message----- From: Аладышев Константин [mailto:aladyshev@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(a)google.com [mailto:jwerner@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).

2 1

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2017