Re: [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=0x70e <<===
CPUID: 00050663
Cores: 2
Stepping: V2
Revision ID: 05
msr(17) = 0010
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)
 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.hendri...@gmail.com]
> Sent: Thursday, January 04, 2018 7:56 AM
> To: Hilbert Tu(杜睿哲_Pegatron)
> Cc: Zoran Stojsavljevic; coreboot@coreboot.org
> Subject: Re: [coreboot] BDX-DE PCI init fail
>
>
>
> Hi Hilbert,
>
>
>
> On Wed, Jan 3, 2018 at 12:56 AM, Hilbert Tu(杜睿哲_Pegatron)
>  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.
> 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Can coreboot for KabyLake rvp11 work on Intel Sasby Island kit?

[Toan Le manh]

Hi,

I had a Intel Sasby Island kit, which has CPU family: SkyLake, model
i7-6600U, Memory: LPDDR4.
Do you think coreboot for Intel rvp11 (Kabylake U, LPDDR4) can work on that
Sasby Island kit?

Thanks & BRs,
Toan Le
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Lewis, Ian (Microstar Laboratories)]

Peter Stuge wrote:
> Consider Section 3 a) "on a medium customarily used for software interchange" 
> - a Control Panel snap-in arguably isn't such a medium.
> What specific interface to use for delivery of source code probably depends 
> on how your product works, and what you want to enable your customers to 
> offer.
Peter Stuge wrote:
> Unlike David I'm not so sure about this. Requiring a special software to 
> access the source code IMO does not satisfy "medium customarily used for 
> software interchange" - while a virtual CD-ROM would, if your product 
> connects via USB in normal operation.
> The Control Panel idea may be a good way to help your customers with being 
> compliant, but I don't think it's very good for your own compliance, if that 
> makes sense?
Peter Stuge wrote:
>Lewis, Ian (Microstar Laboratories) wrote:
>> Still, the more I look at this, the more it sounds like we would meet 
>> our obligations if we provide an About tab in our control panel 
>> application...

> Mh - again, I don't think that's cool.

Would you consider this true - for our compliance - if we put a piece of paper 
in the box that told you where to find the source code from your measurement 
device? If this point about the medium on which the user obtains the source 
code is critical, then this option is probably not a good solution for us. But, 
I am still curious whether you would consider us compliant if we had a piece of 
paper in the box that told the user that the source code for the 
Coreboot/SeaBIOS (if we use SeaBIOS) firmware in their measurement instrument 
is available by opening our Control Panel application, going to the About tab, 
and clicking the Get Firmware Source button (say).

I will note that it is impossible to use our device in any way unless our 
driver and server are installed, the basic version of which is available to 
anyone for download from our web site. And, the installation of these 
components always installs the Control Panel application. So, even if an OEM 
were to pre-configure a system with our hardware, the Control Panel application 
would always be available to all potential users of our device.

Peter Stuge wrote:
> Sorry, I wasn't clear enough. I meant to refer to flash memory which is 
> *somehow* accessible via USB - but not neccessarily in the form of a 
> "removable drive". A much better "look" would be a virtual CD-ROM, which are 
> per definition read-only.

I fully understood what you said in your original message. My point remains: if 
we provide a virtual CD-ROM - which I still consider a "removable drive" even 
if it is read only - then plugging in our device, which has nothing to do with 
a drive of any kind, you suddenly have a new drive letter taken under Windows 
for no obvious reason (for most users). Taking up a drive letter can really 
mess things up for a user if they assume that letter is free for use, for 
example to attach to a network share when they log into a network. 

Of course, you do gain the nice feature that Windows will pop up a box on first 
use telling you the new drive showed up. And, that would give you something 
that lets a user know something is going on that might need their attention. 
And, as you say, a CD-ROM is clearly a " medium customarily used for software 
interchange".

Peter Stuge wrote:
> This is actually quite common with USB cellphone network modems and with some 
> other USB-connected devices as well. 

Yes. We know how to do this, though I am not overly enthusiastic about 
implementing it. I do not know much about USB cellphone modems, but it seems 
like the drive might make some sense to the user in this case. It certainly 
does when you plug in a cell phone since the cell phone has storage you want to 
be able to access. With our device, it would just be a spurious drive in most 
real installations. Of course, a user could disable the drive. But, because of 
the way Windows manages USB devices, it would most likely keep popping back up 
from time to time when you plugged it into a different slot.

Peter Stuge wrote:
> I would recommend to avoid SeaBIOS if you can. Not because it's bad, but 
> because you may not require it, and it would avoid dealing with GPLv3 
> compliance, which is a lot more involved.

