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.
-----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-----
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
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
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:maste...
* 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
by Raptor Engineering Automated Coreboot Test Stand
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
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.
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
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?
> 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
>>>>>
>>>>
>>>>
>>>
>>
>
