coreboot-gerrit December 2018

coreboot-gerrit@coreboot.org

1 participants
1832 discussions

Change in ...coreboot[master]: mb/google/sarien: Enable ISH on arcada, disable on sarien
by Jett Rink (Code Review) 06 Dec '18

06 Dec '18

Jett Rink has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/30070 ) Change subject: mb/google/sarien: Enable ISH on arcada, disable on sarien ...................................................................... Patch Set 1: Code-Review+1 Thank for catching my mistake. Turns out my first coreboot change was a dud. -- To view, visit https://review.coreboot.org/c/coreboot/+/30070 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: If933623f7dbb45c4805fb61430465236eca19ee8 Gerrit-Change-Number: 30070 Gerrit-PatchSet: 1 Gerrit-Owner: Duncan Laurie <dlaurie(a)chromium.org> Gerrit-Reviewer: Duncan Laurie <dlaurie(a)chromium.org> Gerrit-Reviewer: Jett Rink <jettrink(a)chromium.org> Gerrit-Reviewer: Jett Rink <jettrink(a)google.com> Gerrit-Reviewer: Li1 Feng <li1.feng(a)intel.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 06 Dec 2018 16:18:17 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in ...coreboot[master]: Documentation/CoC: revise the instructions for contact the arb team
by Patrick Georgi (Code Review) 06 Dec '18

06 Dec '18

Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30086 Change subject: Documentation/CoC: revise the instructions for contact the arb team ...................................................................... Documentation/CoC: revise the instructions for contact the arb team It's not very helpful to tell somebody who feels wronged "that their mail was probably lost" (in just as many words). State why we don't go for a mailing list or ticket system for grievances and encourage contact multiple people from the outset. Change-Id: Idac4bcdf8b596a7325e463036c580b17a8b2f27b Signed-off-by: Patrick Georgi <pgeorgi(a)google.com> --- M Documentation/code_of_conduct.md 1 file changed, 18 insertions(+), 9 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/86/30086/1 diff --git a/Documentation/code_of_conduct.md b/Documentation/code_of_conduct.md index 3747c70..c06a9fa 100644 --- a/Documentation/code_of_conduct.md +++ b/Documentation/code_of_conduct.md @@ -25,11 +25,20 @@ misunderstandings can (and do) happen. Always assume that others are friendly and may have picked less-than-stellar wording by accident. -If you feel that you have been treated unfairly, we want to hear about -it so we can handle the situation. Please contact our arbitration team -directly: They will listen to you. If you don't get a response within -a few days, your mail was probably lost. Please resend your mail to -another member of the arbitration team in that case. +If you have a grievance due to conduct in this community, we want to hear +about it so we can handle the situation. Please contact our arbitration +team directly: They will listen to you and react in a timely fashion. + +For transparency there is no alias or private mailing list address for +you to reach out to, since we want to make sure that you know who will +(and who won't) read your message. + +However since people might be on travel or otherwise be unavailable at +times, consider reaching out to multiple persons. + +The team will treat your messages confidential as far as the law permits. +For the purpose of knowing what law applies, the list provides the usual +country of residence of each team member. ## Unacceptable Behavior @@ -90,10 +99,10 @@ ## Contact info Our arbitration team consists of the following people -* Stefan Reinauer <stefan.reinauer(a)coreboot.org> -* Patrick Georgi <patrick(a)coreboot.org> -* Ronald Minnich <rminnich(a)coreboot.org> -* Marc Jones <mjones(a)coreboot.org> +* Stefan Reinauer <stefan.reinauer(a)coreboot.org> (USA) +* Patrick Georgi <patrick(a)coreboot.org> (Germany) +* Ronald Minnich <rminnich(a)coreboot.org> (USA) +* Marc Jones <mjones(a)coreboot.org> (USA) ## License and attribution -- To view, visit https://review.coreboot.org/c/coreboot/+/30086 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Idac4bcdf8b596a7325e463036c580b17a8b2f27b Gerrit-Change-Number: 30086 Gerrit-PatchSet: 1 Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

1 0

Change in ...coreboot[master]: Documentation: Import Code of Conduct from Wiki
by Patrick Georgi (Code Review) 06 Dec '18

