search

intel / FSP

Intel(R) Firmware Support Package (FSP)
Other
288 stars 126 forks source link

FSP 1.1 and later clarification #61

Closed PQURETechnology closed 6 months ago

PQURETechnology commented 3 years ago

Hi,

I have been looking for some information required for FSP 1.1 and later.

As FSP API has been split up to more calls, it is unknown using the new APIs wether TSEG, GFX buffers etc. has been initialised by FSP or not.

It would be natural to make the conclusion that they are initialised by the memory API function. It is important from a boot loader perspective to know when it initialised and the order of the stolen memory regions.

From some google source code for Skylake it looks like stolen memory is subtracted in the following order: BDSM, BGSM and TSEG.

The questions are:

  1. Is the stolen memory regions above initialised in the memory init or silicon init functions?
  2. In what order ?

A clarification would be greatly appreciated.

nate-desimone commented 6 months ago

The number of stolen memory regions, their purpose, and their ordering can vary between Intel processor designs. The FSP specification does not require any specific behavior. Describing the behavior of stolen memory regions is one of the purposes of the FSP integration guide.

For example, here is the memory map for Skylake & Kabylake:

image

Hope this helps.

PQURETechnology commented 6 months ago

FSP is unfortunately depending on several UEFI structures lik HOBs. So it's not an independent firmware initialising the DRAM and the silicon. So in many cases some boot loaders or BIOSes may not be able to use it. I integrated the 1.1 FSP in my BIOS, implementing the UEFI HOBs and all. It hang in the silicon init part. Later when implementing the BIOS on the same architecture without FSP, I found that some parts in the hardware was depending on what the BIOS has done before calling the FSP services. In order to be a real black box, the FSP should clearly define all outside dependencies. It should also define what parts of the silicon that should be initialised by the BIOS or boot loader. So in my point of view, the FSP should be totally independent of UEFI and clearly specify what's the BIOS/BootLoader job and whats the FSP job. It should also specify the memory regions and the structures used for calling the services should be proprietary for the FSP. It would then be a totally independent black box.

I would prefer to use FSP if it was possible, as doing all the memory and initialisation is a very time consuming and tedious task. I would have a fully working BIOS with a FSP that works in only 2 weeks. Without FSP it takes 6 - 12 months due to the complexity, lack of documentation and support. So I like the FSP idea, but they should have implemented in differently and make sure it works. It should definitely not hang if the BootLoader/BIOS provide the proper parameters and not depend on UEFI structures.