Re: [coreboot] Intel FSP on Bayley Bay CRB: No output

[Sean McNeil]

Hi Martin,

I hope you are using the torque screwdriver and not tightening them 
beyond the recommended ft-lbs. If you go too tight, you can damage the 
board.

Cheers,
Sean

On 06/23/2014 02:53 AM, Martin Roth wrote:
> This whole microcode issue caused us a couple of weeks of delay.
> Here's the basics of what I found - I don't know if any of this is
> fixed, I'll check with Intel and report back:
>
> There are 2 different microcode load routines, one for the BSP, and
> one for the APs.  The BSP's routine will load the microcode without
> checking that the SKU is correct.  The AP's loading routine won't load
> if the microcode SKU is wrong.  Unfortunately, it doesn't report this,
> it just doesn't load the microcode and carries on as if nothing
> happened.
>
> The hang is caused due to an MSR access that isn't valid unless the
> microcode is loaded.  Accessing this MSR hangs the APs.  The system
> will then hang waiting for the AP init to complete.
>
> I believe you'll find that if you comment out the final FSP call, the
> system will boot, but you'll probably only have one core running.
>
> The issue with the correct microcode is that apparently there were no
> Bay Trail I SKUs released for the B0 rev - they were released as a
> "super-Sku" that is identified as a Bay Trail T.  There is, however,
> for some reason, still a microcode patch available for the Bay Trail I
> B0/B1.
>
> I *believe* that the correct microcode patch for the B0 parts is the
> Bay Trail T patch that's in the FSP package.  If this microcode patch
> isn't working for anyone on their B0, please let me know.
>
> We (Intel and Sage) had initially decided that only the B3 silicon was
> going to be supported for this release.  I'm still not sure that
> wasn't the correct choice, but it was later requested to add the
> support for the B0 part as well.  I'd really urge anyone using a B0 to
> just upgrade to a B3 part.
>
> On an unrelated note, after heavy use of the Bayley Bay and Bakersport
> boards, we noticed that the boot was halting in memory init, when
> nothing on the board had changed.  I finally figured out that this was
> due to a bad board connection with the processor.  Since the
> processors are not soldered to the board, it seems like sometimes the
> connection would develop issues.  Tightening the adapter holding the
> processor to the board fixed all the issues we were having.
>
> Martin
>
> On Sat, Jun 21, 2014 at 5:37 PM, Giri  wrote:
> > Regarding below two items
> > The microcode that is being included is not a part of coreboot, so it
> >
> > needs to be disabled for the default build so that abuild doesn't fail.
> > Intel wants to release the microcode as part of the FSP package and not
> > include it in the coreboot repo so that the microcode vs FSP versions can be
> > matched up.
> >
> > Microcode is not part of FSP but just consumes the pointer and length.
> > Microcode and FSP versions doesn't need to match but the microcode needs to
> > match the CPU on that platform.
> > The microcode that's included for the intel FSP is for B2/B3 silicon, but
> >
> > it seems like many users are still using B0 silicon, which requires a
> > different microcode patch.  This shouldn't be a problem but since there are
> > 4 SKUs of Bay Trail and using the microcode for the wrong SKU will *APPEAR*
> > to work, but cause issues later, the microcode can cause massive amounts of
> > confusion.
> >
> > Please check if the microcode is loaded by reading MSR 0x8B
> >
> > -Giri
> >
> > -----Original Message-----
> > From: coreboot [mailto:[e-mail]] On Behalf Of Peter
> > Stuge
> > Sent: Friday, June 6, 2014 2:57 AM
> > To: [e-mail]
> > Subject: Re: [coreboot] Intel FSP on Bayley Bay CRB: No output
> >
> > Martin Roth wrote:
> > > Eh, it's code...  It's going to have issues and bugs.
> >
> > I disagree with that attitude. A platform vendor writing platform init code
> > doesn't really have a valid excuse for producing buggy code.
> >
> > "Release early, release often" can't be an excuse to push the consequences
> > of one's own shortcomings onto others. That's just poor programmer's moral.
> >
> > I obviously disagree with letting shortcomings in other code generate issues
> > in coreboot.
> > > We're all interested in getting these things to the highest quality,
> >
> > It doesn't seem to me that Intel is interested in that at all.
> >
> > They're making themselves the only actor in the world capable of producing
> > correct platform init code for their platforms, yet they don't. My guess as
> > to why is that time to market is quite short.
> > > They're still actively developing the code and working to improve
> > > things, so in that way it's definitely better than getting a single
> > > source code drop that never gets updated again.
> >
> > That's a joke, right?
> >
> > Source code without updates is clearly better than no source code.
> >
> > Maybe I'm getting too old to waste my life on closed source nonsense?
> >
> > //Peter