06 Dec '18

Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30085 Change subject: Documentation: Import Code of Conduct from Wiki ...................................................................... Documentation: Import Code of Conduct from Wiki I reordered the contacts by current activity and added a link to the CC-BY-SA license, otherwise it's the original text. Change-Id: I6f41611db8d9a2f60b24d95abdf30f4fd47cd6f2 Signed-off-by: Patrick Georgi <pgeorgi(a)google.com> --- A Documentation/code_of_conduct.md M Documentation/index.md 2 files changed, 104 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/85/30085/1 diff --git a/Documentation/code_of_conduct.md b/Documentation/code_of_conduct.md new file mode 100644 index 0000000..3747c70 --- /dev/null +++ b/Documentation/code_of_conduct.md @@ -0,0 +1,103 @@ +# Code of Conduct + +This code of conduct outlines our rules and expectations for everybody +participating in the coreboot community. + +## Mailing list and chat etiquette + +We have a friendly and productive atmosphere on our mailing lists, +development / code review tools and IRC chat rooms. Our principles evolve +around the following: + +* It's not the user's fault if something goes wrong. +* Attempt collaboration before conflict. +* People who intentionally insult others (users, developers, corporations, + other projects, or the coreboot project itself) will be dealt with. See + policy below. +* We are dealing with hardware with lots of undocumented pitfalls. It is quite + possible that you did everything right, but coreboot or its tools still + won't work for you. + +Refrain from insulting anyone or the group they belong to. Remember that +people might be sensitive to other things than you are. + +Most of our community members are not native English speakers, thus +misunderstandings can (and do) happen. Always assume that others are +friendly and may have picked less-than-stellar wording by accident. + +If you feel that you have been treated unfairly, we want to hear about +it so we can handle the situation. Please contact our arbitration team +directly: They will listen to you. If you don't get a response within +a few days, your mail was probably lost. Please resend your mail to +another member of the arbitration team in that case. + +## Unacceptable Behavior + +Unacceptable behaviors include: intimidating, harassing, abusive, +discriminatory, derogatory or demeaning speech or actions by any +participant in our community online, at all related events and in +one-on-one communications carried out in the context of community +business. Community event venues may be shared with members of the public; +please be respectful to all patrons of these locations. + +Examples of behaviors we do not accept in our community: + +* harmful or prejudicial verbal or written comments related to gender, + sexual orientation, race, religion, disability; +* inappropriate physical contact, and unwelcome sexual advances; +* deliberate intimidation, stalking or following; +* harassing photography or recording; +* sustained disruption of talks or other events. + +Using this code of conduct aggressively against other people in the +community might also be harassment. Be considerate when enforcing the code +of conduct and always try to listen to both sides before passing judgment. + +## Consequences of Unacceptable Behavior + +Unacceptable behavior from any community member, including sponsors and +those with decision-making authority, will not be tolerated. + +Anyone asked to stop unacceptable behavior is expected to comply +immediately. + +If a community member engages in unacceptable behavior, the community +organizers may take any action they deem appropriate, up to and including +a temporary ban or permanent expulsion from the community without warning +(and without refund in the case of a paid event). Community organizers +can be part of the arbitration team, or organizers of events and online +communities. + +## If You Witness or Are Subject to Unacceptable Behavior + +If you are subject to or witness unacceptable behavior, or have any other +concerns, please notify someone from the arbitration team immediately. + + +## Addressing Grievances + +If you feel you have been falsely or unfairly accused of violating this +Code of Conduct, you should notify the arbitration team with a concise +description of your grievance. + +## Scope + +We expect all community participants (contributors, paid or otherwise; +sponsors; and other guests) to abide by this Code of Conduct in all +community venues, online and in-person, as well as in all one-on-one +communications pertaining to community business. + +## Contact info + +Our arbitration team consists of the following people +* Stefan Reinauer <stefan.reinauer(a)coreboot.org> +* Patrick Georgi <patrick(a)coreboot.org> +* Ronald Minnich <rminnich(a)coreboot.org> +* Marc Jones <mjones(a)coreboot.org> + +## License and attribution + +This Code of Conduct is distributed under +a [Creative Commons Attribution-ShareAlike +license](http://creativecommons.org/licenses/by-sa/3.0/). It is based +on the [Citizen Code of Conduct](http://citizencodeofconduct.org/) diff --git a/Documentation/index.md b/Documentation/index.md index 4b3324c..9fdb0dc 100644 --- a/Documentation/index.md +++ b/Documentation/index.md @@ -9,6 +9,7 @@ * [Getting Started](getting_started/index.md) * [Rookie Guide](lessons/index.md) +* [Code of Conduct](code_of_conduct.md) * [Timestamps](timestamp.md) * [Intel IFD Binary Extraction](Binary_Extraction.md) * [Dealing with Untrusted Input in SMM](technotes/2017-02-dealing-with-untrusted-input-in-smm.md) -- To view, visit https://review.coreboot.org/c/coreboot/+/30085 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I6f41611db8d9a2f60b24d95abdf30f4fd47cd6f2 Gerrit-Change-Number: 30085 Gerrit-PatchSet: 1 Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

