coreboot February 2022

coreboot@coreboot.org

19 participants
43 discussions

[Proposal] Drop support for Ice lake [unmaintained]
by Tim Wawrzynczak 30 May '22

30 May '22

Good day folks, In a recent change[0], it was proposed that we drop support for the Intel Ice Lake platform. The only mainboard supporting the platform was the Intel RVP, but as far as anyone knows, it appears the project never progressed past the initial silicon, and so the code is now unmaintained and also unused. Since Ice Lake is very similar to TGL & ADL, it poses a maintenance burden when dealing with Intel common code e.g., anything in src/soc/intel/common. According to [1], this should be announced in upcoming release notes first, and removal could happen in 6 months. Wondering if anyone has any thoughts on why we should keep it around, otherwise let's update the upcoming release notes to give the "official" notice that it will be dropped. Cheers, - Tim [0]https://review.coreboot.org/c/coreboot/+/60053 [1]https://doc.coreboot.org/releases/templates.html

2 1

Open letter to Intel regarding the PSE on Elkhart Lake
by Zeh, Werner 09 May '22

09 May '22

Dear coreboot community. I guess the most of you have seen the tension that was introduced to the community once Intel started to enable the Programmable Service Engine on the new IOTG SoC called Elkhart Lake (for reference, please see [1]). One of the outcome of this difficulties was to ask Intel for open sourcing the PSE code in order to avoid a new blob being introduced to coreboot. I took this action item and reached out to Intel in this regard. As a result I have had two meetings with the responsible people at Intel and they started to look into this request. So as of now Intel is analyzing the code to understand what needs to be done to open source it. What has been mentioned by Intel to me is that up to now nobody else have ever requested this for the PSE. Furthermore Intel let me know that it would be easier to convince the management layer to spend work on open sourcing the code if there would be more people from different companies requesting the same. My first guess was: we can do this! Therefore I have drafted up an open letter which I would like share with all of you: https://openletter.earth/request-for-opening-the-source-code-for-the-pse-on- elkhart-lake-26bad82a The wording have now been reviewed for two days between different parties and I would like to keep it as it is in order to get it done in time. This is now the moment where you can raise your voice! Please have a look at the open letter and sign it if you agree with the terms and if you support this approach. The more people we get the higher are our chances to be visible as an open source community. And it would be really helpful if we could get this letter signed by companies, this will for sure increase the traction of this request. I will keep this letter in "signing" state until 2021-12-09 07:00 am German time. Once we are there I will hand it over to Intel. Thank you for your support in advance Werner [1] <https://review.coreboot.org/c/coreboot/+/55367> https://review.coreboot.org/c/coreboot/+/55367

4 6

Question about compressed FIT payloads
by Krystian Hebel 02 May '22

02 May '22

Hello coreboot community, For our work on POWER9 coreboot port we were using Skiboot [1] packed into FIT payload. While it worked fine, we wanted to provide users with easier way of testing it on hardware. I believe it may be possible to modify only one of PNOR (fancy name for flash given by POWER people) partitions. In order to do this, we would have to fit whole CBFS into 512k (actually 1M including ECC, but that would require non-power-of-2 size), which should be doable with LTO and compressed payload. According to [2], whole file compression is not available for FIT payloads. I understand that this makes sense, thanks to this we can decompress/load individual parts of payload (e.g. kernel and initramfs) once, otherwise we would have to decompress it to read metadata first and then move code around in memory. However, FIT format doesn't hold information about uncompressed sizes of its components, required by decompressing functions in coreboot. Instead, their compressed sizes [3] are used to initialize output region sizes [4] and those are then passed to decompressors [5]. Only FDT has a workaround to this problem [6], and kernel's size is calculated in an arm64-specific way in [7]. On other architectures components (other than FDT) are partially decompressed until they run of of space, silently ignoring the rest. What should be "the proper way" of getting uncompressed size? I can think of the following options, listed in no particular order: 1. Extend hack used for FDT to other components, use it for all compressed parts. Arbitrary size multiplier may either waste some space potentially overlapping other component's memory range or not be enough in edge cases (e.g. mostly zeroed file). 2. For LZMA you may get decompressed size from the header, unfortunately this is not possible with LZ4. 3. Dry decompression just to check proper size - sounds too costly. 4. New properties for components' nodes in ITS file. May need changes in mkimage, haven't looked yet. Preferably shouldn't have to be manually written to ITS as that would be prone to error. While playing with mkimage, may add automatic compression, right now it expects already compressed files in ITS, although this can also be scripted. 5. Add more arch- and payload-specific parsing of images, as was done for arm64. This may require some kind of mark that a payload needs special handling (new CBFS attribute maybe?) 6. Enable whole file compression of FIT payloads, which results in juggling in RAM. 7. Mix of the above. For our current issue we can also load Skiboot from another PNOR partition (from where it is normally loaded by Hostboot [8] which we are basically substituting with coreboot) and manually create FDT for it. This would however break normal coreboot boot flow and we would like to avoid that. [1] https://github.com/open-power/skiboot [2] https://doc.coreboot.org/lib/payloads/fit.html#supported-compression [3] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [4] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [5] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [6] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [7] https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/sr… [8] https://github.com/open-power/hostboot -- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com

