Hi Simon,
On Fri, Dec 5, 2014 at 11:12 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 5 December 2014 at 02:14, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Fri, Dec 5, 2014 at 7:43 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 4 December 2014 at 08:02, Bin Meng bmeng.cn@gmail.com wrote:
Integrate the processor microcode version 1.05 for Tunnel Creek, CPUID device 20661h.
Signed-off-by: Bin Meng bmeng.cn@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