coreboot January 2018

coreboot@coreboot.org

60 participants
155 discussions

Re: [coreboot] BDX-DE PCI init fail
by Hilbert Tu(杜睿哲_Pegatron) 15 Jan '18

15 Jan '18

Hi Zoran, That information was dumped when I use SeaBIOS as coreboot's payload. I don't know why it is related to GRUB_legacy. If I use GRUB2 as payload, it just hangs there. I am still struggling on this :( By the way, I saw following message in the log. Should I choose NodeManager Mode? Do you know what's different? >>[SPS] SiliconEnabling Mode Thanks. -Hilbert -----Original Message----- From: Zoran Stojsavljevic [mailto:zoran.stojsavljevic@gmail.com] Sent: Thursday, January 11, 2018 7:27 PM To: Hilbert Tu(杜睿哲_Pegatron) Cc: Zeh, Werner; coreboot(a)coreboot.org; David Hendricks Subject: Re: [coreboot] BDX-DE PCI init fail > Booting from Hard Disk... > Booting from 0000:7c00 It is booting from the thirty second Kbyte of HDD (sector 62, sector 0 is MBR), where the beginning of GRUB Legacy is placed/implanted, called core.img or similar name. https://wiki.archlinux.org/index.php/GRUB_Legacy Well, you have succeed, by all means. Problem solved! ;-) Zoran _______ On Thu, Jan 11, 2018 at 12:06 PM, Hilbert Tu(杜睿哲_Pegatron) <Hilbert_Tu(a)pegatroncorp.com> wrote: > Hi Werner, > > Thanks for your information. It works but still has same result. The result is like following. My usb stick is ext4fs formatted and has kernel and rootfs files. I wish SeaBIOS can give me a shell like Grub so that I can specify how to boot next. Or should I create a bootable usb stick? > > > ============= PEIM FSP is Completed ============= > > Returned from FspNotify(EnumInitPhaseReadyToBoot) > Jumping to boot code at 000ff06e(7eff6000) > CPU0: stack: 00128000 - 00129000, lowest used address 00128b00, stack used: 1280 bytes > entry = 0x000ff06e > lb_start = 0x00100000 > lb_size = 0x0012d6d0 > buffer = 0x7ed66000 > SeaBIOS (version rel-1.10.2-0-g5f4c7b1) > BUILD: gcc: (coreboot toolchain v1.44 March 3rd, 2017) 6.3.0 binutils: (GNU Binutils) 2.28 > Found mainboard Intel Camelback Mountain CRB > Relocating init from 0x000e3860 to 0x7ef74cc0 (size 49824) > Found CBFS header at 0xffe00138 > multiboot: eax=0, ebx=0 > Found 25 PCI devices (max PCI bus is 05) > Copying SMBIOS entry point from 0x7efc1000 to 0x000f7140 > Copying ACPI RSDP from 0x7efd2000 to 0x000f7110 > Using pmtimer, ioport 0x408 > WARNING - Timeout at tis_wait_sts:160! > WARNING - Timeout at tis_wait_sts:160! > Scan for VGA option rom > XHCI init on dev 00:14.0: regs @ 0xfea00000, 21 ports, 32 slots, 32 byte contexts > XHCI protocol USB 2.00, 8 ports (offset 1), def 3001 > XHCI protocol USB 3.00, 6 ports (offset 16), def 1000 > XHCI extcap 0xc1 @ 0xfea08040 > XHCI extcap 0xc0 @ 0xfea08070 > XHCI extcap 0x1 @ 0xfea0846c > EHCI init on dev 00:1a.0 (regs=0xfea18020) > EHCI init on dev 00:1d.0 (regs=0xfea19020) > WARNING - Timeout at i8042_flush:71! > ebda moved from 9f000 to 9e800 > AHCI controller at 00:1f.2, iobase 0xfea17000, irq 5 > Found 0 lpt ports > Found 2 serial ports > XHCI no devices found > Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/storage@1/*@0/*@0,0 > Searching bootorder for: /pci@i0cf8/usb@1d/hub@1/usb-*@1 > USB MSC vendor='Generic-' product='Multiple Reader' rev='1.11' type=0 removable=1 > ehci_wait_td error - status=80e42 > Initialized USB HUB (0 ports used) > USB MSC blksize=512 sectors=30777344 > Initialized USB HUB (1 ports used) > All threads complete. > Scan for option roms > Running option rom at c000:0003 > Running option rom at c100:0003 > Searching bootorder for: /pci@i0cf8/pci-bridge@2,2/*@0 > Searching bootorder for: /pci@i0cf8/pci-bridge@2,2/*@0,1 > > Press ESC for boot menu. > > WARNING - Timeout at tis_wait_sts:160! > Searching bootorder for: HALT > drive 0x000f70c0: PCHS=0/0/0 translation=lba LCHS=1024/255/63 s=30777344 > Space available for UMB: c2000-efb00, f6960-f70c0 > Returned 184320 bytes of ZoneHigh > e820 map has 9 items: > 0: 0000000000000000 - 000000000009e800 = 1 RAM > 1: 000000000009e800 - 00000000000a0000 = 2 RESERVED > 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED > 3: 0000000000100000 - 000000007efae000 = 1 RAM > 4: 000000007efae000 - 0000000090000000 = 2 RESERVED > 5: 00000000feb00000 - 00000000feb10000 = 2 RESERVED > 6: 00000000feb80000 - 00000000fef00000 = 2 RESERVED > 7: 00000000ff000000 - 0000000100000000 = 2 RESERVED > 8: 0000000100000000 - 0000000280000000 = 1 RAM > enter handle_19: > NULL > Booting from Hard Disk... > Booting from 0000:7c00 > > -Hilbert > > This e-mail and its attachment may contain information that is confidential or privileged, and are solely for the use of the individual to whom this e-mail is addressed. If you are not the intended recipient or have received it accidentally, please immediately notify the sender by reply e-mail and destroy all copies of this email and its attachment. Please be advised that any unauthorized use, disclosure, distribution or copying of this email or its attachment is strictly prohibited. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

[Lenovo G505S] KB9012 EC controller patches for the latest flashrom
by Mike Banon 15 Jan '18

15 Jan '18

Hi Nico and Paul, and Lenovo G505S owners/developers, I have ported the patches by Paul Kocialkowski to the latest flashrom sources of master branch (earlier there were incompatibilities) -- making it possible to flash KB9012 EC controller [found in Lenovo G505S AMD coreboot-supported laptop (no AMD PSP backdoor!)] with the latest flashrom. Probed/read/erased/flashed/verified a few times, looks like its working perfectly :) Also, thanks to [v4,5/6] patch, now KB9012 is "hidden" and will never be probed for, unless explicitly specified by its chip name: -c "KB9012 (EDI)" or --chip "KB9012 (EDI)" . That should help to avoid the problems with other chips [v4,5/6] Add the hidden-from-probing chips category and make KB9012 hidden There are some chips like ENE KB9012, probing for which could cause the other chips to misbehave. Therefore, such chips should be "hidden" - not probed for unless the user wants This commit introduces a new field to the "flashchip" structure: int hidden; Now it is possible to "hide" any chip by adding this line .hidden = 1, to the "struct flashchip flashchips[]" structure of a chip, like .write = edi_chip_write, .read = edi_chip_read, .voltage = {2700, 3600}, .hidden = 1, }, flashrom will probe for a chip only if one of these conditions is true: 1) no chip has been specified AND this chip is not "hidden" 2) this chip has been specified by -c | --chip <chipname> All the patches could be reviewed by these links below, and it is possible to merge them sequentially: [v4,1/6] --> [v4,2/6] --> [v4,3/6] --> [v4,4/6] --> [v4,5/6] --> [v4,6/6] https://review.coreboot.org/#/c/flashrom/+/23258 [v4,1/6] Add support for selecting the erased bit value with a flag https://review.coreboot.org/#/c/flashrom/+/23259 [v4,2/6] ENE Embedded Debug Interface EDI and ENE KB9012 EC flashing support https://review.coreboot.org/#/c/flashrom/+/23260 [v4,3/6] ENE EDI - add dummy read to ensure proper detection of ENE chips https://review.coreboot.org/#/c/flashrom/+/23261 [v4,4/6] ENE EDI - print debug info like others while probing for ENE chips https://review.coreboot.org/#/c/flashrom/+/23262 [v4,5/6] Add the hidden-from-probing chips category and make KB9012 hidden https://review.coreboot.org/#/c/flashrom/+/23263 [v4,6/6] Add support for reading the current flash contents from a file Cheers, Mike On Wed, Jan 3, 2018 at 5:18 PM, Paul Kocialkowski <contact(a)paulk.fr> wrote: > Hi, > > Le mercredi 03 janvier 2018 à 15:34 +0300, Ivan Ivanov a écrit : >> Please tell - are there any real reasons why the Paul Kocialkowski's >> KB9012 support patches >> still cannot be merged? It is very discouraging - after 2 years of >> waiting to not see them at 1.0 >> Is there any way to get these patches merged, and maybe re-tag the >> flashrom 1.0 release ? > > We have been discussing about the future of these patches and they > cannot be accepted as-is today. Mostly, Nico was worried that issuing > SPI commands for the EDI protocol might cause some chips to misbehave if > these commands have another signification. I think this is a valid > concern. > > We agreed that one way to solve this would be to create groups for > probing, e.g. one with jedec-compliant chips (default) and one for ene > chips, so that only one group is probbed at the same time. > > I did not have the time to implement this idea yet, so it will block > kb9012 inclusion for now. If you'd like to go ahead and implement this > feature, I'd be happy to review your patches! > > Cheers, > > Paul > >> 2017-12-30 23:49 GMT+03:00 Ivan Ivanov <qmastery16(a)gmail.com>: >> > Hi Nico, please could you also merge the KB9012 patches by Paul >> > Kocialkowski : >> > >> > https://patchwork.coreboot.org/patch/4412/ >> > https://patchwork.coreboot.org/patch/4413/ >> > https://patchwork.coreboot.org/patch/4414/ >> > >> > It is ridiculous how these patches are still not merged , after >> > almost >> > 2 years... :P >> > These patches are adding the support for KB9012 reading / writing, >> > the only open source flashing solution for these embedded >> > controllers >> > >> > Merging these patches could accelerate the development of Origami EC >> > libre firmware, >> > please do it >> > >> > Best regards, >> > Ivan Ivanov > -- > Paul Kocialkowski, developer of free digital technology and hardware > support > > Website: https://www.paulk.fr/ > Coding blog: https://code.paulk.fr/ > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > https://mail.coreboot.org/mailman/listinfo/flashrom > >