1 0

Change in ...coreboot[master]: [RFC] commonlib/region: Check `xlate` regions early
by build bot (Jenkins) (Code Review) 06 Dec '18

06 Dec '18

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/30083 ) Change subject: [RFC] commonlib/region: Check `xlate` regions early ...................................................................... Patch Set 1: (2 comments) https://review.coreboot.org/#/c/30083/1/src/commonlib/include/commonlib/reg… File src/commonlib/include/commonlib/region.h: https://review.coreboot.org/#/c/30083/1/src/commonlib/include/commonlib/reg… PS1, Line 88: int (*region_ok)(const struct region_device *, const struct region *); function definition argument 'const struct region_device *' should also have an identifier name https://review.coreboot.org/#/c/30083/1/src/commonlib/include/commonlib/reg… PS1, Line 88: int (*region_ok)(const struct region_device *, const struct region *); function definition argument 'const struct region *' should also have an identifier name -- To view, visit https://review.coreboot.org/c/coreboot/+/30083 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I2cdb9dd1ab9c00b227839a03fff389ba6fe78b4a Gerrit-Change-Number: 30083 Gerrit-PatchSet: 1 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-CC: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-Comment-Date: Thu, 06 Dec 2018 15:27:45 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in ...coreboot[master]: cbfs: Alert if something goes wrong in cbfs_boot_locate()
by Nico Huber (Code Review) 06 Dec '18

06 Dec '18

Nico Huber has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30084 Change subject: cbfs: Alert if something goes wrong in cbfs_boot_locate() ...................................................................... cbfs: Alert if something goes wrong in cbfs_boot_locate() Change-Id: I5a3cb41b3a7ff2aa527cc2b40c9d7438474c2f93 Signed-off-by: Nico Huber <nico.huber(a)secunet.com> --- M src/lib/cbfs.c 1 file changed, 9 insertions(+), 3 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/84/30084/1 diff --git a/src/lib/cbfs.c b/src/lib/cbfs.c index 9ea7df6..a5c9f85 100644 --- a/src/lib/cbfs.c +++ b/src/lib/cbfs.c @@ -41,17 +41,23 @@ const struct region_device *boot_dev; struct cbfs_props props; - if (cbfs_boot_region_properties(&props)) + if (cbfs_boot_region_properties(&props)) { + printk(BIOS_ALERT, "ERROR: Failed to locate boot region\n"); return -1; + } /* All boot CBFS operations are performed using the RO device. */ boot_dev = boot_device_ro(); - if (boot_dev == NULL) + if (boot_dev == NULL) { + printk(BIOS_ALERT, "ERROR: Failed to find boot device\n"); return -1; + } - if (rdev_chain(&rdev, boot_dev, props.offset, props.size)) + if (rdev_chain(&rdev, boot_dev, props.offset, props.size)) { + printk(BIOS_ALERT, "ERROR: Failed to access boot region inside boot device\n"); return -1; + } return cbfs_locate(fh, &rdev, name, type); } -- To view, visit https://review.coreboot.org/c/coreboot/+/30084 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I5a3cb41b3a7ff2aa527cc2b40c9d7438474c2f93 Gerrit-Change-Number: 30084 Gerrit-PatchSet: 1 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-MessageType: newchange

