On Thu, Sep 12, 2019 at 04:46:00PM +0000, awokd via coreboot wrote:
Drivers needs support to not get in the way of later development, and AGESA is sorely lacking in that department. If you see value in that code, please step up now, not only when we're looking into removing that code for good.
Which drivers and what support? I see Kyösti Mälkki replied with better questions. Where is the biggest pain point today, i.e. not already being worked on and would return the most value to Coreboot by my work?
In general terms:
coreboot is really a loose bunch of related projects ("open source firmware") sharing common code, but the specific code shares relatively little activity: You don't need to know about AMD bring-up if you're dealing with Intel or even ARM. The idea is that if everybody takes care of the parts they're interested in, we get full coverage of everything we need to support.
You'd provide the most value for the project if you keep the parts of the code alive that are relevant to you. That way, we know that the actively used code is in a good shape.
Keeping it "alive" starts with providing board-status reports (so we know what boards are still in use: it doesn't make much sense to support 15 year old stuff that nobody uses and you can't even find on ebay anymore).
The next step would to be look which parts of the sources are specific to your board (or its family of boards) and are at risk getting neglected: People are in for the new shiny, so it's normal that the developer base for older stuff gets smaller - with a few notable exceptions, like the desire to have capital-F-free boards where there are few-to-no new ones.
Such parts of the code would benefit the most (you, and through you, the project) from some additional developer eyeballs.
Finally, once you feel comfortable enough, you could volunteer as a maintainer of a device, making you the official point of contact if anything needs to be done about a board.
The duties of a maintainer aren't well carved-out yet, but they definitely include being responsive to changes on our code review system that affect the board, being responsive to inquiries ("We want to redo X and it might require changes to your code") and to do regular tests, so you know when the part you're responsible for break (due to unrelated changes), and then fix it.
Being a maintainer doesn't require you to be some kind of rockstar coder: You should be able to handle basic changes and understand what the code does, but if there are any large redesigns across coreboot, there's typically somebody on the other end of the project (those doing these redesigns) able to help you out.
Even if you need some guidance for more intricate changes, the more active devs doing project-wide changes can't know all the details and can't have all the devices to test them. As a maintainer, that's where you come in: You either know what the code does that you maintain or you're willing to find out. You have the device and you're willing to test unstable code and you're able to recover from bad flashes.
Let's move away from the abstract and to the practical:
If you have a board that you want to ensure remains in a healthy state in coreboot, you maybe should start to get your feet wet.
Step 1: Figure out what code is involved in booting your board.
I'm using ASUS F2A85-M as an example because that's somewhat related to this thread:
$ grep "^[[:space:]]*<chip>" src/mainboard/asus/f2a85-m/devicetree_f2a85-m.cb |sed "s,\t, ,g" chip northbridge/amd/agesa/family15tn/root_complex chip cpu/amd/agesa/family15tn chip northbridge/amd/agesa/family15tn # CPU side of HT root complex chip northbridge/amd/agesa/family15tn # PCI side of HT root complex chip southbridge/amd/agesa/hudson # it is under NB/SB Link, but on the same pci bus chip drivers/generic/generic #dimm 0 chip drivers/generic/generic #dimm 1 chip superio/ite/it8728f
These "chips" point to drivers, each in their own directory (prepend src/ and you're there). In these directories, Makefile.inc is the main mechanism that decides which files go where.
If somebody breaks common code, we'll notice immediately. If somebody breaks a driver that is used on a lot of boards, we'll notice quickly (e.g. SuperIO drivers). At highest risk are drivers that are specific to a few boards, especially if they're all approximately the same age (and therefore popularity). These are the chipset drivers (northbridge, southbridge, cpu, or on newer boards "soc"), and that's what we need maintainers for the most.
Step 2: Find something to do with the code
We have a few contributors who do rather manual tasks, like sorting out if the included header files are all necessary or making sure the coding style is followed (although we plan to automate the latter part).
There are also usually a number of bugs or TODOs mentioned in the code that you could look out for and dig into.
Plus, I mentioned it already, there's stuff like Coverity Scan (and scan-build at https://coreboot.org/scan-build/) that point out "suspicious" issues in the code. These are nice because they're often well-scoped: Here's a small snippet of code, and this issue is worth looking into.
If you're stuck, you're always welcome to ask for help or guidance on the mailing list or on IRC (chat). It can take a while to get a response since we're all busy with all kinds of things, but you'll usually find somebody who is willing to help.
The only thing we can't do is make you motivated to dig into the minutiae of hardware init: if that's your thing, we'll help fill in the gaps. If that sounds boring to you, you might want to look for something else to do.
Step 3: When you did something to the code, expose it
I'm not sure how well-versed you are in open source development, but this step can be frightening: You changed the code, it didn't break anything (to your knowledge) and now people are looking at it in something that is called "code review". Scary!
But I encourage you to see it as opportunity: We love it when folks get started in our codebase, and we love giving advice (makes us feel better, too!).
With that I encourage you to accept feedback as "hey, here's a way to get even better", not as "aw, that's crap". The community encourages a positive tone as well (although, since we're people, it doesn't always work out as intended).
Step 4: Become a domain expert
It takes surprisingly little to become more knowledgable about some specific thing in coreboot than everybody else. If that thing is directly related to your interest, everybody wins.
Signing up as maintainer (see the MAINTAINERS file) makes your willingness to be such a domain expert and primary contact about that thing official. We'll stop folks in time if we think that they're not ready yet ;-)
Patrick