intel/fsp

Intel(R) Firmware Support Package (FSP)

fsp's Issues

Braswell MR2: Internal UART can't be disabled

Internal UART can't be disabled using UPDs PcdEnableHsuart0/PcdEnableHsuart1.
See https://review.coreboot.org/#/c/coreboot/+/28464/ for reference.

Microcode for E3825

Hello,

I am trying to compile coreboot for E3825.
It need Microcode file .
How to get them from FSP files ?
In the past it was with FSP files.

Best

FSP: Apollolake: dies in fsp_silicon_init

I am having a wired issue on a custom APL based system. After about 150 warm-reboots the device does not boot up and I pined it to the silicon init call in done by coreboot.
I think its related to PCIe as we are switching FPGA vendors and the old one there are no issues. So it might be great to gain access to a debug version of the APL FSP. If it helps the company I work for have NDAs signed with Intel.

Testing

Testing only.

CoffeeLakeFspBinPkg: Hangs w/ coreboot since update to FSP 7.0.68.40

Since commit f3ecfc4 (Coffee Lake FSP 7.0.68.40) we are unable to boot our CoffeeLake-S and -H systems. FSP-M simply hangs, no error reported.

Was this build tested? If so, with what hardware and bootloader combinations?

BroadwellDEFspPkgBin hiding IIO port for GbE after MemoryInit breaks NotifyStage #35

Reopening, since this was closed without solution. #35
@PatrickRudolph @anpetrovfb @nate-desimone

Braswell: Different FSP signatures

With d1c99a5 (MR2 version of Braswell FSP) the FSP_IMAGE_ID changed from $BSWFSP$ to BSWSBFSP. What was the reason for this change? Does this refer to different branches of FSP?

FSP Broadwell DE not up-to-date

Hey folks,

We are having trouble finding the Broadwell DE MR2 Gold release on
Github. Any information if you can make it available?

CherryTrail : Missing support

CherryTrail are Airmont based, where Airmont is the 14 nm die shrink of Silvermont

Other Airmont FSP support exist : Braswell

When Silvermont have BayTrail FSP

Braswell OR BayTrail can be used for CherryTrail chips ?

KabylakeFspBinPackage Missing data in DIMM_INFO FSP 2.0

Hi,

i just noticed while I was creating SMBIOS Type17 Entries in coreboot, that the fields MfgId and ModulePartNum in the DIMM_INFO Struct are empty. In Coreboot you can find the struct here: coreboot/3rdparty/fsp/KabylakeFspBinPkg/Include/MemInfoHob.h.

Best Regards,

FSP DRAM configuration for memory with only single channel

Hello,
We're using the custom hardware (let's call it BRC) based on the Apollo lake's Leaf hill crb.

BRC -> 4 x 16 gib = 8 GiB of memory(4 dual-rank chips organized as 512 M by 32 bits.). This configuration i am able to boot up.

Now, we have new variant of this board (just the memory downsized) with 1 x 8 gib = 1 GiB of LPDDR4 memory (1 single-rank chip organized as 256 M by 32 bits.).
(the other 3 chips were not populated).

(Note: Micron memory is being used : MT53E256M32D2DS-053 in both cases).

This is my DRAM config for these two boards:
8 GiB of memory(4 dual-rank chips organized as 512 M by 32 bits):
Channeln (n = 0, 1, 2, 3):
RankEnable :0x1
DeviceWidth :0x1
DramDensity :0x4
Option :0x3
OdtConfig :0x0
TristateClk1 :0x0
Mode2N :0x0
OdtLevels :0x0

1 GiB of memory(1 single-rank chip organized as 256 M by 32 bits):
Channel0:
RankEnable :0x1
DeviceWidth :0x1
DramDensity :0x2
Option :0x3
OdtConfig :0x0
TristateClk1 :0x0
Mode2N :0x0
OdtLevels :0x0

Channeln (n = 1, 2, 3):
RankEnable :0x0

With this configuration, SBL is not getting past fspmemoryinit(). I am using the FSP debug library from Intel. From that, i am not quite sure what's going wrong. Does anyone of you have experience of using only single channel memory configuration?

I am enclosing the beyond compare snapshot between these two versions (working 4-channel board and single channel board).
Also enclosing the console log for this single channel board. Any leads on this will be really helpful.
brc3-1gb-fsp-debug-only-RankEnable-disabled.txt

