coreboot March 2018

coreboot@coreboot.org

62 participants
103 discussions

Optiplex 790 now has preliminary support by coreboot

by Taiidan＠gmx.com

https://review.coreboot.org/21774 In case anyone else didn't notice - It is a sandy/ivy system with IOMMU. This is great and should help get coreboot in to the corporate user world.

1 year

Lenovo T410 Coreboot

by A. Veek

2 years, 1 month

FOSDEM Hardware Enablement Devroom

by Paul Kocialkowski

A Hardware Enablement devroom will be taking place at FOSDEM this year, on Sunday 10 December 2017. This newly-created devroom is the result of 3 proposals that were merged together. It is co-organized by several individuals. The devroom covers all aspects related to hardware enablement and support with free software, including aspects related to boot software, firmwares, drivers and userspace tools and adaptation. Proposals for talks related to these topics are welcome and can be submitted until Sunday 26 November 2017 via the pentabarf interface. Short talks are encouraged over longer ones in order to cover a wide range of topics. The announcement for the devroom, that contains all the useful information, was published at: https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html Cheers and see you at FOSDEM! -- 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/

2 years, 1 month

When does AMD release the fam15 spectre microcode updates?

by Taiidan＠gmx.com

They said they would be releasing opteron microcode updates in a few weeks but it has been over a month and I am wondering when this is going to happen or if it already has and I should re-compile coreboot? https://www.amd.com/en/corporate/speculative-execution "We expect to make updates available for our previous generation products over the coming weeks." Thanks!

2 years, 9 months

Re: [coreboot] Asus AM1I-A

by Elisenda Cuadros

Hi Gergely, Thank you for your config. Now I have coreboot + SeaBIOS perfectly working. Console speed is now "normal" :-) These are the changes between the two configs: ------------- diff config_original.txt config_Gergely.txt 23c23 < # CONFIG_USE_BLOBS is not set --- > CONFIG_USE_BLOBS=y 101c101 < CONFIG_UART_FOR_CONSOLE=0 --- > CONFIG_UART_FOR_CONSOLE=1 150c150 < CONFIG_POST_DEVICE=y --- > # CONFIG_POST_DEVICE is not set 210c210 < CONFIG_TTYS0_BASE=0x3f8 --- > CONFIG_TTYS0_BASE=0x2f8 428,429d427 < # CONFIG_PCI_OPTION_ROM_RUN_REALMODE is not set < # CONFIG_PCI_OPTION_ROM_RUN_YABEL is not set 431d428 < # CONFIG_VGA_TEXT_FRAMEBUFFER is not set 556c553 < # Serial port base address = 0x3f8 --- > # Serial port base address = 0x2f8 581,583d577 < CONFIG_POST_DEVICE_NONE=y < # CONFIG_POST_DEVICE_LPC is not set < # CONFIG_POST_DEVICE_PCI_PCIE is not set -------------- I made some tweaks to the configuration, added VGA output before payload, a nice bootsplash, etc.. Other considerations: VGA Device PCI IDs are 1002,9830 (The default 1002,9836 does not get output). Memory has to be located firstly on second slot (yellow DIMM_A2). If not you get AGESA_FATAL_ERROR. I only have one module. Please, find attached a working config.txt and console.log. Coreboot revision is 4.7-294-g2db6fbc47b. If you verify these changes are working for you is it possible to change the defaults in Kconfig? Thank you very much. Best regards, -- Eli On 11/02/18 00:07, Gergely Kiss wrote: > Strange, the log you shared looked less verbose to me than expected > but seems like I was wrong. Anyway, you might find an example on a > full debug log here [1]. > > I have a small build script I use to build coreboot for my board, > please find it attached. > > The version currently running on my box is 4.6-2554-ga1b4c94. > > [1] https://www.coreboot.org/Board:asus/am1i-a#Bootlog > > On 10 February 2018 at 23:18, Elisenda Cuadros <lists(a)e4l.es > <mailto:lists@e4l.es>> wrote: > > Thank you for your kind reply Gergely. > > I think the cable is not the problem, I have been using it for > years and it's intact. > > I am using a usb dongle but not a cheap one. Tomorrow I will try > with another cable and a real COM port. Just to be 100% sure. > > Console is fast at the very first time (just the "normal") but > after two seconds it becomes extremely slow. > > Please, can you say me which is the git revision you are using? > > The console log I attached is from a SPEW debug level, not > corresponding with the config.. I tried several configs today :-) . > > Is it possible to share your config with me? > > Best regards, > > Eli > > > On 10/02/18 21:44, Gergely Kiss wrote: >> Hi Eli, >> >> I've been using Coreboot on my board for several weeks, it is >> serving as an HTPC running 24/7 and it's working perfectly stable >> which suggests the firmware should be free of bugs. It is likely >> that you are facing some configuration or hardware issue here. >> >> I didn't see any issues with the serial output while working with >> the board once the SuperIO chip started to work. Make sure the >> cable you use is intact and try to attach it to another machine. >> At the time I was working with my board, I used a Dell Port >> Replicator with a native COM port so I could use a standard >> null-modem cable and it was working flawlessly. In case you use a >> USB serial adapter, try replacing it or attach the serial cable >> directly to a COM port if you have one available. >> >> Also, please enable debug_level=Spew as it seems the console log >> you attached comes from a less verbose setting and therefore it's >> not as useful as it should be. >> >> Note that the VBIOS image is executed by SeaBIOS which means you >> won't see anything on your display until the payload is executed. >> >> If all else fails, you can still attach a POST debug module to >> the LPC header of the board [1] which can help a lot to find out >> where the boot process hangs. >> >> Feel free to contact me if you need some more help or >> information, I'm happy to assist! >> >> Regards, >> Gergely >> >> [1] https://www.youtube.com/watch?v=aGGqsWx3-1c >> <https://www.youtube.com/watch?v=aGGqsWx3-1c> >> >> On 10 February 2018 at 18:17, Elisenda Cuadros <lists(a)e4l.es >> <mailto:lists@e4l.es>> wrote: >> >> Hello, >> >> I'm trying to use Coreboot in an Asus AM1I-A board recently >> ported by Gergely Kiss (thank you!). >> >> I am using the default config settings and added vga rom >> extracted with UEFITool from the vendor bios. >> >> After flashing and booting I get no output from vga. >> >> Serial console is extremely slow too (30 minutes to write the >> log) >> >> I attach the coreboot console log, config and cbfs.txt. >> >> Any hints? >> >> Thanks in advance. >> >> Best regards, >> >> -- Eli >> >> >> > > > >