We will almost certainly try to do this, though for initial development - all 
in house, so no GPL issues, we are going to work with SeaBIOS because we 
already have loader code that knows how to talk with a legacy BIOS. Once we 
have that fully functional, we can look at direct loading from Coreboot. 
Currently we boot our systems either directly from the first instruction the 
processor executes, when using our own processor designs, or from a legacy BIOS 
or UEFI for processor modules. I suspect it will be pretty easy for us to add 
one more boot mechanism to load directly as a payload of Coreboot. We make very 
little demand on the initial boot load environment.

Peter Stuge wrote:
> You really should learn how 

Re: [coreboot] BDX-DE PCI init fail

[David Hendricks]

Hi Hilbert,

On Wed, Jan 3, 2018 at 12:56 AM, Hilbert Tu(杜睿哲_Pegatron) <
hilbert...@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.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] soc/intel/braswell for cherrytrail ?

[Zoran Stojsavljevic]

Hello Peter,

ATOM Cherrytrail is well known code name for CCG creations (retail
target space). ATOM Braswell is an IOTG creation (embedded marketing
space), and it comes with some Cherrytrail enhancements (silicon
packaging, which goes from -40C to +85C - retail is from 0C to +70C).

As I recall. this is THE only change, so silicon should be the same. You can go
and try. 99.9% it is compatible!

Zoran
___

On Wed, Jan 3, 2018 at 3:50 PM, Peter Stuge  wrote:
> Hi,
>
> do you think the braswell code should work for cherrytrail Atoms?
>
>
> Thanks!
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] soc/intel/braswell for cherrytrail ?

[Peter Stuge]

Hi,

do you think the braswell code should work for cherrytrail Atoms?


Thanks!

//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Peter Stuge]

Lewis, Ian (Microstar Laboratories) wrote:
> Peter Stuge wrote:
> > If you can handle the cost then you could design a (read-only, e.g.
> > USB- attached flash memory appearing as a CD-ROM) medium *into* your
> > hardware, which stores the source code corresponding to the object code
> > which is in boot flash. I find that ideal.
> 
> What you suggest is very much what I was thinking when I originally
> considered a microSD to house the source. My thought was to attach the
> microSD permanently to our system in such a way that our OS could read
> it (not the host PC OS). Then, from our Windows Control Panel
> application for our device, on an About tab, say, a user could click a
> button and get the source for the actual image used to boot the system,
> which of course would include the license and all other content needed
> to satisfy GPL. This would completely protect the microSD from write
> because we would not allow any means to write to it (though, we would
> probably allow removal for advanced users who really wanted to get
> directly to the drive - and GPLv3 might even require us to allow this).

Consider Section 3 a) "on a medium customarily used for software
interchange" - a Control Panel snap-in arguably isn't such a medium.

What specific interface to use for delivery of source code probably
depends on how your product works, and what you want to enable your
customers to offer.


> Your specific suggestion of a USB connected Flash drive setup is also
> possible, and probably a bit less work for us - we would just need a
> built-in USB to USB hub or PCIe to USB host controller to allow for our
> device and the Flash drive to coexist on the same cable, but most flash
> USB drives are too physically big to work for us (resolvable, but
> probably not without adding more engineering effort - the USB connector
> alone is almost too big, and that means we might need to go to a
> board-mount drive - one more complication). And, there is a bit of a
> mess here under Windows because the Flash drive, if not controlled by
> our software, would just show up in Windows as a drive every time
> someone plugged in our device.

Sorry, I wasn't clear enough. I meant to refer to flash memory which
is *somehow* accessible via USB - but not neccessarily in the form of a
"removable drive". A much better "look" would be a virtual CD-ROM,
which are per definition read-only.


> But, at the least, this could be a real nuisance for users. And, it
> seems like it could also be quite confusing (I plugged in a measurement
> device and now I have a new drive. Where did that come from?). 