1 0

Re: [coreboot] Missing PCIe devices
by Nico Huber 14 Jan '18

14 Jan '18

Hi, On 14.01.2018 11:05, Kyösti Mälkki wrote: > On Sun, Jan 14, 2018 at 11:27 AM, Hal Martin <hal.martin(a)gmail.com> wrote: >> Just to verify again, I enabled all the PCI Express devices in the >> devicetree.cb to see if the missing devices would appear. Unfortunately they >> didn't. >> > > The log says some of those PCIe root ports are hidden/disabled: > PCI: Static device PCI: 00:1c.3 not found, disabling it. > > You will want to look at your board's rcba_config() implementation for > the enablement, it essentially takes precedence over anything you have > in devicetree.cb. FD register 0x3418 should be of most interest to > you, and there is also RPFN 0x0404 that affects the enumeration of > 0:1c.0 PCIe root ports. Datasheet should be public. > Yep, they are disabled in `romstage.c`. I've commented on the commit that added the culprit. Hal, generally you shouldn't set any register in your mainboard code that is already handled by the code for the respective chip (in this case sb/intel/bd82x6x/) unless you know what you are doing. Nico

2 1

Adopt-A-Commit (vendorcode/amd/agesa) [Take 2]
by awokd 14 Jan '18

14 Jan '18

