Hi Bin, On 4 June 2015 at 20:03, Bin Meng <bmeng...@gmail.com> wrote: > Hi Simon, > > On Fri, Jun 5, 2015 at 2:31 AM, Simon Glass <s...@chromium.org> wrote: >> Hi, >> >> On 4 June 2015 at 10:27, Andrew Bradford <and...@bradfordembedded.com> wrote: >>> >>> Hi Bin, >>> >>> On 06/04 22:21, Bin Meng wrote: >>> > Hi Simon, >>> > >>> > On Thu, Jun 4, 2015 at 8:12 PM, Bin Meng <bmeng...@gmail.com> wrote: >>> > > This is a temparory hacking for testing U-Boot on a newer version >>> > > MinnowMax board. >>> > > >>> > > Signed-off-by: Bin Meng <bmeng...@gmail.com> >>> > > --- >>> > > >>> > > arch/x86/dts/minnowmax.dts | 2 +- >>> > > 1 file changed, 1 insertion(+), 1 deletion(-) >>> > > >>> > > diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts >>> > > index 7103bc5..9e1fcfc 100644 >>> > > --- a/arch/x86/dts/minnowmax.dts >>> > > +++ b/arch/x86/dts/minnowmax.dts >>> > > @@ -101,7 +101,7 @@ >>> > > >>> > > microcode { >>> > > update@0 { >>> > > -#include "microcode/m0130673322.dtsi" >>> > > +#include "microcode/m0130679901.dtsi" >>> > > }; >>> > > }; >>> > > >>> > > -- >>> > >>> > Saket confirmed these two patches resolved the boot problem he saw. So >>> > we will need think about how to better support such scenario that >>> > different revision board with different stepping CPUs. Could be >>> > multiple microcodes in one U-Boot image, or still one microcode with >>> > some #ifdef #endif. Note FSP has the capability to accept multiple >>> > microcodes as parameters in the FspTempRamInit(), but right now U-Boot >>> > only specifies one. How do you think? >>> >>> Why not just have a minnowmax common dtsi and then top level dts files >>> for each revision of the board containing the ways they are different >>> (such as microcode)? >> >> My preference would be to include all the microcode needed by the >> board and then pass the correct one to the FSP. Now that we can access >> the device tree that should be possible. There is logic in >> ./arch/x86/cpu/ivybridge/microcode_intel.c to do this but it may need >> a bit of refactorng. >> > > The device tree still cannot be accessed in that early phase before > CAR is initialized. The issue is that FSP is designed to have > FspTempRamInit() to do both microcode loading and CAR initialization. >
Ah yes of course. Most unfortunate. Maybe we could have ifdtool or the Makefile put all the microcode in a single big blob somewhere else in u-boot.rom so that the whole thing can be passed to the FSP. In that case I think the FSP will select the correct one I also wonder if it is possible to load the microcode in our own code and pass nothing to the FSP? I think I tried that though and it hung. The FSP design leaves much to b desired. >> The existing microcode approach (with ifdtool adding a pointer to the >> microcode) is a work-around for the FSP problem. Now that Bin has >> solved this I'd be keen to remove it an just use device tree. >> > > Regards, > Bin Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot