coreboot/fam15h: don't set microcode_required

the logic for naming coreboot roms is based on whether
cpu_microcode_blob.bin would exist in cbfs, and whether
deletion was therefore successful.

lbmk was naming nomicrocode on fam15h roms on this basis,
but the microcode was being inserted as microcode_amd.bin
and microcode_amd_fam15h.bin

in the recent 20231021 release, the roms were exclusively
labeled _nomicrocode in the rom names, but they do in fact
contain microcode.

i'm fixing it by telling lbmk *not* to delete microcode.
if microcode_required is not set, or it's set to y, then
only roms *with* microcode updates are provided; even if
the rom doesn't actually contain it, lbmk will only label
it _nomicrocode if that setting is set to n.

i'm not bothering to add further complexity to the rom
handling logic, because canoeboot now exists anyway (at
website https://canoeboot.org/) which is my new version
re-implementing the older, inferior version of libreboot

so i'm going to:
1) document this as errata in the release
2) cross reference in the freedom status page
3) if someone still isn't happy, i'll say use canoeboot

job done.

Signed-off-by: Leah Rowe <leah@libreboot.org>

1 files changed, 0 insertions, 1 deletions

diff --git a/config/coreboot/kcma-d8-udimm_2mb/target.cfg b/config/coreboot/kcma-d8-udimm_2mb/target.cfg
index 2102dc36..6e4887a4 100644
--- a/config/coreboot/kcma-d8-udimm_2mb/target.cfg
+++ b/config/coreboot/kcma-d8-udimm_2mb/target.cfg
@@ -6,5 +6,4 @@ payload_grub_withseabios="y"
 payload_seabios="y"
 payload_memtest="y"
 crossgcc_ada="n"
-microcode_required="n"
 vendorfiles="n"