Regards,
Mahesh.

Denverton: Inconsistent type names

Currently the Denverton FSP headers use FSP{T,M,S}_CONFIG as type name. All of the other FSP2 platforms use FSP_{T,M,S}_CONFIG.

Please change that to be consistent.

Kabylake MRC caching does not work with ECC memory

Kabylake MRC caching does not work with ECC memory

Can I get the document id for the following topics?

1. Intel fsp src code.

2. BlStitch utility for BroadwellDe soc.

3. SSFITC utility for BroadwellDe

Regards,
AC

DDR4 memory test failure

We have designed a custom board based on xeon D1559 processor. We used on board DDR4 memory chip of 8Gb with Part Number: MT40A512M16LY-062E ( https://www.micron.com/products/dram/ddr4-sdram/part-catalog/mt40a512m16ly-062e )
The memory per channnel is 4GB (1GB * 4 chips).
We prepared the SPD binary and provided it as memory down configuration. We are using the Grangeville fsp package (BDXDE_FSP_MR_002_RC5_20161115).
While the system boots up, the memory test failed. Our memory is in 512x16 configuration but we assume that the current code tests memory in x8 configuration. I have attached the debug log for reference.
Please let us know the area in which we can debug more in MRC or in SPD to resolve this issue.
Thanks in advance,
Omkar
DebugLog.txt

[Enhancement] Proposal FSP-M multi-core ram training

Hey Intel FSP team,

We have a feature request to speed up the ram training
by using multiple cores for it.

Braswell: FSP Integration Guide of-of-date

The Braswell FSP Integration Guide states that the base address for FSP binary is 0xfff20000. However, current MR2 release FSP binary base address is 0xfff9c000. Could You please update the documentation or the binary?

FSP switches SAI

FSP switches to POSTBOOT_SAI, there are several issues with that. TL;DR while it probably tries to achieve the opposite, it undermines firmware quality and security.

• In some bootloaders FSP may run long before EOP, this means most of the bootloader runs with POSTBOOT_SAI.
• In the EDS, implications of the SAI switch are not documented. Virtually for every register, it is unknown if it is still accessible after the SAI switch.
• The SAI switch seems to force the bootloader to do some things in SMM. AFAIK, the use of SMM as a more privileged execution mode is generally discouraged, even internally at Intel. This means FSP forces bootloader development to go backwards.
• Generally, security may be undermined if FSP locks something to early, i.e. in a state that doesn't play well with the security concept of the bootloader.

Especially the lack of documentation leads to many bugs in firmware. Even Intel developers working on bootloaders such as coreboot don't seem to know the implications of the SAI switch or lack the resources to re-evaluate all bootloader code wrt. the SAI switch. I fear there is currently a race to the bottom of firmware quality going on: the need to fix bugs eats too many resources which leads to more bugs for future products, eating even more resources. Plus, these resources are limited because of the lack of public documentation.

Two possible solutions come to mind:

1. Do the SAI switch in the very last phase of FSP (or maybe even add an additional phase to lock things down?) and comprehensively document all the implications of the switch. For instance, in all the register tables, there could be column that mentions the applicable SAIs.
2. Make the SAI switch optional in FSP and document how the boot loader can take care of it. This would not only prevent all SAI-switch related bugs but also leave the security concept in a single place, the bootloader. That the configuration of security mechanisms and their locking are currently split between bootloader and FSP makes it very hard to configure an Intel platform reasonably secure (unless you rely on additional security chips in your platform, which is not always affordable).

I think 1. is only feasible in the long run. But maybe it's not too late to set up 2. for all the FSPs that do the SAI switch yet?

Kabylake MRC caching does not work with ECC memory #37

Reopening, since this was closed without solution. #37

BroadwellDEFspPkgBin hiding IIO port for GbE after MemoryInit breaks NotifyStage

Looks like hiding IIO port for GbE (0:2.2 and 0:2.3) after MemoryInit causes FspNotify to hang. Current workaround is to do the hiding before MemoryInit

Kabylake: FSP leaves PAVPC and TSEGMB unlocked when SGX and HT are enabled

FSP leaves PAVPC and TSEGMB unlocked when SGX and HT are enabled. MSR_LT_LOCK_MEMORY does not get set.

MSR_LT_LOCK_MEMORY is not documented!
-> please document

Kabylake: FSP modifies AHCI/SATA capabilities

On Kabylake FSP sets CAP.SSS=0 when not at least one bit in SataPortsSpinUp is set. SataPortsSpinUp[x]=1 sets PxCMD.SUD=1.

Is there any reason FSP is disabling a CAP? IMHO it does not make any sense to make this dependent on SataPortsSpinUp, as the OS assumes the AHCI controller does not support this, then.

BDW-DE FSP: no memory found on MonoLake server

Hi, on a MonoLake server (BDW-DE based), we get following error messages from FSP:
Detect DIMM Configuration -- Started
Detect DIMM Configuration - 353ms
Get Slave Data -- Started
Get Slave Data - 0ms
Check POR Compatibility -- Started
No memory found!

FatalError: SocketId = 0 registered Major Code = 0xE8, Minor Code = 0x 1

Could you help to find out what this means? How to resolve this issue? Traditional firmware works well on this server.

Braswell: Conflicting FSP versions

Hi,

we have again spotted an oddity in coreboot that makes it look like there were forks of FSP. In our repository [1] we have headers for $BSWFSP$ rev 01010700 while here on Github we had $BSWFSP$ rev 01010200 first (MR1?), and now BSWSBFSP rev 01010401 (MR2?).

Is there a chance to get a current $BSWFSP$ into your repository? and in case that it wouldn't cover all features of BSWSBFSP, have both coexist on the same branch?

Best regards,
Nico

[1] https://review.coreboot.org/cgit/coreboot.git/tree/src/vendorcode/intel/fsp/fsp1_1/braswell/FspUpdVpd.h

BroadwellDEFspBinPkg MR2 locks IA32_FEATURE_CONTROL in FSP-M

The IA32_FEATURE_CONTROL MSR is locked on all cores after memory init, but it should be locked in FspNotify(EnumInitPhaseReadyToBoot).
That would allow coreboot to set sane values, instead of the FSP default of 0x4.

Inconsistent folder structure

Folder structure is inconsistent, most of platforms have binary files in FspBin subfolder, while Kabylake and CoffeeLake have theirs binaries in main platform folder.

BayTrailFspBinPkg: FSP getting stuck when PCIe enabled in x4

Hi
Whenever we enable PCIe in x1(All 4 ports in x1 configuration) the board boots well as expected and communication works.
But as soon as we change the configuration in flash descriptor to PCIe x4(just port 1 in x4 configuration), the link gets up when the board boots but the FSP gets stuck. Is there a way we can debug this?
OR the FSP supports only x1 configuration?

Comet Lake: Changed description of Serial Io Device Modes

I hope you don't mind questions about FSP versions that didn't make it into this repo yet (if you do, just tell me).

We have here new UPD headers for Comet Lake. Most of the options are very similar to those of the Coffee Lake FSP. One change resulted in some confusion, though: For the serial i/o mode options we had for CFL (SerialIoDevMode):

0:Disabled, 1:PCI Mode, 2:Acpi mode, 3:Hidden mode (Legacy UART mode)

which is now for CML (SerialIoUartMode amongst others):

0:SerialIoUartDisabled, 1:SerialIoUartPci, 2:SerialIoUartHidden, 3:SerialIoUartCom,                    
4:SerialIoUartSkipInit

So here is the question: Beside the additional value 4, did any semantics change for the values 0 to 3? or was it only the description that changed?

FSP: Insufficient interface documentation

Even with the integration guide it's impossible to understand what UPDs are actually doing.
If a firmware developer can't even properly understand what UPDs should be set, how should one use FSP in a secure manner?
Please improve the interface documentation of all FSP releases and explain in detail what an UPD is actually doing, which dependencies it has, if it works in RELEASE/DEBUG mode only ...

CoffeeLakeFspBinPkg: FSP-M hangs if no IGD present

Hi,
we observed the behaviour that if we do not have a IGD present the FSP-M seems to hang in coreboot. The last Postcode that we see is 0xda50 which is according to the Integration Guide "Initializing Graphics". We turned the graphics off via the UPD options InternalGfx = 0 and set IgdDvmt50PreAlloc to 0. Does it has been tested on CPUs without IGD yet? Do we have to set more UPDs in order to make it work without IGD?

@nate-desimone

FSP tooling only support FSP 2.0

The FSP tooling which is needed for rebasing only supports FSP 1.0.
Is there a way that Intel adds 1.0 and 1.1 support as well?

Broadwell-DE CPUs soft hang issues

We've determined certain SKUs with 32 CPUs exhibit soft lock up issues. This is semi-random but warm reboot tests reliably start encountering it on 20-30 iterations.
This manifests itself in the following kernel messages:

[   38.084920] INFO: rcu_sched detected stalls on CPUs/tasks:
[   38.084924]  2-...: (20978 ticks this GP) idle=e23/140000000000001/0 softirq=98/98 fqs=5250
[   38.084925]  (detected by 28, t=21002 jiffies, g=-224, c=-225, q=24)
[   38.084927] Sending NMI from CPU 28 to CPUs 2:
[   38.085930] NMI backtrace for cpu 2
[   38.085931] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.11.3-41_fbk10_3544_gea63179 #41
[   38.085931] Hardware name: Open Compute Project Mono Lake/Mono Lake, BIOS 4.10-1401-g6a657c2646-dirty 11/05/2019
[   38.085931] task: ffff88085b678000 task.stack: ffffc90003130000
[   38.085932] RIP: 0010:delay_tsc+0x35/0x50
[   38.085932] RSP: 0000:ffff88085ee83c30 EFLAGS: 00000097
[   38.085933] RAX: 000000789b9285bb RBX: ffffffff82311f80 RCX: 000000789b927ee9
[   38.085933] RDX: 00000000000006d2 RSI: 0000000000000002 RDI: 0000000000000706
[   38.085934] RBP: ffff88085ee83c40 R08: 0000000000000010 R09: 0000000000000000
[   38.085934] R10: 00000000000002bb R11: 0000000000000000 R12: 00000000000026e9
[   38.085934] R13: 0000000000000020 R14: ffffffff820d1388 R15: 0000000000000034
[   38.085935] FS:  0000000000000000(0000) GS:ffff88085ee80000(0000) knlGS:0000000000000000
[   38.085935] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   38.085935] CR2: ffffc90003944000 CR3: 000000007de09000 CR4: 00000000003406e0
[   38.085936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   38.085936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   38.085936] Call Trace:
[   38.085936]  <IRQ>
[   38.085937]  ? __const_udelay+0x32/0x40
[   38.085937]  wait_for_xmitr+0x2c/0xa0
[   38.085937]  serial8250_console_putchar+0x1c/0x30
[   38.085937]  ? wait_for_xmitr+0xa0/0xa0
[   38.085938]  uart_console_write+0x30/0x70
[   38.085938]  serial8250_console_write+0xa1/0x200
[   38.085938]  ? msg_print_text+0xa2/0x110
[   38.085939]  univ8250_console_write+0x22/0x30
[   38.085939]  console_unlock+0x3e5/0x520
[   38.085939]  vprintk_emit+0x225/0x2c0
[   38.085939]  vprintk_default+0x1f/0x30
[   38.085940]  vprintk_func+0x27/0x60
[   38.085940]  printk+0x43/0x4b
[   38.085940]  rcu_check_callbacks+0x465/0x8b0
[   38.085940]  ? account_system_index_time+0x8c/0xa0
[   38.085941]  ? tick_nohz_handler+0xf0/0xf0
[   38.085941]  update_process_times+0x57/0xa0
[   38.085941]  tick_sched_timer+0x57/0xd0
[   38.085941]  __hrtimer_run_queues+0xd8/0x220
[   38.085942]  hrtimer_interrupt+0xab/0x190
[   38.085942]  ? unmap_pmd_range+0x2d0/0x2d0
[   38.085942]  smp_apic_timer_interrupt+0x63/0x90
[   38.085942]  apic_timer_interrupt+0x86/0x90

