Hello everyone,
I would like to take part in the development of coreboot projects and become a GSoC 2022 contributor. I'm not a newbie in firmwares (I have experience with uefi, I'm familiar with bios). Now, to prepare myself, I study the coreboot documentation and source code.
I find "Libpayload based memtest payload" and "Fix POST code handling" projects interesting. But I need some tips.
About the first one. To put it simply, the task is to study the memtest sources (memory checking mechanisms) and port it? And of course improve it, if possible.
I have more questions about the last one projects:
1) Main goal is to make Kconfigs have effect on most platforms. For it we should maybe have deal with Kconfigs and replace to post_code(...) which refer to POST_IO and POST_IO_PORT. Right?
2) For example, in `arch/x86/tables.c`, line 81:
post_code(0x9c);
coreboot has no documentation and macro for POST code 0x9c. So, should I find out what it means and write it in the documentation and add a macro?
3) What does the task "Make use of all possible 255 values" mean? Does coreboot use all 255 values?
I would appreciate any feedback.
On Mon, 2022-03-14 at 20:39 +0300, Joursoir wrote:
Hello everyone,
I would like to take part in the development of coreboot projects and become a GSoC 2022 contributor. I'm not a newbie in firmwares (I have experience with uefi, I'm familiar with bios). Now, to prepare myself, I study the coreboot documentation and source code.
Awesome! Welcome :)
I find "Libpayload based memtest payload" and "Fix POST code handling" projects interesting. But I need some tips.
About the first one. To put it simply, the task is to study the memtest sources (memory checking mechanisms) and port it? And of course improve it, if possible.
Correct.
I have more questions about the last one projects:
- Main goal is to make Kconfigs have effect on most platforms. For
it we should maybe have deal with Kconfigs and replace to post_code(...) which refer to POST_IO and POST_IO_PORT. Right?
Unfortunately, I don't know much about this project and not sure if I understood the question. First, all occurrences of outb() should be replaced with post_code(). Then, post codes might not be supported by all platforms. So they need to be guarded.
- For example, in `arch/x86/tables.c`, line 81:
post_code(0x9c);
coreboot has no documentation and macro for POST code 0x9c. So, should I find out what it means and write it in the documentation and add a macro?
Correct. Of course you also can ask people for help!
- What does the task "Make use of all possible 255 values" mean?
Does coreboot use all 255 values?
Maybe some post codes are used for different cases, which can be confusing. Also, I'm thinking of making the post codes more fine granular, so that they are more specific.
I will try to make people aware of your mail. Maybe someone else can help :)
// Felix
On Mon, Mar 14, 2022 at 11:40 AM Joursoir chat@joursoir.net wrote:
Hello everyone,
I would like to take part in the development of coreboot projects and become a GSoC 2022 contributor. I'm not a newbie in firmwares (I have experience with uefi, I'm familiar with bios). Now, to prepare myself, I study the coreboot documentation and source code.
Hello! Welcome to coreboot!
I find "Libpayload based memtest payload" and "Fix POST code handling" projects interesting. But I need some tips.
I took a quick look at the POST code project before as well, so I can provide some comments as I understood it.
I have more questions about the last one projects:
- Main goal is to make Kconfigs have effect on most platforms. For it we should maybe have deal with Kconfigs and replace to post_code(...) which refer to POST_IO and POST_IO_PORT. Right?
I haven't taken a look at the Kconfig side of the post codes so I can't comment much on this.
- For example, in `arch/x86/tables.c`, line 81:
post_code(0x9c);
coreboot has no documentation and macro for POST code 0x9c. So, should I find out what it means and write it in the documentation and add a macro?
I believe that is the intent. I've previously written a bash script that would go through the entire coreboot codebase and output a log summarizing the usage and location of POST codes (both macros and hex literals). Figuring out what a particular value means should be a matter of looking at the code around the POST code and using that context to figure out what it's trying to signal. The log should also help find duplicated usages of a particular code with conflicting meanings. I've attached both the script as well as sample output (should be up to date with the repo as of the time this message was written). The script should be run from the root of the coreboot repo, and outputs to standard output. It does take a while to run (about a minute on my machine), so don't be surprised if it seems like it's frozen.
From what I've seen, there are several macros that are completely unused, and hex literals used in contexts that conflict both with other hex values as well as the macro associated with that value.
- What does the task "Make use of all possible 255 values" mean? Does coreboot use all 255 values?
POST codes are one byte each, so there are 255 possible codes if you ignore 0xFF which is being used to indicate a fatal error. coreboot doesn't use all possible values, so using them all would allow each code to signal more specific parts of the boot process.
Currently, post code macros are located in src/commonlib/include/commonlib/console/post_codes.h, but there are also some in src/soc/amd/common/psp_verstage/include/psp_verstage.h. I've also read that the Intel FSP blob outputs its own post codes, but they don't seem to be well documented, so that may be another challenge.
Cheers, Nicholas
-
Felix Singer -
Joursoir -
Nicholas