November 2020 - coreboot - mail.coreboot.org

Termin mit Notiz abgesagt: coreboot Leadership Meeting - Mi 2. Dez. 2020 19:00 - 20:00 (MEZ) (coreboot@coreboot.org)
by Patrick Georgi Nov. 18, 2020

Nov. 18, 2020

Dieser Termin wurde mit der folgenden Notiz abgesagt: "It's OSFC!" Titel: coreboot Leadership Meeting Meeting Minutes - If you don't have edit access and want it, please ask Patrick G. Wann: Mi 2. Dez. 2020 19:00 – 20:00 Mitteleuropäische Zeit - Berlin Teilnahmeinformationen: Teilnehmen mit: Google Meet https://meet.google.com/syn-toap-agu Per Telefon teilnehmen (US) +1 347-554-5113 (PIN: 858153) Weitere Telefonnummern: https://tel.meet/syn-toap-agu?pin=5345676483196&hs=0 Kalender: coreboot(a)coreboot.org Wer * Patrick Georgi - Organisator * Martin Roth- Veranstalter, Optional * WIM * Dossym Nurmukhanov * christian.walter(a)9elements.com * marshalldawson3rd(a)gmail.com * Stefan Reinauer * jeremy(a)system76.com * Marc Jones * Werner Zeh * David Hendricks * zaolin.daisuki(a)googlemail.com * quasisec(a)google.com * epeers(a)google.com * felix.held(a)amd.corp-partner.google.com * gduynisveld(a)eltan.com * Held, Felix * coreboot(a)coreboot.org * subrata.banik(a)intel.com - Optional * patrick.rudolph(a)9elements.com - Optional * matt.devillier(a)gmail.com - Optional * Ron Minnich - Optional * deb(a)sfconservancy.org - Optional * jaytalbott(a)sysproconsulting.com - Optional * jonzhang(a)fb.com - Optional * Furquan Shaikh - Optional * kerry.brown(a)silverbackltd.com - Optional * Julius Werner - Optional * felix-coreboot(a)felixheld.de - Optional * nico.h(a)gmx.de - Optional * felix(a)felixheld.de - Optional * ed.benyukhis(a)amd.com - Optional * arthur(a)aheymans.xyz - Optional Einladung von Google Kalender: https://calendar.google.com/calendar/ Sie erhalten diese E-Mail unter coreboot(a)coreboot.org, da Sie ein Gast bei diesem Termin sind. Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem Termin zu erhalten. Sie können auch unter https://calendar.google.com/calendar/ ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen für Ihren gesamten Kalender steuern. Wenn Sie diese Einladung weiterleiten, kann jeder Empfänger eine Antwort an den Organisator senden und zur Gästeliste hinzugefügt werden. Außerdem könnte er weitere Nutzer einladen und Ihre Antwort ändern. Weitere Informationen: https://support.google.com/calendar/answer/37135#forwarding

1 0

Re: System gcc requirements
by Branden Waldner Nov. 17, 2020

Nov. 17, 2020