[Sorry for the double post; messed up threading on my first attempt. Also added offer to help test.] Could someone familiar with the AGESA codebase please take over or rework and resubmit what I attempted to do in https://review.coreboot.org/22843? There are two problems with my version: A) Microcode blob should go in 3rdparty/blobs and CBFS- completely agree and understand the reasoning. I found some code in AGESA that appeared to search for microcode_amd_fam15h in CBFS but when I added the module manually it still didn't seem to find it. Attempted to debug but my coding-fu was too weak. If I spent more time on it I could probably figure it out, but: B) Real name policy- I didn't realize these were required but see now it's called out in https://www.coreboot.org/Development_Guidelines#How_to_contribute. It's my fault for missing that, but I'm unwilling to compromise my anonymity after seeing what they did to Appelbaum. Not looking to start a debate either way. I plan to continue contributing to Coreboot through email. The key part of my proposed commit is the addition of those two lines to F15TnEquivalenceTable.c. This permits AGESA's logic to match CPU models when searching for applicable microcode updates. From there, there should be a way to fix the code so microcode_amd_fam15h is properly added and searched in CBFS, which would remove the need to update F15TnMicrocodePatch0600110F_Enc.c. On a related note, my next commit was going to be to update 3rdparty/blobs/.../microcode_amd_fam15h.bin. Looks like the microcode in there for the 6020 processors is outdated (07/23/2014 vs. Debian distro's 01/25/2016). The updated microcode addresses a Piledriver virtualization vulnerability ( https://www.theregister.co.uk/2016/03/06/amd_microcode_6000836_fix/?page=2). Please let me know here or via direct email if you have any questions or if I can help test!

