November 2021 - coreboot - mail.coreboot.org

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

Personal challenge | Ramp up on coreboot : Trials on aftermarket X58 motherboards.
by Master Feb. 15, 2022

Feb. 15, 2022

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.

3 3

Installing coreboot with SeaBIOS
by bernd1-1＠web.de Jan. 23, 2022

Jan. 23, 2022

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

10 52

Git reports an interesting error message
by Gregg Levine Jan. 20, 2022

Jan. 20, 2022

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."

3 5

"Private" changes on Gerrit are now disabled and removed
by Patrick Georgi Jan. 4, 2022

Jan. 4, 2022

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

7 11

How to maintain AGESA-based ports long-term?
by Nico Huber Dec. 5, 2021

Dec. 5, 2021

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

7 20

i440bx PARALLEL_MP testing WAS: Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
by Branden Waldner Dec. 1, 2021

Dec. 1, 2021

On 11/30/21, Keith Hui <buurin(a)gmail.com> wrote: > I suffered an unexpected exception after applying the patch train. > Serial log at the end of this email. I probably could leave out > bootblock/romstage/postcar, but it's here for completeness. Next: > bisect. I had a similar result testing on my P2B. I'm working on recovering it and I was planning on trying a build with log level spew on the P2-99 since it is easy for me to recover with the way I have it setup right now. Branden Waldner

2 2

[coreboot - Bug #323] (New) thinkpad T60 expresscard support
by coreboot＠fe80.eu Nov. 30, 2021

Nov. 30, 2021

Issue #323 has been reported by Michael Edelmann. ---------------------------------------- Bug #323: thinkpad T60 expresscard support https://ticket.coreboot.org/issues/323 * Author: Michael Edelmann * Status: New * Priority: Normal * Assignee: * Category: board support * Target version: ---------------------------------------- I was playing around with expresscard usb 3.0 adapters on a thinkpad T60 and noticed that coreboot breaks its functionality. i tested both the stock bios and coreboot revision b2e8bd83647f664260120fdfc7d07cba694dd89e, the logs listed under https://www.coreboot.org/Motherboard_Porting_Guide are included in the 'coreboot' and 'stock' directories. of course i had my card inserted when i took the logs lspci shows the card under the stock bios, it works fine. coreboot doesnt seem to do anything with it, its getting no power. the card i got, as seen in the attached image, has been known to work on GNU/Linux for other people out of the box, apparently not for coreboot. i'd be glad if coreboot supported expresscards for 2 additional USB ports, thanks for taking a look at it! ---Files-------------------------------- card.jpg (41.1 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

Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
by Branden Waldner Nov. 30, 2021

Nov. 30, 2021

I wasn't really sure that I wanted to comment on this, but seeing as how I have some of the affected boards I guess I should. Angel Pons wrote: > Besides AMD AGESA boards, the other boards that need to be updated are AOpen DXPL > Plus-U (a dual-socket server board that uses Netburst Xeons, no other board in the tree uses > the same chipset code) and various Asus P2B boards (which support Pentium 2/3 CPUs, these > boards are older than me). Even though I only know two people who still have some of these > boards (and they don't have the same boards), they're still supported because the code has > been maintained so far. I am one of the two with Asus P2B boards, with Keith Hui being the other. I've got a P2B and a P2-99 and I believe Keith Hui has a P2B-LS. So far there have not been very many changes and Keith Hui and others have worked on them, all I've done is test master and relevant patch sets every once in a while. I know I have not been uploading board_status results and I have not gotten around to fixing the variant set up for the P2-99 so I'm not uploading results that are uncertain about which board they are for. Not really relevant, but I think it is pretty neat to be running coreboot on boards older then some of the contributors. Mike Banon wrote: > I am often build-testing my boards (didn't notice a > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only because I've been > re-using the previously built toolchains to save time). Also, I am actively tech-supporting all the > people who would like to build coreboot for AMD boards from this list, even right now I am in an > active message exchange with >10 people who are switching to these boards to run coreboot > on them - and any user may give back to the project one day. I actually have a few AMD boards and laptops that might be viable for porting to, but I've never looked in to it much because of the state support is in coreboot and the fact most of the hardware was actively being used. Arthur Heymans wrote: > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes the codepath for > SMM_ASEG. This code is used to start APs and do some feature programming on each AP, but > also set up SMM. This has largely been superseded by PARALLEL_MP, which should be able > to cover all use cases of LEGACY_SMP_INIT, with little code changes. The reason for > deprecation is that having 2 codepaths to do the virtually the same increases maintenance > burden on the community a lot, while also being rather confusing. > > A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on single core > systems. It's likely easy to extend PARALLEL_MP or write some code that just does CPU > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa0000 - 0xb0000) region. A > POC showed that it's not that hard to do with PARALLEL_MP > https://review.coreboot.org/c/coreboot/+/58700 I didn't even know that was a problem until now. I doubt there is much I can do about it myself at this point in time, though I can try to look through it I guess. Branden Waldner

