October 2019 - coreboot - mail.coreboot.org

TianoCore: Get PS/2 keyboard working in UefiPayloadPkg
by Paul Menzel Oct. 8, 2019

Oct. 8, 2019

Dear coreboot folks, Those of you, who missed it in #coreboot(a)irc.freenode.net and do not monitor the TianoCore bug tracker, Greg (myfreeweb) posted instructions on how to get PS/2 working in UefiPayloadPkg [1]. Kind regards, Paul [1]: https://bugzilla.tianocore.org/show_bug.cgi?id=2241#c1

1 0

Apollolake: SATA issues
by Christian Gmeiner Oct. 8, 2019

Oct. 8, 2019

Hi all I have ported coreboot to a custom design based on APL and have random SATA problems with CFast cards. I am using the latest public APL FSP from github with the latest coreboot master. From time to time the SATA link 'dies' during runtime or I it is not possible to establish the SATA link at all (in the used u-boot payload). At the moment I am running out of ideas and I hope someone can point me in the right direction. Btw. with the vendor blob SATA works with out any problems :/ -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy

3 2

Re: [PATCH] x86_64 support needs testing
by Patrick Rudolph Oct. 6, 2019

Oct. 6, 2019

On 2019-10-01 07:32 PM, Aaron Durbin via coreboot wrote: > On Tue, Oct 1, 2019 at 10:29 AM Raul Rangel <rrangel(a)chromium.org> > wrote: > >> Yeah, we can place the stack at the bottom of a page so if it >> overflows we get a page fault. I'm assuming that will work in SMM? > > Paging works in SMM, yes. However, paging works on 32-bit as well > where one could achieve the same thing. Minimum 4KiB stack granularity > is necessary as well as ensuring physical and virtual address spaces > are split up to allow guard pages. Currently everything is assumed > 1:1. > Currently neither 4KiB page, non identity mapping or a page fault handler is present. It would also require runtime modification of page tables, as the position of TSEG/A-Seg and the stack isn't known at build time, which only works if those reside in RAM. The current approach places page tables in RO CBFS to make sure it can't be modified from ring 0, which is sufficient for basic x86_64 support. Of course those can be added once the basic support has landed and is stable. >> On Tue, Oct 1, 2019 at 10:27 AM Aaron Durbin <adurbin(a)google.com> >> wrote: >> >> On Tue, Oct 1, 2019 at 9:42 AM Raul Rangel <rrangel(a)chromium.org> >> wrote: >> >> That's exciting. That means we can finally catch stack overflows in >> SMM. >> >> Because of paging? >> >> On Sun, Sep 29, 2019 at 5:42 AM Patrick Rudolph <siro(a)das-labor.org> >> wrote: >> Dear coreboot community, >> Please test and review the patch series [1]. >> >> It adds support for x86 long mode on qemu and allows to build test >> most of coreboot's common code using the x86_64 toolchain. >> It serves as reference implementation to migrate real hardware to >> long >> mode. >> >> Here some technical details, that can also be found in the >> Documentation/ folder: >> >> A new tool called pgtblgen create static page tables for a known >> physical >> memory address. The page tables are placed in CBFS at the given >> address. >> Due to the fixed and known address, they can easily be loaded in >> assembly code. >> It only works on platforms that memory map the SPI flash, which are >> almost all >> modern x86 platforms. >> >> The advantage of page tables in ROM are: >> * No runtime (assembly) code to generate page tables >> * No need to find a (4K aligned) place in heap to store them >> * Improved security for SMM, as page tables are always immutable >> >> The page tables are loaded in bootblock and SMM and persist until >> control is handed >> over to the payload. >> >> For the Proof-of-Concept only 4GiB are identity mapped, thus no >> stage >> can't access >> memory over 4GiB. That's not a problem for now as no coreboot code >> make >> use of memory >> above 4GiB yet. >> >> I haven't done further tests on long mode. >> It will be interesting to see if there are improvements on boot >> speed, >> code size or >> faster firmware decompression speeds. >> >> Regards, >> Patrick >> >> 1: >> > https://review.coreboot.org/q/topic:%22x86_64_support2%22+(status:open%20OR… >> _______________________________________________ >> coreboot mailing list -- coreboot(a)coreboot.org >> To unsubscribe send an email to coreboot-leave(a)coreboot.org >> _______________________________________________ >> coreboot mailing list -- coreboot(a)coreboot.org >> To unsubscribe send an email to coreboot-leave(a)coreboot.org > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org

1 0

Ice Lake FSP Released
by Desimone, Nathaniel L Oct. 5, 2019