1 0

Correct value for PCI_INTERRUPT_LINE register
by Аладышев Константин 14 Jan '18

14 Jan '18

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 0000:00:02.0: ignoring bogus IRQ 139 [ 0.080008] irq:pcibios_fixup_irqs: pci 0000:00:03.0: ignoring bogus IRQ 139 [ 0.080012] irq:pcibios_fixup_irqs: pci 0000:00:16.0: ignoring bogus IRQ 139 [ 0.080017] irq:pcibios_fixup_irqs: pci 0000:00:1b.0: ignoring bogus IRQ 139 [ 0.080021] irq:pcibios_fixup_irqs: pci 0000:00:1c.0: ignoring bogus IRQ 139 [ 0.080025] irq:pcibios_fixup_irqs: pci 0000:00:1c.1: ignoring bogus IRQ 139 [ 0.080029] irq:pcibios_fixup_irqs: pci 0000:00:1c.2: ignoring bogus IRQ 138 [ 0.080033] irq:pcibios_fixup_irqs: pci 0000:00:1c.3: ignoring bogus IRQ 138 [ 0.080037] irq:pcibios_fixup_irqs: pci 0000:00:1c.4: ignoring bogus IRQ 139 [ 0.080041] irq:pcibios_fixup_irqs: pci 0000:00:1c.5: ignoring bogus IRQ 139 [ 0.080046] irq:pcibios_fixup_irqs: pci 0000:00:1d.0: ignoring bogus IRQ 139 [ 0.080050] irq:pcibios_fixup_irqs: pci 0000:00:1f.3: ignoring bogus IRQ 138 [ 0.080055] irq:pcibios_fixup_irqs: pci 0000:05:00.0: ignoring bogus IRQ 139 [ 0.080059] irq:pcibios_fixup_irqs: pci 0000:05:00.1: ignoring bogus IRQ 139 [ 0.080069] irq:pcibios_lookup_irq: pci 0000:00:02.0: PCI INT A -> PIRQ 60, mask dc78, excl 0000 [ 0.080073] irq:pcibios_lookup_irq: pci 0000:00:02.0: PCI INT A -> newirq 0 [ 0.080079] irq:pcibios_lookup_irq: pci 0000:00:02.0: can't route interrupt [ 0.080086] irq:pcibios_lookup_irq: pci 0000:00:03.0: PCI INT A -> PIRQ 60, mask dc78, excl 0000 [ 0.080090] irq:pcibios_lookup_irq: pci 0000:00:03.0: PCI INT A -> newirq 0 [ 0.080095] irq:pcibios_lookup_irq: pci 0000:00:03.0: can't route interrupt [ 0.080111] irq:pcibios_lookup_irq: pci 0000:00:16.0: PCI INT A -> PIRQ 60, mask dc78, excl 0000 [ 0.080115] irq:pcibios_lookup_irq: pci 0000:00:16.0: PCI INT A -> newirq 0 [ 0.080120] irq:pcibios_lookup_irq: pci 0000:00:16.0: can't route interrupt [ 0.080128] irq:pcibios_lookup_irq: pci 0000:00:1b.0: PCI INT A -> PIRQ 6a, mask dc78, excl 0000 [ 0.080131] irq:pcibios_lookup_irq: pci 0000:00:1b.0: PCI INT A -> newirq 0 [ 0.080137] irq:pcibios_lookup_irq: pci 0000:00:1b.0: can't route interrupt [ 0.080144] irq:pcibios_lookup_irq: pci 0000:00:1c.0: PCI INT A -> PIRQ 60, mask dc78, excl 0000 [ 0.080148] irq:pcibios_lookup_irq: pci 0000:00:1c.0: PCI INT A -> newirq 0 [ 0.080154] irq:pcibios_lookup_irq: pci 0000:00:1c.0: can't route interrupt [ 0.080161] irq:pcibios_lookup_irq: pci 0000:00:1c.1: PCI INT B -> PIRQ 61, mask dc78, excl 0000 [ 0.080165] irq:pcibios_lookup_irq: pci 0000:00:1c.1: PCI INT B -> newirq 0 [ 0.080171] irq:pcibios_lookup_irq: pci 0000:00:1c.1: can't route interrupt [ 0.080178] irq:pcibios_lookup_irq: pci 0000:00:1c.2: PCI INT C -> PIRQ 62, mask dc78, excl 0000 [ 0.080182] irq:pcibios_lookup_irq: pci 0000:00:1c.2: PCI INT C -> newirq 0 [ 0.080188] irq:pcibios_lookup_irq: pci 0000:00:1c.2: can't route interrupt [ 0.080195] irq:pcibios_lookup_irq: pci 0000:00:1c.3: PCI INT D -> PIRQ 63, mask dc78, excl 0000 [ 0.080199] irq:pcibios_lookup_irq: pci 0000:00:1c.3: PCI INT D -> newirq 0 [ 0.080204] irq:pcibios_lookup_irq: pci 0000:00:1c.3: can't route interrupt [ 0.080212] irq:pcibios_lookup_irq: pci 0000:00:1c.4: PCI INT A -> PIRQ 60, mask dc78, excl 0000 [ 0.080216] irq:pcibios_lookup_irq: pci 0000:00:1c.4: PCI INT A -> newirq 0 [ 0.080221] irq:pcibios_lookup_irq: pci 0000:00:1c.4: can't route interrupt [ 0.080228] irq:pcibios_lookup_irq: pci 0000:00:1c.5: PCI INT B -> PIRQ 61, mask dc78, excl 0000 [ 0.080232] irq:pcibios_lookup_irq: pci 0000:00:1c.5: PCI INT B -> newirq 0 [ 0.080238] irq:pcibios_lookup_irq: pci 0000:00:1c.5: can't route interrupt [ 0.080245] irq:pcibios_lookup_irq: pci 0000:00:1d.0: PCI INT A -> PIRQ 6b, mask dc78, excl 0000 [ 0.080249] irq:pcibios_lookup_irq: pci 0000:00:1d.0: PCI INT A -> newirq 0 [ 0.080255] irq:pcibios_lookup_irq: pci 0000:00:1d.0: can't route interrupt [ 0.080266] irq:pcibios_lookup_irq: pci 0000:00:1f.3: PCI INT C -> PIRQ 62, mask dc78, excl 0000 [ 0.080270] irq:pcibios_lookup_irq: pci 0000:00:1f.3: PCI INT C -> newirq 0 [ 0.080275] irq:pcibios_lookup_irq: pci 0000:00:1f.3: can't route interrupt [ 0.080320] irq:pcibios_lookup_irq: pci 0000:05:00.0: PCI INT A not found in routing table [ 0.080365] irq:pcibios_lookup_irq: pci 0000:05:00.1: PCI INT B not found in routing table So the problem is in strings: irq:pcibios_fixup_irqs: pci 0000:00:XX.0: ignoring bogus IRQ 139 139 (=0x8b) is value from my board devicetree.cb: register "pirqa_routing" = "0x8b" register "pirqb_routing" = "0x8b" register "pirqc_routing" = "0x8a" register "pirqd_routing" = "0x8a" register "pirqe_routing" = "0x85" register "pirqf_routing" = "0x80" register "pirqg_routing" = "0x8b" register "pirqh_routing" = "0x85" 0x8b means IRQ 0xb (=IRQ11) and Interrupt Routing Enable bit = 1. This value is written to PCH in file "southbridge\intel\lynxpoint\lpc.c" static void pch_pirq_init(device_t dev) { device_t irq_dev; /* Get the chip configuration */ config_t *config = dev->chip_info; pci_write_config8(dev, PIRQA_ROUT, config->pirqa_routing); pci_write_config8(dev, PIRQB_ROUT, config->pirqb_routing); pci_write_config8(dev, PIRQC_ROUT, config->pirqc_routing); pci_write_config8(dev, PIRQD_ROUT, config->pirqd_routing); pci_write_config8(dev, PIRQE_ROUT, config->pirqe_routing); pci_write_config8(dev, PIRQF_ROUT, config->pirqf_routing); pci_write_config8(dev, PIRQG_ROUT, config->pirqg_routing); pci_write_config8(dev, PIRQH_ROUT, config->pirqh_routing); /* Eric Biederman once said we should let the OS do this. * I am not so sure anymore he was right. */ for(irq_dev = all_devices; irq_dev; irq_dev = irq_dev->next) { u8 int_pin=0, int_line=0; if (!irq_dev->enabled || irq_dev->path.type != DEVICE_PATH_PCI) continue; int_pin = pci_read_config8(irq_dev, PCI_INTERRUPT_PIN); switch (int_pin) { case 1: /* INTA# */ int_line = config->pirqa_routing; break; case 2: /* INTB# */ int_line = config->pirqb_routing; break; case 3: /* INTC# */ int_line = config->pirqc_routing; break; case 4: /* INTD# */ int_line = config->pirqd_routing; break; } if (!int_line) continue; pci_write_config8(irq_dev, PCI_INTERRUPT_LINE, int_line); } } It is correct and right to write values like 0x8b to PIRQX_ROUT registers but in PCI_INTERRUPT_LINE registers Linux Kernel seems to expect values <16 (http://elixir.free-electrons.com/linux/v3.13/source/arch/x86/pci/irq.c#L102 6). So maybe the correct way to write these registers is: pci_write_config8(irq_dev, PCI_INTERRUPT_LINE, int_line & 0xf); After this change Linux boots correctly with 'acpi=off nolapic' options combination. PCI specification states: "For x86 based PCs, the values in this register correspond to IRQ numbers (0-15) of the standard dual 8259 configuration. The value 255 is defined as meaning "unknown" or "no connection" to the interrupt controller. Values between 15 and 254 are reserved." (https://www.xilinx.com/Attachment/PCI_SPEV_V3_0.pdf - page 223) I'm not an expert with IRQs and also I see that many other southbridges in coreboot fill this registers like Lynxpoint with values >=16, so before creating a patch I've wanted to ask you if I'm wrong with this? Best regards, Aladyshev Konstantin

2 1

Re: [coreboot] Missing PCIe devices
by Kyösti Mälkki 14 Jan '18

14 Jan '18

On Sun, Jan 14, 2018 at 11:27 AM, Hal Martin <hal.martin(a)gmail.com> wrote: > Hi Kyösti, > > Thank you for the hints. I have some comments below. > > > Just to verify again, I enabled all the PCI Express devices in the > devicetree.cb to see if the missing devices would appear. Unfortunately they > didn't. > The log says some of those PCIe root ports are hidden/disabled: PCI: Static device PCI: 00:1c.3 not found, disabling it. You will want to look at your board's rcba_config() implementation for the enablement, it essentially takes precedence over anything you have in devicetree.cb. FD register 0x3418 should be of most interest to you, and there is also RPFN 0x0404 that affects the enumeration of 0:1c.0 PCIe root ports. Datasheet should be public. > I am wondering though, all of these devices share the same PCIe clock > signal, which goes through a differential clock driver which according to > the manufacturer's documentation: I would expect all 4 NICs to fail if a separate buffer was the culprit. Kyösti

1 0

Re: [coreboot] Missing PCIe devices
by Hal Martin 14 Jan '18

14 Jan '18

Hi Kyösti, Thank you for the hints. I have some comments below. On Sat, Jan 13, 2018 at 8:59 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > Hi > > On Sat, Jan 13, 2018 at 8:51 PM, Hal Martin <hal.martin(a)gmail.com> wrote: > > Hi all, > > > > Is there any documentation around describing how coreboot scans for PCI > > Express buses and devices? > > Don't know of one. It's a recursive walk of the PCI tree, with the > assigned bus number incremented for every detected PCI bridge. How > vendor firmware does assignment may be different. > > > I have an expansion module for the Intense PC I'd like to get working > with > > Coreboot. The expansion module adds 4 Intel Gigabit Ethernet interfaces > > (82574L) via PCI Express 4 PCIe ports. All interfaces are on the same > > physical FACE module. > > > > In the vendor firmware, all four cards are properly detected: > > 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > > Connection > > 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > > Connection > > 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > > Connection > > 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > > Connection > > > > But in coreboot, only the first two cards are detected: > > 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > > Connection > > 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > > Connection > > > > It seems from the coreboot uart output that coreboot isn't scanning PCIe > > buses 6 & 7. Looking at pci_scan_bus in src/device/pci_device.c it seems > > coreboot should be recursively scanning PCI bridges for any devices > behind > > them. The lspci output from the vendor firmware and coreboot lists the > same > > number of PCI bridges: > > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core > processor > > PCI Express Root Port (rev 09) > > 00:01.1 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core > processor > > PCI Express Root Port (rev 09) > > > > Can you send 'lspci -tnv' output and 'sudo lspci -xxxx' from vendor > firmware boot. Same for coreboot and perhaps the complete log. There > are more PCIe root ports on device 0:1c.0, some of those you have > marked disabled in devicetree.cb. > Just to verify again, I enabled all the PCI Express devices in the devicetree.cb to see if the missing devices would appear. Unfortunately they didn't. I am wondering though, all of these devices share the same PCIe clock signal, which goes through a differential clock driver which according to the manufacturer's documentation: "The device distributes a differential input clock to four differential pairs of clock outputs either with or without PLL. The clock outputs are controlled by input selection of several static control signals and Host SMBus interface. The device oriented and designed for PCI Express applications." I used `i2cdetect -l` on the stock firmware and in coreboot, but nothing for SMBus appeared. I'm wondering if perhaps the issue is that this Pericom PI6C20400 clock driver is only providing clock to two of the devices and needs further configuration via SMBus? i2c-3 i2c i915 gmbus dpc I2C adapter i2c-1 i2c i915 gmbus vga I2C adapter i2c-6 i2c DPDDC-C I2C adapter i2c-4 i2c i915 gmbus dpb I2C adapter i2c-2 i2c i915 gmbus panel I2C adapter i2c-0 i2c i915 gmbus ssc I2C adapter i2c-7 i2c DPDDC-D I2C adapter i2c-5 i2c i915 gmbus dpd I2C adapter The information about the module I am using can be found on pages 36-40 of this document: http://fit-pc.com/download/face-modules/documents/face- modules-hw-specifications.pdf The lspci output would make this email ~450KB, so I'll only link to them: Vendor firmware lspci -tnv: https://watchmysys.com/ files/3f6e6fb3-8231-4320-905b-94b11a88d09d/lspci-tnv_compulabfw.txt Vendor firmware lspci -xxxx: https://watchmysys.com/ files/3f6e6fb3-8231-4320-905b-94b11a88d09d/lspci-xxxx_compulabfw.txt coreboot lspci -tnv: https://watchmysys.com/files/3f6e6fb3-8231-4320-905b- 94b11a88d09d/lspci-tnv_coreboot.txt coreboot lspci -xxxx: https://watchmysys.com/files/3f6e6fb3-8231-4320-905b- 94b11a88d09d/lspci-xxxx_coreboot.txt coreboot cbmem log: https://watchmysys.com/files/3f6e6fb3-8231-4320-905b- 94b11a88d09d/fm4lan_cbmem_console.txt Thanks, Hal > > > From the boot logs, it seems that coreboot stops scanning after PCI bus > 05: > > Default limit should be 63 for sandy/ivy and you could increase it to > 127 or 255. > > Kyösti >

1 0

Re: [coreboot] HP Elitebook 8770w Suspend-to-RAM
by Robert Reeves 14 Jan '18

14 Jan '18

I merely downgraded to 1.10.3.On Jan 13, 2018 6:42 AM, Nico Huber wrote: > > On 12.01.2018 00:57, Robert Reeves wrote: > > Yep, looks like that was the problem. I'm glad it was something simple. Thanks. > > So did you fix it? or only work around? as many people run into trouble > lately with the coreboot + SeaBIOS combination, I'm curious about what's > causing the trouble. > > Nico

1 0

Re: [coreboot] Missing PCIe devices
by Kyösti Mälkki 13 Jan '18

13 Jan '18

Hi On Sat, Jan 13, 2018 at 8:51 PM, Hal Martin <hal.martin(a)gmail.com> wrote: > Hi all, > > Is there any documentation around describing how coreboot scans for PCI > Express buses and devices? Don't know of one. It's a recursive walk of the PCI tree, with the assigned bus number incremented for every detected PCI bridge. How vendor firmware does assignment may be different. > I have an expansion module for the Intense PC I'd like to get working with > Coreboot. The expansion module adds 4 Intel Gigabit Ethernet interfaces > (82574L) via PCI Express 4 PCIe ports. All interfaces are on the same > physical FACE module. > > In the vendor firmware, all four cards are properly detected: > 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > > But in coreboot, only the first two cards are detected: > 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > > It seems from the coreboot uart output that coreboot isn't scanning PCIe > buses 6 & 7. Looking at pci_scan_bus in src/device/pci_device.c it seems > coreboot should be recursively scanning PCI bridges for any devices behind > them. The lspci output from the vendor firmware and coreboot lists the same > number of PCI bridges: > 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor > PCI Express Root Port (rev 09) > 00:01.1 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor > PCI Express Root Port (rev 09) > Can you send 'lspci -tnv' output and 'sudo lspci -xxxx' from vendor firmware boot. Same for coreboot and perhaps the complete log. There are more PCIe root ports on device 0:1c.0, some of those you have marked disabled in devicetree.cb. > From the boot logs, it seems that coreboot stops scanning after PCI bus 05: Default limit should be 63 for sandy/ivy and you could increase it to 127 or 255. Kyösti

1 0

Missing PCIe devices
by Hal Martin 13 Jan '18

13 Jan '18

Hi all, Is there any documentation around describing how coreboot scans for PCI Express buses and devices? I have an expansion module for the Intense PC I'd like to get working with Coreboot. The expansion module adds 4 Intel Gigabit Ethernet interfaces (82574L) via PCI Express 4 PCIe ports. All interfaces are on the same physical FACE module. In the vendor firmware, all four cards are properly detected: 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection But in coreboot, only the first two cards are detected: 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection It seems from the coreboot uart output that coreboot isn't scanning PCIe buses 6 & 7. Looking at pci_scan_bus in src/device/pci_device.c it seems coreboot should be recursively scanning PCI bridges for any devices behind them. The lspci output from the vendor firmware and coreboot lists the same number of PCI bridges: 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 00:01.1 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) >From the boot logs, it seems that coreboot stops scanning after PCI bus 05: PCI: pci_scan_bus for bus 01 PCI: 01:00.0 [8086/10d3] enabled Enabling Common Clock Configuration PCIE CLK PM is not supported by endpoint ASPM: Enabled L0s and L1 Failed to enable LTR for dev = PCI: 01:00.0 scan_bus: scanning of bus PCI: 00:01.0 took 18672 usecs PCI: pci_scan_bus for bus 02 scan_bus: scanning of bus PCI: 00:01.1 took 2609 usecs PCI: pci_scan_bus for bus 03 PCI: 03:00.0 [8086/10d3] enabled ... PCI: pci_scan_bus for bus 05 PCI: 05:00.0 [10ec/8168] enabled Enabling Common Clock Configuration ASPM: Enabled L1 Failed to enable LTR for dev = PCI: 05:00.0 scan_bus: scanning of bus PCI: 00:1c.2 took 14395 usecs scan_bus: scanning of bus PCI: 00:1f.0 took 2 usecs scan_bus: scanning of bus PCI: 00:1f.3 took 2 usecs scan_bus: scanning of bus DOMAIN: 0000 took 222594 usecs scan_bus: scanning of bus Root Device took 231592 usecs done BS: BS_DEV_ENUMERATE times (us): entry 0 run 238973 exit 0 found VGA at PCI: 00:02.0 Setting up VGA for PCI: 00:02.0 Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Allocating resources... Reading resources... Adding PCIe enhanced config space BAR 0xf8000000-0xfc000000. Done reading resources. I grepped in src/ but couldn't find where the min/max PCI bus IDs are set. Given that these work with the vendor firmware, and they appear to be on buses above what coreboot normally initializes (at least from my log output), I'm wondering how I can force coreboot to continue scanning/initializing PCIe buses above bus 05. Thanks, Hal

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
16
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 January 2018