Hi Bin,
On 9 December 2014 at 23:24, Simon Glass sjg@chromium.org wrote:
Hi Bin.
On 9 December 2014 at 23:17, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, Dec 10, 2014 at 2:09 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 9 December 2014 at 07:50, 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
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@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