Hi Bin, On 9 December 2014 at 23:24, Simon Glass <s...@chromium.org> wrote: > Hi Bin. > > > On 9 December 2014 at 23:17, Bin Meng <bmeng...@gmail.com> wrote: >> Hi Simon, >> >> On Wed, Dec 10, 2014 at 2:09 PM, Simon Glass <s...@chromium.org> wrote: >>> Hi Bin, >>> >>> On 9 December 2014 at 07:50, Bin Meng <bmeng...@gmail.com> wrote: >>>> Integrate the processor microcode version 1.05 for Tunnel Creek, >>>> CPUID device 20661h. >>>> >>>> Signed-off-by: Bin Meng <bmeng...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
