March 2017 - coreboot - mail.coreboot.org

Re: [coreboot] Coreboot wiki: what license is the content under?
by David Hendricks March 31, 2017

March 31, 2017

On Fri, Mar 31, 2017 at 10:20 AM, Sam Kuper <sam.kuper(a)uclmail.net> wrote: > Also, to further address Patrick's point above about marketing > material: it is important that the provenance of information about > Coreboot can be established. This is a reputational matter. That means > it is important that people should not legally be able to misrepresent > Coreboot contributors' views, etc, Both CC-BY and CC-BY-SA have "no endorsement" clauses, and the source of derived materials will still be easily traced back to coreboot.org (or archive.org or wherever). > or claim Coreboot contributors' > work as their own. Both BY and BY-SA licenses require attribution. > > [1] How so? Because a licensee who creates a derivative work of a CC > BY-licensed work can license that derivative under terms (e.g. CC-0) > that would allow *their* licensees do potentially misattribute or > otherwise create reputational risk without fear of breaching licensing > terms. Section 3.A.4 of the BY license covers that: "If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License." So distributing a derived work with a different license does not nullify the original terms.

1 0

Re: [coreboot] Coreboot wiki: what license is the content under?
by Timothy Pearson March 31, 2017

March 31, 2017

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/31/2017 11:17 AM, Sam Kuper wrote: > On 30/03/2017, Patrick Georgi via coreboot <coreboot(a)coreboot.org> wrote: >> I'd go with CC-BY for the simple reason that documentation acts as >> marketing material which should see the widest distribution possible. > > This does not make sense to me. CC BY-SA would not hinder distribution > of documentation. For what it's worth we generally require attribution for public release of both source and documentation. Source can generally be handled in a "weaker" manner via GIT and the copyright lines in the file headers, since the consumers of the source code generally understand how to determine authorship of a file (this is especially useful to determine who is to blame for sloppy coding / outright bugs, and work toward a fix). Plus, there is an intrinsic motivation to keep working on the source code itself; it is inherently rewarding to improve a software project and to be able to make it work better for your specific need. Documentation, on the other hand, is designed for public consumption and is generally a thankless chore for developers who would much rather be adding new features to the software than writing things they already know down. Perhaps the knowledge that someone's name will be attached in perpetuity to the documentation they write might just motivate creation of more material? Just my $0.02. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJY3od8AAoJEK+E3vEXDOFbkS0H/i5155G4WRBEG0gy4j3EkyjR 89oPCmMmx94IzYcf76IDLLus46lzmF5MoBMPgJA3eQpavEtWoRMb1s+6jmV/paY3 LJcPOStqx5x6sLQqjjbeWBZ6QBsFfN/gR09TKuYP5BosGH6oURtj63U39LrbLRta XqOUTunIcu/s7UmGICZM+Nt6cEhVSOdgza0Xnhba9iQG6PpZ97uZpv2bbGnmgXzk vlk99zKe4O8c5n4uCFhjO3CEhbEWbVl5zHRG/eSHMwFU7EbMuysl5nu/4Ct0vOcK Td1Kte47XY9Y2TBkOcmQUxQgEGRqz2axpAn90LumjK/QoJnDUcoIL4M755ljCVY= =lKQa -----END PGP SIGNATURE-----

2 1

Re: [coreboot] Coreboot wiki: what license is the content under?
by Nico Huber March 31, 2017

March 31, 2017

