summaryrefslogtreecommitdiff
path: root/util/dell-flash-unlock/dell_flash_unlock.c
diff options
context:
space:
mode:
authorLeah Rowe <leah@libreboot.org>2023-10-28 21:19:48 +0100
committerLeah Rowe <leah@libreboot.org>2023-10-28 21:19:48 +0100
commit83bf23766040d5e1642b8c80d975953c1c34f876 (patch)
tree0df71bf09b0145df4e954e397bb292f92d91061a /util/dell-flash-unlock/dell_flash_unlock.c
parent5f6ba01d414e2d98d7db049347b8c5c5d125ba61 (diff)
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>
Diffstat (limited to 'util/dell-flash-unlock/dell_flash_unlock.c')
0 files changed, 0 insertions, 0 deletions