Well, this seems to be really going off topic. My only intention was to ask what the required/recommended host(system) compiler was and what documentation there was for that. Branden Waldner wrote: > Is there an expected minimal system gcc version and if so, is it > documented? I couldn't find it noted anywhere. Nico Huber Wrote: > I don't think it's documented. As you already noticed, we depend on a 3rdparty library (vboot), > so we actually don't know the minimum. I think it would be nice to document the expected compatible version(s), especially if it can done in a version/release relevant way. Trying to build "old" projects without any build system documentation can get pretty frustrating for example. Julius Werner wrote: > So I think the "official" rule is basically that the minimum requirement for host utilities is the > same compiler and version that crossgcc uses, which I think makes some amount of sense > (otherwise we'll just have to keep tracking and deploying two separate versions). It's kind of hard to say it's a rule when it's not written anywhere. Also, while it sounds okay in theory to _require_ and test against a specific version of gcc, that ends up leading to some practicality issues in potentially needing to build a specific version of gcc on the host if it's not packaged, followed by the usual crossgcc build. Though in my situation, updating from Debian Stretch to Buster would likely fix the problem for now (and be significantly faster then compiling gcc as well (I would also likely already have most of the packages cached locally)). Following up on that, if Jenkins only tests using the same version of gcc as the current coreboot crossgcc, doesn't that leave out testing potential compatibility problems with newer (or older) versions of gcc (or clang?) that could be automatically tested for and identified as early as possible? Of course, that could end up with orders of magnitude more work for the build bot to do, which could end up being impractical. Julius Werner wrote: > FWIW I do seem to recall that this already came up back when __attribute__((fallthrough)) was > added to vboot, and back then everyone seemed to agree that it was reasonable to assume the > same version for the host compiler that we use in crossgcc. I would consider "assuming" the same host compiler as crossgcc to be a bug, since a coded check can do a lot better then that, with the the required maintenance of only being changed (automatically?) when crossgcc is updated. I don't recall when I first noticed the problem, but I "assumed" it was a regression that would be fixed, not that my system no longer had a new enough version of gcc. It was also confusing why vboot was being pulled in even though I didn't have it selected. While it sounds simple enough that cbfstool builds in crypto/hash support from vboot, it also doesn't really seem that big a deal to expect it to be able to option it out either. Of course there is some extra maintenance involved in that, but with cbfs being a stable for quite a while (according to recent posts at least), there shouldn't be too many changes? That is not necessarily tied in to the host gcc problem though - I realize that I need a newer version and didn't specifically complain about it, other then it being for rather trivial reasons. Also, an interesting reference for the required build environment is the linux kernel of course: https://www.kernel.org/doc/html/latest/process/changes.html (that url seems weird, but the page title is "Minimal requirements to compile the Kernel"). That likely requires some automated testing to verify and also probably ends up with a lot of work to maintain, but at least it's there. I hope I at least managed to add something of value to the conversation, though some of it just seems like me complaining... Branden Walder

1 0

Planning the next coreboot release
by Angel Pons Nov. 17, 2020

Nov. 17, 2020

Hi everybody, It's high time we looked into cutting yet another release. As usual, other than our 6-monthly cadence of incrementing a number on our tree and pushing out tarballs and press releases, no particular rationale prompts this event. Unlike previous occasions, this is my first time executing the coreboot release process along with Patrick Georgi. We plan to do the release on Wednesday, November 18. This announcement is in conformity with the process described on https://doc.coreboot.org/releases/checklist.html, as we're currently at the "~2 weeks prior to release" point. For this reason, I would earnestly appreciate it if you (everyone subscribed to this list, but given that you're reading this mail, yes, you too!) could help out with the following: 1. Testing: the more, the better. Please test as much of your coreboot-supported hardware as you can, report and/or address any issues, and upload fresh reports to the board-status repo. Despite having no quality requirement to give a new number to our tree (create a new release), it is important to ensure what we have in the tree is still functional, since it lowers the work needed to pin-point new issues (bisections since 4.12 should still take 12 steps or less at this time, even though there's about 40% more commits than between the last two releases). 2. Please try to postpone riskier changes and similar until the release is done (unless they're ready to land in the next few days), in order to keep the tree stable while people test whether their hardware still works as expected. If a major feature doesn't make it into this release, don't worry; it can always be part of the following release. Let's make sure this coreboot release keeps booting. 3. Please take a look at the preliminary release notes in Documentation/releases/coreboot-4.13-relnotes.md and add whatever happened since 4.12 that is worth mentioning. If unsure, simply push a change to Gerrit and have your fellow developers discuss it. Thanks, Angel Pons

1 2

Coreboot Picasso FSP questions
by chen.kenyy＠inventec.com Nov. 16, 2020

Nov. 16, 2020

Hi, I study in AMD AGESA v9 boot in the coreboot. So far, I boot to the FSP image failed as below log. CBFS: Locating 'fspm.bin' CBFS: 'fspm.bin' not found. FSPM not available or failed to load! And I google the related information, found the gerrit review information(https://review.coreboot.org/c/coreboot/+/34423/), I want to query you how to make/create the FSP binary for AMD or FSP information to coreboot image. Could you give me some instructions? Thanks.

3 2

Information about "HP-Compaq 8200 Elite SFF"
by dac9＠emailportal.ch Nov. 15, 2020

Nov. 15, 2020

Hi guys Thanks a lot for the great work on coreboot. I'm looking for install coreboot on my "HP-Compaq 8200 Elite SFF", so I was happy to found your site: https://doc.coreboot.org/mainboard/hp/compaq_8200_sff.html In this documentation stands: "Internal programming: The SPI flash can be accessed using flashrom.". So I tried to read the factory-BIOS with flashrom but without success. Please consult the annexed log-file. Could you please explain-me why reading with the internal-programmer doesn't work for me? Thanks in advance Best regards Dario

2 1

Including a video BIOS
by Andy Pont Nov. 11, 2020

Nov. 11, 2020

Hello, Using the instructions in the old Wiki page [1] I have used the UEFI method and UEFI tool to extract the video BIOS from the standard binary that comes with the board. I have followed the layout of some of the other Kconfig files in the mainboard directory and added the following to my boards Kconfig: config BOARD_SPECIFIC_OPTIONS ... select VGA_BIOS ... config VGA_BIOS_ID string default "8086,0406" config VGA_BIOS_FILE string default "pci8086,0406.rom" When I try to build with that I get an error: make: *** No rule to make target 'pci8086,0406.rom', needed by 'build/coreboot.pre'. Stop. The other mainboards that use this methodology all seem to have “select GFX_GMA_PANEL_1_ON_LVDS” but as my display is connected directly to the eDP port I added “select GFX_GMA_PANEL_1_ON_EDP”. This in turn appears to need “select GFX_GMA”. Now when I try to build I get: warning: (BOARD_SPECIFIC_OPTIONS) selects GFX_GMA which has unmet direct dependencies ((NORTHBRIDGE_INTEL_GM45 || NORTHBRIDGE_INTEL_X4X || NORTHBRIDGE_INTEL_IRONLAKE || NORTHBRIDGE_INTEL_SANDYBRIDGE || NORTHBRIDGE_INTEL_HASWELL || SOC_INTEL_BROADWELL || SOC_INTEL_SKYLAKE || SOC_INTEL_APOLLOLAKE || SOC_INTEL_KABYLAKE || SOC_INTEL_COFFEELAKE || SOC_INTEL_WHISKEYLAKE) && (MAINBOARD_USE_LIBGFXINIT || INTEL_GMA_LIBGFXINIT_EDID)) The board I am working with uses Comet Lake so I have "select SOC_INTEL_COMETLAKE” in the board specific options. Am I going about this the wrong way or does the depends on list for GFX_GMA in src/drivers/intel/gma/Kconfig need SOC_INTEL_COMETLAKE adding to the list? -Andy. [1] - https://www.coreboot.org/VGA_support

4 8

ALC256 datasheet
by Andy Pont Nov. 11, 2020

Nov. 11, 2020

Hello all, A bit of a long shot… does anyone have a datasheet for the ALC256 HDA audio CODEC? I know that the device exists as I have some boards with it on (that I am working on a Coreboot port for) on my desk but a look on the Realtek website doesn’t yield anything. Thanks, -Andy.

3 3

Flashing coreboot and Intel Flash Descriptor Erase Issue
by Balaji Sivakumar Nov. 11, 2020

Nov. 11, 2020

Hello Everyone, We are using SPI flash(Macronix) to program the BIOS. And we use an external programmer to flash the BIOS (coreboot including FD+ME) into SPI Flash (16384 kB, SPI), it works fine and boots well. The board is functional and we have successfully booted a kernel on it. Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well. But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location. As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails. Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor? Any pointers would be appreciated. Thanks Balaji

2 7

Deprecating spurious PCI bus master enabling (was Re: Planning the next coreboot release)
by Nico Huber Nov. 10, 2020

Nov. 10, 2020

Hi, On 04.11.20 23:21, Angel Pons wrote: > 3. Please take a look at the preliminary release notes in > Documentation/releases/coreboot-4.13-relnotes.md and add whatever > happened since 4.12 that is worth mentioning. If unsure, simply push a > change to Gerrit and have your fellow developers discuss it. I have a candidate for a deprecation warning: We're currently working to make all not (clearly) necessary PCI bus master enabling optional. The added Kconfig option still defaults to `y` [1], for compatibility reasons. This has security implications and hence I propose to proceed as follows: After the follow-up (spring) release, * remove the option and the code using it, or at least * reduce its usage to a minimum and change the default to `n`. This should give people enough time to test (with the option disabled) and potentially fix their payloads (and OS?). If there are no concerns, I'll add that to the release notes. There are cases where enabling PCI bus mastering already in coreboot might be necessary. For instance, Intel documents for their integrated graphics to enable it before the initialization sequence (without tel- ling us why and tests show that it ignores the bit anyway *shrug*). And also cases where it's clearly necessary, e.g. before hiding a PCI devices configuration space to put it into ACPI mode (if the OS is not aware of the device' PCI nature, it can't know that bus mastering needs to be enabled). If anybody knows or discovers more cases where it needs to be enabled in advance by coreboot, please mention it here. Nico [1] https://review.coreboot.org/c/coreboot/+/42459

5 5

Flashing coreboot and Intel Flash Descriptor Erase Issue
by Balaji Sivakumar Nov. 10, 2020

Nov. 10, 2020

We are using SPI flash(Macronix) to program the BIOS. And we use an external programmer to flash the BIOS (coreboot including FD+ME) into SPI Flash (16384 kB, SPI), it works fine and boots well. The board is functional and we have successfully booted a kernel on it. Am working on adding a feature to upgrading the BIOS (complete IFD+ME+Coreboot) using intel-spi driver at the OS level. Able to successfully take the backup full 16MB spi nor flash data which includes IFD+ME+BIOS using flashrom Internal Programmer option and it is identified as Opaque flash chip and using dd command as well. But we are seeing the erase fail through both flashrom and flash_erase utility. I believe it fails to erase at the flash descriptor location. As far as Read/Write access to the SPI regions, I have enabled the Host CPU BIOS write access and ME Master Access as 0xFFFF through Intel FIT Tool but still not able to erase it and it fails. Is there anything that could be preventing to enable read/write access to the Intel flash descriptor or any SOC SPI controller protection to access the Flash descriptor? -- Thanks, Balaji

4 10