April 2018 - coreboot - mail.coreboot.org

Re: [coreboot] SATA init on FSP 2.0 for Skylake
by Nico Huber April 3, 2018

April 3, 2018

On 03.04.2018 03:16, Naresh G. Solanki wrote: > coreboot-4.7-51-g2ca4ca3f21-dirty Thu Jan 18 22:05:03 UTC 2018 > romstage starting... > pm1_sts: ffff pm1_en: ffff pm1_cnt: ffffffff > gpe0_sts[0]: ffffffff gpe0_en[0]: ffffffff > gpe0_sts[1]: ffffffff gpe0_en[1]: ffffffff > gpe0_sts[2]: ffffffff gpe0_en[2]: ffffffff > gpe0_sts[3]: ffffffff gpe0_en[3]: ffffffff > I've seen (and fixed) this before. I suspect you have to `select SKYLAKE_SOC_PCH_H` in your Kconfig. > It seems to me that PM base is not setup properly.(this should be fixed first) > Right, please fix things from top to bottom. You can't expect everything to work if you have earlier problems in your log. Nico

1 0

POST cards, I/O ports and M.2 to MiniPCIe
by Trammell Hudson April 3, 2018

April 3, 2018

How soon after reset are port 0x80 messages available on a MiniPCIe attached POST card? And would the POST card be expected to work with a M.2 to MiniPCIe adapter? How is the ISA bus' I/O address space mapped to PCIe devices? I'm dealing an early bring-up problem on a modern architecture without serial ports and wondering if that would a good way to debug it. -- Trammell

1 0

Re: [coreboot] Problems with NVidia on Lenovo ThinkPad T430
by Michał Kopeć April 3, 2018

April 3, 2018

> Hello everybody! > > I have problems with getting coreboot running on a Lenovo ThinkPad > T430. > Better to say: Running with the integrated second graphics adapter NVS > 5400M. The Intel HD 4000 is working fine and from the wiki I know that > NVidia Optimus is not supported for now. So what to do exactly getting > the graphics adapter running? Even only NVidia only would be great. > Both > adapters are not needed on GNU-Linux for my usecase. I have two > VGA-ROMs > extracted and compiled this using the concurrent stable-version 4.7. > Is > this wrong? Some help and hints would be appreciated. > > Best regards, > Tobias. Hello Tobias, You can switch between GPUs by changing the value of the hybrid_graphics_mode CMOS setting using nvramcui or nvramtool. Currently, for the T430 this field can be set to either Integrated only or Dedicated only. Make sure you are using CMOS for configuration values. Unfortunately, I was unable to switch the power for the dGPU off at all, which resulted in rather high power consumption even if only the integrated GPU is enabled. Regards, Michał Kopeć

1 0

Re: [coreboot] SATA init on FSP 2.0 for Skylake
by Naresh G. Solanki April 3, 2018

April 3, 2018

Hi, Looking at coreboot-4.7-51-g2ca4ca3f21-dirty Thu Jan 18 22:05:03 UTC 2018 romstage starting... pm1_sts: ffff pm1_en: ffff pm1_cnt: ffffffff gpe0_sts[0]: ffffffff gpe0_en[0]: ffffffff gpe0_sts[1]: ffffffff gpe0_en[1]: ffffffff gpe0_sts[2]: ffffffff gpe0_en[2]: ffffffff gpe0_sts[3]: ffffffff gpe0_en[3]: ffffffff It seems to me that PM base is not setup properly.(this should be fixed first) Also before you use SATA, make sure FspSUpd for sata is set to be enabled. Also respective sata port is enabled. Above that, also check in fit tool whether right setting is done for flex io for sata port. On Sun, Apr 1, 2018, 6:43 PM Zheng Bao <fishbaoz(a)hotmail.com> wrote: > I met the same problem. I use the FSP1.1 and the 0:17h:0 disappears after > raminit. > It seems that the FSP disable the SATA. > > The SATA device can be disabled if SCFD is set. But it can not re-enable. > > SATA Controller Function Disable (SCFD): BIOS program this bit to 1 to > disable > the SATA Controller function. When 0, SATA Controller function is enabled. > When > disable, SATA Host Controller will not claimed the register access > targeting its > Configuration Space. In IOSF primary Fabric Decode scheme, it's expected > BIOS also > program the corresponding bit used by the Fabric Decoder accordingly hence > both > SATA SIP and Fabric Decoder are in sync, and BIOS need to program this bit > before > programming the one in Fabric Decoder. Once this bit is set, BIOS isnot > able to revert > it back to Function Enable until next round of platform reset. > > Zheng > > ------------------------------ > *From:* coreboot <coreboot-bounces(a)coreboot.org> on behalf of roman > perepelitsin <perepelitsin.roman(a)gmail.com> > *Sent:* Wednesday, March 28, 2018 2:51 PM > *To:* coreboot(a)coreboot.org > *Subject:* [coreboot] SATA init on FSP 2.0 for Skylake > > Hi! > I got a little problem with SATA controller in H110 Skylake PCH (desktop). > SATA device geographical address - 0:17h:0 on PCI, and it enabled via > devicetree.cb. This params correctly send in FspSiliconInit. After this > coreboot run PCI bus scan. And my SATA device return 0xffffffff on PCI read > config cycles. I search in Intel datasheet for specific SATA disable pin or > something else, but there is no methods that can make SATA inactive. Maybe > somebody advice about it? > > > > -- > regards, > Perepelitsin Roman > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Server systems shipped with coreboot
by Sam Kuper April 2, 2018

