Page MenuHomeFreeBSD

sysutils/devcpu-data: Use new microcode format

Authored by sbruno on May 15 2018, 3:46 PM.



Use new microcode format processing tools from Ed.

Diff Detail

rP FreeBSD ports repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

sbruno created this revision.May 15 2018, 3:46 PM
sbruno added inline comments.
9 ↗(On Diff #42579)

I'm not happy with this shell script being here. I'd rather have the Makefile do the work but I couldn't figure out how to do it. Looking for suggestions.

We have four fewer files in %%DATADIR%% now, which at first seems troubling. But, microcode_amd*.bin have disappeared, so from the perspective of the Intel ucode files at least it appears sensible. What's the story with the amd ucode files?

Can you try sha256 -q *-*-*.* against the new files and sha256 -q *.fw against the old files to confirm that we have the same content in both cases?

I posted the tool in D15433 for experimentation / testing, and it should probably be part of cpucontrol (either splitting or the ability to load one of n blobs in an unsplit ucode file). That said, for actually deploying new ucode updates to our users it's best to have the tool in the port (as here) and process the ucode files at build time. Otherwise we'd had a dependency on an EN and everyone upgrading.

emaste added inline comments.May 15 2018, 4:11 PM
9 ↗(On Diff #42579)

Something like this in the Makefile ought to work:

ucode:        ucode-split
        mkdir -p ${OUTPUT_DIR}
        cd ${OUTPUT_DIR}
        for file in ../${INTEL_UCODE}/*; do \
                ../ucode-split $$file; \
sbruno updated this revision to Diff 42581.May 15 2018, 4:13 PM

Restore delete AMD cpu files.

Delete old mcode tool for breaking apart microcode.dat

sbruno updated this revision to Diff 42582.May 15 2018, 4:22 PM

Drop the uneeded shell script and DTRT in Make to get a for
loop. :-)

I committed D15433 to tools/tools/intel-ucode-update/ and also updated it somewhat - you may want to pick up a new version from tools/tools. It has some warning fixes and a few improvements in the header printing/parsing, and also doesn't print anything by default now unless you pass -v.

I think this change is good; ideally folks who encountered the failure on the original attempt to switch to new-style updates can test and confirm.

sbruno updated this revision to Diff 42646.May 16 2018, 9:33 PM

Remove "" from a previous incarnation of the port.

sbruno updated this revision to Diff 42647.May 16 2018, 9:59 PM

Synch ucode-split.c to svn r333661

sbruno updated this revision to Diff 42649.May 16 2018, 10:22 PM

For reasons that I don't understand, poudriere testport seems to
invoke Makefile commands differently than poudriere bulk commands.

Execute the ucode-split binary in the same shell as the change dir
to the location of the intel ucode bits.

swills accepted this revision.May 16 2018, 10:57 PM


This revision is now accepted and ready to land.May 16 2018, 10:57 PM
cy added a subscriber: cy.May 17 2018, 1:43 AM
sbruno added a subscriber: secteam.May 17 2018, 3:00 PM
delphij added inline comments.
3 ↗(On Diff #42649)

Minor style nit: Maybe move INTEL_UCODE one line above, and add a blank line between the variables and before all:?

79 ↗(On Diff #42649)

I'd probably change 16 to sizeof("ff-ff-ff"), or use asprintf in format_signature to make the code easier to follow, but no action requested for now.

119 ↗(On Diff #42649)

Can we use e.g. PATH_MAX instead of 128 here?

emaste added inline comments.May 17 2018, 5:58 PM
79 ↗(On Diff #42649)

done in rS333742

119 ↗(On Diff #42649)

done in rS333742

sbruno updated this revision to Diff 42673.May 17 2018, 6:10 PM

Synchronize intel-ucode-split to svn r333742

This revision now requires review to proceed.May 17 2018, 6:10 PM
sbruno marked 4 inline comments as done.May 17 2018, 6:10 PM
delphij accepted this revision.May 17 2018, 6:39 PM

I think you should exit(EX_OK) or return 0 in main(); without it the compiler would give a warning and caller may or may not get wrong exit status (of whatever was left in %rax) at the point. The change otherwise looks good to me.

205 ↗(On Diff #42673)

Technically you should exit(EX_OK) or return 0 here?

This revision is now accepted and ready to land.May 17 2018, 6:39 PM
This revision was automatically updated to reflect the committed changes.