2 5

ThinkPad T420 and FireWire chip on Linux
by Alesandar Metodiev 09 Apr '22

09 Apr '22

Hello, Recently I have decided to give a try to coreboot for first time and flashed my ThinkPad T420, but a few weeks ago I have swapped the USB controller on the back, next to the battery, with a FireWire/USB controller (40GAB5809-G200) from another T420. Nothing special, since some models have been shipped like this. The controller is no longer accessible on my laptop. It seems like it may have been detected as an "SD Host Controller" or not detected at all. I will probably have to remove the chip and compare the output of lspci and lshw. If nothing has changed, I will probably have to return the stock BIOS and compare the results again. I have also tried to load some of the firewire kernel modules manually with modprobe. The operating systems I have tested so far are Arch Linux and Xubuntu. I am willing to provide more useful information, boot into a fresh Windows install, flash the chip again or whatever else. Correct me if I am wrong, but if I go back to the stock BIOS, the next time I flash, I will have to disassemble the laptop again and otherwise I must be fine with flashing internally, right? Thanks

6 28

Memtest 86+ fork
by Sameeruddin Shaik 03 Apr '22

03 Apr '22

Hi all, I wanted to work on below ticket https://ticket.coreboot.org/issues/184 Is there anyone working on it. Any inputs/hints would be appreciated. --sameer.

3 2

[GSoC 2022] Interested in Contributing to coreboot.
by Ahamed Husni 12 Mar '22

12 Mar '22

Dear All, I am hoping to apply for the GSoC 2022 program. I am really interested in contributing to the coreboot project as I love to work with low level development. I completed the pre-requisites mentioned in the documentation. I built a 32-bit EFI binary in the gnu-efi environment. I used U-Boot as the payload for coreboot to test this EFI binary. The target is x86_64(QEMU). Serial output: https://gist.github.com/drac98/6166d29f6c3a2baf2f4e791925ea98d3 I sent a patch for review about a year ago related to adding heap-out-of-bound detection support to AddressSanitizer port. If this is not acceptable as my first patch for review, please let me know. I can fix some coding styles or do a simple task given by the community. PATCH: https://review.coreboot.org/c/coreboot/+/51787 I find the "*Add U-BOOT's UEFI payload as a coreboot payload*" project mentioned in the coreboot project collection interesting to me. I have no prior experience with UEFI. As a starting point I learned to build and run an EFI binary with coreboot using the U-Boot payload. Please let me know what I should do next to learn and prepare for this project. Thanks & Best regards, Husni.

2 5

New on blogs.coreboot.org: Announcing coreboot 4.16
by blogs.coreboot.org 26 Feb '22

26 Feb '22

1 0

Certificate expired
by Galarazamba 26 Feb '22

26 Feb '22

Dear Coreboot Team, I am trying to build a Heads x230-maximized.rom on Debian 10.4.0, but right at the beginning I get the error, that the certificate of www.coreboot.org cannot be trusted because it has expired. Updating my ca-certificates in Debian hasn't helped. Do you have any further ideas? Thanks in advance for your help, keep up your awesome work!

3 2

Where is the ECC 2017 DDR3 RAM init presentation slides now?
by Keith Hui 25 Feb '22

25 Feb '22

Hi coreboot, We had this presentation on native DDR3 RAM init on Sandy Bridge: https://www.youtube.com/watch?v=h-Lkkg03Erk&t=1510s I was thinking it could help as I try to (foolishly?) redo native RAM init on AMD family 10h CPUs, but the audio is unclear and the link to the slides is dead. Now all I have to go by are the actual sandybridge and (outdated) amdfam10 sources, plus the JEDEC DDR3 standard. Does anyone have the transcript and slides for this presentation? Thanks Keith

