Re: Request for Guidance on Coreboot Porting for Raptor Lake-S RVP + DDR5 Motherboard
"Keshavamurthy K [Firmware-NTL] via coreboot" <[email protected]> Tue, 16 Jun 2026 12:12:24 +0000
| Newsgroups | gmane.linux.bios |
|---|---|
| Message-ID | <PN2P287MB04160CBA120FE33DE50329538EE52@PN2P287MB0416.INDP287.PROD.OUTLOOK.COM> |
--===============7259050023607664387== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_PN2P287MB04160CBA120FE33DE50329538EE52PN2P287MB0416INDP_" --_000_PN2P287MB04160CBA120FE33DE50329538EE52PN2P287MB0416INDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Alicja and Florian, Thank you both for the detailed guidance and recommendations. I have currently set up the Coreboot build environment and am able to succe= ssfully generate a ROM image using the existing Alder Lake reference platfo= rm (ADL_RVP) configuration. Before proceeding further, I have one concern. We have access to an Intel R= VP board based on the B760 desktop chipset with DDR5 memory, and I am cons= idering using it as an initial validation platform. Would it be safe and appropriate to flash a Coreboot ROM generated from the= ADL_RVP configuration directly onto the Intel ADL RVP DDR5 board for early= testing, or would you recommend first creating a dedicated mainboard port = and adapting the GPIO, memory, PCIe, and board-specific configuration befor= e attempting any flashing? My concern is whether flashing a generic ADL_RVP image could lead to issues= related to GPIO configuration, FSP UPD settings, memory initialization, or= boot flow differences on the target RVP platform. Any recommendations on the safest approach for initial bring-up would be gr= eatly appreciated. Thank you again for your support. Best Regards, Keshavamurthy K ________________________________ From: Florian Jung via coreboot <[email protected]> Sent: Monday, June 15, 2026 5:36 PM To: [email protected] <[email protected]> Subject: [coreboot] Re: Request for Guidance on Coreboot Porting for Raptor= Lake-S RVP + DDR5 Motherboard [You don't often get email from [email protected]. Learn why this is im= portant at https://aka.ms/LearnAboutSenderIdentification ] Hey Keshavamurthy, since I just recently got into porting an Alder Lake-S board, too, I'm gonna add my 2 cents, here, too: Am 15.06.26 um 12:51 schrieb Keshavamurthy K [Firmware-NTL] via coreboot: > I would > appreciate any recommendations on the best existing mainboards or > reference implementations that can be used as a starting point for a > custom Raptor Lake-S + DDR5 design. My work is heavily inspired by src/mainboard/msi/{ms7d25,ms7e06}, I'd recommend looking into these. Also, try `git grep 'soc/intel/alderlake' '*.cb'` to find more sources of inspiration. I also found it useful to look into `util/autoport`. Unfortunately, the tool does not support any recent platform, but reading the code is, in parts, like a "how to port"-tutorial. > I am particularly looking for guidance on the following topics: > > * Intel FSP requirements and integration for Raptor Lake-S. > * DDR5 memory initialization and training. You won't need to worry about this, coreboot does The Right Thing[tm]; except that you'll need tell it where to find the RAM SPDs, as Alicja mentioned. > * H610 chipset configuration and board enablement. Scroll through soc/intel/alderlake/chip.h and try to make sense of the field names. This already helps a lot. > * GPIO and pad configuration setup. Use `util/inteltool` to read GPIO/Pad config from your vendor's firmware, then use `util/intelp2m` to generate a `gpio.h` file (and don't forget to call `gpio_configure_pads`). > * Intel ME firmware requirements. > * Boot Guard considerations during development. You can ignore that for now, just don't overwrite any flash portions which are not in the BIOS region. > * PCIe, SATA, USB, and onboard peripheral initialization. You'll need the board schematics (or at least know which clock/data lines are routed where), then you enter that information into your device tree (check how other boards do it). That's basically it. Oh and in case of doubt, disable ASPM, it tends to cause problems :D. > * Early boot debugging methods (UART, POST codes, external SPI > flashing, etc.). Easiest IMHO is flash console, but it wears out your flash. You can enable it in Kconfig. Am 15.06.26 um 13:17 schrieb Alicja Michalska: > Just use 0x3f8 RS232 provided by SuperIO and configure it accordingly in = bootblock. Also, this. I found the PnP ISA Specification (http://www.osdever.net/documents/PNP-ISA-v1.0a.pdf) helpful to figure out how to even configure these SuperIOs, but maybe that's just me loving to read documentation :D Early console is extremely valuable, life becomes so much better if you have printf-debugging. Before printf debugging works, I found that triangulating with a hard reset to be useful; you can trigger it by just ~two IO port writes and it gives you distinguishable behavior (as opposed to `while (true) {}`) even if nothing else works yet. Not fun, but if that's the only thing you have, it's valualble. Am 15.06.26 um 13:17 schrieb Alicja Michalska: > 1. Invest in EM100 (flash emulator), it will save you so much time it wil= l essentially pay for itself. Using a fast(!) flasher (e.g. CH347; not CH341, it's dead slow) and having a proper connector to the flash chip (not a hand-held pogo pin clamp) works fine for me. Especially in conjunction with the `--flash-contents` and `--noverify` flags of flashrom, flashing is a matter of seconds (do know what you're doing, though!) > 3. Add GPIO-controlled AC plug to power the system on, throw in an octoco= upler for good measure to control front-panel remotely That's definitely the more remote-friendly solution, but frankly just reaching over my desk and switching the power on my PSU does just fine for me. Oh, and I soldered together a "front panel" consisting of literally just a 5x2 socket, two buttons for power and reset and two LEDs. This allows me to use the bare board without having it in a case (with a frontpanel) obstructing my access. Also, I'd recommend dumping all information from the vendor firmware first, including but not limited to actual flash contents, ACPI tables, HDA verbs (see autoport), GPIO config etc etc. Good luck and have fun :) Best regards, Florian -- Florian Jung Development -- TUXEDO Computers GmbH Alter Postweg 101 ~ D-86159 Augsburg -- E-Mail: [email protected] -- www.tuxedocomputers.com<http://www.tuxedocomputers.com> -- Amtsgericht Augsburg: HRB 27755 USt-IdNr.: DE815420876 CEO: Herbert Feiler -- Florian Jung Development -- TUXEDO Computers GmbH Alter Postweg 101 ~ D-86159 Augsburg -- E-Mail: [email protected] -- www.tuxedocomputers.com<http://www.tuxedocomputers.com> -- Amtsgericht Augsburg: HRB 27755 USt-IdNr.: DE815420876 CEO: Herbert Feiler _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected] Note : " We Never inform change of Bank details by email. If you receive an= y such emails from our domain/users. Please don't respond, and contact us s= eparately " --_000_PN2P287MB04160CBA120FE33DE50329538EE52PN2P287MB0416INDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Hello Alicja and Florian,</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Thank you both for the detailed guidance and recommendations.</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> I have currently set up the Coreboot build environment and am able to succe= ssfully generate a ROM image using the existing Alder Lake reference platfo= rm (ADL_RVP) configuration.</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Before proceeding further, I have one concern. We have access to an Intel R= VP board based on the B760 desktop chipset with DDR5 memory, and I am= considering using it as an initial validation platform.</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Would it be safe and appropriate to flash a Coreboot ROM generated from the= ADL_RVP configuration directly onto the Intel ADL RVP DDR5 board for early= testing, or would you recommend first creating a dedicated mainboard port = and adapting the GPIO, memory, PCIe, and board-specific configuration before attempting any flashing?</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> My concern is whether flashing a generic ADL_RVP image could lead to issues= related to GPIO configuration, FSP UPD settings, memory initialization, or= boot flow differences on the target RVP platform.</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Any recommendations on the safest approach for initial bring-up would be gr= eatly appreciated.</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Thank you again for your support.</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Best Regards,</div> <div class=3D"elementToProof" style=3D"margin-top: 1em; margin-bottom: 1em;= font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helv= etica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Keshavamurthy K</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div id=3D"appendonsend"></div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Florian Jung via core= boot <[email protected]><br> <b>Sent:</b> Monday, June 15, 2026 5:36 PM<br> <b>To:</b> [email protected] <[email protected]><br> <b>Subject:</b> [coreboot] Re: Request for Guidance on Coreboot Porting for= Raptor Lake-S RVP + DDR5 Motherboard</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">[You don't often get email from coreboot@coreboot.= org. Learn why this is important at <a href=3D"https://aka.ms/LearnAboutSenderIdentification">https://aka.ms/Le= arnAboutSenderIdentification</a> ]<br> <br> Hey Keshavamurthy,<br> <br> since I just recently got into porting an Alder Lake-S board, too, I'm<br> gonna add my 2 cents, here, too:<br> <br> Am 15.06.26 um 12:51 schrieb Keshavamurthy K [Firmware-NTL] via coreboot:<b= r> <br> > I would<br> > appreciate any recommendations on the best existing mainboards or<br> > reference implementations that can be used as a starting point for a<b= r> > custom Raptor Lake-S + DDR5 design.<br> <br> My work is heavily inspired by src/mainboard/msi/{ms7d25,ms7e06}, I'd<br> recommend looking into these.<br> Also, try `git grep 'soc/intel/alderlake' '*.cb'` to find more sources<br> of inspiration.<br> <br> I also found it useful to look into `util/autoport`. Unfortunately, the<br> tool does not support any recent platform, but reading the code is, in<br> parts, like a "how to port"-tutorial.<br> <br> > I am particularly looking for guidance on the following topics:<br> ><br> > * Intel FSP requirements and integration for Raptor Lake-S= .<br> > * DDR5 memory initialization and training.<br> <br> You won't need to worry about this, coreboot does The Right Thing[tm];<br> except that you'll need tell it where to find the RAM SPDs, as Alicja<br> mentioned.<br> <br> > * H610 chipset configuration and board enablement.<br> <br> Scroll through soc/intel/alderlake/chip.h and try to make sense of the<br> field names. This already helps a lot.<br> <br> > * GPIO and pad configuration setup.<br> <br> Use `util/inteltool` to read GPIO/Pad config from your vendor's<br> firmware, then use `util/intelp2m` to generate a `gpio.h` file (and<br> don't forget to call `gpio_configure_pads`).<br> <br> > * Intel ME firmware requirements.<br> > * Boot Guard considerations during development.<br> <br> You can ignore that for now, just don't overwrite any flash portions<br> which are not in the BIOS region.<br> <br> > * PCIe, SATA, USB, and onboard peripheral initialization.<= br> <br> You'll need the board schematics (or at least know which clock/data<br> lines are routed where), then you enter that information into your<br> device tree (check how other boards do it). That's basically it.<br> <br> Oh and in case of doubt, disable ASPM, it tends to cause problems :D.<br> <br> > * Early boot debugging methods (UART, POST codes, external= SPI<br> > flashing, etc.).<br> <br> Easiest IMHO is flash console, but it wears out your flash. You can<br> enable it in Kconfig.<br> <br> Am 15.06.26 um 13:17 schrieb Alicja Michalska:<br> > Just use 0x3f8 RS232 provided by SuperIO and configure it accordingly = in bootblock.<br> <br> Also, this. I found the PnP ISA Specification<br> (<a href=3D"http://www.osdever.net/documents/PNP-ISA-v1.0a.pdf">http://www.= osdever.net/documents/PNP-ISA-v1.0a.pdf</a>) helpful to figure<br> out how to even configure these SuperIOs, but maybe that's just me<br> loving to read documentation :D<br> <br> Early console is extremely valuable, life becomes so much better if you<br> have printf-debugging.<br> <br> Before printf debugging works, I found that triangulating with a hard<br> reset to be useful; you can trigger it by just ~two IO port writes and<br> it gives you distinguishable behavior (as opposed to `while (true) {}`)<br> even if nothing else works yet. Not fun, but if that's the only thing<br> you have, it's valualble.<br> <br> Am 15.06.26 um 13:17 schrieb Alicja Michalska:<br> > 1. Invest in EM100 (flash emulator), it will save you so much time it = will essentially pay for itself.<br> <br> Using a fast(!) flasher (e.g. CH347; not CH341, it's dead slow) and<br> having a proper connector to the flash chip (not a hand-held pogo pin<br> clamp) works fine for me. Especially in conjunction with the<br> `--flash-contents` and `--noverify` flags of flashrom, flashing is a<br> matter of seconds (do know what you're doing, though!)<br> <br> > 3. Add GPIO-controlled AC plug to power the system on, throw in an oct= ocoupler for good measure to control front-panel remotely<br> <br> That's definitely the more remote-friendly solution, but frankly just<br> reaching over my desk and switching the power on my PSU does just fine<br> for me.<br> <br> Oh, and I soldered together a "front panel" consisting of literal= ly just<br> a 5x2 socket, two buttons for power and reset and two LEDs. This allows<br> me to use the bare board without having it in a case (with a frontpanel)<br= > obstructing my access.<br> <br> Also, I'd recommend dumping all information from the vendor firmware<br> first, including but not limited to actual flash contents, ACPI tables,<br> HDA verbs (see autoport), GPIO config etc etc.<br> <br> Good luck and have fun :)<br> <br> Best regards,<br> Florian<br> <br> <br> <br> --<br> Florian Jung<br> Development<br> --<br> TUXEDO Computers GmbH<br> Alter Postweg 101 ~ D-86159 Augsburg<br> --<br> E-Mail: [email protected]<br> --<br> <a href=3D"http://www.tuxedocomputers.com">www.tuxedocomputers.com</a><br> --<br> Amtsgericht Augsburg: HRB 27755<br> USt-IdNr.: DE815420876<br> CEO: Herbert Feiler<br> <br> --<br> Florian Jung<br> Development<br> --<br> TUXEDO Computers GmbH<br> Alter Postweg 101 ~ D-86159 Augsburg<br> --<br> E-Mail: [email protected]<br> --<br> <a href=3D"http://www.tuxedocomputers.com">www.tuxedocomputers.com</a><br> --<br> Amtsgericht Augsburg: HRB 27755<br> USt-IdNr.: DE815420876<br> CEO: Herbert Feiler<br> _______________________________________________<br> coreboot mailing list -- [email protected]<br> To unsubscribe send an email to [email protected]<br> </div> </span></font></div> Note : " We Never inform change of Bank details by email. If you recei= ve any such emails from our domain/users. Please don’t respond, and c= ontact us separately " </body> </html> --_000_PN2P287MB04160CBA120FE33DE50329538EE52PN2P287MB0416INDP_-- --===============7259050023607664387== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected] --===============7259050023607664387==--