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

[Simon Glass]

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:

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.

Regards,
Simon