The solution of this issue is to rebuild FSP with maximum number of CPUs bumped to 32.

CoffeelakeFspBinPkg: Fix Inconsistent File Naming Convention in Fsp.fd

The file in CoffeelakeFspBinPkg has the name "FSP.fd". In other FspBinPkg directories, the convention is "Fsp.fd". The request is to use "Fsp.fd" so generic scripts in case-sensitive operating systems can generically handle this file.

MP_SERVICES pointer is optional

Hi,

As discussed on review.coreboot.org, looks like the MP_SERVICES pointer is not a requirement:

1. The MP_SERVICES pointer is completely optional. You can set it to NULL and FSP will use its built-in MP implementation, which negates this whole argument. I am aware of several platforms that use coreboot with this set to NULL. It is the user's choice to configure coreboot in this way, not Intel's.

It would be nice to enhance the documentation with this additional information.

Thanks in advance,

Angel

Broadwell-DE FSP

@nate-desimone-intel Currently headers and sample code are missing in the repository. Can you add the missing ones?

[Security] FSP TRR support

Hey guys, @nate-desimone,

Does the FSP support TRR on DDR4 memory for rambleed
attack mitigation https://rambleed.com/ ?

If so which UPD option enables it?

BR, Philipp

Out-of-date or missing FSP release notes and changelogs

