March 2022 - coreboot - mail.coreboot.org

[Proposal] Drop support for Ice lake [unmaintained]
by Tim Wawrzynczak May 30, 2022

May 30, 2022

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 May 10, 2022

May 10, 2022

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 May 2, 2022

May 2, 2022

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

Deprecation of the Intel Quark SoC
by Felix Singer April 24, 2022

April 24, 2022

Hi all, to me it seems like the Intel Quark SoC has been unmaintained and unused for a long time now. So I'm proposing to deprecate the support for it with coreboot release 4.17 [1], in order to drop the support with release 4.19 so that the community has less maintenance overhead. Does anyone use this platform? Any opinions against this? // Felix [1] https://review.coreboot.org/c/coreboot/+/63283

15 55

2022-03-29 - coreboot UEFI working group meeting minutes
by coreboot org April 23, 2022

April 23, 2022

# 2022-03-29 - coreboot UEFI working group Next meeting: 2022-04-26 ## Attendees: Jay, Werner, Martin, Sheng, Ron, David ## Minutes: * In the coreboot meeting last week, we discussed a proposal from Intel to change the handoff mechanism to payloads [1]. After that discussion, the decision was made to move further discussion of that topic over to the UEFI working group meeting. There was another meeting on Monday, March 28th where we got a much better understanding of what’s going on and the reasons behind the proposal. * Intel wants to look at modifying the payload handoff as a part of their universal-scalable-firmware [2] initiative. * The current payload handoff method has a number of flaws that they’d like to fix, such as the address for stack being hardcoded. * This likely also gives coreboot an opportunity to address other parts of the USF spec that cause issues or incompatibilities for us. * The coreboot project got involved when Sheng suggested to Intel that it would be good to align the payload-handoff format with other projects such as coreboot. * Thanks Sheng! * Using CBOR is the current proposal, but Intel was open to discussing different formats than CBOR if anyone has a better suggestion. * If anyone is not familiar with CBOR, you can get more information at cbor.io [3]. * In the coreboot meeting, it was suggested that we push to just use coreboot tables as they’re already supported in a number of payloads. This really isn’t practical however. Intel would need to be able to modify the list of known cbmem IDs and they would need to be able to change the description format to something that’s more self-describing. * The coreboot project can, however, encapsulate a CBOR-based handoff-structure into cbmem, similar to what we currently do with ACPI tables. * Additionally Intel was willing to look at using CBOR structures as input and output to the FSP, so we could get rid of both the UPDs & HOBs. * The coreboot community can help to drive this, and Intel has said that they will send an email to the coreboot mailing list. * Since this is a part of the Universal-Scalable-Firmware initiative, it would be good to look that over for issues as well. Currently, it’s very Intel oriented, and specifies that the FSP will be used as the silicon initialization layer, which obviously doesn’t work for non-x86 platforms. * The details for the weekly meeting are below. * Self Describing Blob discussion. A copy of this meeting has been added to the coreboot calendar [4]. Biweekly on Monday, 4:00 – 5:00pm CET/CEST Berlin (Currently UTC+2) Video call link: https://meet.google.com/gha-shza-wnw Or dial: ‪(DE) +49 30 300195187‬ PIN: ‪848 847 031‬# More phone numbers: https://tel.meet/gha-shza-wnw?pin=2380921555764 Self Describing Blob discussion Meeting minutes [5]. * Sean Rhodes from StarLabs has worked to get all of the coreboot related EDK2 patches submitted to their repo. These are still currently in review. [1]: https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK… [2]: https://universalscalablefirmware.github.io/documentation/ [3]: https://cbor.io/ [4]: https://calendar.google.com/event?action=TEMPLATE&tmeid=NHVvZDRuYXZ2bjdtZTJ… [5]: https://docs.google.com/document/d/1IDQqr4cv8dQHa9faSxBc29xHSeKuXNTiMP3a3bL…

6 13

[coreboot][GSoC] idea for a proposal project porting to a Thinkpad AMD Ryzen 3rd gen machine
by Lahfa Samy April 10, 2022

April 10, 2022

