svn commit: r334046 - head/tools/tools/intel-ucode-split

[Eitan Adler]

On 13 June 2018 at 07:07, Mark Johnston <markj at freebsd.org> wrote:
> On Wed, Jun 13, 2018 at 01:46:34AM +0200, Oliver Pinter wrote:
>> On Wednesday, June 13, 2018, Ed Maste <emaste at freebsd.org> wrote:
>>
>> > On Tue, 12 Jun 2018 at 18:17, Sean Bruno <sbruno at freebsd.org> wrote:
>> > >
>> > > On 06/12/18 16:05, Oliver Pinter wrote:
>> > > > On 5/22/18, Ed Maste <emaste at freebsd.org> wrote:
>> > > >> Author: emaste
>> > > >> Date: Tue May 22 14:35:33 2018
>> > > >> New Revision: 334046
>> > > >> URL: https://svnweb.freebsd.org/changeset/base/334046
>> > > >>
>> > > >> Log:
>> > > >>   intel-ucode-split: add -n flag to skip creating output files
>> > > >>
>> > > >>   Sponsored by:      The FreeBSD Foundation
>> > > >>
>> > > >> Modified:
>> > > >>   head/tools/tools/intel-ucode-split/intel-ucode-split.c
>> > > >
>> > > > Hi!
>> > > >
>> > > > Could you please MFC the intel-ucode-split related commits to
>> > 11-STABLE?
>> > > >
>> > > > Thanks,
>> > > > op
>> > >
>> > > Do you need it in base for some reason?  This code is already in the
>> > > devcpu-data port and is used when the port is built.  Its not needed for
>> > > anything AFAIK.
>> >
>> > Indeed, the real use in FreeBSD is via the devcpu-data port; I
>> > committed it to src/tools/ for collaboration and testing. I'll merge
>> > it to stable/11 if it will be useful for someone, but am curious about
>> > the use case.
>> >
>>
>>
>> I'm considering to write an in kernel microcode update facility, based on
>> firmware(9), and in first idea it would be nice during the generation of
>> firmware modules.
>
> FWIW, I'm working on this for 12.0 and was planning to describe my
> proposal on -arch in the next couple of weeks.  For my purposes at
> least, firmware(9) isn't suitable.  We'd like to ensure that updates are
> applied before the kernel does CPU identification, and that happens
> quite early during boot.  This places some constraints on the
> implementation which exclude firmware(9).

Naive question, knowing nothing about firmware(9), but why can't it be
enhanced to work that early? It seems there might be other use-cases
for very-early-boot firmware application.



-- 
Eitan Adler