diff options
author | Leah Rowe <leah@libreboot.org> | 2023-10-28 21:19:48 +0100 |
---|---|---|
committer | Leah Rowe <leah@libreboot.org> | 2023-10-28 21:19:48 +0100 |
commit | 83bf23766040d5e1642b8c80d975953c1c34f876 (patch) | |
tree | 0df71bf09b0145df4e954e397bb292f92d91061a /util/dell-flash-unlock/dell_flash_unlock.c | |
parent | 5f6ba01d414e2d98d7db049347b8c5c5d125ba61 (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