Hello,

Looks like the release notes for various FSP binaries are only for the "Gold" versions. For version updates, like the bump to Coffee Lake FSP 7.0.68.40, no description about the changes that this update includes is provided. This is extremely worrying when there are changes to the FSP UPDs, since things can break without warning.

If possible, I would appreciate if a changelog per platform could be added, and updated with every update to the FSP binaries.

Thanks in advance,

Angel

KabylakeFspBinPackage: Crash in FSP #30

Reopening, since this was closed without solution. #30
@PatrickRudolph @nate-desimone

KabylakeFspBinPackage: Crash in FSP

If PchHdaVcType is zero in FSP_SIL_UPD the FSP-S crashes due to NULL pointer dereference.
As the Hda/Azalia device is disabled on my board, I don't see why this needs to be set at all.

Braswell: not working Memory Init

I am experiencing problems with FSP Memory Init on Braswell SoCs. It seems like memory initialization fails because Memory Init is not returning, platform hangs after calling FSP Memory Init.
I have following processors that fail: Celeron J3060 and Celeron J3160; both have the same issue.

The platforms have 1 SODIMM module on channel 0. I am feeding the UPD header with correct SPD, but still no luck. I have also tried FSP MR1 and MR2, but nothing works.

The memory DIMMs I have:

https://www.samsung.com/semiconductor/dram/module/M471B5173DB0-YK0/
https://www.samsung.com/semiconductor/dram/module/M471B5273DH0-YK0/

