coreboot December 2021

coreboot@coreboot.org

45 participants
46 discussions

Open letter to Intel regarding the PSE on Elkhart Lake

by Zeh, Werner

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

1 month, 3 weeks

Question about compressed FIT payloads

by Krystian Hebel

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 months

ThinkPad T420 and FireWire chip on Linux

by Alesandar Metodiev

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

2 months, 3 weeks

Personal challenge | Ramp up on coreboot : Trials on aftermarket X58 motherboards.

by Master

Hello everyone, I hope you're doing fine I would like to do some trials to see if I may be able to support few boards I have cause they are aftermarket withoout EFI and without firmware updates and not working as I would like them to. (https://askubuntu.com/questions/1370496/cant-boot-latests-lives-for-install…) I really would not like to throw them... They are X58 chipset with ICH10 with Xeon Westmere on socket 1366 and SuperIO NCT5532D. (https://www.intel.com/content/dam/doc/datasheet/x58-express-chipset-datashe…) (https://www.intel.com/content/dam/doc/datasheet/io-controller-hub-10-family…) (https://datasheetspdf.com/pdf-file/1042365/novoTon/NCT5532D/1) I have the tooling to backup and restore the flash and already done that few time. I have built latest coreboot (4.14 using lenovo x201 config) with EDK2 firmware as payload (edk2-stable202108 NOOPT) successfully but nothing is happening after flash swap and power on. I have RS232 debug working at ttyS0 (at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A) From the original firmware, just after power on, even before any bip or display or keyboard light I see "Socket = 0" on serial, so the the original firmware is able to output to this serial very early. I read quite a lot of literature about coreboot, but still, I am not sure how to pursue now. Thanks in advance, Have a nice day, Best Regards, Mickaël.

4 months, 2 weeks

915G support

by Sid_key

Hello, is 915G supported? Is it hard to implement support for Gigabyte 8i915md-g? Which motherboard dt take as base to adapt for it?

5 months

Installing coreboot with SeaBIOS

by bernd1-1＠web.de

Hi. I go through this tutorial: https://doc.coreboot.org/tutorial/part1.html I'm on Step 5 - Configure the build > Check your configuration (optional step): I entered $ make savedefconfig $ cat defconfig I have changed my mind. Now I'd like to install SeaBIOS instead of coreinfo. What do I need to do? How do I change it? Regards, Bernd

5 months, 1 week

Git reports an interesting error message

by Gregg Levine

Hello! I just tried to synch my local tree with what's stored back there, and instead of watching it update I saw this one: fatal: unable to access 'https://review.coreboot.org/coreboot.git/': SSL certificate problem: certificate has expired Huh? Is everyone else aware of this? ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

5 months, 2 weeks

My Asus P2B-LS is still having fun with coreboot/SeaBIOS/flashrom. Now I have questions.

by Keith Hui

Previously on the resource allocator discussion, I was about to test Arthur's fix for PARALLEL_MP when all my boards suddenly failed to come up. I still refuse to let this legend die, so I managed to get it going again, and look what it did for me in return. First, I plugged the flash chip with vendor firmware to rule out hardware failure. Came up just fine. Excellent! Swapped in my coreboot chip and tried to flash my copy of coreboot (which is still carrying PARALLEL_MP and the fix. It worked!). flashrom knows it has the 440BX chipset but can't seem to convince itself it will work. See the attached log. I have to calmly tell it "laptop=this is not a laptop" and then it works as usual. I don't remember ever having to do this before. Why? If I have a clue I can code up and submit a patch. Back to how it failed to boot in the first place. The hard disk booting stalled after SeaBIOS. Took me hours but eventually I found a line in my serial log that there has been a DMA timeout. Turning UDMA off in devicetree.cb and flash again made it boot again. So I would have to revert 576315e1 (aka CB:40961), but I'm hesitant because that seemed like the reasonable thing to do and it should have worked. So I'm also unsure why it didn't. Thanks Keith

5 months, 3 weeks

"Private" changes on Gerrit are now disabled and removed

by Patrick Georgi

Hi everybody, it came to my attention that changes marked "private" on Gerrit are hidden in the UI but easily accessible through gitiles and with "git fetch". I don't think it matters for most cases, but since we advertised it as being accessible for the owner and individual reviewers, I didn't want to keep things exposed, especially not after there's an announcement that such access is possible (as through this email). Therefore I: - disabled the "private" CL feature in the Gerrit UI, so you can't mark changes as private - created per-account git bundles[1] of their private CLs. Since I don't want to spam a few hundred users with stuff they might not care about, this is a pull transaction: if you want them, reach out to me. - removed the private commits and references from the coreboot.git repo. You might still see the changes in the UI but that's due to its aggressive caching: The UI actually honors the private flag, so that's not a concern and all other means of accessing commits access the repo and will fail on these now-gone commits. https://review.coreboot.org/c/coreboot/+/59229 also proposes updating the docs to remove mentions of the "private change" feature. As an alternative we could also decide to re-enable the feature but with documentation pointing out that there are ways for motivated unauthenticated users to access these commits, which makes them more of a structuring feature (keep things out of sight until they're ready). In that case I could also reinstate the commits I deleted from the repo. Thoughts? Best regards, Patrick [1] https://git-scm.com/docs/git-bundle

6 months

Re: My Asus P2B-LS is still having fun with coreboot/SeaBIOS/flashrom. Now I have questions.

by Branden Waldner

Hi > I have to calmly tell it "laptop=this is not a laptop" and then it works as usual. I don't remember > ever having to do this before. Why? If I have a clue I can code up and submit a patch. If I recall correctly both my p2b and p2-99 boards do that while running vendor firmware, though I don't recall ever seeing it while running coreboot (which I just checked to verify it still doesn't show up). > Back to how it failed to boot in the first place. The hard disk booting stalled after SeaBIOS. Took > me hours but eventually I found a line in my serial log that there has been a DMA timeout. > Turning UDMA off in devicetree.cb and flash again made it boot again. So I would have to revert > 576315e1 (aka CB:40961), but I'm hesitant because that seemed like the reasonable thing to do > and it should have worked. So I'm also unsure why it didn't. I've had the occasional issue with my p2-99 in the past, but I've always got it booting again after reseating chips (flash/memory/cpu card). I guess I should be making sure to have the serial link set up more often, I normally only use it when I have a known bad version of coreboot flashed. I actually have the cable connected between the two boards right now, which seems to work decently for testing. Branden

6 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2021