4 3

Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
by Arthur Heymans Nov. 29, 2021

Nov. 29, 2021

Hi I would like to suggest to deprecate some legacy codepaths inside the coreboot tree and therefore make some newer ones mandatory. The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes the codepath for SMM_ASEG. This code is used to start APs and do some feature programming on each AP, but also set up SMM. This has largely been superseded by PARALLEL_MP, which should be able to cover all use cases of LEGACY_SMP_INIT, with little code changes. The reason for deprecation is that having 2 codepaths to do the virtually the same increases maintenance burden on the community a lot, while also being rather confusing. A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on single core systems. It's likely easy to extend PARALLEL_MP or write some code that just does CPU detection on the BSP CPU. - Support smm in the legacy ASEG (0xa0000 - 0xb0000) region. A POC showed that it's not that hard to do with PARALLEL_MP https://review.coreboot.org/c/coreboot/+/58700 No platforms in the tree have any hardware limitations that would block migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase. The second codepath that I'd like to propose for deprecation is RESOURCE_ALLOCATOR_V3. V4 was introduced more than a year ago and with minor changes most platforms were able to work just fine with it. A major difference is that V3 uses just one continuous region below 4G to allocate all PCI memory BAR's. V4 uses all available space below 4G and if asked to, also above 4G too. This makes it important that SoC code properly reports all fixed resources. Currently only AGESA platforms have issues with it. On gerrit both attempts to fix AMD AGESA codebases to use V4 and compatibility modes inside the V4 allocator have been proposed, but both efforts seem stalled. See the (not yet merged) documentation https://review.coreboot.org/c/coreboot/+/43603 on it's details. It looks like properly reporting all fixed resources is the culprit. About the timeline of deprecations. Is deprecating non conforming platforms from the master branch after the 4.16 release in 6 months a reasonable proposal? The affected boards currently are: AMD_INAGUA AMD_OLIVEHILL AMD_PARMER AMD_SOUTHSTATION AOPEN_DXPLPLUSU AMD_PERSIMMON AMD_THATCHER AMD_UNIONSTATION ASROCK_E350M1 ASUS_A88XM_E ASROCK_IMB_A180 ASUS_AM1I_A ASUS_F2A85_M ASUS_F2A85_M_PRO ASUS_F2A85_M_LE ASUS_P2B_RAMDEBUG ASUS_P2B_LS ASUS_P2B_F ASUS_P2B_D ASUS_P2B_DS ASUS_P3B_F ASUS_P2B ODE_E20XX BIOSTAR_AM1ML BIOSTAR_A68N5200 ELMEX_PCM205400 ELMEX_PCM205401 GIZMOSPHERE_GIZMO2 GIZMOSPHERE_GIZMO HP_ABM HP_PAVILION_M6_1035DX JETWAY_NF81_T56N_LF LENOVO_G505S LIPPERT_FRONTRUNNER_AF LIPPERT_TOUCAN_AF MSI_MS7721 PCENGINES_APU1_ PCENGINES_APU2_ PCENGINES_APU3_ PCENGINES_APU4_ PCENGINES_APU5_ PCENGINES_APU1 PCENGINES_APU2 PCENGINES_APU3 PCENGINES_APU4 PCENGINES_APU5 sidenote: Qemu platforms support both LEGACY_SMP_INIT and PARALLEL_MP init so I did not list them here. Let me know your thoughts. Arthur

16 27