Oct. 5, 2019

Hi All, Intel is pleased to announce that Ice Lake FSP is now available on https://github.com/IntelFsp/FSP. With Best Regards, Nate

1 0

Graphics Initialization
by Senthil Kumar G Oct. 4, 2019

Oct. 4, 2019

Hi, We are developing coreboot along with UEFI shell payload for Coffelake architecture. We are using the processor integrated graphics controller for display. I am getting the following error on porting the coreboot. Grahics hand-off block not found.FSP did not return a valid framebuffer. I checked internal graphics is enabled in FSP and graphics memory is set to 32 MB. Also applied a patch found in coreboot mailing list on device tree and gpio files for Intel graphics. Whether Coreboot can print any messages on the display (other than console). Coreboot came up and I got the shell prompt on Uart Console. The same shell prompt has to come on the display (monitor) but not displayed. I suspect some graphics initialization problem. Regards,gsen.

5 6

KGPE-D16 maintainership
by Piotr Król Oct. 2, 2019

Oct. 2, 2019

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, we see a lot of attention around KGPE-D16 maintainership problems. After discussion with Thierry Laurion (Insurgo) at OSFC2019 3mdeb decided to help in maintaining that platform by organizing crowd founding campaign or getting founds in other ways (direct sponsors). Since we are based in Poland there is chance that even with small contribution from community we would be able to cover the costs. Ideal plan would be to have structure similar to what we maintain for PC Engines: https://pcengines.github.io/ Where we providing signed and reproducible binaries every month and keep as close to mainline as possible. Of course if development will be active, then there always would be delta of patches held in review. Unfortunately we don't have hardware. During OSFC 2019 Stefan left one board, but it was too late (and probably too expensive) for us to organize any shipment to Poland. We looking to have 2 mainboards one for development and one in our automated regression testing environment. Of course we will start even with just one. If anyone is willing to help in founding, sponsoring hardware or by code development and testing we would be very grateful. Please copy other people and share this post wherever is necessary to keep this platform alive. Positive feedback will help things rolling. Best Regards, - -- Piotr Król Embedded Systems Consultant GPG: B2EE71E967AA9E4C https://3mdeb.com | @3mdeb_com -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAl2ApSoACgkQsu5x6Weq nkw0XQ//WeO+U6VFcr6wsfCkv5qXnKVHb6XDXyEknhu7Q82HZ9Hx+0IiZ0+ikzVZ oLU36euPwlHoRFh3HPm34DHeeYAZYzzsdc41+0MZJao152CGZJQwe+pqD/JeymOU Jky+PhULeGKXt22ftbxte1ac82tRDFt//0Yc07qxP9G/CboZ8sjckKjfyfoy5PFm 9jRFwdZUMbU42mU+NYLn/iXGWM/+mxC+ghncQBYwwGX1npr1r5gSiZS9ImoHFpgj DQaaUQq2v8vS1uvYZ84vVEXeOljTkzFg7UyUZq3sSob8bA/a42rsgFMPVI6Bpc5R lAEdhBZgMaD4jjO2GK+3zFSy32pBvK71tzwrdLjhb/bjjN1phHy2zbwTebFWlyiu HQJ/+iu4uoTQj69GT9i7HLyngorh37GWFHKScDDzEASnSO868ELhlrt+yHwyY284 EAe7dTOhOtfdxJOKcfdyUez5nwPZON4AXEVSvLWLUv4r+f82CG89f+LLg7rbZH5n C0HnUOJas89xEvRhXChTBHnM9NBKSWpch5uZ5SbZHb/JCWBb26yT6Ua46H0STFRh y+pWHc8AN76FQnWvpYer5F3hyVEX1+wAsi+RJMROFUejCn3lCl5ogAnT4ZRCqzo3 61Ao6dYmtYhaQ3JjZ+5bv3926ZwRjvr7i5t9bHf9THXCn1UobjY= =wYUt -----END PGP SIGNATURE-----

7 12

Re: General protection fault in `switch_mm_irqs_off()`
by Paul Menzel Oct. 2, 2019

Oct. 2, 2019

[CC: +affected coreboot folks, +coreboot mailing list] Dear Thomas, More affected people discussed this issue on the coreboot mailing list [1]. On 2019-01-14 18:37, Lendacky, Thomas wrote: > On 1/14/19 11:09 AM, Paul Menzel wrote: >> On 01/14/19 18:00, Lendacky, Thomas wrote: >>> On 1/10/19 12:34 PM, Lendacky, Thomas wrote: >>>> On 1/10/19 10:49 AM, Paul Menzel wrote: >>>>> Dear Boris, dear Thomas, >>>>> >>>>> >>>>> On 01/10/19 17:00, Borislav Petkov wrote: >>>>>> On Thu, Jan 10, 2019 at 02:57:40PM +0100, Paul Menzel wrote: >>>>>>> Thank you very much. Indeed, the machine does not crash. I used Linus’ >>>>>>> master branch for testing, and applied your patch on top. Please find >>>>>>> the full log attached. >>>>>> >>>>>>> 80.649: [ 3.197107] Spectre V2 : spectre_v2_user_select_mitigation: set X86_FEATURE_USE_IBPB >>>>>> >>>>>> This is amazing. >>>>>> >>>>>> Ok, next diff, same exercise. Thx.> >>>>>> --- >>>>>> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h >>>>>> index dad12b767ba0..528ef8336f5f 100644 >>>>>> --- a/arch/x86/include/asm/nospec-branch.h >>>>>> +++ b/arch/x86/include/asm/nospec-branch.h >>>>>> @@ -284,6 +284,12 @@ static inline void indirect_branch_prediction_barrier(void) >>>>>> { >>>>>> u64 val = PRED_CMD_IBPB; >>>>>> >>>>>> + if (WARN_ON(boot_cpu_has(X86_FEATURE_USE_IBPB))) { >>>>>> + pr_info("%s: c: %px, array: 0x%x\n", >>>>>> + __func__, &boot_cpu_data, boot_cpu_data.x86_capability[7]); >>>>>> + return; >>>>>> + } >>>>>> + >>>>>> alternative_msr_write(MSR_IA32_PRED_CMD, val, X86_FEATURE_USE_IBPB); >>>>>> } >>>>>> >>>>>> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c >>>>>> index 8654b8b0c848..e818e5abe611 100644 >>>>>> --- a/arch/x86/kernel/cpu/bugs.c >>>>>> +++ b/arch/x86/kernel/cpu/bugs.c >>>>>> @@ -371,6 +371,9 @@ spectre_v2_user_select_mitigation(enum spectre_v2_mitigation_cmd v2_cmd) >>>>>> if (boot_cpu_has(X86_FEATURE_IBPB)) { >>>>>> setup_force_cpu_cap(X86_FEATURE_USE_IBPB); >>>>>> >>>>>> + pr_err("%s: set X86_FEATURE_USE_IBPB, c: %px, array: 0x%x\n", >>>>>> + __func__, &boot_cpu_data, boot_cpu_data.x86_capability[7]); >>>>>> + >>>>>> switch (cmd) { >>>>>> case SPECTRE_V2_USER_CMD_FORCE: >>>>>> case SPECTRE_V2_USER_CMD_PRCTL_IBPB: >>>>>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c >>>>>> index cb28e98a0659..8566737fa500 100644 >>>>>> --- a/arch/x86/kernel/cpu/common.c >>>>>> +++ b/arch/x86/kernel/cpu/common.c >>>>>> @@ -765,6 +765,9 @@ static void apply_forced_caps(struct cpuinfo_x86 *c) >>>>>> c->x86_capability[i] &= ~cpu_caps_cleared[i]; >>>>>> c->x86_capability[i] |= cpu_caps_set[i]; >>>>>> } >>>>>> + >>>>>> + if (c == &boot_cpu_data) >>>>>> + pr_info("%s: c: %px, array: 0x%x\n", __func__, c, c->x86_capability[7]); >>>>>> } >>>>>> >>>>>> static void init_speculation_control(struct cpuinfo_x86 *c) >>>>>> @@ -778,6 +781,10 @@ static void init_speculation_control(struct cpuinfo_x86 *c) >>>>>> if (cpu_has(c, X86_FEATURE_SPEC_CTRL)) { >>>>>> set_cpu_cap(c, X86_FEATURE_IBRS); >>>>>> set_cpu_cap(c, X86_FEATURE_IBPB); >>>>>> + >>>>>> + pr_info("%s: X86_FEATURE_SPEC_CTRL: c: %px, array: 0x%x, CPUID: 0x%x\n", >>>>>> + __func__, c, c->x86_capability[7], cpuid_edx(7)); >>>>>> + >>>>>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL); >>>>>> } >>>>>> >>>>>> @@ -793,9 +800,13 @@ static void init_speculation_control(struct cpuinfo_x86 *c) >>>>>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL); >>>>>> } >>>>>> >>>>>> - if (cpu_has(c, X86_FEATURE_AMD_IBPB)) >>>>>> + if (cpu_has(c, X86_FEATURE_AMD_IBPB)) { >>>>>> set_cpu_cap(c, X86_FEATURE_IBPB); >>>>>> >>>>>> + pr_info("%s: X86_FEATURE_AMD_IBPB: c: %px, array: 0x%x, CPUID: 0x%x\n", >>>>>> + __func__, c, c->x86_capability[7], cpuid_ebx(0x80000008)); >>>>>> + } >>>>>> + >>>>>> if (cpu_has(c, X86_FEATURE_AMD_STIBP)) { >>>>>> set_cpu_cap(c, X86_FEATURE_STIBP); >>>>>> set_cpu_cap(c, X86_FEATURE_MSR_SPEC_CTRL); >>>>> >>>>> Please find the logs attached. >>>> >>>> Ah, so the CPUID value is showing X86_FEATURE_AMD_IBPB (not sure why the >>>> cpuid command was showing a value of zero for EBX in your previous email). >>>> Let me see what I can find out about this processor/firmware relation. I >>>> wouldn't expect to see the #GP given that the firmware says IBPB is >>>> supported. >>> >>> I'm not able to reproduce this issue on my family 21, model 1, stepping 2 >>> processor (AMD Opteron(TM) Processor 6274) as I am able to successfully >>> write to the PRED_CMD MSR. >> >> It’s not exactly the same processor, but I guess the same family should be >> good enough. What board do you have? Do you have two sockets, and both >> populated? > > Yes, It is a two-socket system with two processors installed. > >> Here is an Asus KGPE-D16 with two AMD Opterons put in. >> >> Lastly, my microcode updates are applied in firmware, and not by GNU/Linux. > > Ok, I was confused on how you had reported that, sorry. Kinky reports, that populating the memory slots of both NUMA nodes fixes this. Kinky, what slots do you have exactly populated? I haven’t been able to verify that yet, but please find my output of `sudo dmidecode -t memory` with a 8 * 16 GB system attached, which is affected. > Can we try an experiment where you use the older version of the Asus > firmware but build an initramfs that will perform early microcode loading? > I'm curious if things will work when loaded via Linux. I believe the users reported that this works. >>> Let's check the firmware file that you're loading. The one I'm using is: >>> >>> $ sha1sum /lib/firmware/amd-ucode/microcode_amd_fam15h.bin >>> 90896256951d8edf7baf8181ae11e2dc618a5171 /lib/firmware/amd-ucode/microcode_amd_fam15h.bin >>> >>> Does that match what you have? >> >> Yes, that matches exactly. >> >> 90896256951d8edf7baf8181ae11e2dc618a5171 3rdparty/blobs/cpu/amd/family_15h/microcode_amd_fam15h.bin Kind regards, Paul [1]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/QZIV…

1 0

[PATCH] x86_64 support needs testing
by Patrick Rudolph Oct. 1, 2019

Oct. 1, 2019

Dear coreboot community, Please test and review the patch series [1]. It adds support for x86 long mode on qemu and allows to build test most of coreboot's common code using the x86_64 toolchain. It serves as reference implementation to migrate real hardware to long mode. Here some technical details, that can also be found in the Documentation/ folder: A new tool called pgtblgen create static page tables for a known physical memory address. The page tables are placed in CBFS at the given address. Due to the fixed and known address, they can easily be loaded in assembly code. It only works on platforms that memory map the SPI flash, which are almost all modern x86 platforms. The advantage of page tables in ROM are: * No runtime (assembly) code to generate page tables * No need to find a (4K aligned) place in heap to store them * Improved security for SMM, as page tables are always immutable The page tables are loaded in bootblock and SMM and persist until control is handed over to the payload. For the Proof-of-Concept only 4GiB are identity mapped, thus no stage can't access memory over 4GiB. That's not a problem for now as no coreboot code make use of memory above 4GiB yet. I haven't done further tests on long mode. It will be interesting to see if there are improvements on boot speed, code size or faster firmware decompression speeds. Regards, Patrick 1: https://review.coreboot.org/q/topic:%22x86_64_support2%22+(status:open%20OR…

3 4

Looking for boards to port.
by Maccraft123 . Oct. 1, 2019

Oct. 1, 2019

I can port boards with already known documentation if you send me board that you want ported. Requirements: DDR{,2,3} Desktop RAM support AMD: Athlon II/Phenom X4 CPU supported by board Intel: Core 2 Duo E8400 CPU supported by board Requirements are from hardware that I already have You pay for shipping. I will inform you of all progress in porting of that board.

1 0