Hi all Coreboot folks, I'm a first year graduate student in CS, been hanging around on #coreboot IRC (Libera.Chat server) and was thinking if it was possible or not to port Coreboot to a Thinkpad T495 (AMD Ryzen 7 3700U PRO) [1] manufactured in May 2019, I successfully dumped the BIOS using flashrom internally, see `flashrom_info.log` and 'flashrom_info.err.log`. It is unclear if there is any AMD protection that does the same as Intel BootGuard on Ryzen 3rd gen (there is for sure this [2] since the 1st gen of Ryzen which is the equivalent to Intel Management Engine). AMD has a whitepaper stating that from Ryzen 5000s mobile generation [3], AMD PSB (Platform Secure Boot) is activated, and it looks like kind of the same as Intel BootGuard if I'm not mistaken here. I know so far that the BIOS SPI chip is operating at 1.8v, and is a Winbond flash chip "W25Q128.W" (16384 kB, SPI), will be useful in case I need to externally flash the SPI ROM to unbrick the laptop. I still have to : - Test whether there is a protection that checks if the firmware was changed or not by patching the original bios ROM, I was told for this to change a copyright string or changing the logo : - it is a gif file and has a sha2-256 signature in its properties, which isn't the sha256sum of the file. - I've attached the `identify -verbose logo.gif` output) and trying to boot could allow checking for any tamper protection on the ROM flash (bricking intentionally the device if there is). - Understand if the EC RAM is something I can make out of or not (so far there is a lot of FF and 00 in it, the last line shows the version of the embedded firmware), so far I'm not too sure I can make sense of it right now. - Get the model of the EC and try to find datasheets online. I have at my disposal: - A kind of cheap 16 channel logic analyzer [4] with a software available on Linux/Windows with a few decoders for most known serial protocols such as SMBUS, I2C, SPI and more. - Raspberry Pi 3 model B+ (will be used as an external programmer, but I still need to find out how I could pull down the power to 1.8v since the VCC is 3.3v). - SOIC clip 8 pins (will be delivered to me in 2 weeks), I took the best one from this guide [5]. - A cheap multimeter with basic probes, capable of continuity test. And possibly more such as FPGAs by going to hackerspaces in my vicinity. I have built Coreboot for qemu with the Seabios payload as the documentation for GSoC recommended, see coreboot-serial.log output attached as a text file. In the case where there is indeed a protection, maybe a solution could be found by using a flash emulator (spispy ?) [6] but I need more details on this. I am also aware that a complete port will not be feasible under the time period of GSoC hence I need to know what should be the basics that needs to be covered for a Coreboot port to be considered minimally working first ? USB should work ? Charging is made using a USB-C port, this might be partly handled by the EC Embedded Controller. Finally, if nothing could be done on this Thinkpad because it is too recent, I also have an older Intel Thinkpad a T450, that has Intel BootGuard but that I'm looking try to port Coreboot to it too, using a flash emulator and possibly this attack [7]. Thanks for the time taken to read this lengthy mail, I hope the goal of this mail is clear. Kind regards, Lahfa Samy Links: ------ [1] https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_T495/ThinkPad_T4… [2] https://en.wikipedia.org/wiki/AMD_Platform_Security_Processor [3] https://www.amd.com/system/files/documents/amd-security-white-paper.pdf [4] https://sigrok.org/wiki/Kingst_LA2016 [5] http://dangerousprototypes.com/docs/Flashing_a_BIOS_chip_with_Bus_Pirate [6] https://github.com/osresearch/spispy [7] https://trmm.net/Sleep_attack/

2 2

ThinkPad T420 and FireWire chip on Linux
by Alesandar Metodiev April 9, 2022

April 9, 2022

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

[GSoC] Console via SMBus
by Ahamed Husni April 5, 2022

April 5, 2022

Hi everyone, I would like to work with bringing up the Console via SMBus project [1]. This project requires a mainboard with pluggable RAM for the development so that we can use a RAM breakout board [2] to access the SMBus interface. Preferably the mainboard should already support coreboot. Please add your thoughts and concerns about the project and suggest a mainboard for the project :) [1] https://www.coreboot.org/Project_Ideas#console_via_SMBus [2] https://www.joom.com/en/products/5fa9df2ea1684001068ec310 Thank you, Husni.

2 2

Memtest 86+ fork
by Sameeruddin Shaik April 3, 2022

April 3, 2022

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

Support to Openpower platforms
by ratatouille gamer April 1, 2022

April 1, 2022

the openpower have created this new firmware for boot openpower platforms is possible to coreboot use this base to write a new code for best support in openpower socs? https://github.com/open-power/hostboot

4 3