coreboot December 2021

coreboot@coreboot.org

45 participants
46 discussions

Support status ASUS P8C WS & Supermicro X9SAE
by Stéphane Delaunay 06 Dec '21

06 Dec '21

Hi everyone, I'm looking at the board list again currently for a Home-NAS/Nextcloud build that supports both ECC RAM and has multiple SATA3 ports. Since the system will be connected to the outside permanently, I also want to reduce obscure remote management firmware as much as feasible. I've found these two workstation boards: ASUS P8C WS (https://doc.coreboot.org/mainboard/asus/p8c_ws.html) Supermicro X9SAE (https://doc.coreboot.org/mainboard/supermicro/x9sae.html) They both fit the bill pretty well, apparently ECC is supported and Ivy Bridge means the ME could be cleaned mostly without needing any other blobs. However, I've found NOTHING on the support status for these boards. The old page says P8C-WS support is "Unknown" and the Supermicro board is not even listed. The mail archive also finds nothing on them. The ASUS' doc-page states that it's actually written for the "ASUS P8H77-V" model at the top. Yet, both debug descriptions seem well-written and trustworthy... Has anybody ever really used those boards and can confirm if they work at all, before I try to go out and buy one of them? I can't find any info on who ported or tested them. Are they included in the automatic config device-list? Kind regards!

1 0

Add memory support for mb/apple: MacBook Air 5,2 (A1466)
by Mariusz Grabarczyk 06 Dec '21

06 Dec '21

Hi I would like to have memory support added for mb/apple: MacBook Air 5,2 (A1466) Per https://review.coreboot.org/c/coreboot/+/32604/36/Documentation/mainboard/a… Originally https://review.coreboot.org/c/coreboot/+/32604 If your RAM configuration is not supported, you can help supporting it. Run `sudo inteltool -m`, save output to a text file and send a message to coreboot inteltool -g | get_macbook_ramcfg -m mba52 unsupported memory configuration 1 inteltool -m >> macbook52_memory Attached is dump file

3 3

How to maintain AGESA-based ports long-term?
by Nico Huber 05 Dec '21

05 Dec '21

Hi coreboot folks, there have always been platforms in the coreboot tree that are easy to maintain and others, alas, that seem to be the complete opposite. When new features or new iterations of existing code are pushed, we'd love to keep everything up-to-date. But this is infeasible. Given the vast amount of platforms in-tree, including poorly written ones with inex- plicable code, it's simply not possible to demand this from any single developer or entity. Hence, what usually happens is that at first only the easy-to-maintain platforms are updated. This pattern usually works for some time, but at some point it looks like coreboot has been forked within its own tree, making further maintenance too hard. So we drop old code paths and the platforms relying on them from time to time. It seems to me that AGESA-based ports are always on the brink of being dropped. I can't say for sure why that is, neither do I want to pretend to know how to avoid it. However, I'm convinced that they are among the hard to maintain ports that drag the project down. And I have no doubt that we'd have to squabble less about them if somebody would actively take care of the code. I can't say that I'd be of much help and I don't really care about the code. But it seemed to me that other people do care and need a little nudge to get a discussion going. I'll list some thoughts what could be done. Feel free to agree to or dismiss any of it. Some things are mutually exclusive, others are not. Branching --------- I know some people are easily offended by the thought, but I want to mention it anyway as it seems to me like a cheap solution for the com- munity as a whole. We could maintain platforms on separate branches. Keeping things working shouldn't be much effort. At least, I guess the following would be necessary: * Keep the toolchain up-to-date and the code compatible. * Keep the payload hook-ups up-to-date and test them from time to time. Naturally, this is less effort on a branch that is dedicated to specific platforms, i.e. does not keep all the other things in the tree like we have on release branches. I would drop anything not related to the plat- forms in question right after the branch point. This would move most of the effort to the folks who actually benefit from the maintenance. However, given my experience in this community, I would expect people who usually only work on the master branch to still be responsive and helpful. Porting ------- Given that we are talking about platforms that are not based on native coreboot code but unmaintained vendor code instead, it might help to port these platforms to coreboot proper. I don't think that the integration of vendor core is a root-cause of the trouble. FWIW, other vendor code (well, usually in the form of blobs) has been integrated into coreboot with more success. However, a fresh port with decent review could definitely lose a lot of the burden of the old one. It's a huge effort of course, I don't want to hide that. Just like for the famous KGPE-D16 and surrounding platform code, I'd estimate roughly $200k for such an endeavor (maybe half of it for the initial implemen- tation and the rest for both sides during a few months of review). IMHO, this is an investment that was missed initially when these plat- forms were added to coreboot. Generally, getting something to boot with coreboot is rather easy. I guess you can get things running with maybe 20% of the effort necessary for a port of reasonable code quality. How- ever, if things are left in such a state, somebody has to pay 10% on top during every year of maintenance (which is currently left to the active coreboot developers). IOW, the current state is also very expen- sive whilst not getting anywhere, and paid by the wrong people. Documenting Hardware -------------------- The existing documentation, at least AFAICS, is rather thin. Every time some developer wants to advance coreboot and has to touch the respective code, they could use some good documentation. I can't exactly say what is missing. It's like whenever I have to look into a BKDG, I don't find what I'm looking for. Also, it's very hard to tell which AMD document applies to what hardware. Register descrip- tions are usually there, maybe what I'm missing is some in-depth docu- mentation of the concepts. Or maybe it would already help to extend the register descriptions. Also, organizing the available information could help. Comparing BKDGs to Intel's public, scrubbed datasheets, it seems the latter already have more in-depth textual descriptions. Cleaning up the existing ports ------------------------------ Of course, one can also try to continue as usual and bring things for- ward iteratively. This might be the most expensive way, though, so I put it last. Kyösti has already mentioned some things that could be done beyond what is immediately necessary to avoid the current depre- cation plans. He's definitely the guy to talk to about AGESA topics. Generally, just reading the code and bringing it into a readable state would help. There is a whole lot of inexplicable code, sometimes it just can't be explained because it's simply wrong. Sometimes it's just copy-pasta that was written for a different hardware generation. Maybe this could help: Try to figure out for every line of code what assumptions it makes. Try to very such assumptions with the common coreboot code and available documentation. And if it can't be found, and the assumption is about software, time to fix the code probably. If the assumption is about hardware, well, test the hardware (don't trust the code!). If any assumption is a hardware quirk that is not easy to find in the documentation, add a code comment about it. Oh, and I almost forgot, the board ports don't look like coreboot code. There's CamelCase, odd tables in C code (as if there was no devicetree), AGESA configuration done in the code of each and every mainboard that should be done only once in the chipset code... IMHO it looks like a mess. When one is used to coreboot and then sees this, there should be no doubt why we have deprecation squabbles ;) This [1] might be related. Board ports of other platforms have seen a lot of updates over the last ten years, that's not easy for ports where one doesn't know what to begin with. A last thought about board ports, wrt. to blobbed vendor code I stated it like this lately: The board port should be written such that in case one would replace the blob (vendor code) with a native coreboot port, that should be possible without touching the board code. IMO, there shouldn't be a trace of AGESA in the mainboard dirs. The mainboard code should configure the chipset drivers/code and the chipset code can use AGESA to achieve its goal, but shouldn't be force by mainboard code to do so. Nico

6 15

Fwd: Questions Regarding Flashing a Voxel (CP713-3W) Chromebook
by Matthew Kunjummen 04 Dec '21

04 Dec '21

On Fri, Dec 3, 2021 at 11:23 AM Matt DeVillier <matt.devillier(a)gmail.com> wrote: > 3) You really need a Suzy-Q cable in order to reprogram the main > firmware, and to get serial debug info out in order to diagnose the > issue. Gotcha, I'll look into getting one. > PS - you didn't mention what payload you built it with, that would be > helpful to know. Also, your defconfig and what region(s) you flashed. I believe I was using tianocore, and going forward I'll make sure to keep track of the defconfig and regions. Thank you very much for your responses.

1 0

Questions Regarding Flashing a Voxel (CP713-3W) Chromebook
by Matthew K 04 Dec '21

04 Dec '21

Hello! I've been attempting to flash Coreboot to a recently acquired Acer Chromebook CP713-3W with the hope of eventually being able to boot from a USB drive and install some variety of linux. Currently my system is only limitedly responsive when booting, so I acquired a flash programmer to try and program the rom chip directly. When attempting to do this (and also while building the rom from the google source code) I noticed a few things that seemed to complicate the flashing process. The only chip I have identified so far as a rom chip is 1MB in size (Winbond W25Q80DVSNIG). I was unable to read the intel firmware descriptor or a layout file from it when attached with the usb programmer. When using the chromium coreboot sources, selecting the voxel mainboard also automatically selected the layout file associated with the volteer mainboards. Because this layout file was for a 32MB chip, I was unable to use it to build the chip, but because I didn't have a layout file, I didn't know what to set the size of the CBFS filesystem to be in the build config. I attempted several guessed sizes to just see if I could get a file to build, but no attempted size ended up being able to even produce a rom image. I now have some questions. 1. Am I even looking at the right chip? Is there a different 32MB Rom that I should be flashing to? Does the chromebook firmware live on the harddrive somehow (I find this unlikely because the hard drive is replaceable, but I wanted to mention the possibility)? If it's not the bios chip, then what is it? 2. If this is the right chip, how do I reduce the size of the payload and/or determine the appropriate size of the CBFS filesystem in order to create a rom that I could flash? Is it feasible/would it be better to get a 32MB rom chip, flash it with the built image from chromium coreboot and the volteer layout file, and replace the current chip with it? 3. What sort of expectations should I have for the current status of coreboot on this mainboard (either from the coreboot or chromium repositories)? What additional work should I expect to have to do if I want to be able to e. g. boot from a linux flash drive? Please let me know if there's more information I can provide that would be useful, if there's a better place for me to ask these questions, or if there are resources that can help guide me towards answering these questions for myself. Matthew Kunjummen

4 3

Document shared with you: "Proposal: Buildbot as a replacement for Jenkins"
by coreboot org (via Google Docs) 03 Dec '21

03 Dec '21

I've shared an item with you: Proposal: Buildbot as a replacement for Jenkins https://docs.google.com/document/d/10jQc1N67Pck2pE3pkyke7g-YFDIBqum6SkQH7Ud… It's not an attachment -- it's stored online. To open this item, just click the link above.

1 0

Invitation: Buildbot replacing Jenkins @ Wed 2021-12-08 11:00 - 12:00 (MST) (coreboot@coreboot.org)
by coreboot.org＠gmail.com 03 Dec '21

03 Dec '21

You have been invited to the following event. Title: Buildbot replacing Jenkins Meeting Details: https://meet.coreboot.org/BuildbotJenkinsReplacement No phone bridge. This meeting is to discuss the document below. Proposal / Design document: https://docs.google.com/document/d/10jQc1N67Pck2pE3pkyke7g-YFDIBqum6SkQH7Ud… When: Wed 2021-12-08 11:00 – 12:00 Mountain Time - Denver Joining info: Join with Google Meet https://meet.google.com/wqd-kned-vux?hs=224 Calendar: coreboot(a)coreboot.org Who: * coreboot.org(a)gmail.com - creator * felix-coreboot(a)felixheld.de * zaolin.daisuki(a)googlemail.com * gduynisveld(a)eltan.com * Arthur Heymans * Edward O'Callaghan * Ron Minnich * Matt DeVillier * Marc Jones * Noga Smith * Stefan Reinauer * Tim Wawrzynczak * David Hendricks * Karthik Ramasubramanian * Patrick Georgi * Dossym Nurmukhanov * christoph.kuehn(a)advantech.de * felix.held(a)amd.com * Stefan Reinauer * Nico Huber * Julius Werner * manuel.huber(a)ttcontrol.com * jorgefm(a)cirsa.com * nathaniel.l.desimone(a)intel.com * jonzhang(a)fb.com * Christian Walter * Jay Talbott * Marshall Dawson * Banik, Subrata * Eric Peers * Tim Crawford * Werner Zeh * patrick.rudolph(a)9elements.com * andreas_dsl_huber(a)hotmail.de * max_lee(a)pegatroncorp.com * Shelley Chen * Glenesk, Jason * Wim Vervoorn * coreboot * Ron Minnich * felix.singer12(a)gmail.com * Rocky Phagura * Jeremy Soller * Benyukhis, Ed * gregg.drwho8(a)gmail.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MXNrN250bWQ0Ymxq… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account coreboot(a)coreboot.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

coreboot GSOC 2022
by coreboot org 03 Dec '21

03 Dec '21

In the 1 Dec 2021 leadership meeting, we discussed applying to the 2022 Google Summer of Code project. Needs: - Primary Admin - Ideas for projects - Mentors Primary Admin needed: Eric Peers and Martin Roth have both volunteered to help admin the project, but neither has time to act as the primary admin. This means that we need a primary admin to work on the application and run the show. Help is available, both from previous admins, the assistant admins, and from the GSOC community. For anyone looking to step forward in the coreboot community, this is a good opportunity. Mentors Needed: If the coreboot project is accepted for GSOC 2022, we'll need mentors for the projects. It's good to get an idea ahead of time for the number of mentors available, so if anyone is interested please 2022 GSOC overview: https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-i… 2022 GSOC Timeline: https://developers.google.com/open-source/gsoc/timeline coreboot GSOC 2022 Document: https://docs.google.com/document/d/1VIaz7beHkOR6WrLeu3lCVY76FZ6cUQTnLXE9pIh… Anyone interested in volunteering as a mentor, primary admin please comment in the above document. Likewise if anyone has ideas for coreboot projects that would be good for GSOC students, please comment in the document.

1 0

1 December 2021 - coreboot Leadership Meeting Minutes
by coreboot org 03 Dec '21

03 Dec '21

# 1 December 2021 - coreboot Leadership Meeting Minutes ## Attendees Felix Singer, Martin Roth, Werner Zeh, Patrick Georgi, Julius Werner, Eric Peers, Tim Wawrzynczak, Matt DeVillier, Felix Held, Stefan Reinauer, Jason Glenesk ## Key Decisions * coreboot is interested in doing GSOC 2022, but needs to find a primary admin. * Fundraising for coreboot projects is allowed, but will not be sponsored by the coreboot project. * Deprecation of AGESA ports depends only upon not fixing the features being depredated, and will not be done if the chips/boards are updated. * Discussion about deprecation requests and port requirements needs more discussion. ## Agenda / Minutes * [David] This meeting overlaps with the Open Source Firmware Conference, so expect a light turnout: [https://talks.osfc.io/osfc2021/schedule/#2021-12-01](https://talks.osfc.io/… * May need to postpone or continue discussions on Dec. 15. * [Patrick] GSoC 2022? * They allow “short” (175h) and “long” (350h) projects now, so the reason why we skipped applying in 2021 (only short projects) is gone. * Open to everybody 18 years or older who didn’t already participate in GSoC twice. * Participants may not work with projects where they made non-trivial contributions already. * Flashrom wants to participate apparently. Maybe as a separate project, if that doesn’t work but coreboot makes it, we could take them under our umbrella again like we did in the past. * Who’s willing to admin? * [Martin] I’m willing to help, but I don’t want to be the primary admin. * [epeers] Can help too but not as primary. * Martin to ask on mailing list * [Piotr] AGESA-based ports * It looks like a decision was already made, so I just want to tell my point of view. * [Martin] I don’t think that it’s decided yet, especially if there are reasons not to make that decision, so yes, let’s discuss it. I do think that there has been a decision that there will be deprecations at some point again, but not necessarily this code yet. * [Felix] Do we just need the patches that are already in gerrit to keep the platforms alive? * [Piotr] Maybe, we don't really know what the criteria are. * The Proposed changes build bad marketing and may affect contribution level: * Why OEM should sponsor maintenance when total cost of ownership is unknown and subject to spikes? * Why should IBV/IFV/OSFV contribute code to upstream, if the cost of keeping it there can be infinitely increased by design decision out their control? * [Patrick] Why should the community accept contributions if their side of the deal is supposed to mean "maintain it forever, for free"? It's rather simple to dead-lock this debate. * [David] I can't speak for all cases, but AFAIK these maintenance agreements usually come with a timeline. * [Piotr] 10 years for embedded and Intel coming with 15years supported platforms * [David] 15 years ago coreboot was LinuxBIOSv2. What you're suggesting here is unreasonable. Things change in master. Don't base your support contracts/obligations on master. * [Martin] What are the possible alternatives? * Any code put into coreboot is going to need to be maintained by someone, that will need to be either the original contributors, or by people trying to add new features. * Branching model looks like UEFI closed source development model, which proven to be wrong many times (lack of bug fixing across branches, lack of backporting) * This was already said by me couple times - “Disagree and commit” * It will lead to problems mentioned [in this presentation](https://talks.osfc.io/osfc2021/talk/D9X39Z/) and [Alex tweet about UsbRt](https://twitter.com/matrosov/status/1465863974310744064) * [David] Is bitrotting code any better if it's in master than in a branch? * How does an individual or company know that a board will work? Do they checkout master and potentially bisect thousands of changes until they find the last working commit? * [Piotr] This applies also to master branch, there are no guarantees on branches as well as on master. So no one ever can be sure if platform works, however we define works, since coreboot does not provide such guarantees. * How do well-meaning community members refactor code without ability to test on real hardware? * [Piotr] There are Linux kernel parts that nobody can confirm works eg. at some point I tried Marvell Armada 8k crypto engines, but I'm not aware of any activity of hardware support removal because of that. * We need to do a better job of advertising when a board was last known to work. board_status was supposed to help with this, but has its own problems and is not used very often. * 100% agree and 3mdeb will support that effort if agreement about direction would clearly stated - we had that discussion many times at OSFC'20 as well as on vPub. * [David] OTOH, having a variety of SoCs, mainboards, and architectures in the master branch is a huge advantage coreboot has in this space. None in the x86 world come close to the universal extensible firmware _implementation_ which is coreboot ;-) Let's not take that for granted. * Leaving boards on branches means they can die just because of lack of toolchain for building - I’m not sure how likely it is, but we can check how far in the past we can go and still build a toolchain that gives working coreboot.rom. * [David] coreboot builds its toolchain specifically to avoid problems with toolchains. Bitrotten code compiled with a new toolchain may encounter difficult-to-debug issues. This is actually a case where leaving old targets on branches may help, since the code and toolchain will be known to work together. * [Martin] There are builders set up with the older toolchains. Toolchains back to at least 4.10 can be built on current debian/ubuntu systems with the command: CC=gcc-8 CXX=g++-8 make crossgcc CPUS=$(nproc) Note that(4.10 does fail when building make, but current systems use a version of make that works. And yes, I tested this yesterday after seeing this comment. :) Older toolchains can also always be built using the OS versions that existed at the time the system was released. If we need VMs of these older releases, we should make them and post them for download. Right now, compiling still gives some errors even with the correct toolchain due to errors compiling the tools with the new host compiler, but we could either fix those errors in the branch or work out how to configure HOSTCC to get everything compiled with gcc-8. * [David] How to balance maintenance with community resources? * Even if time weren't a factor, lack of testing ability and access to documentation make it difficult to guarantee that code clean-ups don't break things. * coreboot is a hardware-oriented project and that means dealing with hardware scarcity, NDA'd docs from vendors, etc. * Some hardware is simply obsolete. Even with the best of intentions, the amount of work needed to maintain certain targets can never pay off since the hardware is unobtainable (old vendor reference boards, for example). * [Piotr] My points are not about old hardware that nobody has and want support. * [Felix S.] Tree-wide change [CB:39331](https://review.coreboot.org/c/coreboot/+/39331) * Makes PCI ID defines a little bit shorter without losing information * Any objections on this? * This looks good. The commit message tells how to reproduce the patch instead of cherry-picking it. * [Felix] Let's set up meeting for this time next week to discuss the jenkins builder replacement. # 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

[coreboot - Bug #325] (New) Asus P5QL-EM: NVIDIA card in PCIe X1 port not working
by coreboot＠fe80.eu 03 Dec '21

03 Dec '21

Issue #325 has been reported by Francois Ollonois. ---------------------------------------- Bug #325: Asus P5QL-EM: NVIDIA card in PCIe X1 port not working https://ticket.coreboot.org/issues/325 * Author: Francois Ollonois * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- When using my nvidia geforce GT 710 in PCIe X1 slot the screen is not working after graphic driver is loaded. With nomodeset parameter it works but without driver I can't start Xorg. The same card in X16 slot works, but I want to use the X16 port on this board for a nvme adapter card. I discussed the problem with nouveau project and they consider some sort of DMA problem and found some differences between vendor firmware and coreboot that may cause the problems. They also mention some kernel parameters to work around this problem but even with this parameters the screen flickers when using Xorg. With original vendor firmware the card works in X1 port. I use this card: https://www.asus.com/Motherboards-Components/Graphics-Cards/ASUS/GT710-4H-S… Here is the link to the nouveau ticket. https://gitlab.freedesktop.org/drm/nouveau/-/issues/132 I will also add the kernel log and lcpci output and the cbmem output. And here are some information about the differences: ~~~ Coreboot: Latency: 0, Cache Line Size: 64 bytes Capabilities: [100 v1] Virtual Channel Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Vendor: Latency: 0, Cache Line Size: 32 bytes Capabilities: [100 v1] Virtual Channel Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 ~~~ The host bridge also has SERR+ on coreboot vs SERR- on vendor. And the root ports actually have a lot of differences, including stuff like ~~~ Coreboot: Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 <4us ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x0 (downgraded) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Vendor: Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 <4us ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x0 (downgraded) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Slot #0, PowerLimit 10.000W; Interlock- NoCompl- SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- Changed: MRL- PresDet- LinkState- ~~~ ---Files-------------------------------- cbmem_p5ql-em.log (43.5 KB) kernel_log_X1.txt (56.9 KB) kernel_log_X1_nomodeset.txt (55.1 KB) kernel_log_X1_with_para.txt (57.3 KB) kernel_log_X16.txt (56.7 KB) lspci_coreboot_root2.txt (64.3 KB) lspci_vendor.txt (61.9 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

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 December 2021