1 0

Change in ...coreboot[master]: [RFC] commonlib/region: Check `xlate` regions early
by Nico Huber (Code Review) 06 Dec '18

06 Dec '18

Nico Huber has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30083 Change subject: [RFC] commonlib/region: Check `xlate` regions early ...................................................................... [RFC] commonlib/region: Check `xlate` regions early Makes it possible to detect errors early in rdev_chain(). Change-Id: I2cdb9dd1ab9c00b227839a03fff389ba6fe78b4a Signed-off-by: Nico Huber <nico.huber(a)secunet.com> --- M src/commonlib/include/commonlib/region.h M src/commonlib/region.c 2 files changed, 30 insertions(+), 39 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/83/30083/1 diff --git a/src/commonlib/include/commonlib/region.h b/src/commonlib/include/commonlib/region.h index 45484dd..f027bc2 100644 --- a/src/commonlib/include/commonlib/region.h +++ b/src/commonlib/include/commonlib/region.h @@ -30,6 +30,7 @@ * chaining together multiple region_devices. */ +struct region; struct region_device; /* @@ -84,6 +85,7 @@ ssize_t (*writeat)(const struct region_device *, const void *, size_t, size_t); ssize_t (*eraseat)(const struct region_device *, size_t, size_t); + int (*region_ok)(const struct region_device *, const struct region *); }; struct region { diff --git a/src/commonlib/region.c b/src/commonlib/region.c index 541a125..6db13a3 100644 --- a/src/commonlib/region.c +++ b/src/commonlib/region.c @@ -36,12 +36,6 @@ return 1; } -static int normalize_and_ok(const struct region *outer, struct region *inner) -{ - inner->offset += region_offset(outer); - return region_is_subregion(outer, inner); -} - static const struct region_device *rdev_root(const struct region_device *rdev) { if (rdev->root == NULL) @@ -49,6 +43,18 @@ return rdev->root; } +static int normalize_and_ok(struct region *inner, + const struct region_device *outer) +{ + const struct region_device *rdev; + + rdev = rdev_root(outer); + + inner->offset += region_offset(&outer->region); + return region_is_subregion(&outer->region, inner) && + (!rdev->ops->region_ok || rdev->ops->region_ok(rdev, inner)); +} + ssize_t rdev_relative_offset(const struct region_device *p, const struct region_device *c) { @@ -69,7 +75,7 @@ .size = size, }; - if (!normalize_and_ok(&rd->region, &req)) + if (!normalize_and_ok(&req, rd)) return NULL; rdev = rdev_root(rd); @@ -101,7 +107,7 @@ .size = size, }; - if (!normalize_and_ok(&rd->region, &req)) + if (!normalize_and_ok(&req, rd)) return -1; rdev = rdev_root(rd); @@ -118,7 +124,7 @@ .size = size, }; - if (!normalize_and_ok(&rd->region, &req)) + if (!normalize_and_ok(&req, rd)) return -1; rdev = rdev_root(rd); @@ -138,7 +144,7 @@ .size = size, }; - if (!normalize_and_ok(&rd->region, &req)) + if (!normalize_and_ok(&req, rd)) return -1; rdev = rdev_root(rd); @@ -159,7 +165,7 @@ .size = size, }; - if (!normalize_and_ok(&parent->region, &req)) + if (!normalize_and_ok(&req, parent)) return -1; /* Keep track of root region device. Note the offsets are relative @@ -343,16 +349,9 @@ size_t size) { const struct xlate_region_device *xldev; - struct region req = { - .offset = offset, - .size = size, - }; xldev = container_of(rd, __typeof__(*xldev), rdev); - if (!region_is_subregion(&xldev->sub_region, &req)) - return NULL; - offset -= region_offset(&xldev->sub_region); return rdev_mmap(xldev->access_dev, offset, size); @@ -370,17 +369,10 @@ static ssize_t xlate_readat(const struct region_device *rd, void *b, size_t offset, size_t size) { - struct region req = { - .offset = offset, - .size = size, - }; const struct xlate_region_device *xldev; xldev = container_of(rd, __typeof__(*xldev), rdev); - if (!region_is_subregion(&xldev->sub_region, &req)) - return -1; - offset -= region_offset(&xldev->sub_region); return rdev_readat(xldev->access_dev, b, offset, size); @@ -389,17 +381,10 @@ static ssize_t xlate_writeat(const struct region_device *rd, const void *b, size_t offset, size_t size) { - struct region req = { - .offset = offset, - .size = size, - }; const struct xlate_region_device *xldev; xldev = container_of(rd, __typeof__(*xldev), rdev); - if (!region_is_subregion(&xldev->sub_region, &req)) - return -1; - offset -= region_offset(&xldev->sub_region); return rdev_writeat(xldev->access_dev, b, offset, size); @@ -408,26 +393,29 @@ static ssize_t xlate_eraseat(const struct region_device *rd, size_t offset, size_t size) { - struct region req = { - .offset = offset, - .size = size, - }; const struct xlate_region_device *xldev; xldev = container_of(rd, __typeof__(*xldev), rdev); - if (!region_is_subregion(&xldev->sub_region, &req)) - return -1; - offset -= region_offset(&xldev->sub_region); return rdev_eraseat(xldev->access_dev, offset, size); } +static int xlate_region_ok(const struct region_device *rd, + const struct region *req) +{ + const struct xlate_region_device *xldev; + + xldev = container_of(rd, __typeof__(*xldev), rdev); + return region_is_subregion(&xldev->sub_region, req); +} + const struct region_device_ops xlate_rdev_ro_ops = { .mmap = xlate_mmap, .munmap = xlate_munmap, .readat = xlate_readat, + .region_ok = xlate_region_ok, }; const struct region_device_ops xlate_rdev_rw_ops = { @@ -436,6 +424,7 @@ .readat = xlate_readat, .writeat = xlate_writeat, .eraseat = xlate_eraseat, + .region_ok = xlate_region_ok, }; -- To view, visit https://review.coreboot.org/c/coreboot/+/30083 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I2cdb9dd1ab9c00b227839a03fff389ba6fe78b4a Gerrit-Change-Number: 30083 Gerrit-PatchSet: 1 Gerrit-Owner: Nico Huber <nico.h(a)gmx.de> Gerrit-MessageType: newchange

1 0

Change in ...coreboot[master]: Documentation: Add documentation about the release process
by Patrick Georgi (Code Review) 06 Dec '18

06 Dec '18

Patrick Georgi has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/30082 Change subject: Documentation: Add documentation about the release process ...................................................................... Documentation: Add documentation about the release process It's originally written by Martin who graciously allowed to me rework it a bit and push it into coreboot's documentation. Change-Id: I14938d678e4620abec7ed5f0d35dddaf00edda6d Signed-off-by: Patrick Georgi <pgeorgi(a)google.com> --- A Documentation/releases/checklist.md M Documentation/releases/index.md 2 files changed, 216 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/82/30082/1 diff --git a/Documentation/releases/checklist.md b/Documentation/releases/checklist.md new file mode 100644 index 0000000..f03f87d --- /dev/null +++ b/Documentation/releases/checklist.md @@ -0,0 +1,210 @@ +# coreboot Release Process + +This document describes our release process and all prerequisites to implement +it successfully. + +## Purpose of coreboot releases +Our releases aren't primarily a vehicle for code that is stable across all +boards: The logistics of testing the more than 100 boards that are spread out +all continents (except Antarctica, probably) on a given tree state are +prohibitive for project of our size. + +Instead, the releases are regular breakpoints that serve multiple purposes: +They support cooperation between multiple groups (corporations or otherwise) +in that it's easier to keep source trees synchronized based on a limited set +of commits. They allow a quick assessment of the age of any given build or +source tree based on its git version (4.8-1234 was merged into master a few +months after 4.8, which came out in April 2018. 4.0-21718's age is harder to +guess). + +And finally we use releases to as points in time where we remove old code: +Once we decide that a certain part of coreboot gets in the way of future +development, we announce on the next release that we intend to remove that +part - and everything that depends on it - after the following release. +So removing feature FOO will be announced in release X for release +X+1. The first commit after X+1 is fair game for such removal. + +Together with our 6 months release horizon, this provides time to plan +any migrations necessary to keep older boards in the tree by bringing +them up to current standards. + +## Needed credentials & authorizations +* Website access is required to post the release files to the website. +* IRC admin access is required to update the topic. +* Git access rights are needed to post the tag. +* Blog post access is needed to do the blog post. +* A PGP key is required to sign the release tarballs and git tag. + +This set of required credentials implies that releases can only be done +by a coreboot admin. + +## When to release +Releases are done roughly on a 6-month schedule, ideally around end +of April and end of October (can be a bit earlier or delay into May +or November). + +We initially followed a 3 month release schedule, but we found that to +be more frequent than was needed, so we scaled it back to twice a year. + +## Checklist +### ~2 weeks prior to release +- [ ] Announce upcoming release to mailing list, ask people to test and + to update release notes + +### ~1 week prior to release +- [ ] Send reminder email to mailing list, ask for people to test, + and to update the release notes +- [ ] Update the topic in the irc channel with the date of the upcoming + release + +### Day of release +- [ ] Update release notes, without specifying release commit ids +- [ ] Select a commit ID to base the release upon, announce to IRC, + ask for testing. +- [ ] Test the commit selected for release +- [ ] Run release script +- [ ] Test the release from the actual release tarballs +- [ ] Push signed Tag to repo +- [ ] Announce that the release tag is done on IRC +- [ ] Update release notes with actual commit id, push to repo +- [ ] Upload release files to web server +- [ ] Update download page to point to files, push to repo +- [ ] Write and publish blog post with release notes. +- [ ] Update the topic in the irc channel that the release is done. + +## Pre-Release tasks +Announce the upcoming release to the mailing list release 2 weeks ahead +of the planned release date. + +The announcement should state the planned release date, point to the +release notes that are in the making and ask people to test the hardware +they have to make sure it's working with the current master branch, +from which the release will ultimately be derived from. + +People should also be encouraged to provide additions to the +release notes, for example by putting them on some [collaborative +editor](https://www.piratenpad.de). + +The final release notes will reside in coreboot's Documentation/releases +directory, so asking for additions to that through the regular Gerrit +process works as well. Note that git requires lots of conflict resolution +on heavily edited text files though. + +Frequently, we will want to wait until particular things are in the +release. Once those are in, you can select the commit ID that you want +to use for your release. For the 4.6 release, we waited until we had +time to do the release, then pulled in a few patches that we wanted +to have in the release. The release was based on the final of those +patches to be pulled in. + +When a release candidate has been selected, announce the commit ID to +the #coreboot irc channel, and request that it get some testing, just +to make sure that everything is sane. + +## Generate the release +After the commit for the release has been selected and verified, run the +release script - util/release/build-release. This will download a new +tree, checkout the commit that you specified, download the submodules, +create a tag, then generate and sign the tarballs. + +Be prepared to type in your PGP key’s passphrase. + +```` +usage: util/release/build-release <version> [commit id] [username] [gpg key id] +Tags a new coreboot version and creates a tar archive + +version: New version name to tag the tree with +commit id: check out this commit-id after cloning the coreboot tree +username: clone the tree using ssh://USERNAME - defaults to https:// +gpg key id: used to tag the version, and generate a gpg signature +```` + +After running the script, you should have a new directory for the release, +along with 4 files - 2 tarballs, and 2 signature files. + +```` +drwxr-xr-x 9 martin martin 4096 Apr 30 19:57 coreboot-4.6 +-rw-r--r-- 1 martin martin 29156788 Apr 30 19:58 coreboot-4.6.tar.xz +-rw-r--r-- 1 martin martin 836 Apr 30 19:58 coreboot-4.6.tar.xz.sig +-rw-r--r-- 1 martin martin 5902076 Apr 30 19:58 coreboot-blobs-4.6.tar.xz +-rw-r--r-- 1 martin martin 836 Apr 30 19:58 coreboot-blobs-4.6.tar.xz.sig +```` + +Here’s the command that was used to generate the 4.6 release: +```` +% util/release/build-release 4.6 db508565 Gaumless 3E4F7DF7 +```` + +## Test the release from the tarballs +* Run “make what-jenkins-does” and verify that everything is building. +* Build and test qemu + ```` + cp configs/config.emulation_qemu_x86_i440fx .config; make olddefconfig; make + qemu-system-x86_64 -bios build/coreboot.rom -serial stdio + ```` +* Build and test any other platforms you can. +* Compare the directory from the tarballs to the coreboot repo to make sure nothing went wrong. +* Push the tag to git + +A good tag will look like this: +```` +% git show 4.6 +tag 4.6 +Tagger: Martin Roth <martinroth(a)google.com> +Date: Sun Apr 30 19:48:38 2017 -0600 + +coreboot version 4.6 +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iQIcBAABCQAGBQJZBpP2AAoJEBl5bCs+T333xfgQAKhilfDTzqlr3MLJC4VChbmr +... +678e0NzyWsyqU1Vx2rdFdLANx6hghH1R7E5ybzHHUQrhb55BoEsnQMU1oS0npnT4 +dwfLho1afk0ZLPUU1JFW +=25y8 +-----END PGP SIGNATURE----- + +commit db508565d2483394b709654c57533e55eebace51 (HEAD, tag: 4.6, origin/master, origin/HEAD) +... +```` + +When you used the script to generate the release, a tag was generated in the tree that was downloaded. +From the coreboot-X.Y tree, just run: `git push -f origin <TAG (X.Y)>` + +You will need write access for tags to the coreboot git repo to do this. + +## After the release is tagged in git +Announce that the release has been tagged - this lets people know that +they should update their trees to grab the new tag. Until they do this, +the version number in build.h will still be based on the previous tag. + +Copy the tarballs and .sig files generated by the script to +the coreboot server, and put them in the release directory at +`/srv/docker/www.coreboot.org-staticfiles/releases/` + +```` +% sha256sum -b coreboot-*.tar.xz > sha256suma.txt # Update the sha256sum file +% diff sha256sum.txt sha256suma.txt # make sure that the two new files are present (and that nothing else has changed) +% mv sha256suma.txt sha256sum.txt +```` + +People can now see the release tarballs on the website at +https://www.coreboot.org/releases/ + +The downloads page is the official place to download the releases from, and it needs to be updated with links to the new release tarballs and .sig files. It can be found at https://review.coreboot.org/cgit/homepage.git/tree/downloads.html + +Here is an example commit to change it: https://review.coreboot.org/#/c/19515/ + +## After the release is complete +Post the release notes on https://blogs.coreboot.org + +## Making a branch +At times we will need to create a branch, generally for patch fixes. +When making a branch, do NOT name it the same as the release tag: X.Y - this creates trouble when trying to check it out, as git can’t tell whether you want the tag or the branch. +Instead, name it X.Y\_branch: `git checkout 4.8; git checkout -b 4.8_branch; git push origin 4.8_branch` + +You can then cherry-pick changes and push them up to the branch: +```` +git cherry-pick c6d134988c856d0025153fb885045d995bc8c397 +git push origin HEAD:refs/for/4.8_branch +```` diff --git a/Documentation/releases/index.md b/Documentation/releases/index.md index 602a63a..4571d12 100644 --- a/Documentation/releases/index.md +++ b/Documentation/releases/index.md @@ -10,6 +10,12 @@ * [4.7 - January 2018](coreboot-4.7-relnotes.md) * [4.8 - May 2018](coreboot-4.8.1-relnotes.md) +The checklist contains instructions to ensure that a release covers all +important things and provides a reliable format for tarballs, branch +names etc. + +* [checklist](checklist.md) + Upcoming release ---------------- -- To view, visit https://review.coreboot.org/c/coreboot/+/30082 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: I14938d678e4620abec7ed5f0d35dddaf00edda6d Gerrit-Change-Number: 30082 Gerrit-PatchSet: 1 Gerrit-Owner: Patrick Georgi <pgeorgi(a)google.com> Gerrit-MessageType: newchange

1 0

Change in ...coreboot[master]: soc/intel/braswell: Add support for FSP MR2
by Frans Hendriks (Code Review) 06 Dec '18

06 Dec '18

Frans Hendriks has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/29661 ) Change subject: soc/intel/braswell: Add support for FSP MR2 ...................................................................... Patch Set 3: > Patch Set 3: > > >> Am I correct that the IMAGE_REV coreboot already knows is newer? Did > >> you ask Intel to update the version on Github? > > > > No. The actual version of FSP (in 3rdparty\fsp) is MR2. To support > > this version this patch is required. > > I do understand that. Just wondering if it wouldn't be a better > upstream solution to use the newest version everywhere. I'm not sure about the FSP used google cyan (and variants). If a non-standard/custom FSP is used for these boards, after update FSP would be loaded. -- To view, visit https://review.coreboot.org/c/coreboot/+/29661 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Id40b5d46ddda93845d9739b56aaf7ad24ee89246 Gerrit-Change-Number: 29661 Gerrit-PatchSet: 3 Gerrit-Owner: Frans Hendriks <fhendriks(a)eltan.com> Gerrit-Reviewer: Frans Hendriks <fhendriks(a)eltan.com> Gerrit-Reviewer: Hannah Williams <hannah.williams(a)intel.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-CC: Nico Huber <nico.h(a)gmx.de> Gerrit-Comment-Date: Thu, 06 Dec 2018 13:35:02 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in ...coreboot[master]: soc/intel/braswell: Add support for FSP MR2
by Nico Huber (Code Review) 06 Dec '18

06 Dec '18

Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/29661 ) Change subject: soc/intel/braswell: Add support for FSP MR2 ...................................................................... Patch Set 3: >> Am I correct that the IMAGE_REV coreboot already knows is newer? Did >> you ask Intel to update the version on Github? > > No. The actual version of FSP (in 3rdparty\fsp) is MR2. To support > this version this patch is required. I do understand that. Just wondering if it wouldn't be a better upstream solution to use the newest version everywhere. -- To view, visit https://review.coreboot.org/c/coreboot/+/29661 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Id40b5d46ddda93845d9739b56aaf7ad24ee89246 Gerrit-Change-Number: 29661 Gerrit-PatchSet: 3 Gerrit-Owner: Frans Hendriks <fhendriks(a)eltan.com> Gerrit-Reviewer: Frans Hendriks <fhendriks(a)eltan.com> Gerrit-Reviewer: Hannah Williams <hannah.williams(a)intel.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-CC: Nico Huber <nico.h(a)gmx.de> Gerrit-Comment-Date: Thu, 06 Dec 2018 13:22:11 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in ...coreboot[master]: soc/intel/braswell: Add support for FSP MR2
by Frans Hendriks (Code Review) 06 Dec '18

06 Dec '18

Frans Hendriks has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/29661 ) Change subject: soc/intel/braswell: Add support for FSP MR2 ...................................................................... Patch Set 3: > Patch Set 3: > > Am I correct that the IMAGE_REV coreboot already knows is newer? Did > you ask Intel to update the version on Github? No. The actual version of FSP (in 3rdparty\fsp) is MR2. To support this version this patch is required. -- To view, visit https://review.coreboot.org/c/coreboot/+/29661 To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Change-Id: Id40b5d46ddda93845d9739b56aaf7ad24ee89246 Gerrit-Change-Number: 29661 Gerrit-PatchSet: 3 Gerrit-Owner: Frans Hendriks <fhendriks(a)eltan.com> Gerrit-Reviewer: Frans Hendriks <fhendriks(a)eltan.com> Gerrit-Reviewer: Hannah Williams <hannah.williams(a)intel.com> Gerrit-Reviewer: Patrick Georgi <pgeorgi(a)google.com> Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: Michał Żygowski <michal.zygowski(a)3mdeb.com> Gerrit-CC: Nico Huber <nico.h(a)gmx.de> Gerrit-Comment-Date: Thu, 06 Dec 2018 13:07:57 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit December 2018