Are these modules not compatible with FSP?

BroadwellDEFspBinPkg asserts if PCI 00:1f.6 is disabled

If PCI device 00:1f.6 (Thermal Management Controller) is disabled, FSP asserts in FspNotify(EnumInitPhaseReadyToBoot).

FSP 1.0 headers throwing warnings

@nate-desimone-intel Intel FSP 1.0 headers throwing warnings which are interpreted as errors in coreboot. It would be great if it gets fixed.

Output:
`src/drivers/intel/fsp1_0/hob.c: In function 'print_hob_type_structure':
3rdparty/fsp/RangeleyFspBinPkg/Include/fsphob.h:318:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
((*(EFI_HOB_GENERIC_HEADER *)&(HobStart))->HobType)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3rdparty/fsp/RangeleyFspBinPkg/Include/fsphob.h:361:37: note: in expansion of macro 'GET_HOB_TYPE'
#define END_OF_HOB_LIST(HobStart) (GET_HOB_TYPE (HobStart) == (UINT16)EFI_HOB_TYPE_END_OF_HOB_LIST)
^~~~~~~~~~~~
src/drivers/intel/fsp1_0/hob.c:202:13: note: in expansion of macro 'END_OF_HOB_LIST'
Lasthob = END_OF_HOB_LIST(Currenthob); / Check for end of HOB list */
^~~~~~~~~~~~~~~
3rdparty/fsp/RangeleyFspBinPkg/Include/fsphob.h:346:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
(VOID )((UINT8 *)&(HobStart) + GET_HOB_LENGTH (HobStart))
^~~~~~~~~~~~~~~~~~~~~
src/drivers/intel/fsp1_0/hob.c:204:14: note: in expansion of macro 'GET_NEXT_HOB'
Nexthob = GET_NEXT_HOB(Currenthob); / Get next HOB pointer /
^~~~~~~~~~~~
3rdparty/fsp/RangeleyFspBinPkg/Include/fsphob.h:332:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
(((EFI_HOB_GENERIC_HEADER **)&(HobStart))->HobLength)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3rdparty/fsp/RangeleyFspBinPkg/Include/fsphob.h:346:37: note: in expansion of macro 'GET_HOB_LENGTH'
(VOID )((UINT8 *)&(HobStart) + GET_HOB_LENGTH (HobStart))
^~~~~~~~~~~~~~
src/drivers/intel/fsp1_0/hob.c:204:14: note: in expansion of macro 'GET_NEXT_HOB'
Nexthob = GET_NEXT_HOB(Currenthob); / Get next HOB pointer */
^~~~~~~~~~~~

src/drivers/intel/fsp1_0/fsp_util.c: In function 'save_mrc_data':
3rdparty/fsp/RangeleyFspBinPkg/Include/fsphob.h:375:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
(VOID )((UINT8 **)&(HobStart) + sizeof (EFI_HOB_GUID_TYPE))
^~~~~~~~~~~~~~~~~~~~~
src/drivers/intel/fsp1_0/fsp_util.c:255:17: note: in expansion of macro 'GET_GUID_HOB_DATA'
mrc_hob_data = GET_GUID_HOB_DATA (mrc_hob);
^~~~~~~~~~~~~~~~~
3rdparty/fsp/RangeleyFspBinPkg/Include/fsphob.h:332:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
((*(EFI_HOB_GENERIC_HEADER **)&(HobStart))->HobLength)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/drivers/intel/fsp1_0/fsp_util.c:256:23: note: in expansion of macro 'GET_HOB_LENGTH'
mrc_hob_size = (u32) GET_HOB_LENGTH(mrc_hob);
^~~~~~~~~~~~~~
`

