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/BBQRBIWYZR53X3OEWONCLTTBWJVC7XA5/ On Tue, 28 Feb 2023 15:45:36 +0400 Joursoir <c...@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. > > 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. > _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
