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
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
signature.asc
Description: PGP signature
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