BroadwellDEFspPkgBin USB initialization issues

With Broadwell-DE MR2 FSP, USB port initialization has multiple issues:

• only user-facing controls are to enable/disable the two EHCI controllers; nothing for XHCI
• with SeaBIOS payload, attached USB devices only detected if FSP debug level set to 3 and MRC cache disabled (or first boot after flashing)
• with Linux payload, ehci/xhci host controllers (and child devices) only detected when modules compiled with =y (vs =m); attached devices detected but non-functional

edit: USB ports/attached devices are fully functional once Linux kernel has booted regardless of state in bootloader

FSP 2.0 skips MRC cache and forces MRC training on Intel SPS systems

On systems with Intel SPS MRC cache does not get used and memory retraining gets forced on every cold boot. This issue is confirmed on two boards (Supermicro X11SSH and X11SSM).
One workaround is flashing ME instead of SPS.

@PatrickRudolph

Kabylake FSP crashes when PrmrrSize=1

Kabylake FSP crashes when PrmrrSize=1 and SGX=0. 32MiB and above work

KabyLake vbt file triggers Linux error message

The vbt files included in FSP 3.7.1 and later use a config size of 39 bytes. The last byte of this structure is not used according to the BSF.
This causes Linux to report : [drm:intel_bios_init] ERROR Unexpected child device config size 39 (expected 38 for VBT version 221).
At this point in time there is no functional problem with this but it would be better to either synchronize the Linux driver with the newer VBT so the 39 bytes are actually supported or report 38 instead of 39 bytes.

VBT: LFP cannot be disabled on coffeelake VBT

Using BMP, nothing will change in the binary if LFP is set to "no device" or to "eDP". This will cause windows to always detect a non-existent monitor.

Braswell undocumented FSP-T dependence

The Braswell FSP1.1 TempRaminit sets up a larger CAR region than advertised. It advertised 0x4000 but in reality sets up a CAR region 0x20000 size. It also places some information (for instance strings like "MCUD" and "PER0") at the top of that CAR region. If somehow that information is not present FSP_MEMORY_INIT will not succeed.

This dependency on FSP-T of FSP_MEMORY_INIT and not touching that CAR region is undocumented and should be fixed.
It is not present or was removed on the skylake FSP1.1.

SpiFlashCfgLockDown UPD vanished after KBL

In the later Kaby Lake FSP releases, there used to be a SpiFlashCfgLockDown UPD. Is there any option with similar effect for newer platforms?

Without this option, it seems impossible to let FSP finish its silicon initialization, and use peripherals like the AHCI or xHCI controllers before FLOCKDN (or PRR34_LOCKDN) is set. A bootloader using FSP is then forced to either perform firmware updates in early stages which significantly increases attack surface there, or to implement different boot modes with different locked SPI settings. In any case it seems to increase complexity of the security concept and thus makes it more error-prone.

Microcode update availability

FSP provides only the platform binaries. To boot recent hardware, there's also the FIT to fill out, which also includes pointers to microcode updates.

What's the canonical place to obtain them (ideally under the same terms as FSP)? Should this repo ship them, too?