April 2, 2018

On 23/03/2018, Thierry Laurion <thierry.laurion(a)gmail.com> wrote: > If ... ME is disabled with its modules erased, could > the maker pursue the seller for having made those modifications? Interesting question. ThinkPenguin seems to be willing to take that risk, but hedges it by voiding the warranty: "Backdoors in modern computing devices are unfortunately a certainty today and while we can't be sure of a fix here it is possible to partially disable one component believed to be a problem. This option does have side-effects and will void any return." [1] (AFAICT, that laptop has the ME "disabled" if the buyer wishes, but it does not ship with Coreboot or Libreboot.) [1] https://www.thinkpenguin.com/gnu-linux/penguin-z-gnulinux-laptop

1 0

Re: [coreboot] Out of MTRRs
by Jay Talbott April 1, 2018

April 1, 2018

Hi Nico, What's the status for getting the patches merged that Aaron referenced below? Do you think they will resolve the issue that I am seeing? Also, just a note that the three ”No more variable MTRRs: 10" messages that occur during postcar are in the log regardless of how much memory I have in the system. Thanks, - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) JayTalbott(a)sysproconsulting.com http://www.sysproconsulting.com > -----Original Message----- > From: Aaron Durbin [mailto:adurbin@google.com] > Sent: Monday, March 19, 2018 10:22 AM > To: Jay Talbott > Cc: Coreboot > Subject: Re: [coreboot] Out of MTRRs > > On Mon, Mar 19, 2018 at 10:55 AM, Jay Talbott > <JayTalbott(a)sysproconsulting.com> wrote: > > See below… > > - Jay > > > > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=79fff000 End=7a000000 > (Size 1000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7a000000 End=7a800000 > (Size 800000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7a800000 End=7ac00000 > (Size 400000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7ac00000 End=7ae00000 > (Size 200000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7ae00000 End=7af00000 > (Size 100000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7af00000 End=7af80000 > (Size 80000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7af80000 End=7afc0000 > (Size 40000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7afc0000 End=7afe0000 > (Size 20000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7afe0000 End=7aff0000 > (Size 10000) > [Mon Mar 19 09:41:59.840 2018] MTRR Range: Start=7aff0000 End=7aff8000 > (Size 8000) > [Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10 > [Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10 > [Mon Mar 19 09:41:59.840 2018] No more variable MTRRs: 10 > > This is from postcar loading. I don't understand why the code is is > adding that many MTRR entries during postcar loading. The only that > should be added is the ranges needed to load and run ramstage. The > postcar MTRR code *does not* combine entries. It just determines the > number of MTRRs to meet what is sent in. It seems 0x79fff000--7aff8000 > is being requested. That's a pretty bad request given the current > constraints. Do you know why that was requested? And why it can't be > more naturally aligned? > > Below is the final MTRR calculation in ramstage: > > [Mon Mar 19 09:42:04.473 2018] MTRR: Physical address space: > [Mon Mar 19 09:42:04.473 2018] 0x0000000000000000 - 0x00000000000a0000 > size 0x000a0000 type 6 > [Mon Mar 19 09:42:04.473 2018] 0x00000000000a0000 - 0x00000000000c0000 > size 0x00020000 type 0 > [Mon Mar 19 09:42:04.473 2018] 0x00000000000c0000 - 0x000000007b800000 > size 0x7b740000 type 6 > [Mon Mar 19 09:42:04.473 2018] 0x000000007b800000 - 0x00000000c0000000 > size 0x44800000 type 0 > [Mon Mar 19 09:42:04.473 2018] 0x00000000c0000000 - 0x00000000d0000000 > size 0x10000000 type 1 > [Mon Mar 19 09:42:04.473 2018] 0x00000000d0000000 - 0x0000000100000000 > size 0x30000000 type 0 > [Mon Mar 19 09:42:04.473 2018] 0x0000000100000000 - 0x000000047f000000 > size 0x37f000000 type 6 > [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x250 0x0606060606060606 > [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x258 0x0606060606060606 > [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x259 0x0000000000000000 > [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x268 0x0606060606060606 > [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x269 0x0606060606060606 > [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606 > [Mon Mar 19 09:42:04.473 2018] MTRR: Fixed MSR 0x26b > 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26d > 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26e > 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] call enable_fixed_mtrr() > [Mon Mar 19 09:42:04.480 2018] CPU physical address size: 39 bits > [Mon Mar 19 09:42:04.480 2018] MTRR: default type WB/UC MTRR counts: > 6/11. > [Mon Mar 19 09:42:04.480 2018] MTRR: WB selected as default type. > [Mon Mar 19 09:42:04.480 2018] MTRR: 0 base 0x000000007b800000 mask > 0x0000007fff800000 type 0 > [Mon Mar 19 09:42:04.480 2018] MTRR: 1 base 0x000000007c000000 mask > 0x0000007ffc000000 type 0 > [Mon Mar 19 09:42:04.480 2018] MTRR: 2 base 0x0000000080000000 mask > 0x0000007fc0000000 type 0 > [Mon Mar 19 09:42:04.480 2018] MTRR: 3 base 0x00000000c0000000 mask > 0x0000007ff0000000 type 1 > [Mon Mar 19 09:42:04.480 2018] MTRR: 4 base 0x00000000d0000000 mask > 0x0000007ff0000000 type 0 > [Mon Mar 19 09:42:04.480 2018] MTRR: 5 base 0x00000000e0000000 mask > 0x0000007fe0000000 type 0 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x250 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x258 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x259 0x0000000000000000 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x268 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x269 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606 > [Mon Mar 19 09:42:04.480 2018] MTRR: Fixed MSR 0x26b > 0x0606060606060606 > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606 > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26d > 0x0606060606060606 > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26e > 0x0606060606060606 > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606 > [Mon Mar 19 09:42:04.486 2018] MTRR: TEMPORARY Physical address space: > [Mon Mar 19 09:42:04.486 2018] call enable_fixed_mtrr() > [Mon Mar 19 09:42:04.486 2018] 0x0000000000000000 - 0x00000000000a0000 > size 0x000a0000 type 6 > [Mon Mar 19 09:42:04.486 2018] 0x00000000000a0000 - 0x00000000000c0000 > size 0x00020000 type 0 > [Mon Mar 19 09:42:04.486 2018] 0x00000000000c0000 - 0x000000007b800000 > size 0x7b740000 type 6 > [Mon Mar 19 09:42:04.486 2018] 0x000000007b800000 - 0x00000000ffe00000 > size 0x84600000 type 0 > [Mon Mar 19 09:42:04.486 2018] 0x00000000ffe00000 - 0x0000000100000000 > size 0x00200000 type 5 > [Mon Mar 19 09:42:04.486 2018] 0x0000000100000000 - 0x000000047f000000 > size 0x37f000000 type 6 > [Mon Mar 19 09:42:04.486 2018] CPU physical address size: 39 bits > [Mon Mar 19 09:42:04.486 2018] MTRR: Removing WRCOMB type. WB/UC > MTRR > counts: 13/11 > 8. > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x250 0x0606060606060606 > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x250 0x0606060606060606 > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x258 0x0606060606060606 > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x259 0x0000000000000000 > [Mon Mar 19 09:42:04.486 2018] MTRR: Fixed MSR 0x268 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x269 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26b > 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26d > 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26e > 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x258 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] call enable_fixed_mtrr() > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x259 0x0000000000000000 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x268 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x269 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26a 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26b > 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26c 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26d > 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26e > 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] MTRR: Fixed MSR 0x26f 0x0606060606060606 > [Mon Mar 19 09:42:04.859 2018] CPU physical address size: 39 bits > [Mon Mar 19 09:42:04.859 2018] call enable_fixed_mtrr() > [Mon Mar 19 09:42:04.859 2018] MTRR: default type WB/UC MTRR counts: > 13/11. > [Mon Mar 19 09:42:04.859 2018] MTRR: UC selected as default type. > [Mon Mar 19 09:42:04.859 2018] CPU physical address size: 39 bits > [Mon Mar 19 09:42:04.859 2018] MTRR: 0 base 0x0000000000000000 mask > 0x0000007fc0000000 type 6 > [Mon Mar 19 09:42:04.859 2018] MTRR: 1 base 0x0000000040000000 mask > 0x0000007fe0000000 type 6 > [Mon Mar 19 09:42:04.865 2018] MTRR: 2 base 0x0000000060000000 mask > 0x0000007ff0000000 type 6 > [Mon Mar 19 09:42:04.865 2018] MTRR: 3 base 0x0000000070000000 mask > 0x0000007ff8000000 type 6 > [Mon Mar 19 09:42:04.865 2018] MTRR: 4 base 0x0000000078000000 mask > 0x0000007ffc000000 type 6 > [Mon Mar 19 09:42:04.865 2018] MTRR: 5 base 0x000000007b800000 mask > 0x0000007fff800000 type 0 > [Mon Mar 19 09:42:04.865 2018] MTRR: 6 base 0x00000000ffe00000 mask > 0x0000007fffe00000 type 5 > [Mon Mar 19 09:42:04.865 2018] MTRR: 7 base 0x0000000100000000 mask > 0x0000007f00000000 type 6 > [Mon Mar 19 09:42:04.865 2018] Taking a reserved OS MTRR. > [Mon Mar 19 09:42:04.865 2018] MTRR: 8 base 0x0000000200000000 mask > 0x0000007e00000000 type 6 > [Mon Mar 19 09:42:04.865 2018] Taking a reserved OS MTRR. > [Mon Mar 19 09:42:04.865 2018] MTRR: 9 base 0x0000000400000000 mask > 0x0000007f80000000 type 6 > [Mon Mar 19 09:42:04.865 2018] Taking a reserved OS MTRR. > [Mon Mar 19 09:42:04.865 2018] ERROR: Not enough MTRRs available! MTRR > indexis 10 with 10 MTTRs in total. > [Mon Mar 19 09:42:04.865 2018] Not enough MTRRs: 11 vs 10 > [Mon Mar 19 09:42:04.865 2018] Unable to insert temporary MTRR range: > 0x00000000ffe00000 - 0x0000000100000000 size 0x00200000 type 5 > [Mon Mar 19 09:42:04.865 2018] > [Mon Mar 19 09:42:04.865 2018] MTRR check > [Mon Mar 19 09:42:04.865 2018] Fixed MTRRs : Enabled > [Mon Mar 19 09:42:04.865 2018] Variable MTRRs: Enabled > > Looks like the temporary mapping is causing all the spam. You could do > a couple fo things: don't try calling mtrr_use_temp_range(). > Additionally you could set your settings differently such that it > reduces the MTRR pressure; something like requesting different io hole > sizes, etc. > > 0x0000000100000000 - 0x000000047f000000 size 0x37f000000 type 6 > > That one hurts a lot. Count the bits set in the size. That's 9 entries > right there. > > Nico has some patches outstanding that could possibly better optimize > this condition. https://review.coreboot.org/#/c/coreboot/+/21915/ and > 2 more on top.

3 3

Assigning PCI resources clobbers console with io-mapped / memory-mapped UART
by Jay Talbott April 1, 2018

April 1, 2018

We ran into an issue where we were not getting a full coreboot log on Denverton with the Harcuvar CRB, where it just abruptly stops the serial console output during the assignment of the PCI resources. Root Device assign_resources, bus 0 link: 0 DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:09.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 01 io PCI: 00:09.0 24 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14 bus 01 prefmem PCI: 00:09.0 20 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14 bus 01 mem PCI: 00:09.0 10 <- [0x00df700000 - 0x00df71ffff] size 0x00020000 gran 0x11 mem64 PCI: 00:0e.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 02 io PCI: 00:0e.0 24 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14 bus 02 prefmem PCI: 00:0e.0 20 <- [0x00dfffffff - 0x00dffffffe] size 0x00000000 gran 0x14 bus 02 mem PCI: 00:0e.0 10 <- [0x00df720000 - 0x00df73ffff] size 0x00020000 gran 0x11 mem64 PCI: 00:10.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 03 io PCI: 00:10.0 24 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x14 bus 03 prefmem PCI: 00:10.0 20 <- [0x00de000000 - 0x00de8fffff] size 0x00900000 gran 0x14 bus 03 mem PCI: 00:10.0 10 <- [0x00df740000 - 0x00df75ffff] size 0x00020000 gran 0x11 mem64 PCI: 00:10.0 assign_resources, bus 3 link: 0 PCI: 03:00.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 04 io PCI: 03:00.0 24 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x14 bus 04 prefmem PCI: 03:00.0 20 <- [0x00de000000 - 0x00de8fffff] size 0x00900000 gran 0x14 bus 04 mem PCI: 03:00.0 assign_resources, bus 4 link: 0 PCI: 04:00.0 10 <- [0x00dc000000 - 0x00ddffffff] size 0x02000000 gran 0x19 prefmem PCI: 04:00.0 14 <- [0x00de820000 - 0x00de823fff] size 0x00004000 gran 0x0e mem PCI: 04:00.0 18 <- [0x00de000000 - 0x00de7fffff] size 0x00800000 gran 0x17 mem PCI: 04:00.0 30 <- [0x00de800000 - 0x00de81ffff] size 0x00020000 gran 0x11 romem PCI: 03:00.0 assign_resources, bus 4 link: 0 PCI: 00:10.0 assign_resources, bus 3 link: 0 PCI: 00:12.0 10 <- [0x00df77b000 - 0x00df77b3ff] size 0x00000400 gran 0x0a mem64 PCI: 00:14.0 10 <- [0x00df774000 - 0x00df775fff] size 0x00002000 gran 0x0d mem PCI: 00:14.0 14 <- [0x00df77c000 - 0x00df77c0ff] size 0x00000100 gran 0x08 mem PCI: 00:14.0 18 <- [0x0000001c40 - 0x0000001c47] size 0x00000008 gran 0x03 io PCI: 00:14.0 1c <- [0x0000001c60 - 0x0000001c63] size 0x00000004 gran 0x02 io PCI: 00:14.0 20 <- [0x0000001c00 - 0x0000001c1f] size 0x00000020 gran 0x05 io PCI: 00:14.0 24 <- [0x00df77a000 - 0x00df77a7ff] size 0x00000800 gran 0x0b mem PCI: 00:15.0 10 <- [0x00df760000 - 0x00df76ffff] size 0x00010000 gran 0x10 mem64 PCI: 00:16.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 05 io PCI: 00:16.0 24 <- [0x00dea00000 - 0x00deefffff] size 0x00500000 gran 0x14 bus 05 prefmem PCI: 00:16.0 20 <- [0x00df500000 - 0x00df5fffff] size 0x00100000 gran 0x14 bus 05 mem PCI: 00:16.0 assign_resources, bus 5 link: 0 PCI: 05:00.0 10 <- [0x00dea00000 - 0x00debfffff] size 0x00200000 gran 0x15 prefmem64 PCI: 05:00.0 20 <- [0x00dee00000 - 0x00dee03fff] size 0x00004000 gran 0x0e prefmem64 PCI: 05:00.0 30 <- [0x00df500000 - 0x00df57ffff] size 0x00080000 gran 0x13 romem PCI: 05:00.1 10 <- [0x00dec00000 - 0x00dedfffff] size 0x00200000 gran 0x15 prefmem64 PCI: 05:00.1 20 <- [0x00dee04000 - 0x00dee07fff] size 0x00004000 gran 0x0e prefmem64 PCI: 05:00.1 30 <- [0x00df580000 - 0x00df5fffff] size 0x00080000 gran 0x13 romem PCI: 00:16.0 assign_resources, bus 5 link: 0 PCI: 00:17.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 06 io PCI: 00:17.0 24 <- [0x00df000000 - 0x00df4fffff] size 0x00500000 gran 0x14 bus 06 prefmem PCI: 00:17.0 20 <- [0x00df600000 - 0x00df6fffff] size 0x00100000 gran 0x14 bus 06 mem PCI: 00:17.0 assign_resources, bus 6 link: 0 PCI: 06:00.0 10 <- [0x00df000000 - 0x00df1fffff] size 0x00200000 gran 0x15 prefmem64 PCI: 06:00.0 20 <- [0x00df400000 - 0x00df403fff] size 0x00004000 gran 0x0e prefmem64 PCI: 06:00.0 30 <- [0x00df600000 - 0x00df67ffff] size 0x00080000 gran 0x13 romem PCI: 06:00.1 10 <- [0x00df200000 - 0x00df3fffff] size 0x00200000 gran 0x15 prefmem64 PCI: 06:00.1 20 <- [0x00df404000 - 0x00df407fff] size 0x00004000 gran 0x0e prefmem64 PCI: 06:00.1 30 <- [0x00df680000 - 0x00df6fffff] size 0x00080000 gran 0x13 romem PCI: 00:17.0 assign_resources, bus 6 link: 0 PCI: 00:18.0 10 <- [0x00df776000 - 0x00df776fff] size 0x00001000 gran 0x0c mem64 The boot continues, there's just no more console output from coreboot past this point. The payload launches fine after coreboot is finished. If we use a Linux kernel payload, it still successfully sends all of its kernel console output to the serial console beginning immediately after where the coreboot console output stopped. The last device that has its resources assigned that is displayed in the log is D24, F0 (PCI 00:18.0). The next device in the list to have its resources assigned is D26, F0 (PCI 00:1a.0), which is UART 0, which is the UART used for the serial console. So this is starting to make some sense. Since the BARs are assigned in order, and the first BAR of the UART device is the I/O BAR at offset 0x10, it's pretty clear that changing the I/O space resource assigned to the UART is what's clobbering the console. I haven't looked at it yet, but I'm assuming that the UART driver just caches the base address early on and doesn't know that the base address changed during PCI resource assignment later in the boot cycle. Of course, not only do we lose the console output, but also the UART driver is still writing the rest of the log to an I/O address that is no longer associated with the UART, but now potentially assigned to some other PCI device. Fortunately, with Denverton, the UART mode can be changed from the default Non Legacy Mode to Legacy Mode, which appears to have resolved the issue in this particular case. However, I can see this as being a general problem on any/all platforms that don't have a legacy UART (or a UART that can be put in legacy mode). Any platform with UARTs that strictly use I/O and/or memory mapped registers that are accessed via PCI BARs have the potential of having the BARs programmed with different addresses during PCI resource assignment, thus terminating the console output and otherwise potentially causing other bad things to happen. I thought it best to bring this up to the coreboot community, since this could easily be a problem on any/all platforms that don't have a legacy UART (or a UART that can be put into legacy mode). Has anybody else run into this and/or thought about a general solution to this potential problem? - Jay Jay Talbott Principal Consulting Engineer SysPro Consulting, LLC 3057 E. Muirfield St. Gilbert, AZ 85298 (480) 704-8045 (480) 445-9895 (FAX) <mailto:JayTalbott@sysproconsulting.com> JayTalbott(a)sysproconsulting.com <http://www.sysproconsulting.com/> http://www.sysproconsulting.com

2 1

Re: [coreboot] SATA init on FSP 2.0 for Skylake
by Zheng Bao April 1, 2018

April 1, 2018

I met the same problem. I use the FSP1.1 and the 0:17h:0 disappears after raminit. It seems that the FSP disable the SATA. The SATA device can be disabled if SCFD is set. But it can not re-enable. SATA Controller Function Disable (SCFD): BIOS program this bit to 1 to disable the SATA Controller function. When 0, SATA Controller function is enabled. When disable, SATA Host Controller will not claimed the register access targeting its Configuration Space. In IOSF primary Fabric Decode scheme, it's expected BIOS also program the corresponding bit used by the Fabric Decoder accordingly hence both SATA SIP and Fabric Decoder are in sync, and BIOS need to program this bit before programming the one in Fabric Decoder. Once this bit is set, BIOS isnot able to revert it back to Function Enable until next round of platform reset. Zheng ________________________________ From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of roman perepelitsin <perepelitsin.roman(a)gmail.com> Sent: Wednesday, March 28, 2018 2:51 PM To: coreboot(a)coreboot.org Subject: [coreboot] SATA init on FSP 2.0 for Skylake Hi! I got a little problem with SATA controller in H110 Skylake PCH (desktop). SATA device geographical address - 0:17h:0 on PCI, and it enabled via devicetree.cb. This params correctly send in FspSiliconInit. After this coreboot run PCI bus scan. And my SATA device return 0xffffffff on PCI read config cycles. I search in Intel datasheet for specific SATA disable pin or something else, but there is no methods that can make SATA inactive. Maybe somebody advice about it? -- regards, Perepelitsin Roman

1 0