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... Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