2 1

2022-02-23 - coreboot Leadership Meeting Minutes
by coreboot org 23 Feb '22

23 Feb '22

# 2022-02-23 - coreboot Leadership Meeting Minutes ## Attendees: Felix Singer, Jay Talbott, Werner Zeh, Martin Roth, Ron Minnich, Eric Peers, Piotr Krol, Felix Held, Jason Glenesk, Subrata Banik, David Hendricks, Marshall, Sheng, Tim C. ## Key Decisions: * coreboot would like to apply for Google Season of docs, but needs someone to run the project. * The documentation menu is being reworked. * No decision made at this time about CB:62013. It would be nice to make it easier to support chips building from outside of the existing codebase, but that encourages not pushing those changes back to coreboot. If/When we do make this easier to support, please don't use weak externs. ## Minutes: * [FelixS] [Season of Docs 2022](https://opensource.googleblog.com/2022/02/Announcing%20Season%20of%20… application phase starts on 23.02. * Martin will ask around to see who would be interested in running this for coreboot. TimW expressed interest in it last year, so we can start with him. * [Jay] Support for 1st/2nd gen Xeon-SP (Sky Lake / Cascade Lake) on OCP Tioga Pass. * Facebook & Intel had put together a POC for 1st Gen, and showed it at a couple of events. FSP was hacked together and was not going to be published. coreboot code is present and is ongoing for future platforms. SysPro was hired by ITRenew to port the Gen3 code back to gen 1 & 2. ITRenew was just bought out by Iron Mountain, and that line has been scrapped. Funding has been lost, so SysPro will be shelving this until someone else funds it. Creating the FSP under agreement with Intel, which will also not be going forward. * David - Tides may turn again. That had been ITRenew’s model and they found that reselling the servers for use can earn a lot more $$$ then selling discrete parts. Maybe the parts shortage changed this... * Send to mailing list. Check with OCP to see if anyone there is interested in finishing the project. * Can’t really hand off the project to anyone else easily - FSP is under contract between Intel & SysPro. But coreboot can be developed by anyone. * [Subrata] Like to discuss about [CB:62013](https://review.coreboot.org/c/coreboot/+/62013) ( a problem highlighted by Intel for early SoC development using downstream coreboot, will share more lights if get chance to talk during meeting) * Having the device IDs in common code causes rebase issues when developing a new SOC internally before the information can be released. * The patch may help intel development, but this also allows the vendors to avoid downstreaming the code. * [David] this is definitely a common problem in development. * [FelixH] Unless there’s a definite technical reason, it’d be preferable to keep it in the common code. It’s not too difficult to keep the patches in sync by rebase every once in a while. * [Werner] Let’s try to point to a better way of doing open sourcing. * [David] How do we get vendors like Intel & AMD get to a state where they can more easily push code upstream before their platform is released? Is there a model to reduce needed diffs to common code when a new product goes upstream? * [Marshall] Is the problem that this is solving an embargo problem? Is it that companies would keep code internal forever and not publish it to the coreboot codebase? * [Subrata] Not really an embargo issue, though David’s point is valid. * In the patch train, there’s a comment that talks about the early development problem. * For meteor lake, intel copied the current code a while back, and branched it off into a separate SOC. This makes rebasing issues difficult. * To make this easier, moving things to the SOC code out of the common code. * Keeping the device ids in common code pollutes the namespace and causes code to have to loop through all of the device IDs. * Weak externs cause a lot of issues because you can’t easily tell where the code is coming from. * [MartinR] 4.16 release is coming along - should be done today or tomorrow. * [Felix S] Reworking the menu of doc.coreboot.org. More patches will follow [https://review.coreboot.org/c/coreboot/+/62219](https://review.coreboot.org… * [Martinr] Coverity builds have been having issues. When the Go code was added to the coreboot build, that messed up the analysis for a while. We got that fixed at the beginning of february, but coverity updated their toolchain, and things are getting stuck again. Martin is working on getting this going again. * [MartinR] Adding a tool to jenkins to scan the codebase for broken links. * Lots of broken links found, especially in the wiki. * [Subrata] Requested help a couple of weeks ago to drop APIs from FSP. 2 already done, and still more are planning for removal. Thanks! # Notice Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2022