[U-Boot] [PATCH v2 15/27] x86: Integrate Tunnel Creek processor microcode

[Bin Meng]

Hi Simon,

On Thu, Dec 11, 2014 at 10:34 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 9 December 2014 at 23:24, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin.
>>
>>
>> On 9 December 2014 at 23:17, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Wed, Dec 10, 2014 at 2:09 PM, Simon Glass <sjg at chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 9 December 2014 at 07:50, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>>> Integrate the processor microcode version 1.05 for Tunnel Creek,
>>>>> CPUID device 20661h.
>>>>>
>>>>> Signed-off-by: Bin Meng <bmeng.cn at gmail.com>
>>>>> ---
>>>>>
>>>>> Changes in v2: None
>>>>
>>>> We are going to end up with microcode both in the device tree and in
>>>> an assembler include file.
>>>>
>>>> This seems unfortunate. I wonder if we can always put it in the device
>>>> tree, but then optionally also compile it into the image using a
>>>> symbol (as we do in dts/Makefile for CONFIG_OF_EMBED). This could be
>>>> done with fdtget to read the binary output of the property perhaps. I
>>>> haven't looked at it in detail though.
>>>>
>>>
>>> This will do for the embedded case, but it won't help for the separate dtb case.
>>>
>>>> Maybe this is too clumsy but it would be good to have it in one
>>>> format. Or maybe we should have a tool which can generate either
>>>> format.
>>>
>>> I don't think we are able to parse device tree in that early phase
>>> (before car_init), to get the microcode content from dtb. I know in
>>> some Intel processors, the microcode update are required before CAR
>>> initialization, as without the microcode update, the CAR
>>> initialization will fail.
>>
>> Right, I meant that we could perhaps do this in the build system -
>> i.e. compile in the microcode after reading it from the device tree.
>>
>> Not thrilled with the idea...
>
> I wonder if we could do this:
>
> 1. Put the microcode in a .dtsi file, perhaps with a tool to do this
> automatically.
> 3. Build the board
> 2. Use something like this to extract the hex data manualy:

'manually' means we don't let the build system to do this 'automatically'?

>
> fdtget -tx /path/to/u-boot.dtb /microcode/update at 0 data | sed 's/ /, 0x/g'
>
> then put this in a file that you compile. That way if we come up with
> a clever solution later we can use it. Unfortunately it means
> submitting the same microcode update in a .c format for now, but have
> a path to fixing it.
>

Sorry I am confused. In what format should we submit the microcode
data? Is it dtsi or .c? Intel normally releases the microcode update
in .h format.

BTW: I have cleaned up the remaining coding convention issues for ths
FSP codes. Do you want to continue reviewing other patches in this v2,
so that I can fix all issues in v3? Do you think we need address this
microcode update in v3? I think we can leave this issue for this
series, and address this microcode issue in another patch series, as
it may touch the chromebook_link codes.

Regards,
Bin