This is actually quite common with USB cellphone network modems and
with some other USB-connected devices as well. USB allows exposing
several different interfaces (that's a specific USB term), each with
different functionality, over one electrical (cable, onboard) connection.


Lewis, Ian (Microstar Laboratories) wrote:
> > Also, why do you mention GPL V3? Coreboot is 2 or later.
> 
> The module we are using uses both Coreboot (GPLv2) and SeaBIOS (GPLv3).

I would recommend to avoid SeaBIOS if you can. Not because it's bad, but
because you may not require it, and it would avoid dealing with GPLv3
compliance, which is a lot more involved.

SeaBIOS provides legacy compatibility for systems that really require a
BIOS, but since your board only ever boots your OS, maybe you can avoid
one.

If your operating system depends strongly on BIOS services and data
structures then you can consider using libpayload in your operating
system, instead of BIOS calls. libpayload has a BSD license.


Lewis, Ian (Microstar Laboratories) wrote:
> Ø  Did you actually need to change coreboot or SeaBIOS?
> 
> No.  We have made no changes.  At the moment we do not even know
> how to build the required modules for the system.  Personally, I
> would rather we did not have to know how to do a build, but I think
> we will need to so that we can validate that the source code
> matches the binary we distribute.

You really should learn how to build the boot image yourself, because
it is quite risky to rely on third parties. The good news is that it's
not very difficult; especially for the Vortex86EX it should be
straightforward, because coreboot has few if any external dependencies
there.


> Even once we do work out how to do a build, I very much doubt we
> will make any changes at all.  If we do change anything in coreboot
> or SeaBIOS – or any other GPL licensed project for that matter, we
> will definitely release our changes back to the relevant project to
> accept or reject.

You don't strictly have to just to be compliant, but it is certainly
in the spirit of the license, and it does *simplify* compliance,
because you do not have to maintain private patches.


> Ø  Your idea about using the "About" tab to inform the user about
> the licenses and where to find the code is good.  It should cover
> your company even if the customer never reads it.
> 
> If this is 

Re: [coreboot] [flashrom] [announce] flashrom 1.0

[Paul Kocialkowski]

Hi,

Le mercredi 03 janvier 2018 à 15:34 +0300, Ivan Ivanov a écrit :
> Please tell - are there any real reasons why the Paul Kocialkowski's
> KB9012 support patches
> still cannot be merged? It is very discouraging - after 2 years of
> waiting to not see them at 1.0
> Is there any way to get these patches merged, and maybe re-tag the
> flashrom 1.0 release ?

We have been discussing about the future of these patches and they
cannot be accepted as-is today. Mostly, Nico was worried that issuing
SPI commands for the EDI protocol might cause some chips to misbehave if
these commands have another signification. I think this is a valid
concern.

We agreed that one way to solve this would be to create groups for
probing, e.g. one with jedec-compliant chips (default) and one for ene
chips, so that only one group is probbed at the same time.

I did not have the time to implement this idea yet, so it will block
kb9012 inclusion for now. If you'd like to go ahead and implement this
feature, I'd be happy to review your patches!

Cheers,

Paul

> 2017-12-30 23:49 GMT+03:00 Ivan Ivanov :
> > Hi Nico, please could you also merge the KB9012 patches by Paul
> > Kocialkowski :
> > 
> > https://patchwork.coreboot.org/patch/4412/
> > https://patchwork.coreboot.org/patch/4413/
> > https://patchwork.coreboot.org/patch/4414/
> > 
> > It is ridiculous how these patches are still not merged , after
> > almost
> > 2 years... :P
> > These patches are adding the support for KB9012 reading / writing,
> > the only open source flashing solution for these embedded
> > controllers
> > 
> > Merging these patches could accelerate the development of Origami EC
> > libre firmware,
> > please do it
> > 
> > Best regards,
> > Ivan Ivanov
> > 
> 
> 2018-01-03 0:50 GMT+03:00 Nico Huber :
> > Hi folks,
> > 
> > flashrom-1.0 is out! finally. It's not a very big version step in
> > terms
> > of changes, but it was about time and we thought with the switch
> > over to
> > Git it's the right moment for 1.0.
> > 
> > Here are the release notes:
> > https://flashrom.org/Flashrom/1.0
> > 
> > If you don't use Git, you can find a tarball here:
> > https://download.flashrom.org/releases/flashrom-1.0.tar.bz2
> > 
> > Thanks to everybody supporting flashrom and this release in
> > particular.
> > 
> > Nico
> > 
> > ___
> > flashrom mailing list
> > flash...@flashrom.org
> > https://mail.coreboot.org/mailman/listinfo/flashrom
-- 
Paul Kocialkowski, developer of free digital technology and hardware
support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [flashrom] [announce] flashrom 1.0

[Ivan Ivanov]

Hi Nico,

Please tell - are there any real reasons why the Paul Kocialkowski's
KB9012 support patches
still cannot be merged? It is very discouraging - after 2 years of
waiting to not see them at 1.0
Is there any way to get these patches merged, and maybe re-tag the
flashrom 1.0 release ?

Best regards,
Ivan Ivanov

2017-12-30 23:49 GMT+03:00 Ivan Ivanov :
> Hi Nico, please could you also merge the KB9012 patches by Paul Kocialkowski :
>
> https://patchwork.coreboot.org/patch/4412/
> https://patchwork.coreboot.org/patch/4413/
> https://patchwork.coreboot.org/patch/4414/
>
> It is ridiculous how these patches are still not merged , after almost
> 2 years... :P
> These patches are adding the support for KB9012 reading / writing,
> the only open source flashing solution for these embedded controllers
>
> Merging these patches could accelerate the development of Origami EC
> libre firmware,
> please do it
>
> Best regards,
> Ivan Ivanov
>

2018-01-03 0:50 GMT+03:00 Nico Huber :
> Hi folks,
>
> flashrom-1.0 is out! finally. It's not a very big version step in terms
> of changes, but it was about time and we thought with the switch over to
> Git it's the right moment for 1.0.
>
> Here are the release notes:
> https://flashrom.org/Flashrom/1.0
>
> If you don't use Git, you can find a tarball here:
> https://download.flashrom.org/releases/flashrom-1.0.tar.bz2
>
> Thanks to everybody supporting flashrom and this release in particular.
>
> Nico
>
> ___
> flashrom mailing list
> flash...@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Werner Zeh]

