Change in coreboot[master]: soc/amd/common/block/cpu: Cache the uCode to avoid multiple SPI reads

[Furquan Shaikh (Code Review)]

Attention is currently required from: Jason Glenesk, Raul Rangel, Martin Roth, Marshall Dawson, Karthik Ramasubramanian, Felix Held.
Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/55987 )

Change subject: soc/amd/common/block/cpu: Cache the uCode to avoid multiple SPI reads
......................................................................

Patch Set 1:

(2 comments)

File src/soc/amd/common/block/cpu/update_microcode.c:

https://review.coreboot.org/c/coreboot/+/55987/comment/00fa6717_84239911 
PS1, Line 17: bool buffer_valid;
            : uint8_t buffer[CONFIG_SOC_AMD_COMMON_BLOCK_UCODE_SIZE];
These can live within the scope of `amd_update_microcode_from_cbfs` and marked as static?

https://review.coreboot.org/c/coreboot/+/55987/comment/58fd62f4_0d806c37 
PS1, Line 85: ucode
> On x86 `cbfs_map` returns a pointer to the MMAP SPI. i.e., It's returning the same pointer every time.

Right. I was not sure if it is the cbfs lookup that is taking up the time or if it actually the read of ucode from SPI flash.
> I'm not sure how large the cache is, and if it's getting evicted, but explicitly caching it in RAM saves 30ms.

That is interesting. If the memory-mapped access is slower and we need to stash in local buffer, why not switch to using `cbfs_load`? That should allow you to load the microcode into a local buffer without having to explicitly call memcpy.