Hi Simon, On Thu, Dec 11, 2014 at 11:50 PM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 11 December 2014 at 08:01, Bin Meng <bmeng...@gmail.com> wrote: >> Hi Simon, >> >> On Thu, Dec 11, 2014 at 10:34 PM, Simon Glass <s...@chromium.org> wrote: >>> 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: >> >> 'manually' means we don't let the build system to do this 'automatically'? > > For now, since I suspect automatically might be hard for you. > >> >>> >>> 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. >>> >> >> Sorry I am confused. In what format should we submit the microcode >> data? Is it dtsi or .c? Intel normally releases the microcode update >> in .h format. > > We should have a tool which converts Intel's format into a device tree > .dtsi include file. I'd like that .dtsi to be the file we commit to > the U-Boot source tree. However since this is not suitable for your > platform then we need to figure out an approach to convert it to a > form you need. I believe all you really need to know is the address of > the microcode update, and I feel there must be a way to make this work > automatically in the build system. > > My suggestion above was just a short-term approach to get you unblocked. > >> >> BTW: I have cleaned up the remaining coding convention issues for ths >> FSP codes. Do you want to continue reviewing other patches in this v2, >> so that I can fix all issues in v3? Do you think we need address this >> microcode update in v3? I think we can leave this issue for this >> series, and address this microcode issue in another patch series, as >> it may touch the chromebook_link codes. > > Yes I will get to the others. Overall it all looks fine so don't > expect anything major. I'm happy to sort out the microcode in a later > series if you prefer, but we do need to fix it.
Yes, we can address the microcode issue in a later series. For this v2 series, I would assume I can just send v3 with the remaining U-Boot coding convention changes and it is ready to apply? Let me know if you have different thoughts. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