Hi Ian.

First of all I want to clarify some things so that all of us have the
same understanding:

1. On our current coreboot-based products we just use coreboot itself
with no other payload (e.g. SeaBIOS). We use instead a Linux as a
payload which is self-tailored for every dedicated mainboard.
2. The vast majority of our products is sold to OEMs.
3. We provide the OS to the OEM which remains the one and only OS in the
system. The OEMs uses our OS and it's provided interfaces to build his
own applications on top of it.
4. Every mainboard/hardware belongs to a complete system which will in
any case have a way to show informations to the end-customer (it might
be a LCD-panel, a VNC-connection or a dedicated engineering system which
is able to communicate with the devices).

> With a few minutes spent looking, it is not at all clear to me how
Siemens handles their GPL responsibility and whether they attempt to
provide compliance for their customers or not.

The way we decided to deal with the GPL-obligations is:
1. Make sure all our mainboards are on master! We always build the final
image based on the latest master. Of course one version freezes the time
it is released while master keeps going forward. But one can easily get
the git-commit which was the latest once the version has been released
(by looking at the console output for example).
2. Provide a screen (very similar to your About-Screen) on the system
where every one who is interested in can see all the needed informations
(version, licenses, ...). The information is gathered in a text file
which is located in the CBFS on the flash. Therefore this information is
bound to the hardware itself. We do provide a built-in text-viewer so
that one can see all the information when ever there is a need for it.

So if there is someone out there who wants to run its own copy of
coreboot on our hardware: Go to coreboot.org, get the latest tree,
select the matching mainboard and...make! Beside the fact that you will
loose the warranty if you install your own firmware (which was not
verified by Siemens) on our hardware  you are free to go!

Do I oversee something?

Werner



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BDX-DE PCI init fail

[杜睿哲_Pegatron]

Hi Zoran,

The log was just at following link:
http://mail.coreboot.org/pipermail/coreboot/attachments/20171227/b07eb74e/attachment.txt
With messages:

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

By the way, I have tried to use U-Boot and Grub2 as payload, but I don't think 
the payload was executed since it failed at PCI 00:1f.3 init.

-Hilbert

-Original Message-
From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
Sent: Saturday, December 30, 2017 2:32 PM
To: Hilbert Tu(杜睿哲_Pegatron)
Cc: David Hendricks; coreboot@coreboot.org
Subject: Re: [coreboot] BDX-DE PCI init fail

> I still have same issue even tried to comment out the 1f.3 device in
> ./src/mainboard/intel/camel- backmountain_fsp/devicetree.cb then
> rebuild coreboot.

You wrote that you submitted the log. Is this the full log? I doubt. I do NOT 
see physical memory layout as well as MTRR layout.

Could you, please, submit the full/complete log?

Which payload are you using? SeaBIOS?

Thank you,
Zoran

On Fri, Dec 29, 2017 at 5:58 AM, Hilbert Tu(杜睿哲_Pegatron)
 wrote:
