Hi. I go through this tutorial:
I'm on Step 5 - Configure the build > Check your configuration (optional step):
$ 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?
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
Is everyone else aware of this?
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
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 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.
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
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.
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.
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.
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
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  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
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:
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
Issue #323 has been reported by Michael Edelmann.
Bug #323: thinkpad T60 expresscard support
* Author: Michael Edelmann
* Status: New
* Priority: Normal
* 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!
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
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
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
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
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.
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
- Support smm in the legacy ASEG (0xa0000 - 0xb0000) region. A POC showed
that it's not that hard to do with PARALLEL_MP
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
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
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
About the timeline of deprecations. Is deprecating non conforming platforms
from the master branch after the 4.16 release in 6 months a reasonable
The affected boards currently are:
sidenote: Qemu platforms support both LEGACY_SMP_INIT and PARALLEL_MP init
so I did not list them here.
Let me know your thoughts.
I'm thinking about porting coreboot to a FM2A88X Extreme4+ board. This
board has a DIP8 flash with a socket and I wondered what would be the best
way to do an efficient development cycle. Ideally, I suppose that the best
option would be to use a clip test and a CH341A, but all the clips that I
found are SOIC/SOP. Should I buy a SOIC clip and an adapter from SOIC to
DIP? I've seen those adapters, but I'm not sure if they will fit well in
the mobo DIP8 socket.
Aside from the mechanical question, I'd appreciate any advice about the
safety of externally programming the board. I don't have the schematics and
I wonder if there could be any risk of damaging the board.