Re: Request for Guidance on Coreboot Porting for Raptor Lake-S RVP + DDR5 Motherboard

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 will 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 octocoupler 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
--
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
--
Amtsgericht Augsburg: HRB 27755
USt-IdNr.: DE815420876
CEO: Herbert Feiler
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]