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