> Hi David,
>
>
>
> Thanks for your information.
>
> I still have same issue even tried to comment out the 1f.3 device in
> ./src/mainboard/intel/camelbackmountain_fsp/devicetree.cb then rebuild
> coreboot.
>
> Could you let me know how to do that?
>
>
>
> -Hilbert
>
>
>
> From: David Hendricks [mailto:david.hendri...@gmail.com]
> Sent: Friday, December 29, 2017 9:46 AM
> To: Hilbert Tu(杜睿哲_Pegatron)
> Cc: coreboot@coreboot.org
> Subject: Re: [coreboot] BDX-DE PCI init fail
>
>
>
> Hi Hilbert,
>
> Have you had any luck? I have a board with a similar problem.
> Commenting out the entry for device 1f.3 in devicetree.cb seemed to
> help (I copied src/mainboard/intel/camelbackmountain_fsp for my project).
>
>
>
> On Wed, Dec 27, 2017 at 2:17 AM, Hilbert Tu(杜睿哲_Pegatron)
>  wrote:
>
> Hi,
>
>
>
> I am porting coreboot on Intel BDX-DE platform and it gets stuck when
> init PCI 00:1f.3. This device should be SMBus, serial management bus.
> But I don’t know why this happened. Does anyone can give me some hint?
> Attached is my boot up log. Thanks in advance.
>
>
>
> -Hilbert
>
> 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.
> 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件
> 通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
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.
本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] BDX-DE PCI init fail

[Zoran Stojsavljevic]

Hello Hilbert,

I am currently at job, so I do not have any time to look into it/into
your maximal log, enabled now. Somebody from Google folks assigned to
Coreboot might want to chime in. :-)

I will look to your log later tonite.

Thank you,
Zoran

On Wed, Jan 3, 2018 at 9:56 AM, Hilbert Tu(杜睿哲_Pegatron)
 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.
>
> -Hilbert
>
> -Original Message-
> From: Hilbert Tu(杜睿哲_Pegatron)
> Sent: Tuesday, January 02, 2018 9:41 AM
> To: 'Zoran Stojsavljevic'
> Cc: David Hendricks; coreboot@coreboot.org
> Subject: Re: [coreboot] BDX-DE PCI init fail
>
> Hi Zoran,
>
> The log was just at following link:
> http://mail.coreboot.org/pipermail/coreboot/attachments/20171227/b07eb74e/attachment.txt
> With messages:
>
> MTRR check
> Fixed MTRRs   : Enabled
> Variable MTRRs: Enabled
>
> By the way, I have tried to use U-Boot and Grub2 as payload, but I don't 
> think the payload was executed since it failed at PCI 00:1f.3 init.
>
> -Hilbert
>
> -Original Message-
> From: Zoran Stojsavljevic [mailto:zoran.stojsavlje...@gmail.com]
> Sent: Saturday, December 30, 2017 2:32 PM
> To: Hilbert Tu(杜睿哲_Pegatron)
> Cc: David Hendricks; coreboot@coreboot.org
> Subject: Re: [coreboot] BDX-DE PCI init fail
>
>> I still have same issue even tried to comment out the 1f.3 device in
>> ./src/mainboard/intel/camel- backmountain_fsp/devicetree.cb then
>> rebuild coreboot.
>
> You wrote that you submitted the log. Is this the full log? I doubt. I do NOT 
> see physical memory layout as well as MTRR layout.
>
> Could you, please, submit the full/complete log?
>
> Which payload are you using? SeaBIOS?
>
> Thank you,
> Zoran
>
> On Fri, Dec 29, 2017 at 5:58 AM, Hilbert Tu(杜睿哲_Pegatron)
>  wrote:
>> Hi David,
>>
>>
>>
>> Thanks for your information.
>>
>> I still have same issue even tried to comment out the 1f.3 device in
>> ./src/mainboard/intel/camelbackmountain_fsp/devicetree.cb then rebuild
>> coreboot.
>>
>> Could you let me know how to do that?
>>
>>
>>
>> -Hilbert
>>
>>
>>
>> From: David Hendricks [mailto:david.hendri...@gmail.com]
>> Sent: Friday, December 29, 2017 9:46 AM
>> To: Hilbert Tu(杜睿哲_Pegatron)
>> Cc: coreboot@coreboot.org
>> Subject: Re: [coreboot] BDX-DE PCI init fail
>>
>>
>>
>> Hi Hilbert,
>>
>> Have you had any luck? I have a board with a similar problem.
>> Commenting out the entry for device 1f.3 in devicetree.cb seemed to
>> help (I copied src/mainboard/intel/camelbackmountain_fsp for my project).
>>
>>
>>
>> On Wed, Dec 27, 2017 at 2:17 AM, Hilbert Tu(杜睿哲_Pegatron)
>>  wrote:
>>
>> Hi,
>>
>>
>>
>> I am porting coreboot on Intel BDX-DE platform and it gets stuck when
>> init PCI 00:1f.3. This device should be SMBus, serial management bus.
>> But I don’t know why this happened. Does anyone can give me some hint?
>> Attached is my boot up log. Thanks in advance.
>>
>>
>>
>> -Hilbert
>>
>> 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.
>> 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件
>> 通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
> 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.
> 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot