[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 <girim77 at gmail.com> wrote:
>> Regarding below two items
>>
>> 1) 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.
>>
>> 2) 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:coreboot-bounces at coreboot.org] On Behalf Of Peter
>> Stuge
>> Sent: Friday, June 6, 2014 2:57 AM
>> To: coreboot at coreboot.org
>> 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
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot