[S] Change in coreboot[master]: soc/amd/common: Add a config to keep signed AMD/PSP FW separately

[Karthik Ramasubramanian (Code Review)]

Attention is currently required from: Jason Glenesk, Raul Rangel, Marshall Dawson, Kangheui Won, Matt DeVillier, Paul Menzel, Fred Reitberger, Felix Held.

Karthik Ramasubramanian has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/59867 )

Change subject: soc/amd/common: Add a config to keep signed AMD/PSP FW separately
......................................................................

Patch Set 13:

(1 comment)

Commit Message:

https://review.coreboot.org/c/coreboot/+/59867/comment/58a96f97_e276c870 
PS13, Line 10: SIGNED_AMDFW_
> Do we still want to go down this path? […]

Please bear with me for my detailed response:

I am not sure if all the AMD boards are going to enable CBFS verification. That may lead to difference in how CBFS looks like on boards with and without CBFS verification enabled. Hopefully AMD is fine with that. Even on boards without CBFS verification we can keep each signed PSP binaries as individual CBFS files and all the unsigned binaries + directory tables + EFS header as one single CBFS file. This can help bring consistency for all AMD SoC based mainboards.

This adds few complications in the construction of directory and hash tables.
1) Currently amdfwtool constructs amdfw.rom, amdfw_a/b.rom and hence it knows the offset of each PSP binaries (signed & unsigned). Thus it is able to construct the directory and hash tables with ease. All we need is only one pre-defined SPI ROM offset for amdfw*.rom file. If we have to keep each PSP binary as a CBFS file, then we may need a pre-defined offset for each one of them with sufficient room for potential growth of binaries.
2) With CBFS verification enabled, every time a file is accessed the header for all the files in the CBFS are accessed to ensure they are not corrupted. With this approach, we went from 1 file to atleast 20 files to my knowledge. That will lead to more SPI ROM reads and potentially a slow down.

Both 1) and 2) can be addressed by creating a separate CBFS file type for such binaries which is:
1) excluded from CBFS verification
2) Passed through for second time to construct the directory and hash tables.

But with these files excluded from CBFS verification, we will be in the same situation as this approach except for a significant amdfwtool refactoring.