[coreboot] [patch][v2] AMD Fam10 rev B3 microcode patches
c-d.hailfinger.devel.2006 at gmx.net
Tue Jul 22 20:39:36 CEST 2008
On 22.07.2008 19:56, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>>> + (c) Advanced Micro Devices, Inc., 2004-2008
>>> + The enclosed microcode is intended to be used with AMD
>>> + Microprocessors. You may copy, view and install the
>>> + enclosed microcode only for development and deployment of
>>> + firmware, BIOS, or operating system code for computer
>>> + systems that contain AMD processors. You are not
>>> + authorized to use the enclosed microcode for any other
>>> + purpose.
>> I trust that AMD is not going to hunt us down if we check out the
>> complete svn tree (copy) with the intent to develop for non-AMD systems.
>> Still, the legalese feels a bit weird.
> You bring this up every time I update microcode patches. This has been
> worked out in the past. The statement seems very straight forward to
> me (but I am not a lawyer).
I wish to apologize. I can't seem to remember having made a similar
statement in the past, but I'm not going to object the inclusion of this
code. Go ahead.
>>> +/* From the Revision Guide :
>>> + * Equivalent Processor Table for AMD Family 10h Processors
>>> + *
>>> + * Installed Processor Equivalent Processor Patch Level
>>> + * Revision ID Revision ID
>>> + * 00100F00h 1000h 01000020h
>>> + * 00100F01h 1000h 01000020h
>>> + * 00100F02h 1000h 01000020h
>>> + * 00100F20h 1020h 01000084h
>>> + * 00100F21h 1020h 01000084h
>>> + * 00100F2Ah 1020h 01000084h
>>> + * 00100F22h 1022h 01000083h
>>> + * 00100F23h 1022h 01000083h
>> AFAICS it could happen that different "Equivalent Processor IDs" have
>> the same patch level. Naming the microcode files only after the patch
>> level would cause all sorts of interesting conflicts in that case.
>> How about a naming scheme like
> I don't see your point. The code already handles equivalent processor
> ids. I put the table in so you didn't have to read the revision guide
> to understand what is going on. What you suggest only makes it more
> difficult if different equivalent ids have the same patch level.
Hm. Maybe I misunderstand the current scheme, but I think it breaks
exactly for the case you cite: "different equivalent ids have the same
> #include "mc_patch_01000065.h"
>>> + /* Barcelona rev B2, B3 */
>>> + #include "mc_patch_01000083.h"
>> This looks like manual source code editing is required to support
>> Barcelona processors before B2. May I suggest a Kconfig variable for
> Yes, it is manual editing so I will add a config option to v2. A
> Kconfig variable would be great when you port it to v3. :)
Heh. I live in the v3 world and forgot about the nonexistence of Kconfig
in v2. I'll take care of the conversion to Kconfig for a v3 port.
Does this changeset also include a removal of old microcode?
More information about the coreboot