[coreboot] BDX-DE PCI init fail

[Zoran Stojsavljevic]

Hello Hilbert,

I have glanced through your full log. It does not tell me direct
failure, I see that you are stuck with PCIe 00:1F.3 .

But it does tell me much more than your initial log. Mainly, the first
part (good 70%) is MRC algorithm executed in the ROM stage. At the end
of the romstage the early PCH init takes place. And, also interesting
thing is that DMI links use beneath QPI links, in nutshell seems that
DMI links are initially initialized as QPI links, then changed to DMI
protocol?!

Then you get to the RAM stage, where an interesting function
(enumerating PCIe buses on PCH) gets executed (forgot the name,
NotifyPeim-blah... Or similar, it gets called twice):

The interesting part is marked with <<======== :

coreboot-coreboot-unknown Wed Jan  3 06:02:08 UTC 2018 ramstage starting...
Moving GDT to 7effe9e0...ok
BS: BS_PRE_DEVICE times (us): entry 0 run 2 exit 0
CBFS: 'Master Header Locator' located CBFS at [100:1fffc0)
CBFS: Locating 'cpu_microcode_blob.bin'
CBFS: Found @ offset 3c80 size 5400
microcode: sig=0x50663 pf=0x10 revision=0x700000e <<===========================
CPUID: 00050663
Cores: 2
Stepping: V2
Revision ID: 05
msr(17) = 0010000000000000
msr(ce) = 20080833f2810c00
BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 29408 exit 0
Enumerating buses...

Please, read the following Coreboot thread:
https://mail.coreboot.org/pipermail/coreboot/2016-July/081645.html

You'll see there that there are four (4) CPUIDs for BDX-DE: 0x50661,
0x50662, 0x50663 and 0x50664! I know that 0x50663 is PPR (Pre PR),
whilst 0x50664 is PR (Production Release). For 0x50661/2 the story is
much more complicated, you do not want to know that/you do not need to
know that.

What you should be aware of is the MCU. If you use wrong MCU with the
wrong sku, then it'll exibit the similar "features" you have
discovered. In other words you have to track for 0x50663 the proper
MCUs, and you also might change the sku (to use PR 0x50664, and proper
MCUs for it).

And one more (VERY important) thing: you should use for PPR 0x50663
PPR PCH, and for PR 0x50664 PR PCH. Mixtures would not work!

Good Luck!
Zoran
_______


On Thu, Jan 4, 2018 at 5:37 AM, Hilbert Tu(杜睿哲_Pegatron)
<Hilbert_Tu at pegatroncorp.com> wrote:
> Hi David,
>
>
>
> Yes, actually I have same try like you to comment out the SMBus clock
> gating. But the result is it started to reboot again after jumping to boot
> code as attached. I use U-Boot as payload. If grub was used, it just hanged
> there. Did you have same condition before? Thanks.
>
>
>
> -Hilbert
>
>
>
> From: David Hendricks [mailto:david.hendricks at gmail.com]
> Sent: Thursday, January 04, 2018 7:56 AM
> To: Hilbert Tu(杜睿哲_Pegatron)
> Cc: Zoran Stojsavljevic; coreboot at coreboot.org
> Subject: Re: [coreboot] BDX-DE PCI init fail
>
>
>
> Hi Hilbert,
>
>
>
> On Wed, Jan 3, 2018 at 12:56 AM, Hilbert Tu(杜睿哲_Pegatron)
> <Hilbert_Tu at pegatroncorp.com> wrote:
>
> Hi Zoran,
>
> I have changed to maximal log level and found SMBus init was failed when
> enabling clock gating. Do you have any comments about this? Thanks.
>
>
>
> Yes, looking back at my notes from earlier that is also how I got past the
> issue - by commenting out the following lines in
> src/soc/intel/fsp_broadwell_de/smbus.c:
>         /* Enable clock gating */
>        reg32 =read32(rcba + 0x341c);
>        reg32 |= (1 << 5);
>        write32(rcba + 0x341c, reg32);
>
> I suspected that reading the register is where it hung, however I did not
> have a chance to root cause the issue or try to enable clock gating
> elsewhere. The system worked without clock gating enabled, though.
>
>
>
> I also tested another Broadwell-DE device that did not require the same
> hack, but it used different memory and a different processor stepping
> (stepping 3 instead of stepping 4) which may have made a difference.
>
>
>
> This e-mail and its attachment may contain information that is confidential
> or privileged, and are solely for the use of the individual to whom this
> e-mail is addressed. If you are not the intended recipient or have received
> it accidentally, please immediately notify the sender by reply e-mail and
> destroy all copies of this email and its attachment. Please be advised that
> any unauthorized use, disclosure, distribution or copying of this email or
> its attachment is strictly prohibited.
> 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。