Hello everyone,
I'm interested in participating in GSoC 2023. I would like to take part in the development of the coreboot, moreover I already have a bunch of commits in the flashrom. I find the "Libpayload based memtest payload" project interesting and have a few questions about it.
1) This project was added a few years ago, also coreboot payload of memtest based on memtest from 2019 (however, in 2022 memtest86+ v6 is released). So, maybe something has changed since that time and not reflected in the docs?
I found such ticket: https://ticket.coreboot.org/issues/184
2) Do I understand correctly, that this payload should be memtest-fork with a difference that will be built on libpayload and a design that will allow multiple architectures to be added?
3) There are no mentors at the moment :(
I would appreciate any feedback.
Hello again,
First of all, I would like to apologize for any inconvenience caused. I have carefully reviewed the project "Libpayload based memtest payload" and have come to the conclusion that it's not aligned with my interests. I would prefer to work on something more closely related to coreboot codebase. Therefore, I would like to propose "Fix POST code handling" as a more suitable alternative. So, I did some preliminary research on this project and have made some explorations which I'd like to share with you.
POST code macros are defined in the next locations:
* `src/commonlib/include/commonlib/console/post_codes.h` - a central point for POST codes used throughout coreboot * `src/soc/amd/common/psp_verstage/include/psp_verstage.h` - amd-specific, POST codes over eSPI (`PSP_POSTCODES_ON_ESPI`) * `src/soc/amd/common/block/include/amdblocks/post_codes.h` - amd-specific * `src/soc/intel/common/block/include/intelblocks/post_codes.h` - intel-specific * `src/include/cpu/intel/post_codes.h` - intel-specific
`post_code()` is defined in the two places:
* `src/include/cpu/x86/post_code.h` - used during bootblock stage * `src/console/post.c` - the main function
Replacing old `outb(0x80, ...)`, updating `Documentation/POSTCODES` (and I think that it would be great to show it on the web-site doc), droping duplicated POST codes are all quite understandable thing.
However, I have doubts about Kconfig. The description says `Guard Kconfigs with a depends on to only show on supported platforms`. So, am I supposed to determine if the 0x80 port is supported by a particular platform by checking check the system documentation?
Additionally, I've sent a patch to demonstrate my intentions for this project. Please, take a look at it[0].
But I'm worried that it may be a relatively small project. However, I was wondering if there are any debugging methods currently being used in the codebase that could be improved? I would be interested in exploring ways to enhance the debugging process. And I've also noticed that there is currently no debug documentation. While I would be happy to create such documentation, I feel that it would be more effective if I could first modify and improve the existing debug methods.
P.S. Many thanks to Felix and Nicholas for answering my question in the last year :) [1]
-- Joursoir
[0] https://review.coreboot.org/c/coreboot/+/73744 [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BBQRB...
On Tue, 28 Feb 2023 15:45:36 +0400 Joursoir chat@joursoir.net wrote:
Hello everyone,
I'm interested in participating in GSoC 2023. I would like to take part in the development of the coreboot, moreover I already have a bunch of commits in the flashrom. I find the "Libpayload based memtest payload" project interesting and have a few questions about it.
- This project was added a few years ago, also coreboot payload of
memtest based on memtest from 2019 (however, in 2022 memtest86+ v6 is released). So, maybe something has changed since that time and not reflected in the docs?
I found such ticket: https://ticket.coreboot.org/issues/184
- Do I understand correctly, that this payload should be memtest-fork
with a difference that will be built on libpayload and a design that will allow multiple architectures to be added?
- There are no mentors at the moment :(
I would appreciate any feedback.
On 3/16/23 05:11, Joursoir wrote:
Hello again,
First of all, I would like to apologize for any inconvenience caused. I have carefully reviewed the project "Libpayload based memtest payload" and have come to the conclusion that it's not aligned with my interests. I would prefer to work on something more closely related to coreboot codebase. Therefore, I would like to propose "Fix POST code handling" as a more suitable alternative. So, I did some preliminary research on this project and have made some explorations which I'd like to share with you.
POST code macros are defined in the next locations:
- `src/commonlib/include/commonlib/console/post_codes.h` - a central point for POST codes used throughout coreboot
- `src/soc/amd/common/psp_verstage/include/psp_verstage.h` - amd-specific, POST codes over eSPI (`PSP_POSTCODES_ON_ESPI`)
- `src/soc/amd/common/block/include/amdblocks/post_codes.h` - amd-specific
- `src/soc/intel/common/block/include/intelblocks/post_codes.h` - intel-specific
- `src/include/cpu/intel/post_codes.h` - intel-specific
`post_code()` is defined in the two places:
- `src/include/cpu/x86/post_code.h` - used during bootblock stage
- `src/console/post.c` - the main function
Replacing old `outb(0x80, ...)`, updating `Documentation/POSTCODES` (and I think that it would be great to show it on the web-site doc), droping duplicated POST codes are all quite understandable thing.
Martin had brought up the topic of POST codes on the mailing list a few months ago [0][1] and proposed a new organization of the hex codes for better consistency and utilization of the 255 possible codes. He also had posted a few patches regarding POST codes [2][3][4][5][6][7][8][9].
However, I have doubts about Kconfig. The description says `Guard Kconfigs with a depends on to only show on supported platforms`. So, am I supposed to determine if the 0x80 port is supported by a particular platform by checking check the system documentation?
I think the intention was to avoid showing certain POST options on platforms not supporting a certain method, such as outb port io POST codes which only make sense on x86 platforms. I don't think you would need to check if a specific (x86) board supports the 0x80 port as it's usually possible to configure that in the chipset to be forwarded over PCI or LPC such that something like an add-in card can be connected. However, looking at src/console/Kconfig, it seems like a lot of those Kconfigs already depend on CONFIG_PC80_SYSTEM which is only defined in arch/x86/Kconfig. Digging around in menuconfig, it seems like only the "Show POST codes on the debug console" show up on non-x86 systems.
Additionally, I've sent a patch to demonstrate my intentions for this project. Please, take a look at it[0].
But I'm worried that it may be a relatively small project. However, I was wondering if there are any debugging methods currently being used in the codebase that could be improved? I would be interested in exploring ways to enhance the debugging process. And I've also noticed that there is currently no debug documentation. While I would be happy to create such documentation, I feel that it would be more effective if I could first modify and improve the existing debug methods.
Regarding the size, I think it still might be bigger than you think. From the script I had made before to summarize POST codes, there are still a few hundred calls to post_code, a lot of which still use raw hex codes which may conflict with each other. So there would be some work to figure out what those hex codes are being used for and replace it with an appropriate macro that fits a unified system. In addition, more calls to post_code() could be added using the ranges Martin had proposed for more granular POST code debug points.
The most common debugging methods in the codebase are serial UARTs, cbmem, and the flash console, and I think those are fairly well supported. There are additional methods such as spkmodem, NE2000 network console, and Oxford OXPCIe952 (PCIe serial adapter) which are quite old and haven't had a ton of development, and potentially could be improved. - Spkmodem: I think it does work, though I think some boards don't set up the audio codec to route the PC Beep to the speakers or line out jack. Could be better documented.
- NE2K: This is a rather old network card that hasn't been produced for years, and there probably isn't anything similar that would be simple enough to warrant adding a driver to coreboot (we don't really want to be implementing full network drivers)
- OxPCIe952: A fairly old card that is hard to come by for an affordable price nowadays. However, there are plenty of newer cards based on chips like the AX99100, which I think are simple enough (just basic PCIe bus init and base addresses, like the OxPCIe952). I do know that some of the PCIe init code to support the OxPCIe952 is currently broken
The GDB stub is also not well documented and there currently seems to be issues with it, based on some recent attempts to get it working from myself and someone on the OSFW Slack.
P.S. Many thanks to Felix and Nicholas for answering my question in the last year :) [1]
-- Joursoir
[0] https://review.coreboot.org/c/coreboot/+/73744 [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BBQRB...
On Tue, 28 Feb 2023 15:45:36 +0400 Joursoir chat@joursoir.net wrote:
Hello everyone,
I'm interested in participating in GSoC 2023. I would like to take part in the development of the coreboot, moreover I already have a bunch of commits in the flashrom. I find the "Libpayload based memtest payload" project interesting and have a few questions about it.
- This project was added a few years ago, also coreboot payload of
memtest based on memtest from 2019 (however, in 2022 memtest86+ v6 is released). So, maybe something has changed since that time and not reflected in the docs?
I found such ticket: https://ticket.coreboot.org/issues/184
- Do I understand correctly, that this payload should be memtest-fork
with a difference that will be built on libpayload and a design that will allow multiple architectures to be added?
- There are no mentors at the moment :(
I would appreciate any feedback.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Cheers,
Nicholas
[0] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/UQM7Y... [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2XG6O... [2] https://review.coreboot.org/c/coreboot/+/69865 [3] https://review.coreboot.org/c/coreboot/+/69866 [4] https://review.coreboot.org/c/coreboot/+/69867 [5] https://review.coreboot.org/c/coreboot/+/71591 [6] https://review.coreboot.org/c/coreboot/+/71592 [7] https://review.coreboot.org/c/coreboot/+/71593 [8] https://review.coreboot.org/c/coreboot/+/71594 [9] https://review.coreboot.org/c/coreboot/+/71596 [10] https://review.coreboot.org/c/coreboot/+/69712
Hi Nicholas,
Martin had brought up the topic of POST codes on the mailing list a few months ago [0][1] and proposed a new organization of the hex codes for better consistency and utilization of the 255 possible codes. He also had posted a few patches regarding POST codes [2][3][4][5][6][7][8][9].
Thanks for pointing out Martin's idea to me. I really like it and think it would be a great addition to the project. I especially appreciate the focus on section specific (SoC/CPU/mainboard) POST codes, which is an area that definitely needs improvement. It should allow us to handle larger amounts of POST codes more easily and quickly, and the debugging will be even easier. I'm definitely in favor of moving forward with this idea :)
I think the intention was to avoid showing certain POST options on platforms not supporting a certain method, such as outb port io POST codes which only make sense on x86 platforms. I don't think you would need to check if a specific (x86) board supports the 0x80 port as it's usually possible to configure that in the chipset to be forwarded over PCI or LPC such that something like an add-in card can be connected. However, looking at src/console/Kconfig, it seems like a lot of those Kconfigs already depend on CONFIG_PC80_SYSTEM which is only defined in arch/x86/Kconfig. Digging around in menuconfig, it seems like only the "Show POST codes on the debug console" show up on non-x86 systems.
I also thought so at first. But yeah, as you said, it only makes sense on x86 platforms and it's already done in Kconfigs. There's no suggestion regarding the POST IO port if you choose a non-x86 platform. I also noticed that some platforms explicitly set POST IO options (for example, config.prodrive_hermes[0] and config.protectli_vp4670[1]). Based on this, I decided that platform != architecture in this context. But as I now understand, we shouldn't care that much about that, at least not right now.
Regarding the size, I think it still might be bigger than you think. From the script I had made before to summarize POST codes, there are still a few hundred calls to post_code, a lot of which still use raw hex codes which may conflict with each other. So there would be some work to figure out what those hex codes are being used for and replace it with an appropriate macro that fits a unified system. In addition, more calls to post_code() could be added using the ranges Martin had proposed for more granular POST code debug points.
Probably yes. If not, then additional improvements suggested by Martin can be made.
The most common debugging methods in the codebase are serial UARTs, cbmem, and the flash console, and I think those are fairly well supported. There are additional methods such as spkmodem, NE2000 network console, and Oxford OXPCIe952 (PCIe serial adapter) which are quite old and haven't had a ton of development, and potentially could be improved.
- Spkmodem: I think it does work, though I think some boards don't
set up the audio codec to route the PC Beep to the speakers or line out jack. Could be better documented.
- NE2K: This is a rather old network card that hasn't been produced
for years, and there probably isn't anything similar that would be simple enough to warrant adding a driver to coreboot (we don't really want to be implementing full network drivers)
- OxPCIe952: A fairly old card that is hard to come by for an
affordable price nowadays. However, there are plenty of newer cards based on chips like the AX99100, which I think are simple enough (just basic PCIe bus init and base addresses, like the OxPCIe952). I do know that some of the PCIe init code to support the OxPCIe952 is currently broken
The GDB stub is also not well documented and there currently seems to be issues with it, based on some recent attempts to get it working from myself and someone on the OSFW Slack.
Oh, I appreciate this quick overview! The GDB stub seems the most interesting for me, so I'll try to take a look at it as soon as possible.
In the coming days, I will combine the GSoC project description and the Martin proposal, trying to cover all points with detailed description to make them clear for everybody (for example, diving into the method used by the SPD to identify Manufacturers as a similar concept for Driver/SuperIO/Debug IDs). You should expect results from me on Wednesday/Thursday.
I don't know what the postcode ranges are based on, but I assume that I still need to analyze where all these postcodes are currently used and, based on that, it may be necessary to make changes to these ranges.
On Thu, 16 Mar 2023 10:02:32 -0600 Nicholas Chin nic.c3.14@gmail.com wrote:
On 3/16/23 05:11, Joursoir wrote:
Hello again,
First of all, I would like to apologize for any inconvenience caused. I have carefully reviewed the project "Libpayload based memtest payload" and have come to the conclusion that it's not aligned with my interests. I would prefer to work on something more closely related to coreboot codebase. Therefore, I would like to propose "Fix POST code handling" as a more suitable alternative. So, I did some preliminary research on this project and have made some explorations which I'd like to share with you.
POST code macros are defined in the next locations:
- `src/commonlib/include/commonlib/console/post_codes.h` - a central point for POST codes used throughout coreboot
- `src/soc/amd/common/psp_verstage/include/psp_verstage.h` - amd-specific, POST codes over eSPI (`PSP_POSTCODES_ON_ESPI`)
- `src/soc/amd/common/block/include/amdblocks/post_codes.h` - amd-specific
- `src/soc/intel/common/block/include/intelblocks/post_codes.h` - intel-specific
- `src/include/cpu/intel/post_codes.h` - intel-specific
`post_code()` is defined in the two places:
- `src/include/cpu/x86/post_code.h` - used during bootblock stage
- `src/console/post.c` - the main function
Replacing old `outb(0x80, ...)`, updating `Documentation/POSTCODES` (and I think that it would be great to show it on the web-site doc), droping duplicated POST codes are all quite understandable thing.
Martin had brought up the topic of POST codes on the mailing list a few months ago [0][1] and proposed a new organization of the hex codes for better consistency and utilization of the 255 possible codes. He also had posted a few patches regarding POST codes [2][3][4][5][6][7][8][9].
However, I have doubts about Kconfig. The description says `Guard Kconfigs with a depends on to only show on supported platforms`. So, am I supposed to determine if the 0x80 port is supported by a particular platform by checking check the system documentation?
I think the intention was to avoid showing certain POST options on platforms not supporting a certain method, such as outb port io POST codes which only make sense on x86 platforms. I don't think you would need to check if a specific (x86) board supports the 0x80 port as it's usually possible to configure that in the chipset to be forwarded over PCI or LPC such that something like an add-in card can be connected. However, looking at src/console/Kconfig, it seems like a lot of those Kconfigs already depend on CONFIG_PC80_SYSTEM which is only defined in arch/x86/Kconfig. Digging around in menuconfig, it seems like only the "Show POST codes on the debug console" show up on non-x86 systems.
Additionally, I've sent a patch to demonstrate my intentions for this project. Please, take a look at it[0].
But I'm worried that it may be a relatively small project. However, I was wondering if there are any debugging methods currently being used in the codebase that could be improved? I would be interested in exploring ways to enhance the debugging process. And I've also noticed that there is currently no debug documentation. While I would be happy to create such documentation, I feel that it would be more effective if I could first modify and improve the existing debug methods.
Regarding the size, I think it still might be bigger than you think. From the script I had made before to summarize POST codes, there are still a few hundred calls to post_code, a lot of which still use raw hex codes which may conflict with each other. So there would be some work to figure out what those hex codes are being used for and replace it with an appropriate macro that fits a unified system. In addition, more calls to post_code() could be added using the ranges Martin had proposed for more granular POST code debug points.
The most common debugging methods in the codebase are serial UARTs, cbmem, and the flash console, and I think those are fairly well supported. There are additional methods such as spkmodem, NE2000 network console, and Oxford OXPCIe952 (PCIe serial adapter) which are quite old and haven't had a ton of development, and potentially could be improved.
- Spkmodem: I think it does work, though I think some boards don't
set up the audio codec to route the PC Beep to the speakers or line out jack. Could be better documented.
- NE2K: This is a rather old network card that hasn't been produced
for years, and there probably isn't anything similar that would be simple enough to warrant adding a driver to coreboot (we don't really want to be implementing full network drivers)
- OxPCIe952: A fairly old card that is hard to come by for an
affordable price nowadays. However, there are plenty of newer cards based on chips like the AX99100, which I think are simple enough (just basic PCIe bus init and base addresses, like the OxPCIe952). I do know that some of the PCIe init code to support the OxPCIe952 is currently broken
The GDB stub is also not well documented and there currently seems to be issues with it, based on some recent attempts to get it working from myself and someone on the OSFW Slack.
P.S. Many thanks to Felix and Nicholas for answering my question in the last year :) [1]
-- Joursoir
[0] https://review.coreboot.org/c/coreboot/+/73744 [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/BBQRB...
On Tue, 28 Feb 2023 15:45:36 +0400 Joursoir chat@joursoir.net wrote:
Hello everyone,
I'm interested in participating in GSoC 2023. I would like to take part in the development of the coreboot, moreover I already have a bunch of commits in the flashrom. I find the "Libpayload based memtest payload" project interesting and have a few questions about it.
- This project was added a few years ago, also coreboot payload of
memtest based on memtest from 2019 (however, in 2022 memtest86+ v6 is released). So, maybe something has changed since that time and not reflected in the docs?
I found such ticket: https://ticket.coreboot.org/issues/184
- Do I understand correctly, that this payload should be
memtest-fork with a difference that will be built on libpayload and a design that will allow multiple architectures to be added?
- There are no mentors at the moment :(
I would appreciate any feedback.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Cheers,
Nicholas
[0] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/UQM7Y... [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/2XG6O... [2] https://review.coreboot.org/c/coreboot/+/69865 [3] https://review.coreboot.org/c/coreboot/+/69866 [4] https://review.coreboot.org/c/coreboot/+/69867 [5] https://review.coreboot.org/c/coreboot/+/71591 [6] https://review.coreboot.org/c/coreboot/+/71592 [7] https://review.coreboot.org/c/coreboot/+/71593 [8] https://review.coreboot.org/c/coreboot/+/71594 [9] https://review.coreboot.org/c/coreboot/+/71596 [10] https://review.coreboot.org/c/coreboot/+/69712
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hello everyone,
I have uploaded my draft proposal to Google Docs. Available via this link[0]. Please note that any changes you make will be in the form of suggestions. I will continue to make improvements to the proposal.
Feel free to provide your feedback and suggestions as well!
-
Joursoir -
Nicholas Chin