On 31.03.2017 18:17, Sam Kuper wrote: > On 30/03/2017, Patrick Georgi via coreboot <coreboot(a)coreboot.org> wrote: >> I'd go with CC-BY for the simple reason that documentation acts as >> marketing material which should see the widest distribution possible. > > This does not make sense to me. CC BY-SA would not hinder distribution > of documentation. Of course it would. The mere existence of two different licenses (CC BY / CC BY-SA) already implies that. If nobody had an issue with -SA, why would CC BY exist at all? +1 to make everything new CC BY 4.0 by default. > >> People who dislike licensing their content that freely can publish >> elsewhere and set up a (CC-BY'd) link. > > Having people publish content outside the wiki and link to it from the > wiki would obviously lead to even more fragmentation of the > documentation than Coreboot already suffers from, making Coreboot > remain a project that requires a lot of effort to grok, and has slow > uptake. (Cf. Steve Krug's "Don't Make Me Think".) > > Surely it would be better to aim to make the Coreboot wiki a "one-stop > shop" for information about Coreboot, as far as possible. This being > so, Coreboot ought to avoid licensing choices that foreseeably > fragment the documentation. > >> In any case, we can (and IMHO should) decouple the discussions about >> dealing with current content and about future licensing. > > Are you really willing to potentially throw away *that* many hundreds > of hours of volunteer documentation effort? I am. With documentation it seems to be the same as with code: The more you blow it up, the more you hide the significant facts. Both should (almost) always be condensed. And most of the documentation in our wiki is outdated anyway. Nico

1 0

Re: [coreboot] Coreboot wiki: what license is the content under?
by Sam Kuper March 31, 2017

March 31, 2017

On 30/03/2017, Patrick Georgi via coreboot <coreboot(a)coreboot.org> wrote: > I'd go with CC-BY for the simple reason that documentation acts as > marketing material which should see the widest distribution possible. This does not make sense to me. CC BY-SA would not hinder distribution of documentation. > People who dislike licensing their content that freely can publish > elsewhere and set up a (CC-BY'd) link. Having people publish content outside the wiki and link to it from the wiki would obviously lead to even more fragmentation of the documentation than Coreboot already suffers from, making Coreboot remain a project that requires a lot of effort to grok, and has slow uptake. (Cf. Steve Krug's "Don't Make Me Think".) Surely it would be better to aim to make the Coreboot wiki a "one-stop shop" for information about Coreboot, as far as possible. This being so, Coreboot ought to avoid licensing choices that foreseeably fragment the documentation. > In any case, we can (and IMHO should) decouple the discussions about > dealing with current content and about future licensing. Are you really willing to potentially throw away *that* many hundreds of hours of volunteer documentation effort? Regards

1 0

coreboot community meeting minutes for March 30th, 2017
by Martin Roth March 31, 2017

March 31, 2017

Here are the meeting minutes from yesterday's coreboot community meeting. Info about the next meeting (Thursday, April 13) is at the bottom. ####################################################################### Thursday, March 30th, 2017 General coreboot news & discussions * AGESA updates by Kyösti - These need testing, so if you have an AGESA based board, please try them on your board. - https://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+… * TPM regression? - https://ticket.coreboot.org/issues/102 - https://ticket.coreboot.org/issues/104 - PhilippD (TPM area maintainer) is looking into these. * Documentation license - For coreboot proper, coreboot leadership is leaning toward CC-BY, to allow the widest distribution possible. We're not worried about copying things in from other places - those can be referenced on the other websites. - https://creativecommons.org/licenses/ - CC-BY is a non-restrictive license, similar to a BSD license. - CC-BY-SA requires that the license not change, similar to GPL license - Each document is separate, not entangled like the source code, so if we decided to change the license later, we can on an individual basis. Infrastructure Issues & News * Next release 4.6 - Targeting April 17 - Please test your boards - Please fix bugs https://ticket.coreboot.org * Discussions about changing the CCM to a different conferences software. - We can revisit in November if desired. Let's not change before then. * More REACTS systems by Martin (License for 5) - Asus P5GC-MX - Gigabyte GA-G41M-ES2L - Next is AMD Mahogany F10h * Jenkins is misbehaving - completed builds are not marking the servers as being free, causing long delays in running the next build. We're working on it. * Software Freedom Conservancy admission still pending - working out the governance details. - One hangup is the blobs directory. * Working on a jenkins update to show which boards have been changed by a patch. Waiting for jenkins issues to be fixed before moving on with this. * European coreboot conference - https://ecc2017.coreboot.org/ * Denver coreboot conference - Waiting for SFC so we can accept payments * QUESTION: how many folks attend the coreboot conf usually? - Around 50 people max for Denver 2017 unless huge interest. Maybe 100 for the European coreboot conference. Development * flashrom git status? - Do we want to talk about flashrom in the coreboot community meeting - Discuss this with flashrom crew. - Martin isn't positive, but thinks that we're waiting for StefanCT to set up a build test at this point. - Stable branch in gerrit doesn't build (Intentionally) - I think "staging" does, but when a user clones the repo and types "make" in the default "stable" branch it throws an error about needing to use the upstream repo (on flashrom.org) - Can we push to staging now? * Review of siro’s libpayload patches - Patches need reviewers * checkpatch.pl clean-up going on nicely - Lee is done with his cleanup for now - Need to get rid of false positives (Update the script) before turning it on in the builder. ################################################################## Next meeting is Thursday, April 13, 2017 Check the coreboot calendar for the time in your timezone https://www.coreboot.org/calendar.html Join using the bluejeans web app or the phone bridge: https://bluejeans.com/616384323 Phone bridge call in numbers: https://www.bluejeans.com/numbers Meeting ID: 616384323 Current agenda & history: https://coreboot-meeting.pads.ccc.de/CommunityMeetingTopics

1 0

ASUS KGPE-D16 Automated Test Failure [master]
by Raptor Engineering Automated Coreboot Test Stand March 31, 2017

March 31, 2017

The ASUS KGPE-D16 fails verification for branch master as of commit 1e0543541ebd9cc9b30a15029de047a4aebb15b9 The following tests failed: BOOT_FAILURE Commits since last successful test: 1e05435 drivers/intel/gma: Guard GFX_GMA_* configs See attached log for details This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification

1 0

Re: [coreboot] Question about Intel HD graphics and FLR
by Taiidan＠gmx.com March 31, 2017

March 31, 2017

This is indicative of a graphics device without FLR or with a broken reset mechanism. You would have more luck posting on the vfio-users mailing list, the vfio core developer responds to every question there.

2 1

Re: [coreboot] SPI Flash does not work on Intel LeafHill CRB
by Toan Le manh March 31, 2017

March 31, 2017

2017-03-31 12:41 GMT+07:00 Zeh, Werner <werner.zeh(a)siemens.com>: > > In regard to the Winbond flash we had issues that has shown the same > behavior like your case. > The root cause in our case was the "security register" called region in > the flash which resides above the 16 MB address range and > has a size of 0x300 bytes (on W25Q128FV for example). The original flash > contents on the CRB contains some data > in that region and we were only able to boot the CRB after re-flashing if > this region was transferred to the new flash completely. > To do so, you must tweak BeeProg a bit, there are special options to erase > and program this security registers. > > Dear Werner, Thank you very much for the reply. I hope and believe that this is our case too. Could you please guide me to transfer the "security register" region from the original flash to new flash using BeeProg? Once again, thanks a lot. Best Regards, Toan

1 0

Re: [coreboot] SPI Flash does not work on Intel LeafHill CRB
by Zeh, Werner March 31, 2017

March 31, 2017

Hi Toan. On BeeProg you can select the offset inside the flash where your image should be loaded to. Just have a look at the lower section in your "load file" dialog box. There is an entry called "Buffer offset for loading". Select positive offset for binary formats and set to 8 MB. That will load your 8 MB image into the upper portion of the buffer and hence your image will be flashed to the upper flash address range. In regard to the Winbond flash we had issues that has shown the same behavior like your case. The root cause in our case was the "security register" called region in the flash which resides above the 16 MB address range and has a size of 0x300 bytes (on W25Q128FV for example). The original flash contents on the CRB contains some data in that region and we were only able to boot the CRB after re-flashing if this region was transferred to the new flash completely. To do so, you must tweak BeeProg a bit, there are special options to erase and program this security registers. If you use a different flash type like N25Q128Ax1E, this issue is not visible because this flash type does not have the security registers the Winbond one has. It seems like CSE checks the used flash type and uses different boot paths inside. I hope that helps. Werner >Dear Goetz, > >Thanks for your reply. I'm trying to rebuild the image. >Another question here: I had an 8 MB Intel-provided image. I'm using BeeProg2C flashing device (with PG4UW software). >Is there any "trick" forcing the flashing device to flash 8 MB image into 16 MB SPI chip? Something likes flash to the low-8MB of chip instead of high-8MB?

1 0

Re: [coreboot] Question about Intel HD graphics and FLR
by Zoran Stojsavljevic March 30, 2017

March 30, 2017

> So long as you don't have to kill anyone to get the info, I genuinely appreciate the help. Question: did you ever kill... Pulling your leg! :-))) _______ Back on the topic/thread: [1] What kind of VM? [2] Does your VM use PCIe Pass-through method (I guess, you must have also in BIOS IOMMU/VT-d ON, this is A MUST)? *Explanation: PCI Pass-through is a method of giving a VM direct access to a PCI device.* Thank you, Zoran On Thu, Mar 30, 2017 at 7:18 PM, Joshua Pincus <joshua.pincus(a)gmail.com> wrote: > Hi Zoran, > > So long as you don't have to kill anyone to get the info, I genuinely > appreciate the help. > JP > > On Thu, Mar 30, 2017 at 9:54 AM, Zoran Stojsavljevic < > zoran.stojsavljevic(a)gmail.com> wrote: > >> OK, Joshua! >> >> I do not promise anything. But I, out of (your) desperation, will try to >> find answers for you. If (no promise)... >> >> If I (eventually) return back, I have only one condition for you: NEVER >> ask how I found (any future) answer for/to you! >> >> Thank you, >> Zoran >> >> On Thu, Mar 30, 2017 at 5:48 PM, Joshua Pincus <joshua.pincus(a)gmail.com> >> wrote: >> >>> Hi Zoran, >>> >>> Thanks for your reply. >>> >>> My situation is this: When the VM guest comes up the first time from a >>> system-level reset (aka power on), the Broadwell HD graphics device runs >>> fine. I see basic VGA both before and during the boot of Windows. Once >>> Windows boots, the HD graphics device is configured by Intel's driver and I >>> see hi-rez output. On a reboot of Windows within the VM, an FLR is >>> issued. When the guest comes back up, no VGA. Windows does boot but >>> provides no VGA output. If Windows needs to drop into VGA mode so that a >>> user can access the real-mode functionality of the recovery console, still >>> no VGA. >>> >>> It's only on Broadwell-based boards that we have this problem. If we >>> issue FLRs during the reset of the PCI bus for older Intel boards, no >>> problem. We get VGA. Something involved with the FLR is messing up the >>> state of the hardware instead of actually returning the hardware to a >>> virgin state, akin to what you would get from a full system reset. >>> >>> I was wondering if anyone had seen this kind of behavior. We've tried >>> everything. We've manipulated all of the obvious HD graphics MMIO >>> registers involved with restoring VGA but nothing seems to work. >>> >>> Thanks, >>> JP >>> >>> On Thu, Mar 30, 2017 at 4:29 AM, Zoran Stojsavljevic < >>> zoran.stojsavljevic(a)gmail.com> wrote: >>> >>>> Hello Joshua, >>>> >>>> I'll ask similar question, considering UEFI (BIOS). I have no idea if >>>> you can issue somehow easy FLR (PCI Function Level Reset), but if you >>>> can, does this use case repeat itself? >>>> >>>> I found, related to BIOS, this pointer (http://www.tomshardware.co.uk >>>> /forum/278002-30-solved-what-capability-option-bios), since I do NOT >>>> recall this option in any (legacy and UEFI) of the BIOSes I used (and I >>>> used lot (>100) of them). Probably, did not pay too much attention, since I >>>> do not recall this option to be tested/used?! >>>> >>>> Zoran >>>> >>>> On Wed, Mar 29, 2017 at 10:49 PM, Joshua Pincus < >>>> joshua.pincus(a)gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> After performing just an FLR (PCI function level reset) of a Gen8 >>>>> Intel HD graphics device, there's no VGA output from the device, no matter >>>>> what I try to do. I've had coreboot reset the graphics control register, >>>>> VGA control, VGA display disable bit, etc. >>>>> >>>>> Has anyone seen anything like this? The only way I can get VGA >>>>> restored is by performing a system-level reset. But I just want to do an >>>>> FLR. Any ideas? >>>>> >>>>> Thanks, >>>>> JP >>>>> >>>>> -- >>>>> coreboot mailing list: coreboot(a)coreboot.org >>>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>>> >>>> >>>> >>> >> >

1 0