coreboot January 2018

coreboot@coreboot.org

60 participants
155 discussions

Re: [coreboot] BDX-DE PCI init fail
by Hilbert Tu(杜睿哲_Pegatron) 04 Jan '18

04 Jan '18

Hi Zoran, I don't understand. We don't have extra MCU and, from following message, we also have correct microcode. Why you mean we should have " PPR 0x50663 PPR PCH "? My understanding is they are in/just the same chip...Please help to clarify. Thanks. >>microcode: sig=0x50663 pf=0x10 revision=0x700000e <<=========================== >>CPUID: 00050663 -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. 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Re: [coreboot] BDX-DE PCI init fail
by Zoran Stojsavljevic 04 Jan '18

04 Jan '18

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(a)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@gmail.com] > Sent: Thursday, January 04, 2018 7:56 AM > To: Hilbert Tu(杜睿哲_Pegatron) > Cc: Zoran Stojsavljevic; coreboot(a)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(a)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. > 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Re: [coreboot] BDX-DE PCI init fail
by Hilbert Tu(杜睿哲_Pegatron) 04 Jan '18

04 Jan '18

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@gmail.com] Sent: Thursday, January 04, 2018 7:56 AM To: Hilbert Tu(杜睿哲_Pegatron) Cc: Zoran Stojsavljevic; coreboot(a)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(a)pegatroncorp.com<mailto:Hilbert_Tu@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. 本電子郵件及其附件可能含有機密或依法受特殊管制之資訊，僅供本電子郵件之受文者使用。台端如非本電子郵件之受文者或誤收本電子郵件，請立即回覆郵件通知寄件人，並銷毀本電子郵件之所有複本及附件。任何未經授權而使用、揭露、散佈或複製本電子郵件或其附件之行為，皆嚴格禁止。

1 0

Can coreboot for KabyLake rvp11 work on Intel Sasby Island kit?
by Toan Le manh 04 Jan '18

04 Jan '18

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

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Lewis, Ian (Microstar Laboratories) 04 Jan '18

04 Jan '18

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 to build the boot image yourself, because it is quite risky to rely on third parties. Yes. I think this is completely correct. I do not think we would be in a good position at all if we claimed we had the correct source for a binary we did not build ourselves. This would be especially true if we have to comply with GPLv3 where we probably have to provide the instructions on how to go about replacing the firmware. Peter Stuge wrote: > Ian Lewis wrote: >> 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. Understood. But, since we plan to distribute a product, we have to make any changes public. So, we might as well make them available to the original project. And, we usually do that even when we make changes to an open source project only for internal use, if the changes seem to have any general value. Peter Stuge wrote: > Keep in mind that compliance is required when copying and distributing the Program in object code or executable form, meaning that marketing material such as webpages don't come with requirements. Right. I understood this. I did not mean to imply that Siemens had done anything wrong. I just meant that I could not tell how they handled GPL compliance. So, I could not use their practices to learn anything about what we should do. Peter Stuge wrote: >>> If it is already there people will stop asking your customers for >>> the source code! > No - please avoid that reasoning. Peter Stuge wrote: > Upstream *can never* ensure your compliance! Understood. The license itself seems very clear on this point. I very much appreciate the effort you - and everyone else on this group - have taken to help me understand our obligations under GPL and how to use your product in that context. Ian

1 0

Re: [coreboot] BDX-DE PCI init fail
by David Hendricks 04 Jan '18

04 Jan '18

Hi Hilbert, On Wed, Jan 3, 2018 at 12:56 AM, Hilbert Tu(杜睿哲_Pegatron) < Hilbert_Tu(a)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.

1 0

soc/intel/braswell for cherrytrail ?
by Peter Stuge 03 Jan '18

03 Jan '18

Hi, do you think the braswell code should work for cherrytrail Atoms? Thanks! //Peter

2 1

Re: [coreboot] [flashrom] [announce] flashrom 1.0
by Paul Kocialkowski 03 Jan '18

03 Jan '18

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 <qmastery16(a)gmail.com>: > > 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 <nico.h(a)gmx.de>: > > 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 > > flashrom(a)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/

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Werner Zeh 03 Jan '18

03 Jan '18

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

2 1

[announce] flashrom 1.0
by Nico Huber 03 Jan '18

03 Jan '18

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

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2018