2 years, 9 months

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

by Rudolf Marek

Hi, What do you want to protect? If you want to protect the kernel, retpolines are OK on AMD. And you don't need any microcode update. Your CPU needs to have SMEP, otherwise you would need to clear RSB on CPL change (the paper on mentined page says that you need to do that always, but at least on Ryzen, the attack using RSB is not working (we tried that out, maybe it works only on some circumstances). If you want to protect userspace, the RSB will be clear by IBPB (which you would need if you don't have userspace compiled with retpolines). I don't know if intel clears RSB on IBPB... probably not To sum it up on AMD: kernel: retpolines, RSB clear on CPL change on CPU without SMEP (see above) userspace: retpolines, RSB clear on context switch necessary or IBPB (needs microcode update). Plus make sure you enable "LFENCE is dispatch serializing" - perhaps coreboot can do that :) it is simple MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE is dispatch serilizing. Besides that, you don't need any microcode update. Plus of course there is a spectre variant 1, which is more difficult to mitigate, basically you need to check all the software and look for any pattern like array_x[array_z[untrusted_index] * any transformation]. The first access would leak just address (ASLR defated), second will leak data. The variant 1 works on user/user attack and as well as user/kernel. As far I know there are no automated tools to check for this. Thanks Rudolf Dne 18.2.2018 v 12:48 Mike Banon napsal(a): > Maybe its' a good idea to write to AMD support regarding this question > - please share a reply if you would get an answer. I'm curious about > other fam15 CPUs as well, e.g. A10-5750M microcode update would be > nice, maybe a request could be more general, e.g. : what is the > estimated release date for the microcode updates for fam15 AMD CPUs > (so a request is not about "opterons only") > > On Sun, Feb 18, 2018 at 2:47 PM, Mike Banon <mikebdp2(a)gmail.com> wrote: >> Maybe its' a good idea to write to AMD support regarding this question >> - please share a reply if you would get an answer. I'm curious about >> other fam15 CPUs as well, e.g. A10-5750M microcode update would be >> nice, maybe a request could be more general, e.g. : what is the >> estimated release date for the microcode updates for fam15 AMD CPUs >> (so a request is not about "opterons only") >> >> On Sun, Feb 18, 2018 at 4:30 AM, Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: >>> They said they would be releasing opteron microcode updates in a few weeks >>> but it has been over a month and I am wondering when this is going to happen >>> or if it already has and I should re-compile coreboot? >>> >>> https://www.amd.com/en/corporate/speculative-execution >>> "We expect to make updates available for our previous generation products >>> over the coming weeks." >>> >>> Thanks! >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >

2 years, 9 months

Re: [coreboot] Out of MTRRs

by Jay Talbott

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.

2 years, 9 months

Assigning PCI resources clobbers console with io-mapped / memory-mapped UART

by Jay Talbott

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 years, 9 months

OpenBMC/iKVM4 on KGPE-D16: bmc doesn't power up automatically on cold boot

by Ward Vandewege

I have a KGPE-D16 that runs coreboot as of commit 64294eb5e241afe9d93b37b31d8a6310ec8d9279, with the three BMC related patches from https://review.coreboot.org/#/c/coreboot/+/19820/1 applied on top. On cold boot (no power to the machine), the BMC doesn't power up automatically. The host starts without problem. I can make the BMC boot by reading out its rom with the patched version of flashrom linked from https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-status.php. I assume that is because flashrom resets the BMC cpu at the end of the read (the cpu=reset option). Is this a known issue? Thanks, Ward. -- Ward Vandewege GPG Key: 25F774AB Do you use free software? Donate to join the FSF and support freedom at http://www.fsf.org/register_form?referrer=859

2 years, 9 months

Re: [coreboot] shrdw question

by Nico Huber

On 29.03.2018 23:58, ron minnich wrote: > believe it or not that code runs on coreboot simulator, hardware, and qemu, What is `coreboot simulator`? > and gets a different answer on each. Same binary and same processor (e.g. 32-bit protected) mode? Without knowing what your assembler translated it to, anything seems possible. Nico

2 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2018