[U-Boot] [PATCH 16/25] x86: Integrate Tunnel Creek processor microcode

[Bin Meng]

Hi Simon,

On Fri, Dec 5, 2014 at 11:12 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 5 December 2014 at 02:14, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Fri, Dec 5, 2014 at 7:43 AM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 4 December 2014 at 08:02, 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>
>>>> ---
>>>>  arch/x86/cpu/queensbay/M0220661105.inc | 1288 ++++++++++++++++++++++++++++++++
>>>>  1 file changed, 1288 insertions(+)
>>>>  create mode 100644 arch/x86/cpu/queensbay/M0220661105.inc
>>>
>>> Can we put this into the device tree?
>>>
>>
>> Unfortunately the microcode is required by the call to TempRamInit in
>> FSP in car_init, where the device tree functionality is not available.
>> We can of course duplicate one in device tree for reference, not sure
>> if it is necessary.
>
> OK I was hoping you weren't going to say that. There is not even a
> stack at this stage so device tree is out of the question. I wonder
> how common this is. Is there any way to provide a 'NULL'  microcode
> update and then do it later?

I tested this, by providing a 'NULL' microcode to FSP. However the FSP
TempRamInit() will just fail. So we may have to do it this way.

> This is some of the pain of dealing with binary blobs.
>
> Let's see where this lands but we may want to change things around in
> start.S to provide for this more nicely.
>
> Regards,
> Simon

Regards,
Bin