[coreboot] Interrupt routing with PCIe bridges as many functions of one southbridge device
Hello! I'm working with Haswell+Lynxpoint chip and it has 6 PCIe bridges presented on one southbridge device "1c" as six functions (I mean "1c.0", "1c.1", ..., "1c.5"). As I understand, every function (bridge in this example) can drive only one INTX line of its "1c" device. For example, function 1c.2 can drive only INTC of "1c" device. Does it mean that every device behind 1c.2 PCIe bridge should connect all of its INTA-D lines to INTC of 1c.2 in order to work? (by "connect" I mean declare interrupt routing in ACPI/MP table/PIRQ table) Best Regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] "pci=nomsi" parameter for PCIe devices
Hello! I use PCIe device xr17v358 to make UARTs on my motherboard (https://www.exar.com/product/interface/uarts/pcie-uarts/xr17v358). But UARTs work correctly only if I boot Linux kernel with "pci=nomsi" parameter. I can always see and operate with PCIe configuration space correctly, but normally (without "pci=nomsi" parameter) xr17v358 driver never enters its interrupt routine, that is used for transmit/receive characters. Can this somehow be a BIOS issue or it is more likely a xr17v358 driver issue? Best Regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Is CONFIG_USE_OPTION_TABLE option stable?
Hello! I'm trying to include CMOS variables use to my Coreboot, but when I enable "CONFIG_USE_OPTION_TABLE" option strange things happen. Windows stucks at boot logo and coreinfo payload displays very strange NVRAM RTC data (completely incorrect time with year and second that increment every second). I checked this with upstream code on Google/Panther motherboard. This motherboard uses "mc146818rtc" driver for RTC. Without "CONFIG_USE_OPTION_TABLE" option coreinfo displays time correctly. What can be the source of such thing? Best Regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Link layer between "coreboot" - "seabios" - "coreinfo/nvramcui"
I've found out that commit that broke down compatibility with my old Coreboot was: libpayload/libc/console: Flush input driver buffer on init https://review.coreboot.org/#/c/coreboot/+/19345/ If I revert it with the newest Coreboot, payloads (coreinfo/nvramcui) will work with my old Coreboot version. Best regards, Aladyshev Konstantin -Original Message- From: Аладышев Константин [mailto:aladys...@nicevt.ru] Sent: Thursday, January 18, 2018 1:02 PM To: 'Coreboot' Subject: Re: Link layer between "coreboot" - "seabios" - "coreinfo/nvramcui" Last lines of log from SeaBIOS: Run img/coreinfo.elf Segment 45444f43 48469@0xfff6a770 -> 405328@0x0010 Uncompressing data 48469@0xfff6a770 to 405328@0x0010 Calling addr 0x0010 Best regards, Aladyshev Konstantin -Original Message- From: Аладышев Константин [mailto:aladys...@nicevt.ru] Sent: Thursday, January 18, 2018 12:35 PM To: 'Coreboot' Subject: Link layer between "coreboot" - "seabios" - "coreinfo/nvramcui" Hello! I have a project for my motherboard with coreboot version that I fixed couple years back (so it is pretty old), and now I want to update all payloads to most modern ones. There is no problem with SeaBIOS, but coreinfo and nvramcui don't work. When I try to jump to them from SeaBIOS, nothing happens and screen turns black. So... what is the link layer between those payloads and coreboot? Layer that I should also update for those new payloads to work fine? Don't forget, this it is not only video problem, there is no output from COM also. So maybe it is connected to CBFS or payload format? What should I check? Best regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Link layer between "coreboot" - "seabios" - "coreinfo/nvramcui"
Last lines of log from SeaBIOS: Run img/coreinfo.elf Segment 45444f43 48469@0xfff6a770 -> 405328@0x0010 Uncompressing data 48469@0xfff6a770 to 405328@0x0010 Calling addr 0x0010 Best regards, Aladyshev Konstantin -Original Message- From: Аладышев Константин [mailto:aladys...@nicevt.ru] Sent: Thursday, January 18, 2018 12:35 PM To: 'Coreboot' Subject: Link layer between "coreboot" - "seabios" - "coreinfo/nvramcui" Hello! I have a project for my motherboard with coreboot version that I fixed couple years back (so it is pretty old), and now I want to update all payloads to most modern ones. There is no problem with SeaBIOS, but coreinfo and nvramcui don't work. When I try to jump to them from SeaBIOS, nothing happens and screen turns black. So... what is the link layer between those payloads and coreboot? Layer that I should also update for those new payloads to work fine? Don't forget, this it is not only video problem, there is no output from COM also. So maybe it is connected to CBFS or payload format? What should I check? Best regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Link layer between "coreboot" - "seabios" - "coreinfo/nvramcui"
Hello! I have a project for my motherboard with coreboot version that I fixed couple years back (so it is pretty old), and now I want to update all payloads to most modern ones. There is no problem with SeaBIOS, but coreinfo and nvramcui don't work. When I try to jump to them from SeaBIOS, nothing happens and screen turns black. So... what is the link layer between those payloads and coreboot? Layer that I should also update for those new payloads to work fine? Don't forget, this it is not only video problem, there is no output from COM also. So maybe it is connected to CBFS or payload format? What should I check? Best regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Correct value for PCI_INTERRUPT_LINE register
I know that today nobody is really interested in support of legacy boot
options like 'acpi=off', 'noapic', 'nolapic', irq tables like MP table and
$PIR, but sometimes booting with these legacy modes can help you to debug
BIOS issues. So I've wanted to implement support of these options for my
board (Haswell CPU + LynxpointLP PCH).
I've implemented MP table and $PIR and came to fact, that linux can't boot
with 'acpi=off nolapic' options combination. Through some investigation of
Linux boot process I've found out that the problem can be in wrong PCI IRQ
routing. I've enabled debug information in file "arch/x86/pci/irq.c"
("dyndbg='file arch/x86/pci/irq.c +pmf;'") and got this:
[0.080004] irq:pcibios_fixup_irqs: pci :00:02.0: ignoring bogus IRQ
139
[0.080008] irq:pcibios_fixup_irqs: pci :00:03.0: ignoring bogus IRQ
139
[0.080012] irq:pcibios_fixup_irqs: pci :00:16.0: ignoring bogus IRQ
139
[0.080017] irq:pcibios_fixup_irqs: pci :00:1b.0: ignoring bogus IRQ
139
[0.080021] irq:pcibios_fixup_irqs: pci :00:1c.0: ignoring bogus IRQ
139
[0.080025] irq:pcibios_fixup_irqs: pci :00:1c.1: ignoring bogus IRQ
139
[0.080029] irq:pcibios_fixup_irqs: pci :00:1c.2: ignoring bogus IRQ
138
[0.080033] irq:pcibios_fixup_irqs: pci :00:1c.3: ignoring bogus IRQ
138
[0.080037] irq:pcibios_fixup_irqs: pci :00:1c.4: ignoring bogus IRQ
139
[0.080041] irq:pcibios_fixup_irqs: pci :00:1c.5: ignoring bogus IRQ
139
[0.080046] irq:pcibios_fixup_irqs: pci :00:1d.0: ignoring bogus IRQ
139
[0.080050] irq:pcibios_fixup_irqs: pci :00:1f.3: ignoring bogus IRQ
138
[0.080055] irq:pcibios_fixup_irqs: pci :05:00.0: ignoring bogus IRQ
139
[0.080059] irq:pcibios_fixup_irqs: pci :05:00.1: ignoring bogus IRQ
139
[0.080069] irq:pcibios_lookup_irq: pci :00:02.0: PCI INT A -> PIRQ
60, mask dc78, excl
[0.080073] irq:pcibios_lookup_irq: pci :00:02.0: PCI INT A -> newirq
0
[0.080079] irq:pcibios_lookup_irq: pci :00:02.0: can't route
interrupt
[0.080086] irq:pcibios_lookup_irq: pci :00:03.0: PCI INT A -> PIRQ
60, mask dc78, excl
[0.080090] irq:pcibios_lookup_irq: pci :00:03.0: PCI INT A -> newirq
0
[0.080095] irq:pcibios_lookup_irq: pci :00:03.0: can't route
interrupt
[0.080111] irq:pcibios_lookup_irq: pci :00:16.0: PCI INT A -> PIRQ
60, mask dc78, excl
[0.080115] irq:pcibios_lookup_irq: pci :00:16.0: PCI INT A -> newirq
0
[0.080120] irq:pcibios_lookup_irq: pci :00:16.0: can't route
interrupt
[0.080128] irq:pcibios_lookup_irq: pci :00:1b.0: PCI INT A -> PIRQ
6a, mask dc78, excl
[0.080131] irq:pcibios_lookup_irq: pci :00:1b.0: PCI INT A -> newirq
0
[0.080137] irq:pcibios_lookup_irq: pci :00:1b.0: can't route
interrupt
[0.080144] irq:pcibios_lookup_irq: pci :00:1c.0: PCI INT A -> PIRQ
60, mask dc78, excl
[0.080148] irq:pcibios_lookup_irq: pci :00:1c.0: PCI INT A -> newirq
0
[0.080154] irq:pcibios_lookup_irq: pci :00:1c.0: can't route
interrupt
[0.080161] irq:pcibios_lookup_irq: pci :00:1c.1: PCI INT B -> PIRQ
61, mask dc78, excl
[0.080165] irq:pcibios_lookup_irq: pci :00:1c.1: PCI INT B -> newirq
0
[0.080171] irq:pcibios_lookup_irq: pci :00:1c.1: can't route
interrupt
[0.080178] irq:pcibios_lookup_irq: pci :00:1c.2: PCI INT C -> PIRQ
62, mask dc78, excl
[0.080182] irq:pcibios_lookup_irq: pci :00:1c.2: PCI INT C -> newirq
0
[0.080188] irq:pcibios_lookup_irq: pci :00:1c.2: can't route
interrupt
[0.080195] irq:pcibios_lookup_irq: pci :00:1c.3: PCI INT D -> PIRQ
63, mask dc78, excl
[0.080199] irq:pcibios_lookup_irq: pci :00:1c.3: PCI INT D -> newirq
0
[0.080204] irq:pcibios_lookup_irq: pci :00:1c.3: can't route
interrupt
[0.080212] irq:pcibios_lookup_irq: pci :00:1c.4: PCI INT A -> PIRQ
60, mask dc78, excl
[0.080216] irq:pcibios_lookup_irq: pci :00:1c.4: PCI INT A -> newirq
0
[0.080221] irq:pcibios_lookup_irq: pci :00:1c.4: can't route
interrupt
[0.080228] irq:pcibios_lookup_irq: pci :00:1c.5: PCI INT B -> PIRQ
61, mask dc78, excl
[0.080232] irq:pcibios_lookup_irq: pci :00:1c.5: PCI INT B -> newirq
0
[0.080238] irq:pcibios_lookup_irq: pci :00:1c.5: can't route
interrupt
[0.080245] irq:pcibios_lookup_irq: pci :00:1d.0: PCI INT A -> PIRQ
6b, mask dc78, excl
[0.080249] irq:pcibios_lookup_irq: pci :00:1d.0: PCI INT A -> newirq
0
[0.080255] irq:pcibios_lookup_irq: pci :00:1d.0: can't route
interrupt
[0.080266] irq:pcibios_lookup_irq: pci :00:1f.3: PCI INT C -> PIRQ
62, mask dc78, excl
[0.080270] irq:pcibios_lookup_irq: pci :00:1f.3: PCI INT C -> newirq
0
[0.080275] irq:pcibios_lookup_irq: pci :00:1f.3: can't route
interrupt
[0.080320] irq:pcibios_lookup_irq: pci :05:00.0: PCI INT A not found
in routing table
Re: [coreboot] Embedded Controller (EC)
Thanks! But my main purpose right now is to make standard OS-battery interface through ACPI embedded controller. And as I understand embedded controller in 'twinkie' isn't the one suitable for this case, as 'twinkie' is separate board that implements USB-PD sniffing dongle with Type-C connectors . Best Regards, Aladyshev Konstantin -Original Message- From: sha...@google.com [mailto:sha...@google.com] On Behalf Of Shawn N Sent: Friday, December 08, 2017 8:14 PM To: Аладышев Константин Cc: Vadim Bendebury; Randall Spangler; Coreboot Subject: Re: [coreboot] Embedded Controller (EC) On Fri, Dec 8, 2017 at 8:30 AM, Randall Spangler <rspang...@chromium.org> wrote: > On Fri, Dec 8, 2017 at 5:57 AM, Аладышев Константин > <aladys...@nicevt.ru> > wrote: >> >> Thanks for your answer! >> >> I've looked more closely at Chromium Embedded Controller project and >> EC chips it supports. To my surprise 'chromeec' even supports >> ordinary STM32 controllers without ACPI EC registers (am I right?). > > > Yes, we've used it for everything from the main EC to a USB-PD > controller to a charger. STM32 isn't suitable as the main EC for > x86-based Chromebooks, of course, due to lack of eSPI / LPC. > >> >> So I think is it very important to do schematics as it is in >> Chromebooks to make use of this project. >> >> Is there any chance to find schematics for Chromebook boards, to get >> reference design of implementing ECs with ‘chromeec’ project? > > > I don't know. But it supports several STM32 discovery boards, so you > can tinker with it on ready-built hardware. There are also schematics available for several misc. peripherals that use stm32 + cros_ec, see twinkie for example: https://www.chromium.org/chromium-os/twinkie Unfortunately there are no schematics for actual Chromebook mainboards publicly available. I looked into making some public, but there were some overriding concerns. > >> >> Best regards, >> Aladyshev Konstantin >> >> >> >> From: rspang...@google.com [mailto:rspang...@google.com] On Behalf Of >> Randall Spangler >> Sent: Friday, December 01, 2017 7:02 PM >> To: Vadim Bendebury >> Cc: Аладышев Константин; Coreboot; Shawn N >> Subject: Re: [coreboot] Embedded Controller (EC) >> >> On Fri, Dec 1, 2017 at 6:32 AM, Vadim Bendebury >> <vben...@chromium.org> >> wrote: >> [+cc a couple of guys who might have some advice in this respect] >> >> On Fri, Dec 1, 2017 at 5:07 AM, Аладышев Константин >> <aladys...@nicevt.ru> >> wrote: >> Hello! I'm trying to understand, what is the easiest way today to >> integrate EC to custom motherboard? What controller should I choose >> for new custom motherboard? >> >> 1) First of all, are there any ECs on market that ship with embedded >> firmware, where all you need to do is just a little bit of register >> configuration (like SuperIO)? Or is it always like you need to write >> all firmware by yourself? >> >> Most EC vendors that sell dedicated ECs also sell their SDK and >> source code, but it's not cheap. So usually roll your own, hopefully >> based on an open design. >> >> In that case what is the main difference between ordinary >> microcontroller (for example STM32) and some controller marked by >> vendor as EC? >> >> Interfaces. EC will have: >> • Keyboard scanner >> • eSPI / LPC for connecting to x86 SoC • More I2C ports (and in the >> old days, PECI and PS/2 ports). >> >> >> 2) How stable and flexible are projects about open EC firmware? Is it >> possible to adapt these projects for my custom motherboard? >> >> I'm talking about: >> - Chromium Embedded Controller: >> http://www.chromium.org/chromium-os/ec-development >> >> This is used on all current Chromebooks, so it's full-featured and stable. >> We do tend to branch old boards, so if your motherboard has an old >> chipset on it you may need to look back in time to find support for it. >> >> >> - Origami-EC: >> https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary >> >> 3) What is the current status of EC support from coreboot point of view? >> https://review.coreboot.org/cgit/coreboot.git/tree/src/ec >> >> Best regards, >> Aladyshev Konstantin >> >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >> > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Embedded Controller (EC)
I'm a little bit confused. When we say 'main EC' controller, do we mean ACPI EC controller? The one that provides special interface with EC_SC, EC_DATA registers as defined in ACPI spec. Cause my main purpose right now is to make standard OS-battery interface through embedded controller. And I’m looking for the simplest way to do it. As I understand ‘chromeec’ projects describes all embedded controllers used in chromebooks and this includes as standard ACPI EC controllers, as special embedded controllers for things like USB Type-C to DP/HDMI/VGA adapter. Are there any boards in 'chromeec' project that use STM32 as 'main EC'? Or STM32 is only used for other special things like USB Type-C to DP/HDMI/VGA adapter? And is there any info document that describes all boards in ‘board’ catalog? Best Regards, Aladyshev Konstantin From: rspang...@google.com [mailto:rspang...@google.com] On Behalf Of Randall Spangler Sent: Friday, December 08, 2017 7:30 PM To: Аладышев Константин Cc: Vadim Bendebury; Coreboot; Shawn N Subject: Re: [coreboot] Embedded Controller (EC) On Fri, Dec 8, 2017 at 5:57 AM, Аладышев Константин <aladys...@nicevt.ru> wrote: Thanks for your answer! I've looked more closely at Chromium Embedded Controller project and EC chips it supports. To my surprise 'chromeec' even supports ordinary STM32 controllers without ACPI EC registers (am I right?). Yes, we've used it for everything from the main EC to a USB-PD controller to a charger. STM32 isn't suitable as the main EC for x86-based Chromebooks, of course, due to lack of eSPI / LPC. So I think is it very important to do schematics as it is in Chromebooks to make use of this project. Is there any chance to find schematics for Chromebook boards, to get reference design of implementing ECs with ‘chromeec’ project? I don't know. But it supports several STM32 discovery boards, so you can tinker with it on ready-built hardware. Best regards, Aladyshev Konstantin From: rspang...@google.com [mailto:rspang...@google.com] On Behalf Of Randall Spangler Sent: Friday, December 01, 2017 7:02 PM To: Vadim Bendebury Cc: Аладышев Константин; Coreboot; Shawn N Subject: Re: [coreboot] Embedded Controller (EC) On Fri, Dec 1, 2017 at 6:32 AM, Vadim Bendebury <vben...@chromium.org> wrote: [+cc a couple of guys who might have some advice in this respect] On Fri, Dec 1, 2017 at 5:07 AM, Аладышев Константин <aladys...@nicevt.ru> wrote: Hello! I'm trying to understand, what is the easiest way today to integrate EC to custom motherboard? What controller should I choose for new custom motherboard? 1) First of all, are there any ECs on market that ship with embedded firmware, where all you need to do is just a little bit of register configuration (like SuperIO)? Or is it always like you need to write all firmware by yourself? Most EC vendors that sell dedicated ECs also sell their SDK and source code, but it's not cheap. So usually roll your own, hopefully based on an open design. In that case what is the main difference between ordinary microcontroller (for example STM32) and some controller marked by vendor as EC? Interfaces. EC will have: • Keyboard scanner • eSPI / LPC for connecting to x86 SoC • More I2C ports (and in the old days, PECI and PS/2 ports). 2) How stable and flexible are projects about open EC firmware? Is it possible to adapt these projects for my custom motherboard? I'm talking about: - Chromium Embedded Controller: http://www.chromium.org/chromium-os/ec-development This is used on all current Chromebooks, so it's full-featured and stable. We do tend to branch old boards, so if your motherboard has an old chipset on it you may need to look back in time to find support for it. - Origami-EC: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary 3) What is the current status of EC support from coreboot point of view? https://review.coreboot.org/cgit/coreboot.git/tree/src/ec Best regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Embedded Controller (EC)
Thanks for your answer! I've looked more closely at Chromium Embedded Controller project and EC chips it supports. To my surprise 'chromeec' even supports ordinary STM32 controllers without ACPI EC registers (am I right?). So I think is it very important to do schematics as it is in Chromebooks to make use of this project. Is there any chance to find schematics for Chromebook boards, to get reference design of implementing ECs with ‘chromeec’ project? Best regards, Aladyshev Konstantin From: rspang...@google.com [mailto:rspang...@google.com] On Behalf Of Randall Spangler Sent: Friday, December 01, 2017 7:02 PM To: Vadim Bendebury Cc: Аладышев Константин; Coreboot; Shawn N Subject: Re: [coreboot] Embedded Controller (EC) On Fri, Dec 1, 2017 at 6:32 AM, Vadim Bendebury <vben...@chromium.org> wrote: [+cc a couple of guys who might have some advice in this respect] On Fri, Dec 1, 2017 at 5:07 AM, Аладышев Константин <aladys...@nicevt.ru> wrote: Hello! I'm trying to understand, what is the easiest way today to integrate EC to custom motherboard? What controller should I choose for new custom motherboard? 1) First of all, are there any ECs on market that ship with embedded firmware, where all you need to do is just a little bit of register configuration (like SuperIO)? Or is it always like you need to write all firmware by yourself? Most EC vendors that sell dedicated ECs also sell their SDK and source code, but it's not cheap. So usually roll your own, hopefully based on an open design. In that case what is the main difference between ordinary microcontroller (for example STM32) and some controller marked by vendor as EC? Interfaces. EC will have: • Keyboard scanner • eSPI / LPC for connecting to x86 SoC • More I2C ports (and in the old days, PECI and PS/2 ports). 2) How stable and flexible are projects about open EC firmware? Is it possible to adapt these projects for my custom motherboard? I'm talking about: - Chromium Embedded Controller: http://www.chromium.org/chromium-os/ec-development This is used on all current Chromebooks, so it's full-featured and stable. We do tend to branch old boards, so if your motherboard has an old chipset on it you may need to look back in time to find support for it. - Origami-EC: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary 3) What is the current status of EC support from coreboot point of view? https://review.coreboot.org/cgit/coreboot.git/tree/src/ec Best regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Embedded Controller (EC)
Hello! I'm trying to understand, what is the easiest way today to integrate EC to custom motherboard? What controller should I choose for new custom motherboard? 1) First of all, are there any ECs on market that ship with embedded firmware, where all you need to do is just a little bit of register configuration (like SuperIO)? Or is it always like you need to write all firmware by yourself? In that case what is the main difference between ordinary microcontroller (for example STM32) and some controller marked by vendor as EC? 2) How stable and flexible are projects about open EC firmware? Is it possible to adapt these projects for my custom motherboard? I'm talking about: - Chromium Embedded Controller: http://www.chromium.org/chromium-os/ec-development - Origami-EC: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary 3) What is the current status of EC support from coreboot point of view? https://review.coreboot.org/cgit/coreboot.git/tree/src/ec Best regards, Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Does S3 work on Haswell boards?
I don’t think that the problem is connected to operating system version as both Windows 7 and Ubuntu 16.04 act the same for me: - for S3 time less than ~15s, resume works ok - for S3 time longer than ~15s, Coreboot won't resume with quick_ram_check error I use “pm-suspend” to go to S3, but “systemctl suspend” works exactly the same. USB wakeup doesn't work at all for me. I wake system with power button. From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com] Sent: Tuesday, October 31, 2017 10:19 AM To: Аладышев Константин Cc: Coreboot Subject: Re: [coreboot] Does S3 work on Haswell boards? Hello Kostja, Since presently I am not in Munich/Germany (I am in front of my HSW notebook in my apartment in Belgrade), I have limited abilities to test your question, since I do not have native/bare metal Fedora on my SSD (I have in safe box HDD with dual boot: WIN10 and Fedora 26 in Munich). Here, I have my notebook (HP EliteBook 840 G1) with SSD, bare metal WIN10 64 PRO and VMWare reader with Fedora 26 VM. IT is based on HSW i5-4300: [user@192 ~]$ dmesg | grep 4300 [0.097524] smpboot: CPU0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz (family: 0x6, model: 0x45, stepping: 0x1) [user@192 ~]$ Here is the pointer to ark.intel.com for this CPU: https://ark.intel.com/products/76308/Intel-Core-i5-4300U-Processor-3M-Cache-up-to-2_90-GHz The current BSP used is UEFI: BIOS 01.39 Rev.A (08 Nov 2016) -> sp77791.exe (12.7 MB) ___ Being in WIN10, suspend works when I simply press , but resume works ONLY while I press muse buttons - keyboard does not work, although it should?! I did several attempts to suspend and resume using Fedora 26 VM, but I did not have success. I do remember that this does work with my bare metal Fedora 26: Kernel used for Fedora26 VM: uname -r -> 4.13.9-200.fc26.x86_64 . I would strongly suggest to use two methods to check S3 on Linux bare metal: [1] To use systemctl suspend and systemctl resume commands; [2] To install on your HSW platform the following package: http://www.linuxfromscratch.org/blfs/view/cvs/general/pm-utils.html so you can try the following two commands: pm-suspend and pm-hibernate (wakeup should work using keyboard/mouse)! First, you should do all these tests with UEFI BIOS for your platform, record the results, and then switch to Coreboot, than repeat all use cases, and cross compare. If you do, please, post your kernel version and results here. Hope this helps. Best Regards, Zoran Stojsavljevic ___ On Mon, Oct 30, 2017 at 4:49 PM, Аладышев Константин <aladys...@nicevt.ru> wrote: I have problem with S3 mode on Haswell board. Everything is fine if S3 time is very small (<15 seconds), but if it is longer, coreboot won't resume. It fails on quick_ram_check. I've enabled mrc.cache and ME in coreboot. I use ME binary from original board and MRC.bin from Google Panther. Log from S3 resume: """ Disabling Watchdog reboot... done. SMBus controller enabled. Setting up static northbridge registers... done. Initializing Graphics... Back from haswell_early_initialization() Resume from S3 detected. CPU id(40651) ucode:001c Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz AES supported, TXT supported, VT supported PCH type: LP Premium, device id: 9c43, rev id 4 Starting UEFI PEI System Agent CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100 CBFS: CBFS location: 0xf0~0xfff7c0, align: 64 CBFS: Looking for 'mrc.cache' starting from 0xf0. CBFS: - load entry 0xf0 file name (16 bytes)... CBFS: (unmatched file @0xf0: bootsplash.jpg) CBFS: - load entry 0xf187c0 file name (16 bytes)... CBFS: (unmatched file @0xf187c0: bootorder) CBFS: - load entry 0xf18b80 file name (16 bytes)... CBFS: (unmatched file @0xf18b80: cmos_layout.bin) CBFS: - load entry 0xf19040 file name (32 bytes)... CBFS: (unmatched file @0xf19040: pci8086,0a26.rom) CBFS: - load entry 0xf29080 file name (72 bytes)... CBFS: (unmatched file @0xf29080: cpu_microcode_blob.bin) CBFS: - load entry 0xf2e100 file name (32 bytes)... CBFS: (unmatched file @0xf2e100: etc/usb-time-sigatt) CBFS: - load entry 0xf2e140 file name (16 bytes)... CBFS: (unmatched file @0xf2e140: config) CBFS: - load entry 0xf2fa00 file name (16 bytes)... CBFS: (unmatched file @0xf2fa00: revision) CBFS: - load entry 0xf2fc80 file name (16 bytes)... CBFS: (unmatched file @0xf2fc80: ) CBFS: - load entry 0xf2ff80 file name (76 bytes)... CBFS: (unmatched file @0xf2ff80: fallback/romstage) CBFS: - load entry 0xf38f00 file name (32 bytes)... CBFS: (unmatched file @0xf38f00: fallback/ramstage) CBFS: - load entry 0xf4d0c0 file name (32 bytes)... CBFS: (unmatched file @0xf4d0c0: fallback/payload) CBFS: - load entry 0xf5e8c0 file name (32 bytes)... CBFS: (unmatched file @0xf5e8c0: pci8086,1521.rom) CBFS: - load entry 0xf6e900 file name (16 bytes)... CBFS: (unmatched file @0xf6e900: ) CBFS: - load entry 0xf9ffc0 file name (40 bytes)... CBFS: (unmatched file @0x
[coreboot] Does S3 work on Haswell boards?
I have problem with S3 mode on Haswell board. Everything is fine if S3 time
is very small (<15 seconds), but if it is longer, coreboot won't resume. It
fails on quick_ram_check.
I've enabled mrc.cache and ME in coreboot. I use ME binary from original
board and MRC.bin from Google Panther.
Log from S3 resume:
"""
Disabling Watchdog reboot... done.
SMBus controller enabled.
Setting up static northbridge registers... done.
Initializing Graphics...
Back from haswell_early_initialization()
Resume from S3 detected.
CPU id(40651) ucode:001c Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
AES supported, TXT supported, VT supported
PCH type: LP Premium, device id: 9c43, rev id 4
Starting UEFI PEI System Agent
CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100
CBFS: CBFS location: 0xf0~0xfff7c0, align: 64
CBFS: Looking for 'mrc.cache' starting from 0xf0.
CBFS: - load entry 0xf0 file name (16 bytes)...
CBFS: (unmatched file @0xf0: bootsplash.jpg)
CBFS: - load entry 0xf187c0 file name (16 bytes)...
CBFS: (unmatched file @0xf187c0: bootorder)
CBFS: - load entry 0xf18b80 file name (16 bytes)...
CBFS: (unmatched file @0xf18b80: cmos_layout.bin)
CBFS: - load entry 0xf19040 file name (32 bytes)...
CBFS: (unmatched file @0xf19040: pci8086,0a26.rom)
CBFS: - load entry 0xf29080 file name (72 bytes)...
CBFS: (unmatched file @0xf29080: cpu_microcode_blob.bin)
CBFS: - load entry 0xf2e100 file name (32 bytes)...
CBFS: (unmatched file @0xf2e100: etc/usb-time-sigatt)
CBFS: - load entry 0xf2e140 file name (16 bytes)...
CBFS: (unmatched file @0xf2e140: config)
CBFS: - load entry 0xf2fa00 file name (16 bytes)...
CBFS: (unmatched file @0xf2fa00: revision)
CBFS: - load entry 0xf2fc80 file name (16 bytes)...
CBFS: (unmatched file @0xf2fc80: )
CBFS: - load entry 0xf2ff80 file name (76 bytes)...
CBFS: (unmatched file @0xf2ff80: fallback/romstage)
CBFS: - load entry 0xf38f00 file name (32 bytes)...
CBFS: (unmatched file @0xf38f00: fallback/ramstage)
CBFS: - load entry 0xf4d0c0 file name (32 bytes)...
CBFS: (unmatched file @0xf4d0c0: fallback/payload)
CBFS: - load entry 0xf5e8c0 file name (32 bytes)...
CBFS: (unmatched file @0xf5e8c0: pci8086,1521.rom)
CBFS: - load entry 0xf6e900 file name (16 bytes)...
CBFS: (unmatched file @0xf6e900: )
CBFS: - load entry 0xf9ffc0 file name (40 bytes)...
CBFS: (unmatched file @0xf9ffc0: mrc.bin)
CBFS: - load entry 0xfceb40 file name (16 bytes)...
CBFS: (unmatched file @0xfceb40: )
CBFS: - load entry 0xfdffc0 file name (40 bytes)...
CBFS: Found file (offset=0xfe, len=65536).
find_current_mrc_cache_local: picked entry 0 from cache block
prepare_mrc_cache: at fffe0010, size fe0 checksum 9771
CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100
CBFS: CBFS location: 0xf0~0xfff7c0, align: 64
CBFS: Looking for 'mrc.bin' starting from 0xf0.
CBFS: - load entry 0xf0 file name (16 bytes)...
CBFS: (unmatched file @0xf0: bootsplash.jpg)
CBFS: - load entry 0xf187c0 file name (16 bytes)...
CBFS: (unmatched file @0xf187c0: bootorder)
CBFS: - load entry 0xf18b80 file name (16 bytes)...
CBFS: (unmatched file @0xf18b80: cmos_layout.bin)
CBFS: - load entry 0xf19040 file name (32 bytes)...
CBFS: (unmatched file @0xf19040: pci8086,0a26.rom)
CBFS: - load entry 0xf29080 file name (72 bytes)...
CBFS: (unmatched file @0xf29080: cpu_microcode_blob.bin)
CBFS: - load entry 0xf2e100 file name (32 bytes)...
CBFS: (unmatched file @0xf2e100: etc/usb-time-sigatt)
CBFS: - load entry 0xf2e140 file name (16 bytes)...
CBFS: (unmatched file @0xf2e140: config)
CBFS: - load entry 0xf2fa00 file name (16 bytes)...
CBFS: (unmatched file @0xf2fa00: revision)
CBFS: - load entry 0xf2fc80 file name (16 bytes)...
CBFS: (unmatched file @0xf2fc80: )
CBFS: - load entry 0xf2ff80 file name (76 bytes)...
CBFS: (unmatched file @0xf2ff80: fallback/romstage)
CBFS: - load entry 0xf38f00 file name (32 bytes)...
CBFS: (unmatched file @0xf38f00: fallback/ramstage)
CBFS: - load entry 0xf4d0c0 file name (32 bytes)...
CBFS: (unmatched file @0xf4d0c0: fallback/payload)
CBFS: - load entry 0xf5e8c0 file name (32 bytes)...
CBFS: (unmatched file @0xf5e8c0: pci8086,1521.rom)
CBFS: - load entry 0xf6e900 file name (16 bytes)...
CBFS: (unmatched file @0xf6e900: )
CBFS: - load entry 0xf9ffc0 file name (40 bytes)...
CBFS: Found file (offset=0xfa, len=191236).
System Agent: Starting up...
System Agent: S3 resume detected
System Agent: Initializing PCH
install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845}
install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276}
System Agent: Initializing PCH (SMBUS)
System Agent: Initializing PCH (USB)
System Agent: Initializing PCH (SA Init)
System Agent: Initializing PCH (Me UMA)
System Agent: Initializing Memory
System Agent: Done.
Sanity checking heap.
System Agent Version 1.6.1 Build 2
memcfg DDR3 clock 1600 MHz
memcfg channel assignment: A: 0, B 1, C 2
memcfg channel[0] config (00600010):
ECC inactive
enhanced
Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
Ok, I’ve found one more solution: don’t generate ACPI C-state tables. In "devicetree.cb" replace all C-states registers with 0, indicating C0 state. register "c1_battery" = "0"#"2" # ACPI(C1) = MWAIT(C1E) register "c2_battery" = "0"#"3" # ACPI(C2) = MWAIT(C3) register "c3_battery" = "0"#"9" # ACPI(C3) = MWAIT(C7S) register "c1_acpower" = "0" #"2"# ACPI(C1) = MWAIT(C1E) register "c2_acpower" = "0" #"3"# ACPI(C2) = MWAIT(C3) register "c3_acpower" = "0" #"9"# ACPI(C3) = MWAIT(C7S) After this change coreboot wouldn't generate _CST tables for ACPI C-states. Original BIOSes of two Haswell motherboards that I have, don’t generate _CST tables, so maybe it is not so bad. But I don’t quite understand why even without those tables "cpupower idle-info" and "cpupower monitor -m Idle_Stats" shows that CPU enters and exits all supported C-states. Btw, Haswell ULT has a lot of C-states: C0, C1, C1E, C2E, C3, C6, C7, C8, C9, C10. There are a lot of MSRs to control C-states + two alternative interfaces in ACPI (_CST and FADT), so it is quite hard for me to check if all of it is done correctly. State C3 and lower flush core caches, so maybe this is the reason why commit about EHCI command solves my issue. Also I've found interesting part in Haswell BWG: " Idle Duration Reporting is the capability for devices to communicate to the processor about their planned period of activity or idleness. Based on when the device would next interrupt the core, the PCU can place the core in an appropriate idle state. • On 4th Generation Intel® Core™ processors, cores are expected to report their Idle Duration time via the respective APIC timers. Since 4th Generation Intel® Core™ processors support Always running APIC timer (ARAT), the PCU will save this data when cores are in a deep sleep state and use the closest expiring timer value as the Device Idle duration. " So, maybe without APIC-timer cores can't report their activity/idleness time and C-states are not supported?? That is why boot with "noapictimer" doesn't have problems. Or maybe all problems are from wrong APIC timer. What do you think? What part of ACPI code is responsible for APIC timer setting? One more interesting observation: " On previous processors, the chipset was responsible for actually changing the processor C-state seen by the package. On 4th Generation Intel® Core™ processors, this logic moves to the System Agent, and the chipset is no longer responsible for driving processor package C-state transitions. " Can it be that mrc.bin (System Agent blob) just doesn't configured for C-states? And at the end I want to notice, that according to BWG BIOS should expose different C-states tables to different OSes by reading _PDC method and coreboot doesn't do it at all. P.S.: This issue was also responsible for USB stuck in Windows 7. So this problem is seems more important than support of some old Linux kernels. From: Аладышев Константин [mailto:aladys...@nicevt.ru] Sent: Thursday, October 19, 2017 5:57 PM To: 'ron minnich'; 'Julius Werner' Cc: 'Coreboot' Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards 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:rminn...@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 Аладышев Константин <aladys...@nicevt.ru> wrote: I've found one more parameter that helps me boot without USB problem: 'noapictimer' -Original Message- From: Аладышев Константин [mailto:aladys...@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
Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
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:rminn...@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 Аладышев Константин <aladys...@nicevt.ru> wrote: I've found one more parameter that helps me boot without USB problem: 'noapictimer' -Original Message- From: Аладышев Константин [mailto:aladys...@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: jwer...@google.com [mailto:jwer...@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
I've found one more parameter that helps me boot without USB problem: 'noapictimer' -Original Message- From: Аладышев Константин [mailto:aladys...@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: jwer...@google.com [mailto:jwer...@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
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: jwer...@google.com [mailto:jwer...@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
As I described earlier commit that solves my USB problem is 3d9545c and it was merged in kernel 3.5 So in this terminology: Old kernels: <3.5 Modern kernels: >=3.5 From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com] Sent: Tuesday, October 10, 2017 8:03 PM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards > Last time I was solving a problem of OS suspend-resume sequence with modern > kernels and now it is about working with old kernels Hello Kostja, What is modern kernel, and what is old kernel? Any version/revision examples (you are using), so we can get the/some idea? Thank you, Zoran ___ On Tue, Oct 10, 2017 at 10:14 AM, Аладышев Константин <aladys...@nicevt.ru> wrote: Hello Zoran! Yes, I'm working with the same board, but the problem is different. Last time I was solving a problem of OS suspend-resume sequence with modern kernels and now it is about working with old kernels From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com] Sent: Tuesday, October 10, 2017 9:48 AM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards Hello Kostja, We already had this discussion a while ago, didn't we? https://mail.coreboot.org/pipermail/coreboot/2016-December/082772.html (BTW, ATOM BYT has exactly the same problem) Zoran On Mon, Oct 9, 2017 at 11:58 AM, Аладышев Константин <aladys...@nicevt.ru> wrote: I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange problem. USB devices stop working shortly after OS boot (or after USB device replug in OS) with flooding system with messages: hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: Cannot enable port 5. Maybe the USB cable is bad? hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0: connect-debounce failed, port 5 disabled hub 1-1:1.0: unable to enumerate USB device on port 5 hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) Through some digging I've found out that this problem persist on kernels <3.5. I've investigated this problem more closely and come down to the fact that the kernel commit that solves this problem is: 3d9545c EHCI: maintain the ehci->command value properly https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c 62775?diff=split 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? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
Hello Zoran! Yes, I'm working with the same board, but the problem is different. Last time I was solving a problem of OS suspend-resume sequence with modern kernels and now it is about working with old kernels From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com] Sent: Tuesday, October 10, 2017 9:48 AM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards Hello Kostja, We already had this discussion a while ago, didn't we? https://mail.coreboot.org/pipermail/coreboot/2016-December/082772.html (BTW, ATOM BYT has exactly the same problem) Zoran On Mon, Oct 9, 2017 at 11:58 AM, Аладышев Константин <aladys...@nicevt.ru> wrote: I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange problem. USB devices stop working shortly after OS boot (or after USB device replug in OS) with flooding system with messages: hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: Cannot enable port 5. Maybe the USB cable is bad? hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0: connect-debounce failed, port 5 disabled hub 1-1:1.0: unable to enumerate USB device on port 5 hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) Through some digging I've found out that this problem persist on kernels <3.5. I've investigated this problem more closely and come down to the fact that the kernel commit that solves this problem is: 3d9545c EHCI: maintain the ehci->command value properly https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c 62775?diff=split 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? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB problem with Haswell+LynxPointLP motherboards
I've dumped original ACPI tables from original BIOS, but I can't see any such hooks. https://pastebin.com/Mniskv3f part1 of dsdt https://pastebin.com/hnpgvCMN part2 of dsdt (starts from EHCI/XHCI controllers) I hope it is not in SMM cause I really have no idea how to edit it to solve this problem -Original Message- From: jwer...@google.com [mailto:jwer...@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] USB problem with Haswell+LynxPointLP motherboards
I try to port coreboot on boards with Haswell CPU and Lynxpoint LP chipset (IBASE IB908AF-4650 board, DFI HU968) and I've encountered a strange problem. USB devices stop working shortly after OS boot (or after USB device replug in OS) with flooding system with messages: hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: cannot reset port 5 (err = -110) hub 1-1:1.0: Cannot enable port 5. Maybe the USB cable is bad? hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0: connect-debounce failed, port 5 disabled hub 1-1:1.0: unable to enumerate USB device on port 5 hub 1-1:1.0: cannot disable port 5 (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) hub 1-1:1.0: hub_port_status failed (err = -110) Through some digging I've found out that this problem persist on kernels <3.5. I've investigated this problem more closely and come down to the fact that the kernel commit that solves this problem is: 3d9545c EHCI: maintain the ehci->command value properly https://github.com/torvalds/linux/commit/3d9545cc375d117554a9b35dfddadf9189c 62775?diff=split 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? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] EHCI debug that supports both Linux and Windows as a host PC
Does a windows driver (for host PC where I want to see coreboot log) exist for this solution with BeagleBone? -Original Message- From: Andrey Korolyov [mailto:and...@xdel.ru] Sent: Friday, August 04, 2017 3:58 PM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] EHCI debug that supports both Linux and Windows as a host PC On Fri, Aug 4, 2017 at 3:14 PM, Аладышев Константин <aladys...@nicevt.ru> wrote: > What is the easiest and most stable way to do debug through EHCI USB > port instead of COM port? Is there any EHCI dongles on market that > supports both Linux and Windows as a host PC? > The answer varies depending on your exact needs. If you are targeting only on coreboot log obtainment, the RaspberryPI/BeagleBone with dwc2 is probably cheapest cross-platform thing to use. For kgdb, this setup *should* work, but this would add another level of complexity due to gdbserver spatial localization :) I`ve never tried working with combination of the RPI and usb-ip to pass dwc2 port over cdc-ethernet connection, this is the only major difference between 'real' dongle and cheap board-based setup. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] EHCI debug that supports both Linux and Windows as a host PC
What is the easiest and most stable way to do debug through EHCI USB port instead of COM port? Is there any EHCI dongles on market that supports both Linux and Windows as a host PC? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Support for AMD family f17h in coreboot
Hello! Is there any plans to support AMD family f17h processors in coreboot any time soon? Or it can be possible only if AMD will decide to provide AGESA code for this new cpu family and nobody here knows what will AMD do? Does AMD still support coreboot in any way? What are chances that f17h processors will be supported by coreboot? -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] EHCI wakeup on Haswell+Lynxpoint motherboards
I have Haswell+LynxpointLP motherboard and Linux doesn't wakeup from USB devices from S3. EHCI controller is listed in "/proc/acpi/wakeup" as "enabled" and GPE number is seemed to be configured correctly in ACPI to PME_B0, but it doesn't work. What is need to be done to enable USB wakeup? Does USB wakeup work on Haswell+Lynxpoint motherboards? -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] USB problems in Haswell+Lynxpoint motherboards
Does someone have moherboards with Haswell+Lynxpoint? I have problems with USB. In Linux USB devices work fine with "ehci-pci" driver and don't work correctly with "ehci-hcd" driver (they freeze completely short time after boot). In Windows USB devices work fine in safe mode and don't work correctly with normal mode (again they freeze completely short time after boot). What is the difference between these two Linux drivers and what can be the source of this problem? -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PECI temperature in lm-sensors
1) Yes, PECI pin in SuperIO is actually configured as PECI pin and is connected to PECI pin on Haswell CPU 2) I don't have secret PECI docs either, so I don't know what else should I do... 3) You're right, I want to configure SuperIO to control fans on motherboard based on CPU temperature. -Original Message- From: Nico Huber [mailto:nic...@gmx.de] Sent: Monday, January 23, 2017 11:42 PM To: Аладышев Константин Cc: coreboot@coreboot.org Subject: Re: [coreboot] PECI temperature in lm-sensors On 23.01.2017 15:17, Аладышев Константин wrote: > Does someone have any experience with enabling PECI monitoring on > nuvoton SuperIOs ? > > I'm trying to enable it on board with Haswell+Lynxpoint CPU and > NCT6776 SuperIO. > > But all I see in lm-sensors output for now is zero temperature for > PECI Agent. I'd first make sure, that the PECI interface is actually connected to a PECI slave. Do you have evidence that this is the case? It's not unusual to leave it unconnected. > > Does coreboot have any SuperIO chips/Intel CPUs/motherboards, that > have this functional enabled? What is usually need to be done to > enable PECI monitoring? FWIW (cf. superio/ite/it8772f and others), you have to program the PECI slave address and the command used to retrieve the temperature readings. What to program seems to be documented in a secret PECI specification (I could only find a license agreement, WTF?). How to program it, is super i/o specific (see datasheet of your chip). I wonder though, what are you up to? You only need PECI if you want your super i/o to to something automatically (like fan control) based on the readings. If you only want to read out the temperature, you can also directly ask the processor (MSR 0x19c, IIRC). Nico -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PECI temperature in lm-sensors
I'm sure that I have only one chip, I just don't know how to enable PECI monitoring in it: From: Pierre P [mailto:p...@outlook.fr] Sent: Monday, January 23, 2017 6:10 PM To: Аладышев Константин; coreboot Subject: Re: [coreboot] PECI temperature in lm-sensors In my case sensors-detect found one SuperIO the first time I ran it, but there was a second one "hidden" in a i2c chip, each one provide different information. In the end I had two kernel modules loaded instead of only one previously. Pierre _ From: Аладышев Константин <aladys...@nicevt.ru> Sent: Monday, January 23, 2017 4:01 PM To: 'Pierre P' Subject: Re: [coreboot] PECI temperature in lm-sensors Hi! No, "sensors-detect" founds my SuperIO and needed kernel module is installed in system correctly. The problem is in "sensors" command. It displays all voltages and pch temperatures correctly, except of PECI temperature from CPU, PECI agent temp is always zero. From: Pierre P [mailto:p...@outlook.fr] Sent: Monday, January 23, 2017 5:40 PM To: Аладышев Константин Subject: Re: [coreboot] PECI temperature in lm-sensors Hi, Had a similar issue on a KCMA-D8. When running sensors-detect you have to force probing of i2c chips (default choice is "NO" if you just press enter when asked) then hopefully with one of them it will detect other sensors. Hope this helps Pierre _ From: coreboot <coreboot-boun...@coreboot.org> on behalf of Аладышев Константин <aladys...@nicevt.ru> Sent: Monday, January 23, 2017 3:17 PM To: coreboot@coreboot.org Subject: [coreboot] PECI temperature in lm-sensors Does someone have any experience with enabling PECI monitoring on nuvoton SuperIOs ? I'm trying to enable it on board with Haswell+Lynxpoint CPU and NCT6776 SuperIO. But all I see in lm-sensors output for now is zero temperature for PECI Agent. Does coreboot have any SuperIO chips/Intel CPUs/motherboards, that have this functional enabled? What is usually need to be done to enable PECI monitoring? -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] PECI temperature in lm-sensors
Hi! No, "sensors-detect" founds my SuperIO and needed kernel module is installed in system correctly. The problem is in "sensors" command. It displays all voltages and pch temperatures correctly, except of PECI temperature from CPU, PECI agent temp is always zero. From: Pierre P [mailto:p...@outlook.fr] Sent: Monday, January 23, 2017 6:02 PM To: coreboot@coreboot.org; Аладышев Константин Subject: Re: [coreboot] PECI temperature in lm-sensors Hi, Had a similar issue on a KCMA-D8. When running sensors-detect you have to force probing of i2c chips (default choice is "NO" if you just press enter when asked) then hopefully with one of them it will detect other sensors. Hope this helps Pierre _ From: coreboot <coreboot-boun...@coreboot.org> on behalf of Аладышев Константин <aladys...@nicevt.ru> Sent: Monday, January 23, 2017 3:17 PM To: coreboot@coreboot.org Subject: [coreboot] PECI temperature in lm-sensors Does someone have any experience with enabling PECI monitoring on nuvoton SuperIOs ? I'm trying to enable it on board with Haswell+Lynxpoint CPU and NCT6776 SuperIO. But all I see in lm-sensors output for now is zero temperature for PECI Agent. Does coreboot have any SuperIO chips/Intel CPUs/motherboards, that have this functional enabled? What is usually need to be done to enable PECI monitoring? -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] PECI temperature in lm-sensors
Does someone have any experience with enabling PECI monitoring on nuvoton SuperIOs ? I'm trying to enable it on board with Haswell+Lynxpoint CPU and NCT6776 SuperIO. But all I see in lm-sensors output for now is zero temperature for PECI Agent. Does coreboot have any SuperIO chips/Intel CPUs/motherboards, that have this functional enabled? What is usually need to be done to enable PECI monitoring? -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] USB EHCI power management
Salut, Zoran! The question isn’t specific to LynxPoint PCH. It is related to EHCI specification. Every southbridge with EHCI controller should support these registers in a right way. Anyway, after months of investigation I solved this issue couple of days after I posted this letter. The solution was very simple, I just needed to explicitly disable XHCI through RCBA registers: /* Disable unused devices (board specific) */ RCBA_RMW_REG_32(FD, ~0, PCH_DISABLE_ALWAYS | PCH_DISABLE_XHCI), It seems like “device pci 14.0 off end # USB3 XHCI” record in devicetree.cb is not enough. I spend so much time on this, cause USB worked perfectly without this RCBA register until S3 suspend/resume sequence. For complete answer, I’ll post solutions to my questions: 1) D3hot 2) Yes 3) Yes, and in resume BIOS sequence they still be suspended. But besides suspend bit all other bits in this F0-Fx register should be preserved (like current connection status)! If it isn’t so, something is wrong 4) It should be enabled automatically already in resume BIOS sequence From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com] Sent: Tuesday, December 27, 2016 7:35 PM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] USB EHCI power management Privet Konstantin, Ja mogu i po Russkomu (russkij keyboard ne imeet dlja menja nikakogo smisla perekljucat6, tak cto ja po Russkomu naucilsja davnim, prezde cem (paru let prezde) ZX81 i Spektrum pojavilis6, no budu ja pisat6 po Anglijskij, tak cto ljudi Coreboot-a mogut ponjat6 ob cem mi zdes6 tolkujem/hozjataistvujem. :-) ___ I do not think that people here, Coreboot people, have appropriate detailed documentation for Lynx Point (Series 8 PCH), which primarily serves to HSW (CORE 4) Family. It also served (as experimental PCH) to some SKL (Core 6) families. Before Sunrise Point (Series 10, I believe) PCH came to existence. About 14+ months ago. For the bigger picture, I'll suggest to you the following test scenario: [1] You should do all of this what you have asked here with HSW (CORE 4) true BIOS, and then installing on the top of it any Linux distro (I use Fedora, I mastered it, but you can use any Linux distro of your free choice): [A] After bringing BIOS up, and GRUB2, then Linux... You should exercise exactly the same scenario as you described with Coreboot BSP. Then, you should take any and every possible detailed log which you can (to compare with the same scenario using Coreboot). [B] You should see if you have the same behavior as you describe it in your original email. [2] You say/write heading: USB EHCI power management. What about: USB xHCI power management (there is duality there, in Lynx Point PCH, don't you know?)? I hope this email helps somehow. :-) Zoran On Tue, Dec 27, 2016 at 10:24 AM, Аладышев Константин <aladys...@nicevt.ru> wrote: I have a problem with USB EHCI on board with Lynxpoint-LP southbridge. First of all system doesn't wakeup from USB devices from S3. EHCI controller is listed in "/proc/acpi/wakeup" as "enabled" and GPE number is seemed to be configured correctly to PME_B0, but it doesn't work. More troubling issue that USB stops working after wakeup (for example from power button). In attempt to solve this issue I started to investigate how exactly EHCI works in S3 suspend/resume sequence. And I have some questions: 1) PCI_config: PWR_CNTL_STS register (54-55h) What power state should enter EHCI controller when system enters S3? D0 state or D3hot ? 2) MEM_BASE: USB2.0_CMD (20-23h) Is it correct, that system disables "Run/Stop (RS)" bit when system enters S3? 3) MEM_BASE: RMHPORTSTSN (F0h) Is it correct, that all ports became suspended when system enters S3? 4) Who is responsible to set "Run/Stop (RS)" and bring USB ports from suspended state? BIOS or OS? 5) Is there any board in coreboot that has USB EHCI working correctly with S3 suspend/resume? -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] iPXE on multiple chips with the same PCI ID
Hello! Thanks for an answer! Yes, it’s the same board. (Haswell ULT + Lynxpoint) This is a custom board, so I don’t push it to coreboot repository, and therefore it is kinda hard for me to keep up to date with coreboot project. So I’ve fixed on some stable release and developed from there. Again, board is custom, so you’re right, there is no proprietary BIOS. There is definitely overlapping of some kind. I at least want to know the source of it. Is this problem caused by iPXE image or Coreboot/Seabios allocation? I'll try to port my coreboot changes to the newest release someday, but now it sounds like a shot in the dark. From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com] Sent: Thursday, December 29, 2016 1:12 PM To: Аладышев Константин Cc: coreboot Subject: Re: [coreboot] iPXE on multiple chips with the same PCI ID Hello Konstantin, Seems that your board plays kind of fiber based GIGa router with several (max. 10) optical i/f attached. Insinuates the same board from the previous email. Correct? Here is what CPU is used: https://ark.intel.com/products/75114/Intel-Core-i7-4650U-Processor-4M-Cache-up-to-3_30-GHz (CPUID - 0x40651). Glanced via attached log. Yup, there are all visible, and in early stage there are some resource allocations for all three I350 devices/PCIe buses, seems that these resources overlap per device (in early stages). Could not say with 100% certainty. Lot of kludges, assumptions... But let us take the different route, for now (to save the time). Questions to you: [1] Why you are using very old Coreboot build 4.0 (coreboot-4.0-8341-g5e6dd5f-dirty Thu Mar 19 10:15:27 UTC 2015)??? [2] Did you ever use BIOS for this router? How does BIOS behave in the term of PXE booting? I start doubting that customized/tailored BIOS ever existed for this proprietary HSW built board!? TO DO: [1] To rebuild Coreboot with the latest and greatest Coreboot 4.5, and repeat the tests again? Please, let us know! :-) Zoran On Wed, Dec 28, 2016 at 3:17 PM, Аладышев Константин <aladys...@nicevt.ru> wrote: I have a board with multiple external PCIe Ethernet I350 chips. In my lspci I have: 03.00.0 (4-port I350) 03.00.1 03.00.2 03.00.3 04.00.0 (4-port I350) 04.00.1 04.00.2 04.00.3 05.00.0 (2-port I350) 05.00.1 I builtin iPXE image to coreboot and I have all of these devices in Seabios bootmenu. But the problem is that I can only boot from ports of the first appeared chip. In the example above it will be 03.00.x boot devices. If I’ll physically unplug 03.00.x chip, I’ll be able to boot from 04.00.x boot devices. And if I’ll unplug 03.00.x and 04.00.x chip, I’ll be able to boot from 05.00.x boot devices. Does someone had the same problem and how to solve it? Coreboot+SeaBIOS log is in attachment (it has some additional printk’s) -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] iPXE on multiple chips with the same PCI ID
I have a board with multiple external PCIe Ethernet I350 chips.
In my lspci I have:
03.00.0 (4-port I350)
03.00.1
03.00.2
03.00.3
04.00.0 (4-port I350)
04.00.1
04.00.2
04.00.3
05.00.0 (2-port I350)
05.00.1
I builtin iPXE image to coreboot and I have all of these devices in Seabios
bootmenu.
But the problem is that I can only boot from ports of the first appeared
chip. In the example above it will be 03.00.x boot devices. If I'll
physically unplug 03.00.x chip, I'll be able to boot from 04.00.x boot
devices. And if I'll unplug 03.00.x and 04.00.x chip, I'll be able to boot
from 05.00.x boot devices.
Does someone had the same problem and how to solve it?
Coreboot+SeaBIOS log is in attachment (it has some additional printk's)
coreboot-4.0-8341-g5e6dd5f-dirty Thu Mar 19 10:15:27 UTC 2015 romstage
starting...
Hello!
coreboot-4.0-8341-g5e6dd5f-dirty Thu Mar 19 10:15:27 UTC 2015 romstage
starting...
Disabling Watchdog reboot... done.
SMBus controller enabled.
Setting up static northbridge registers... done.
Initializing Graphics...
Back from haswell_early_initialization()
CPU id(40651) ucode:001c Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
AES supported, TXT supported, VT supported
PCH type: LP Premium, device id: 9c43, rev id 4
Starting UEFI PEI System Agent
CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100
CBFS: CBFS location: 0xf0~0xfff7c0, align: 64
CBFS: Looking for 'mrc.cache' starting from 0xf0.
CBFS: - load entry 0xf0 file name (16 bytes)...
CBFS: (unmatched file @0xf0: bootsplash.jpg)
CBFS: - load entry 0xf187c0 file name (16 bytes)...
CBFS: (unmatched file @0xf187c0: cmos_layout.bin)
CBFS: - load entry 0xf18c80 file name (32 bytes)...
CBFS: (unmatched file @0xf18c80: pci8086,0a26.rom)
CBFS: - load entry 0xf28cc0 file name (72 bytes)...
CBFS: (unmatched file @0xf28cc0: cpu_microcode_blob.bin)
CBFS: - load entry 0xf2dd40 file name (16 bytes)...
CBFS: (unmatched file @0xf2dd40: config)
CBFS: - load entry 0xf2f3c0 file name (16 bytes)...
CBFS: (unmatched file @0xf2f3c0: revision)
CBFS: - load entry 0xf2f640 file name (16 bytes)...
CBFS: (unmatched file @0xf2f640: )
CBFS: - load entry 0xf2ff80 file name (76 bytes)...
CBFS: (unmatched file @0xf2ff80: fallback/romstage)
CBFS: - load entry 0xf38d00 file name (32 bytes)...
CBFS: (unmatched file @0xf38d00: fallback/ramstage)
CBFS: - load entry 0xf4cc80 file name (32 bytes)...
CBFS: (unmatched file @0xf4cc80: fallback/payload)
CBFS: - load entry 0xf5e540 file name (32 bytes)...
CBFS: (unmatched file @0xf5e540: pci8086,1521.rom)
CBFS: - load entry 0xf6e580 file name (16 bytes)...
CBFS: (unmatched file @0xf6e580: )
CBFS: - load entry 0xf9ffc0 file name (40 bytes)...
CBFS: (unmatched file @0xf9ffc0: mrc.bin)
CBFS: - load entry 0xfce700 file name (16 bytes)...
CBFS: (unmatched file @0xfce700: )
CBFS: - load entry 0xfdffc0 file name (40 bytes)...
CBFS: Found file (offset=0xfe, len=65536).
find_current_mrc_cache_local: picked entry 0 from cache block
prepare_mrc_cache: at fffe0010, size fe0 checksum 3ea0
CBFS: CBFS_HEADER_ROM_ADDRESS: 0xf7d0/0x100
CBFS: CBFS location: 0xf0~0xfff7c0, align: 64
CBFS: Looking for 'mrc.bin' starting from 0xf0.
CBFS: - load entry 0xf0 file name (16 bytes)...
CBFS: (unmatched file @0xf0: bootsplash.jpg)
CBFS: - load entry 0xf187c0 file name (16 bytes)...
CBFS: (unmatched file @0xf187c0: cmos_layout.bin)
CBFS: - load entry 0xf18c80 file name (32 bytes)...
CBFS: (unmatched file @0xf18c80: pci8086,0a26.rom)
CBFS: - load entry 0xf28cc0 file name (72 bytes)...
CBFS: (unmatched file @0xf28cc0: cpu_microcode_blob.bin)
CBFS: - load entry 0xf2dd40 file name (16 bytes)...
CBFS: (unmatched file @0xf2dd40: config)
CBFS: - load entry 0xf2f3c0 file name (16 bytes)...
CBFS: (unmatched file @0xf2f3c0: revision)
CBFS: - load entry 0xf2f640 file name (16 bytes)...
CBFS: (unmatched file @0xf2f640: )
CBFS: - load entry 0xf2ff80 file name (76 bytes)...
CBFS: (unmatched file @0xf2ff80: fallback/romstage)
CBFS: - load entry 0xf38d00 file name (32 bytes)...
CBFS: (unmatched file @0xf38d00: fallback/ramstage)
CBFS: - load entry 0xf4cc80 file name (32 bytes)...
CBFS: (unmatched file @0xf4cc80: fallback/payload)
CBFS: - load entry 0xf5e540 file name (32 bytes)...
CBFS: (unmatched file @0xf5e540: pci8086,1521.rom)
CBFS: - load entry 0xf6e580 file name (16 bytes)...
CBFS: (unmatched file @0xf6e580: )
CBFS: - load entry 0xf9ffc0 file name (40 bytes)...
CBFS: Found file (offset=0xfa, len=190180).
System Agent: Starting up...
System Agent: Initializing PCH
install_ppi: overwrite GUID {ed097352-9041-445a-80b6-b29d509e8845}
install_ppi: overwrite GUID {908c7f8b-5c48-47fb-8357-f5fd4e235276}
System Agent: Initializing PCH (SMBUS)
System Agent: Initializing PCH (USB)
System Agent: Initializing PCH (SA Init)
System Agent: Initializing PCH (Me UMA)
System Agent: Initializing Memory
System Agent: Done.
Sanity checking heap.
System Agent Version
[coreboot] USB EHCI power management
I have a problem with USB EHCI on board with Lynxpoint-LP southbridge. First of all system doesn't wakeup from USB devices from S3. EHCI controller is listed in "/proc/acpi/wakeup" as "enabled" and GPE number is seemed to be configured correctly to PME_B0, but it doesn't work. More troubling issue that USB stops working after wakeup (for example from power button). In attempt to solve this issue I started to investigate how exactly EHCI works in S3 suspend/resume sequence. And I have some questions: 1) PCI_config: PWR_CNTL_STS register (54-55h) What power state should enter EHCI controller when system enters S3? D0 state or D3hot ? 2) MEM_BASE: USB2.0_CMD (20-23h) Is it correct, that system disables "Run/Stop (RS)" bit when system enters S3? 3) MEM_BASE: RMHPORTSTSN (F0h) Is it correct, that all ports became suspended when system enters S3? 4) Who is responsible to set "Run/Stop (RS)" and bring USB ports from suspended state? BIOS or OS? 5) Is there any board in coreboot that has USB EHCI working correctly with S3 suspend/resume? -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AGESA: RunLateApTaskOnAllAPs(..) function and ProbeFilter
AGESA code have two mechanisms to run tasks on AP cores. The first one is used before Relinquish control of APs, and the second one is used after it. I doubt in the second one, cause it is used only in probe filter initialization (and now OS can't boot with this feature) I walked RunLateApTaskOnAllAPs(..) function [the second mechanism] step by step and didn't find of how system transmits task poinetrs to APs. It seems like code executes on BSC (boot strap core) as many times as APs present in system. AGESA code is very complicated, we traveles a lot to final function, that is located in the same file. If someone look at code, I drew little scheme of this travel. Here it is: http://tinypic.com/r/25sx7p3/6 Maybe i'am missing something, but I can't see the point, where agesa transmits pointers to APs. Also i put LibAmdMsrRead function in DisableAllCaches function and read MSRs containing NodeId and BSC bits. And for all cases of its execution DisableAllCaches prints that NodeId=0 and BSC=1. If i didn't mess up, it proves my theory above. So... How does RunLateApTaskOnAllAPs(..) work? __ Aladyshev Konstantin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
