[XL] Change in coreboot[main]: soc/intel/ptl: Do initial Panther Lake SoC commit till bootblock

[Subrata Banik (Code Review)]

Attention is currently required from: Ashish Kumar Mishra, Dinesh Gehlot, Elyes Haouas, Eran Mitrani, Felix Singer, Jakub Czapiga, Jérémy Compostella, Kapil Porwal, Saurabh Mishra, Tarun.

Subrata Banik has posted comments on this change by Saurabh Mishra. ( https://review.coreboot.org/c/coreboot/+/83354?usp=email )

Change subject: soc/intel/ptl: Do initial Panther Lake SoC commit till bootblock
......................................................................

Patch Set 35:

(1 comment)

File src/soc/intel/pantherlake/Kconfig:

https://review.coreboot.org/c/coreboot/+/83354/comment/818eb259_d2e21928?usp... :
PS30, Line 141: 0xfe02c000
> why would FSP even bother to initialise the UART when we are setting UPD to PchSerialIoSkipInit to ensure FSP is not reprogramming the UART again.
> > We are setting PchSerialIopci in lpss uart0 same as previous platforms.

I will try setting PchSerialIoSkipInit for MTL and share my feedback.
> Looking at the FSP code imo is not the correct practice for below reasons
>
> what if tomorrow FSP decides to change this address again, how to ensure FSP and coreboot status in sync?
> not everyone has FSP source code to take a look.
>
> It would be ideal if we could keep this minimal bootloader requirement in the FSP integration guide (if possible) or if FSP could publish its own memory map so that the BL knows which addresses to avoid. In my opinion, this is just another reserved range that belongs to PCH reserved memory, so there is no need to "align" to FSP. FSP and coreboot can have different addresses as long as FSP honors the UPD (PchSerialIoSkipInit) and does not touch the UART.
> > Agree on that we started discussion to bring UPD in FSPM/S where we can pass the address which FSP should use no need to see the FSP code or align to FSP. currently this UPD is part of FSPT.

we don't use FSP-T hence, ideally this is not applicable to us.