Maximilian Brune has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/68995 )
Change subject: Documentation/sbom: Add SBOM Documentation
......................................................................
Documentation/sbom: Add SBOM Documentation
Change-Id: I39fbcba60a0fbdbed9f662119ed7692c0a0fd30e
---
M Documentation/index.md
A Documentation/sbom/sbom.md
A Documentation/sbom/sbom_generation.plantuml
A Documentation/sbom/sbom_generation.png
4 files changed, 99 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/95/68995/1
diff --git a/Documentation/index.md b/Documentation/index.md
index 0cb462c..416883b 100644
--- a/Documentation/index.md
+++ b/Documentation/index.md
@@ -193,6 +193,7 @@
* [SuperIO](superio/index.md)
* [Vendorcode](vendorcode/index.md)
* [Utilities](util.md)
+* [Software Bill of Materials](sbom/sbom.md)
* [Project infrastructure & services](infrastructure/index.md)
* [Boards supported in each release directory](releases/boards_supported_on_branches.md)
* [Release notes](releases/index.md)
diff --git a/Documentation/sbom/sbom.md b/Documentation/sbom/sbom.md
new file mode 100644
index 0000000..caf0f69
--- /dev/null
+++ b/Documentation/sbom/sbom.md
@@ -0,0 +1,28 @@
+# SBOM (Software Bill of Materials)
+SBOM is simply a collection of Information of each Software component you are supplying/building. Similar to a package manager on Linux based Systems, it holds Information of as much Software parts as possible. These Information can be a Version, Name of the software, URL, License Information and more. An SBOM can be saved in various formats. In coreboot it's saved as "uSWID" File. uSWID is not a Standard or Specification but it doesn't need to be, since it's basically just an Array/List of CoSWID Files which in turn are specified by a RFC Spec. CoSWID Files are saved in a CBOR Format. CBOR is like JSON if JSON would be binary format. Similar to a package manager the CoSWID Format can link multiple Software's together. For example on most modern Intel Systems FSP is shipped as a dependency of coreboot. That kind of relationship between Software components (among others) can be expressed in an uSWID File. That makes Firmware/Software much more transparent. One could for example create a Software that takes a Coreboot Firmware Image as Input and automatically creates a Graph with all Software components the Coreboot Image contains and their relationship to each other.
+
+## SWID/CoSWID File Format
+To get a simple overview of how a SWID/CoSWID File looks like, just take a look at the various "templates" in src/sbom/.
+
+## coreboot implementation
+Quick overview of how things are generated:
+
+![Generation of an SBOM File in coreboot][sbom_generation]
+
+[sbom_generation]: sbom_generation.png
+
+After all SBOM data has been fetched from all the software-components, the 'goswid' tool links them all together into one sbom.uswid file. The goswid tool is therefore basically a linker that takes multiple CoSWID/SWID files and converts them into one uSWID File. Although the Image shows only Files in JSON Format it is also possible to supply them in XML or CBOR Format.
+
+The final SBOM File is located inside the CBFS.
+For each Software component in coreboot SBOM, there is an option in Kconfig (usually called CONFIG_INCLUDE_[software-name]\_SBOM] to either include or not include SBOM metadata for the specified Software. Furthermore there is a a CONFIG_SBOM_[software-name]\_PATH option which contains a path to a SWID/CoSWID File in a Format of choice (being either JSON, XML or CBOR). CONFIG_SBOM_[software-name]\_PATH option usually defaults to a very generic CoSWID file in JSON format (which are stored in src/sbom/). That at least gives minimal information like the name of the software and maybe a version. But it is always preferred, that the CONFIG_SBOM_[software-name]\_PATH is set to a custom CoSWID/SWID file that contains much more information (like License, URL, version/commit-hash ...). Therefore using the defaults is by any means to be avoided, since they hold very little information or even worse wrong information.
+Furthermore some of these Kconfig options have a suboption (usually called CONFIG_[software-name]\_SBOM_GENEREATE) to generate some basic SBOM data for the specified Software component, in order to get at least some bit of information about it by analyzing the binary (for binary blobs) or querying Information via git (for open source projects). This is for example currently done for all payloads. For each payload the commit hash used in the build is taken and put into the SBOM File. For open-source projects (like all payloads) crucial information like the current commit-hash of the payload can easily be put into the SBOM file. Extracting Information out of Binary blobs is a bit trickier for obvious reasons.
+For closed source binary blobs it is therefore recommended that Vendors/Software-Engineers create an SBOM File as part of their build process and add a path to that SBOM File via Kconfig options in coreboot (usually called CONFIG_[software-name]\_SBOM_PATH). That way the final SBOM has much more useful and correct data.
+
+## What to do as Developer of a binary blob (which is used in coreboot)
+1. Generate a SWID/CoSWID/uSWID File in either JSON, XML or CBOR Format as part of your Software build process
+2. Supply that generated File along with your binary blob
+3. To build coreboot: Add CONFIG_SBOM_[software-name]\_PATH to your defconfig pointing to your [software-name] generated File.
+
+## What to do as Developer of an open source project (which is used in coreboot)
+1. Generate a SWID/CoSWID/uSWID File in either JSON, XML or CBOR Format as part of your Software's build process. for example in form of a Makefile target.
+2. Change src/sbom/Makefile.inc (in order to know where to find the CoSWID/SWID/uSWID File) as well as the Makefile in coreboot which builds said Software. For example for GRUB2 that could mean to add a Makefile target in payloads/external/GRUB2/Makefile.
diff --git a/Documentation/sbom/sbom_generation.plantuml b/Documentation/sbom/sbom_generation.plantuml
new file mode 100644
index 0000000..e8d9f1e
--- /dev/null
+++ b/Documentation/sbom/sbom_generation.plantuml
@@ -0,0 +1,61 @@
+@startuml
+
+map "src/sbom/compiler-gcc.json" as gcc {
+ software-name => GCC
+ version => x.y.z
+ ... => ...
+}
+map "src/sbom/intel-me.json" as me {
+ software-name => Intel Mangement Engine
+ ... => ...
+}
+map "src/sbom/intel-microcode.json" as ucode {
+ software-name => Intel Microcode
+ ... => ...
+}
+map "src/sbom/generic-ec.json" as ec {
+ software-name => ecxyz
+ ... => ...
+}
+map "src/sbom/generic-fsp.json" as fsp {
+ software-name => Firmware Support Package
+ version => x.y.z
+ ... => ...
+}
+map "src/sbom/payload-[...].json" as payload {
+ software-name => ...
+ version => x.y.z
+ ... => ...
+}
+map "src/sbom/coreboot.json" as coreboot {
+ software-name => coreboot
+ version => x.y.z
+ url => coreboot.rocks
+ ... => ...
+}
+object "sbom.uswid" as uswid {
+ merged SBOM data in binary format
+}
+object goswid {
+ # ./goswid
+ --compiler gcc.json
+ --parent coreboot.json
+ --requires fsp.json,payload.json
+ intel-me.json
+ intel-ec.json
+ intel-ucode.json
+ --output sbom.uswid
+}
+
+left to right direction
+gcc --> goswid
+me --> goswid
+ucode --> goswid
+goswid <-- ec
+goswid <-- fsp
+goswid <-- payload
+
+coreboot -up> goswid
+goswid -up> uswid
+
+@enduml
diff --git a/Documentation/sbom/sbom_generation.png b/Documentation/sbom/sbom_generation.png
new file mode 100644
index 0000000..7489735
--- /dev/null
+++ b/Documentation/sbom/sbom_generation.png
Binary files differ
--
To view, visit https://review.coreboot.org/c/coreboot/+/68995
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I39fbcba60a0fbdbed9f662119ed7692c0a0fd30e
Gerrit-Change-Number: 68995
Gerrit-PatchSet: 1
Gerrit-Owner: Maximilian Brune <maximilian.brune(a)9elements.com>
Gerrit-MessageType: newchange
Martin L Roth has submitted this change. ( https://review.coreboot.org/c/coreboot/+/68802 )
Change subject: mainboard/amd/chausie: Don't use APCB_FT6_Updatable
......................................................................
mainboard/amd/chausie: Don't use APCB_FT6_Updatable
This APCB binary is not used for coreboot builds. Coreboot does not
support RW APCB.
Change-Id: I4d317ae31cf226b5481619f1539abb6237033f7c
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski(a)amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68802
Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred(a)gmail.com>
Reviewed-by: Jason Glenesk <jason.glenesk(a)gmail.com>
---
M src/mainboard/amd/chausie/Makefile.inc
1 file changed, 19 insertions(+), 2 deletions(-)
Approvals:
build bot (Jenkins): Verified
Jason Glenesk: Looks good to me, approved
Fred Reitberger: Looks good to me, but someone else must approve
diff --git a/src/mainboard/amd/chausie/Makefile.inc b/src/mainboard/amd/chausie/Makefile.inc
index 98b2cdd..b1f93e4 100644
--- a/src/mainboard/amd/chausie/Makefile.inc
+++ b/src/mainboard/amd/chausie/Makefile.inc
@@ -10,8 +10,8 @@
ramstage-y += gpio.c
ramstage-y += port_descriptors.c
-ifneq ($(wildcard $(MAINBOARD_BLOBS_DIR)/APCB_FT6_Updatable.bin),)
-APCB_SOURCES = $(MAINBOARD_BLOBS_DIR)/APCB_FT6_Updatable.bin
+ifneq ($(wildcard $(MAINBOARD_BLOBS_DIR)/APCB_FT6.bin),)
+APCB_SOURCES = $(MAINBOARD_BLOBS_DIR)/APCB_FT6.bin
APCB_SOURCES_RECOVERY = $(MAINBOARD_BLOBS_DIR)/APCB_FT6_DefaultRecovery.bin
else
$(info APCB sources not found. Skipping APCB. The resulting image won't boot.)
--
To view, visit https://review.coreboot.org/c/coreboot/+/68802
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I4d317ae31cf226b5481619f1539abb6237033f7c
Gerrit-Change-Number: 68802
Gerrit-PatchSet: 3
Gerrit-Owner: Nikolai Vyssotski <nikolai.vyssotski(a)amd.corp-partner.google.com>
Gerrit-Reviewer: Felix Held <felix-coreboot(a)felixheld.de>
Gerrit-Reviewer: Fred Reitberger <reitbergerfred(a)gmail.com>
Gerrit-Reviewer: Jason Glenesk <jason.glenesk(a)gmail.com>
Gerrit-Reviewer: Martin L Roth <gaumless(a)gmail.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-MessageType: merged
Martin L Roth has submitted this change. ( https://review.coreboot.org/c/coreboot/+/68500 )
Change subject: Docs/releases: Update release checklist document
......................................................................
Docs/releases: Update release checklist document
Signed-off-by: Martin Roth <gaumless(a)gmail.com>
Change-Id: I9a79cf92620755e19266faaf593dc2657acdb16f
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68500
Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk(a)gmail.com>
---
M Documentation/releases/checklist.md
1 file changed, 159 insertions(+), 80 deletions(-)
Approvals:
build bot (Jenkins): Verified
Jason Glenesk: Looks good to me, approved
diff --git a/Documentation/releases/checklist.md b/Documentation/releases/checklist.md
index 80f59b7..2d33487 100644
--- a/Documentation/releases/checklist.md
+++ b/Documentation/releases/checklist.md
@@ -4,56 +4,73 @@
# coreboot Release Process
-This document describes our release process and all prerequisites to implement
-it successfully.
+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.
+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).
+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
+of 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.
+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
+Together with our 3 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.
+## coreboot release team
+To avoid issues of blocking the release on a single person, a release
+team has been formed. Please see the `COREBOOT RELEASES` section of the
+MAINTAINERS file for the current members.
+
+These individuals work together to make sure releases are done on time,
+follow the steps of this document, and update the release processes and
+scripts.
+
+
## Needed credentials & authorizations
+
+### coreboot admins only
* Website access is required to post the release files to the website.
-* IRC admin access is required to update the topic.
+
+### All release team members
+* IRC topic 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.
+Most of the steps in the release process can be done by anyone on the
+release team. Only adding the files to the website needs to be done
+by a coreboot administrator.
## 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).
+Releases are done roughly on a 3-month schedule. If a release is
+delayed, the next release will still be 3 months after the last release.
-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.
+- [ ] Start marking patches that should to go into the release with a
+ tag "coreboot_release_X.yy"
### ~1 week prior to release
- [ ] Send reminder email to mailing list, ask for people to test,
@@ -66,28 +83,53 @@
- [ ] Finalize release notes as much as possible
- [ ] Prepare release notes template for following release
- [ ] Update `Documentation/releases/index.md`
+- [ ] Check which branches need to be released. Any branch with changes
+ should get a new release. Announce these branch releases and
+ prepare release notes.
+
+### Day before release
+- [ ] Make sure patches with tags for the release are merged.
+- [ ] Announce to IRC that the release will be tomorrow and ask for
+ testing.
- [ ] Run `util/vboot_list/vboot_list.sh` script to update the list of
boards supported by vboot.
### Day of release
-- [ ] Select a commit ID to base the release upon, announce to IRC,
- ask for testing.
+- [ ] Review the full documentation about doing the release below.
+- [ ] Select a commit ID to base the release upon.
- [ ] Test the commit selected for release.
-- [ ] Submit release notes
-- [ ] Create new release notes doc template for the next version.
-- [ ] Fill in the release date, remove "Upcoming release" and other filler
- from the current release notes.
-- [ ] Run release script.
+- [ ] Submit last pre-release release notes.
+- [ ] Run the release script.
- [ ] Test the release from the actual release tarballs.
-- [ ] Push signed Tag to repo.
+- [ ] Push signed Tag to repo. *This is the actual release step.*
+ Once this patch is pushed, the release itself has been done.
+ everything after this step is packaging and delivering the
+ release.
+
- [ ] Announce that the release tag is done on IRC.
-- [ ] Upload release files to web server.
-- [ ] Also extract the release notes and place them on the web server.
-- [ ] Upload crossgcc sources 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.
-- [ ] Announce the release to the mailing list.
+
+- [ ] Do the final release notes - Fill in the release date, remove
+ "Upcoming release" and other filler from the current release
+ notes.
+- [ ] ADMIN: Upload release files to web server.
+- [ ] ADMIN: Upload the final release notes to the web server.
+- [ ] ADMIN: Upload crossgcc sources to web server.
+- [ ] Create coreboot-sdk and coreboot-jenkins-node docker images
+ based on the release ID and push them to dockerhub. These
+ can be used as release builders.
+
+### Week following the release
+- [ ] Update download page to point to files, push to repo.
+- [ ] Write and publish blog post with release final notes. Branch
+ releases notes should be included in the same post.
+- [ ] Remove code that was announced it was going to be removed.
+- [ ] Update `Documentation/releases/boards_supported_on_branches.md`
+
+### Creating a branch
+- [ ] Branches are named 4.xx_branch to differentiate from the tags.
+ Instructions on creating branches are listed below.
+
## Pre-Release tasks
Announce the upcoming release to the mailing list release 2 weeks ahead
@@ -102,29 +144,30 @@
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.
+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
+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
+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
+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.
+**Be prepared to type in your PGP key’s passphrase.**
-````
+```text
usage: util/release/build-release <version> [commit id] [username] [gpg key id]
Tags a new coreboot version and creates a tar archive
@@ -132,37 +175,41 @@
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.
+After running the script, you should have a new directory for the
+release, along with 4 files: 2 tarballs, and 2 signature files.
-````
+```text
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
-````
+```bash
+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
- ````
+```bash
+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.
+* 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:
-````
+````text
% git show 4.6
tag 4.6
Tagger: Martin Roth <martinroth(a)google.com>
@@ -183,33 +230,44 @@
...
````
-When you used the script to generate the release, a signed tag was generated in the
-tree that was downloaded. From the coreboot-X.Y tree, just run: `git push origin X.Y`.
-In case you pushed the wrong tag already, you have to force push the new one.
+When you used the script to generate the release, a signed tag was
+generated in the tree that was downloaded. From the coreboot-X.Y tree,
+just run: `git push origin X.Y`. In case you pushed the wrong tag
+already, you have to force push the new one.
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,
+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
+````bash
+# Update the sha256sum file
+sha256sum -b coreboot-*.tar.xz > sha256suma.txt
+
+# make sure the two new files are present (and nothing else has changed)
+diff sha256sum.txt sha256suma.txt
+
+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>
+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/homepage/+/19515>
+Here is an example commit to change it:
+<https://review.coreboot.org/c/homepage/+/19515>
+
## Upload crossgcc sources
Sometimes the source files for older revisions of
@@ -219,24 +277,32 @@
Run
-````
-% util/crossgcc/buildgcc -u
+````bash
+util/crossgcc/buildgcc -u
````
This will output the set of URLs that the script uses to download the
sources. Download them yourself and copy them into the crossgcc-sources
directory on the server.
+
## After the release is complete
-Post the release notes on <https://blogs.coreboot.org>
+Post the final 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`
+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:
+```bash
+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:
-````
+````bash
git cherry-pick c6d134988c856d0025153fb885045d995bc8c397
git push origin HEAD:refs/for/4.8_branch
````
--
To view, visit https://review.coreboot.org/c/coreboot/+/68500
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I9a79cf92620755e19266faaf593dc2657acdb16f
Gerrit-Change-Number: 68500
Gerrit-PatchSet: 3
Gerrit-Owner: Martin L Roth <gaumless(a)gmail.com>
Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Reviewer: Felix Singer <felixsinger(a)posteo.net>
Gerrit-Reviewer: Jason Glenesk <jason.glenesk(a)gmail.com>
Gerrit-Reviewer: Martin L Roth <gaumless(a)gmail.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-MessageType: merged
Attention is currently required from: Iman Bingi, Martin L Roth, Julius Werner, Patrick Rudolph.
Iman Bingi has uploaded a new patch set (#186) to the change originally created by Patrick Rudolph. ( https://review.coreboot.org/c/coreboot/+/23586 )
Change subject: payloads/cbui: Add new payload CBUI
......................................................................
payloads/cbui: Add new payload CBUI
Depends on libpayload and nuklear.
Features:
* Graphical menus with scrolling.
* Text rendering engine (atm only bitmap font)
* Support for keyboard and mouse
* Support for USB and PS/2 devices
* Ported coreinfo and nvramcui
* Allows to modify NVRAM and RTC
* Works as ELF payload
* Works as Seabios secondary payload
* Basic support for multiple languages
* Hacky support for BIOS calls (depends on NASM)
* Runs in qemu and on real hardware
* Use linker script to allocate low memory
Shortcomings:
* Doesn't work in VGA text mode
* Untested on UEFI
* int32 relocates itself to low memory
Licenses:
* GPLv2 (CBUI + libpayload)
* BSD (libpayload)
* MIT (nuklear)
TODO:
* Test on as much platforms as possible
* Link int32 into low memory
This is Patrick Rudolph's original patch, updated by
Ben Adu-Boahen to:
* Add Read/Write module
* This module allows read/write to any hardware
component that is readable/writeable
Note:
This is work in progress
Change-Id: Ib9a1a07c1065880aa675380625021750d5cab7d1
Signed-off-by: Patrick Rudolph <siro(a)das-labor.org>
Signed-off-by: Ben Adu-Boahen <imanbingy(a)gmail.com>
---
M payloads/Kconfig
M payloads/Makefile.inc
A payloads/cbui/.gitignore
A payloads/cbui/Kconfig
A payloads/cbui/Makefile
A payloads/cbui/NuklearUI/NuklearCheckbox.c
A payloads/cbui/NuklearUI/NuklearCheckbox.h
A payloads/cbui/NuklearUI/NuklearCombo.c
A payloads/cbui/NuklearUI/NuklearCombo.h
A payloads/cbui/NuklearUI/NuklearCommon.h
A payloads/cbui/NuklearUI/NuklearDataGrid.c
A payloads/cbui/NuklearUI/NuklearDataGrid.h
A payloads/cbui/NuklearUI/NuklearDatePicker.c
A payloads/cbui/NuklearUI/NuklearDatePicker.h
A payloads/cbui/NuklearUI/NuklearFieldFile.c
A payloads/cbui/NuklearUI/NuklearFieldFile.h
A payloads/cbui/NuklearUI/NuklearFieldHex.c
A payloads/cbui/NuklearUI/NuklearFieldHex.h
A payloads/cbui/NuklearUI/NuklearFileChooser.c
A payloads/cbui/NuklearUI/NuklearFileChooser.h
A payloads/cbui/NuklearUI/NuklearGroup.c
A payloads/cbui/NuklearUI/NuklearGroup.h
A payloads/cbui/NuklearUI/NuklearHex.c
A payloads/cbui/NuklearUI/NuklearHex.h
A payloads/cbui/NuklearUI/NuklearIntegerRange.c
A payloads/cbui/NuklearUI/NuklearIntegerRange.h
A payloads/cbui/NuklearUI/NuklearLabel.c
A payloads/cbui/NuklearUI/NuklearLabel.h
A payloads/cbui/NuklearUI/NuklearObject.c
A payloads/cbui/NuklearUI/NuklearObject.h
A payloads/cbui/NuklearUI/NuklearRW.c
A payloads/cbui/NuklearUI/NuklearRW.h
A payloads/cbui/NuklearUI/NuklearRoot.c
A payloads/cbui/NuklearUI/NuklearRwAcpi.c
A payloads/cbui/NuklearUI/NuklearRwAcpi.h
A payloads/cbui/NuklearUI/NuklearRwAtaAtapi.c
A payloads/cbui/NuklearUI/NuklearRwAtaAtapi.h
A payloads/cbui/NuklearUI/NuklearRwDimmSpd.c
A payloads/cbui/NuklearUI/NuklearRwDimmSpd.h
A payloads/cbui/NuklearUI/NuklearRwEc.c
A payloads/cbui/NuklearUI/NuklearRwEc.h
A payloads/cbui/NuklearUI/NuklearRwIo.c
A payloads/cbui/NuklearUI/NuklearRwIo.h
A payloads/cbui/NuklearUI/NuklearRwIoIndexData.c
A payloads/cbui/NuklearUI/NuklearRwIoIndexData.h
A payloads/cbui/NuklearUI/NuklearRwMemory.c
A payloads/cbui/NuklearUI/NuklearRwMemory.h
A payloads/cbui/NuklearUI/NuklearRwMemoryIndexData.c
A payloads/cbui/NuklearUI/NuklearRwMemoryIndexData.h
A payloads/cbui/NuklearUI/NuklearRwNvram.c
A payloads/cbui/NuklearUI/NuklearRwNvram.h
A payloads/cbui/NuklearUI/NuklearRwPci.c
A payloads/cbui/NuklearUI/NuklearRwPci.h
A payloads/cbui/NuklearUI/NuklearRwPciIndexData.c
A payloads/cbui/NuklearUI/NuklearRwPciIndexData.h
A payloads/cbui/NuklearUI/NuklearRwSuperIo.c
A payloads/cbui/NuklearUI/NuklearRwSuperIo.h
A payloads/cbui/NuklearUI/NuklearStyle.c
A payloads/cbui/NuklearUI/NuklearStyle.h
A payloads/cbui/NuklearUI/NuklearTabView.c
A payloads/cbui/NuklearUI/NuklearTextView.c
A payloads/cbui/NuklearUI/NuklearTextView.h
A payloads/cbui/NuklearUI/NuklearTextfield.c
A payloads/cbui/NuklearUI/NuklearTextfield.h
A payloads/cbui/NuklearUI/NuklearTimePicker.c
A payloads/cbui/NuklearUI/NuklearTimePicker.h
A payloads/cbui/NuklearUI/NuklearUI.h
A payloads/cbui/NuklearUI/NuklearVector.c
A payloads/cbui/NuklearUI/NuklearVector.h
A payloads/cbui/arch/x86/cpuid.c
A payloads/cbui/arch/x86/cpuid.h
A payloads/cbui/arch/x86/int32.h
A payloads/cbui/arch/x86/int32.ld
A payloads/cbui/arch/x86/int32.nasm
A payloads/cbui/arch/x86/memcpy.c
A payloads/cbui/arch/x86/memcpy.h
A payloads/cbui/arch/x86/vga.c
A payloads/cbui/arch/x86/vga.h
A payloads/cbui/cbui.c
A payloads/cbui/cbui.h
A payloads/cbui/fsys/usbstorage.c
A payloads/cbui/fsys/usbstorage.h
A payloads/cbui/gfx/coreboot.c
A payloads/cbui/gfx/coreboot.h
A payloads/cbui/gfx/gfx.c
A payloads/cbui/gfx/gfx.h
A payloads/cbui/gfx/splash.c
A payloads/cbui/gfx/splash.h
A payloads/cbui/gfx/vbe.c
A payloads/cbui/gfx/vbe.h
A payloads/cbui/lang/de.c
A payloads/cbui/lang/en.c
A payloads/cbui/lang/lang.c
A payloads/cbui/lang/lang.h
A payloads/cbui/logo/cbui.png
A payloads/cbui/lp.config
A payloads/cbui/modules/bootlog_module.c
A payloads/cbui/modules/cbfs_module.c
A payloads/cbui/modules/cmos_module.c
A payloads/cbui/modules/coreboot_module.c
A payloads/cbui/modules/cpuinfo_module.c
A payloads/cbui/modules/license_module.c
A payloads/cbui/modules/modules.c
A payloads/cbui/modules/modules.h
A payloads/cbui/modules/nvram_module.c
A payloads/cbui/modules/pci_module.c
A payloads/cbui/modules/reboot_module.c
A payloads/cbui/modules/rtc_module.c
A payloads/cbui/modules/rw_module.c
A payloads/cbui/modules/timestamps_module.c
A payloads/cbui/modules/usb_module.c
A payloads/libpayload/configs/defconfig-cbui
112 files changed, 17,602 insertions(+), 1 deletion(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/86/23586/186
--
To view, visit https://review.coreboot.org/c/coreboot/+/23586
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: Ib9a1a07c1065880aa675380625021750d5cab7d1
Gerrit-Change-Number: 23586
Gerrit-PatchSet: 186
Gerrit-Owner: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-Reviewer: Iman Bingi <imanbingy(a)gmail.com>
Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org>
Gerrit-Reviewer: Martin L Roth <gaumless(a)gmail.com>
Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Patrick Rudolph <patrick.rudolph(a)9elements.com>
Gerrit-Reviewer: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-Reviewer: Paul Menzel <paulepanter(a)mailbox.org>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Gerrit-Attention: Iman Bingi <imanbingy(a)gmail.com>
Gerrit-Attention: Martin L Roth <gaumless(a)gmail.com>
Gerrit-Attention: Julius Werner <jwerner(a)chromium.org>
Gerrit-Attention: Patrick Rudolph <siro(a)das-labor.org>
Gerrit-MessageType: newpatchset
Attention is currently required from: Rocky Phagura, Paul Menzel, Angel Pons, Tim Chu.
Hello build bot (Jenkins), Rocky Phagura, Angel Pons, Tim Chu,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/68758
to look at the new patch set (#6).
Change subject: drivers/ipmi/ocp: add PCIe SEL support
......................................................................
drivers/ipmi/ocp: add PCIe SEL support
Add Kconfig SOC_RAS_BMS_SEL and corresponding support for
generating PCIe error SEL records and sending them to BMC.
Add PCIe error definitions.
This is needed for SMM, so build the ipmi kcs driver in SMM.
Signed-off-by: Tim Chu <Tim.Chu(a)quantatw.com>
Signed-off-by: Rocky Phagura <rphagura(a)fb.com>
Signed-off-by: Jonathan Zhang <jonzhang(a)meta.com>
Change-Id: I1ee46c8da7dbccbe1e2cc00bfe62e5df2f072d65
---
M src/drivers/ipmi/Makefile.inc
M src/drivers/ipmi/ocp/Kconfig
M src/drivers/ipmi/ocp/Makefile.inc
M src/drivers/ipmi/ocp/ipmi_ocp.h
A src/drivers/ipmi/ocp/ipmi_sel.c
5 files changed, 250 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/58/68758/6
--
To view, visit https://review.coreboot.org/c/coreboot/+/68758
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I1ee46c8da7dbccbe1e2cc00bfe62e5df2f072d65
Gerrit-Change-Number: 68758
Gerrit-PatchSet: 6
Gerrit-Owner: Jonathan Zhang <jonzhang(a)fb.com>
Gerrit-Reviewer: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Reviewer: Rocky Phagura <rphagura(a)fb.com>
Gerrit-Reviewer: Tim Chu <Tim.Chu(a)quantatw.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Paul Menzel <paulepanter(a)mailbox.org>
Gerrit-Attention: Rocky Phagura <rphagura(a)fb.com>
Gerrit-Attention: Paul Menzel <paulepanter(a)mailbox.org>
Gerrit-Attention: Angel Pons <th3fanbus(a)gmail.com>
Gerrit-Attention: Tim Chu <Tim.Chu(a)quantatw.com>
Gerrit-MessageType: newpatchset
Attention is currently required from: Arthur Heymans, Bill XIE, Nico Huber, Eric Lai, Werner Zeh, Kyösti Mälkki.
Jonathan Zhang has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/65420 )
Change subject: allocator_v4: Use memranges only for toplevel
......................................................................
Patch Set 14:
(1 comment)
Patchset:
PS11:
> > Hi Nico, I took the liberty to rebase your patch. […]
Got it. I restored the assign_resource_cb() part.
Let me discuss with Arthur on this. We are trying to use the resource_allocator_v4 for Intel xeon_sp soc.
--
To view, visit https://review.coreboot.org/c/coreboot/+/65420
To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-Change-Id: I70c700318a85f6760f27597730bc9c9a86dbe6b3
Gerrit-Change-Number: 65420
Gerrit-PatchSet: 14
Gerrit-Owner: Nico Huber <nico.h(a)gmx.de>
Gerrit-Reviewer: Arthur Heymans <arthur.heymans(a)9elements.com>
Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-Reviewer: Bill XIE <persmule(a)hardenedlinux.org>
Gerrit-Reviewer: Eric Lai <eric_lai(a)quanta.corp-partner.google.com>
Gerrit-Reviewer: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
Gerrit-Reviewer: Lean Sheng Tan <sheng.tan(a)9elements.com>
Gerrit-Reviewer: Tim Wawrzynczak <inforichland(a)gmail.com>
Gerrit-Reviewer: Werner Zeh <werner.zeh(a)siemens.com>
Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>
Gerrit-CC: Jonathan Zhang <jonzhang(a)fb.com>
Gerrit-Attention: Arthur Heymans <arthur.heymans(a)9elements.com>
Gerrit-Attention: Bill XIE <persmule(a)hardenedlinux.org>
Gerrit-Attention: Nico Huber <nico.h(a)gmx.de>
Gerrit-Attention: Arthur Heymans <arthur(a)aheymans.xyz>
Gerrit-Attention: Eric Lai <eric_lai(a)quanta.corp-partner.google.com>
Gerrit-Attention: Werner Zeh <werner.zeh(a)siemens.com>
Gerrit-Attention: Kyösti Mälkki <kyosti.malkki(a)gmail.com>
Gerrit-Comment-Date: Sat, 29 Oct 2022 22:13:17 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Nico Huber <nico.h(a)gmx.de>
Comment-In-Reply-To: Jonathan Zhang <jonzhang(a)fb.com>
Gerrit-MessageType: comment