[U-Boot] [PATCH] x86: WIP: Enable D0 stepping microcode for MinnowMax

[Simon Glass]

Hi,

On 4 June 2015 at 10:27, Andrew Bradford <andrew at 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.cn at gmail.com> wrote:
> > > This is a temparory hacking for testing U-Boot on a newer version
> > > MinnowMax board.
> > >
> > > Signed-off-by: Bin Meng <bmeng.cn at 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 at 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 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,
Simon