http://www.coreboot.org/api.php?action=feedcontributions&user=PatrickGeorgi&feedformat=atomcoreboot - User contributions [en]2016-12-09T17:49:32ZUser contributionsMediaWiki 1.27.1http://www.coreboot.org/index.php?title=ARM&diff=22143ARM2016-11-14T10:07:00Z<p>PatrickGeorgi: </p>
<hr />
<div>coreboot runs on a bunch of ARM platforms. See [https://review.coreboot.org/cgit/coreboot.git/tree/src/soc src/soc]<br />
<br />
The first fully supported ARM platform in coreboot is the Samsung XE303CE [[Chromebooks|Chromebook]] (&quot;snow&quot;). It features an Exynos5250 SoC with a dual-core Cortex-A15 (ARMv7) processor. Exynos5420 support has also been added. More info about the Exynos5 SoCs and Coreboot is available [[Exynos5|here]].<br />
<br />
TI Beaglebone Black with the TI AM335x (ARM Cortex-A8) support is a work-in-progress. As of writing, basic infrastructure has been added, though full support is incomplete.<br />
<br />
ARM SOCs with PCIe are now on the market for tablets, netbooks and servers. These systems can take advantage of coreboot's strength in properly configuring PCI, SAS, SATA and SCSI devices; fast boot times; and payload support.<br />
<br />
== ARM SOCs ==<br />
<br />
* [http://www.marvell.com/products/processors/armada.html Marvell Armada 300, 510, 1000 with PCIe]<br />
* [http://www.marvell.com/products/processors/embedded/armada_xp/ Marvell Armada XP]<br />
* [http://www.marvell.com/products/processors/embedded/discovery_innovation/ Marvell Discovery Innovation Series with PCIe]<br />
* [http://www.marvell.com/products/processors/embedded/kirkwood/ Marvell Kirkwood Series with PCIe]<br />
* [http://www.st.com/internet/mcu/product/250658.jsp STMicroelectronics SPEAr1310 with PCIe]<br />
* [http://www.st.com/internet/mcu/product/251211.jsp STMicroelectronics SPEAr1340 with PCIe]<br />
* [http://focus.ti.com/dsp/docs/dspplatformscontento.tsp?sectionId=2&amp;familyId=1875&amp;tabId=2643 TI Sitara with PCIe]<br />
* [http://www.caviumnetworks.com/ECONA_CNS3XXX.html Cavium Networks ECONA CNS3XXX]<br />
* [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=844&amp;partnum=Exynos%204210&amp;xFmly_id=229 Samsung Exynos 4210 with PCIe]<br />
* [http://www.nvidia.com/object/tegra.html NVIDIA TEGRA]<br />
* [http://www.semicon.panasonic.co.jp/en/catalog/uniphier/index.html Panasonic UniPhier MN2WS0220]<br />
* [http://www.ziilabs.com/products/processors/zms20.aspx ZiiLabs ZMS-20]<br />
<br />
== Platforms ==<br />
<br />
* [http://www.globalscaletechnologies.com/t-openrdudetails.aspx OpenRD Ultimate with Marvell 88F6281]<br />
* [http://www.marvell.com/platforms/open_rd.html OpenRD Platforms with Marvell 88F6281]<br />
* [http://www.wyse.com/products/hardware/thinclients/T50/ WYSE T50 Marvell Thin Client]<br />
* [http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/12454-12454-321959-338927-3640405-4063703.html HP t5325 Marvell Thin Client]<br />
* [http://www.ztsystems.com/Portals/0/ZTSystems_R1801e.pdf ZTSystems R1801e rackmount server with STMicroelectronics SPEAr 1310 with dual ARM� CortexTM-A9 cores]<br />
* [http://pandaboard.org/ PandaBoard Dual-core ARM� Cortex�-A9 MPCore� mobile dev board]<br />
* [http://www.origenboard.org origenBOARD Exynos 4210 dev board]<br />
* [http://www.toradex.com/Products/Colibri/Modules/Colibri-Tegra-2 Colibri T20 cpu module with NVIDIA Dual Core ARM Cortex A9 Processor]<br />
* [http://trimslice.com/ Trimslice NVIDIA Tegra 2 dual-core ARM Cortex A9 @ 1 GHz 0.6&quot; thin desktop]<br />
* [http://www.compulab.co.il/a510/html/a510-sb-datasheet.htm SBC-A510 Marvell Armada 510 micro-ATX, single board computer]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=MediaWiki:Sidebar&diff=20331MediaWiki:Sidebar2016-08-11T20:15:43Z<p>PatrickGeorgi: </p>
<hr />
<div>* Status<br />
** mainpage|Overview<br />
** Current events|currentevents<br />
** Supported Motherboards|Supported boards<br />
** Supported Chipsets and Devices|Supported chipsets<br />
** Download coreboot|Downloads<br />
** recentchanges-url|Recent changes<br />
** Fun Stuff|Fun Stuff<br />
<br />
* Support<br />
** Documentation|Documentation<br />
** Category:Tutorials|Board&amp;nbsp;status&amp;nbsp;pages<br />
** https://ticket.coreboot.org/|Issue tracker<br />
** Mailinglist|Mailinglist<br />
** IRC|IRC<br />
** FAQ|FAQ<br />
<br />
* Development / QA<br />
** Lesson1|Getting Started<br />
** Development Guidelines|Guidelines<br />
** Developer Manual|Developer manual<br />
** https://review.coreboot.org/cgit/coreboot.git|Browse source<br />
&lt;!--** http://qa.coreboot.org/docs/doxygen/|Doxygen--&gt;<br />
** https://qa.coreboot.org/|QA<br />
&lt;!-- and snapshots--&gt;</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=MediaWiki:Sidebar&diff=20330MediaWiki:Sidebar2016-08-11T20:14:40Z<p>PatrickGeorgi: </p>
<hr />
<div>* Status<br />
** mainpage|Overview<br />
** Current events|currentevents<br />
** Supported Motherboards|Supported boards<br />
** Supported Chipsets and Devices|Supported chipsets<br />
** Download coreboot|Downloads<br />
** recentchanges-url|Recent changes<br />
** Fun Stuff|Fun Stuff<br />
<br />
* Support<br />
** Documentation|Documentation<br />
** Category:Tutorials|Board&amp;nbsp;status&amp;nbsp;pages<br />
** https://ticket.coreboot.org/|Issue tracker<br />
** Mailinglist|Mailinglist<br />
** IRC|IRC<br />
** FAQ|FAQ<br />
** Lesson1|Getting Started<br />
<br />
* Development / QA<br />
** Development Guidelines|Guidelines<br />
** Developer Manual|Developer manual<br />
** http://review.coreboot.org/gitweb?p=coreboot.git|Browse source<br />
&lt;!--** http://qa.coreboot.org/docs/doxygen/|Doxygen--&gt;<br />
** http://qa.coreboot.org/|QA<br />
&lt;!-- and snapshots--&gt;</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=User:GNUtoo/normal.sh&diff=18420User:GNUtoo/normal.sh2016-05-09T16:07:31Z<p>PatrickGeorgi: PatrickGeorgi moved page /normal.sh to User:GNUtoo/normal.sh without leaving a redirect: inaccessible page name</p>
<hr />
<div> #!/bin/sh<br />
# In the cases where this work is copyrightable, it falls under the GPLv2<br />
# or later license that is available here:<br />
# https://www.gnu.org/licenses/gpl-2.0.txt<br />
<br />
image=&quot;$1&quot;<br />
if [ $# -ne 1 ] ; then<br />
echo &quot;Usage $0 &lt;image&gt;&quot;<br />
exit 1<br />
fi<br />
<br />
die()<br />
{<br />
echo &quot;$1 Failed&quot;<br />
exit 1<br />
}<br />
<br />
cbfs_add()<br />
{<br />
name=$1<br />
file=$2<br />
cbfs_remove ${name}<br />
./util/cbfstool/cbfstool ./build/coreboot.rom add -n ${name} -t raw -f ${file}<br />
}<br />
<br />
cbfs_remove()<br />
{<br />
name=$1<br />
./util/cbfstool/cbfstool ./build/coreboot.rom remove -n ${name}<br />
}<br />
<br />
cbfs_reuse_payload()<br />
{<br />
./util/cbfstool/cbfstool ./build/coreboot.rom extract -f ./build/payload.elf -n fallback/payload<br />
./util/cbfstool/cbfstool ./build/coreboot.rom add -f ./build/payload.elf -n normal/payload -t payload<br />
}<br />
<br />
check_config()<br />
{<br />
grep &quot;^CONFIG_CBFS_PREFIX=\&quot;normal\&quot;$&quot; .config &gt; /dev/null || die &quot;Not using normal cbfs prefix&quot;<br />
grep &quot;^CONFIG_UPDATE_IMAGE=y$&quot; .config &gt; /dev/null || die &quot;Not using CONFIG_UPDATE_IMAGE&quot;<br />
grep &quot;^CONFIG_SKIP_MAX_REBOOT_CNT_CLEAR=y&quot; .config &gt; /dev/null || die &quot;Not using CONFIG_SKIP_MAX_REBOOT_CNT_CLEAR&quot;<br />
}<br />
<br />
check_config<br />
make oldconfig || die &quot;make oldconfig&quot;<br />
make clean || die &quot;clean&quot;<br />
mkdir build/ || die &quot;mkdir build&quot;<br />
<br />
cp ${image} ./build/coreboot.rom || die &quot;cp&quot;<br />
<br />
cbfs_remove normal/romstage<br />
cbfs_remove normal/ramstage<br />
cbfs_remove normal/payload<br />
cbfs_remove normal/dsdt.aml<br />
cbfs_remove config<br />
cbfs_remove revision<br />
<br />
# it now adds it automatically<br />
cbfs_remove etc/ps2-keyboard-spinup<br />
<br />
make || die &quot;make&quot;<br />
<br />
# uncomment if you want to reuse fallback's payload<br />
# cbfs_reuse_payload<br />
<br />
./util/cbfstool/cbfstool ./build/coreboot.rom print</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Project_Ideas&diff=17986Project Ideas2016-02-04T17:42:26Z<p>PatrickGeorgi: </p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Git&diff=17980Git2016-02-03T07:19:32Z<p>PatrickGeorgi: </p>
<hr />
<div>= Accessing the repository =<br />
The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularly interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for &quot;Smart HTTP&quot; transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.<br />
<br />
git clone &lt;nowiki&gt;http://review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
git clone &lt;nowiki&gt;ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot&lt;/nowiki&gt;<br />
<br />
Inside the checkout you should install a commit-msg hook that adds a Change-Id into commit messages, which uniquely identifies the logical change in Gerrit even across multiple iterations of the commit. The hook only needs to be installed once per clone, and installation can be done with<br />
<br />
wget -O .git/hooks/commit-msg &lt;nowiki&gt;http://review.coreboot.org/tools/hooks/commit-msg&lt;/nowiki&gt; &amp;&amp; \<br />
chmod +x .git/hooks/commit-msg<br />
<br />
Or you can also just run<br />
<br />
make gitconfig<br />
<br />
= Working with Git =<br />
<br />
Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065422.html a Git introduction] after the switch to Git had been announced on the mailing list.<br />
<br />
This section provides some more details on how to format commits so they match our style, which happens all locally on your development machine. For information on how to contribute these changes to the project, see the section below on the code review tool we use, [[Git#Gerrit|Gerrit]].<br />
<br />
== Commit messages ==<br />
Git does not enforce a commit message style, although perhaps it should. For all aspects of Git to work the best, it's important to follow these simple guidelines for commit messages:<br />
<br />
# The first line of the commit message has a short (less than 65 characters, absolute maximum is 75) summary<br />
# The second line is empty (no whitespace at all)<br />
# The third and any number of following lines contain a longer description of the commit as is neccessary, including relevant background information and quite possibly rationale for why the issue was solved in this particular way. These lines should never be longer than 75 characters.<br />
# The next line is empty (no whitespace at all)<br />
# A Change-Id: line to let gerrit track this logical change<br />
# A Signed-off-by: line according to [[Development_Guidelines#Sign-off_Procedure|the development guidelines]]<br />
<br />
Please do not create Change-Id: and Signed-off-by: manually because it is boring and error-prone. Instead, please install the commit-msg hook as described [[#Accessing_the_repository|above]], and remember to always use '''git commit -s''' to have git add your Signed-off-by: automatically.<br />
<br />
Here is an example of a well-formatted commit message:<br />
examplecomponent: Refactor duplicated setup into a function<br />
<br />
Setting up the demo device correctly requires the exact same register<br />
values to be written into each of the PCI device functions. Moving the<br />
writes into a function allows also otherexamplecomponent to use them.<br />
<br />
Signed-off-by: Joe Hacker &lt;joe@hacker.email&gt;<br />
<br />
The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.<br />
<br />
=== Guidelines on commit message content ===<br />
<br />
* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without needing to analyze the code code.<br />
* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:<br />
git show<br />
<br />
== Pushing changes ==<br />
You need to have an authenticated connection to review.coreboot.org setup. With ssh, you always need to authenticate with your username, so you're all set. For http, fetch the [http://review.coreboot.org/#settings,http-password http password] and edit (maybe create) a file called .netrc in your home directory ($HOME or ~). In this file, create a line containing<br />
<br />
machine review.coreboot.org login &lt;username&gt; password &lt;http password&gt;<br />
<br />
Then run the following command once, to tell git that by default you want to submit all commits in the currently checked-out branch for review on gerrit:<br />
<br />
git config remote.origin.push HEAD:refs/for/master<br />
<br />
After this, the command to push your changes is:<br />
<br />
git push origin<br />
<br />
If you always push from the same or a few branches the workflow can be simplified further by running once for each branch:<br />
<br />
git config branch.&lt;particularbranchname&gt;.remote origin<br />
<br />
...after which you then push changes with any of the configured branches checked out with a simple:<br />
<br />
git push<br />
<br />
Pushing several commits not yet in the coreboot repository at once will create one review request on gerrit per commit. <br />
<br />
'''NB!''' If you have applied patches from gerrit on a branch and you later push that branch, gerrit will think that you are submitting new versions of the patches that you had applied. This may or may not be what you intend. You can always run<br />
<br />
git log origin/master..<br />
<br />
before '''git push''' to verify which commits you are about to send for review.<br />
<br />
For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].<br />
<br />
== Pushing Drafts ==<br />
git push origin HEAD:refs/drafts/master<br />
== Pushing to Topics ==<br />
git push origin HEAD:refs/for/master/i915-kernel-x60<br />
will push to the i915-kernel-x60 topic.<br />
<br />
== Evolving patches ==<br />
<br />
Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.<br />
<br />
You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, <br />
<br />
git rebase -i master<br />
<br />
then commit and push the updated patch.<br />
<br />
Alternatively, you may amend your local commit and push the updated patch to gerrit:<br />
<br />
git add &lt;path/to/updated/files&gt;<br />
git commit --amend<br />
<br />
then push the updated patch.<br />
<br />
== Further Git reading ==<br />
There are tons of git tutorials out there. Take a look at some of these documents:<br />
* http://git-scm.com/<br />
* http://www.kernel.org/pub/software/scm/git/docs/v1.7.5.4/gittutorial.html<br />
* http://git.or.cz/course/svn.html<br />
* and in particular the [http://progit.org/ Pro Git book]<br />
<br />
Please also feel free to ask Git questions in the [[IRC|coreboot IRC channel]] or on the [[Mailinglist|mailing list]].<br />
<br />
= Browsing the sources =<br />
<br />
See http://review.coreboot.org/gitweb?p=coreboot.git<br />
<br />
= Gerrit =<br />
We use Gerrit on http://review.coreboot.org/ for code review.<br />
<br />
== Register with gerrit ==<br />
For authenticated access (to submit patches) you'll need a gerrit account which you can register at http://review.coreboot.org/.<br />
You also need to add your ssh key(s) (used for authenticating your connections to the repo) and your email address(es) (used to match up Signed-off-by: statements) to your gerrit user data at http://review.coreboot.org/#settings.<br />
<br />
=== OpenID and OAuth2 ===<br />
Gerrit uses OpenID and OAuth2 for authentication. Besides many large web services that provide OpenID identity services (eg. Yahoo), you can run your own, if you want. We support OAuth2 for Google and GitHub accounts.<br />
<br />
Once you have an account, you can link additional identity providers on http://review.coreboot.org/#/settings/web-identities (&quot;Link Another Identity&quot;). Any of these accounts can then be used to access your account. If you simply login with each of the identities, different accounts on gerrit are created, which is probably not the intention.<br />
<br />
Note that gerrit is a bit picky about the OpenID format. Always provide a full URL, including protocol (http:// or https:// prefix). Unfortunately the error messages are non-intuitive.<br />
<br />
== Gerrit workflow ==<br />
Gerrit interprets each Git commit as an individual change. Changes are autobuilt by [http://qa.coreboot.org/ Jenkins], and can be reviewed by developers. Once a change has gotten a positive review and has no build issues, it is applied to the master branch. Thus, no developer directly pushes to master.<br />
<br />
Reviews grant points on a scale from -2 to 2. The meaning is:<br />
* -2: Do not merge (blocks gerrit from merging)<br />
* -1: I'd prefer you don't merge it<br />
* 0: neutral<br />
* +1: Looks good, but I won't make the last call on it<br />
* +2: Looks good, go ahead and merge (gerrit provides a &quot;submit&quot; function to developers once it has a +2 vote)<br />
<br />
-2 is only available to core developers since it has veto power. Contributors with more activity than a one-off commit can request (eg. on IRC) to be added to the Reviewers group which has extended permissions (eg giving +2) over the default access level.<br />
<br />
=== Gerrit and CLI ===<br />
Reviews normally happens through the website.<br />
<br />
Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled. You can find the official Gerrit documentation about its CLI tools [https://gerrit-review.googlesource.com/Documentation/cmd-index.html here].<br />
<br />
=== Gerrit and Email ===<br />
Gerrit has no email integration. We extended it to send a couple of notifications to the coreboot-gerrit mailing list.<br />
<br />
=== Translating Gerrit Change-Ids using the CLI ===<br />
To map Gerrit Change-Ids to git commit ids, this git alias may help:<br />
$ # setup (only needed once)<br />
$ git config --global alias.gerrit-id '!f() { git log |egrep &quot;^(commit | *Change-Id:)&quot; |grep -B1 $1 |head -1 |sed &quot;s,^commit ,,&quot;; }; f'<br />
$ # use:<br />
$ git gerrit-id Ifeb277<br />
a3ea1e45902b64b45e141ebae2f59b94e745d187</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Git&diff=17979Git2016-02-03T07:19:15Z<p>PatrickGeorgi: /* Gerrit */</p>
<hr />
<div>= Accessing the repository =<br />
The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularly interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for &quot;Smart HTTP&quot; transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.<br />
<br />
git clone &lt;nowiki&gt;http://review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
git clone &lt;nowiki&gt;ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot&lt;/nowiki&gt;<br />
<br />
Inside the checkout you should install a commit-msg hook that adds a Change-Id into commit messages, which uniquely identifies the logical change in Gerrit even across multiple iterations of the commit. The hook only needs to be installed once per clone, and installation can be done with<br />
<br />
wget -O .git/hooks/commit-msg &lt;nowiki&gt;http://review.coreboot.org/tools/hooks/commit-msg&lt;/nowiki&gt; &amp;&amp; \<br />
chmod +x .git/hooks/commit-msg<br />
<br />
Or you can also just run<br />
<br />
make gitconfig<br />
<br />
= Working with Git =<br />
<br />
Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065422.html a Git introduction] after the switch to Git had been announced on the mailing list.<br />
<br />
This section provides some more details on how to format commits so they match our style, which happens all locally on your development machine. For information on how to contribute these changes to the project, see the section below on the code review tool we use, [[Git#Gerrit|Gerrit]].<br />
<br />
== Commit messages ==<br />
Git does not enforce a commit message style, although perhaps it should. For all aspects of Git to work the best, it's important to follow these simple guidelines for commit messages:<br />
<br />
# The first line of the commit message has a short (less than 65 characters, absolute maximum is 75) summary<br />
# The second line is empty (no whitespace at all)<br />
# The third and any number of following lines contain a longer description of the commit as is neccessary, including relevant background information and quite possibly rationale for why the issue was solved in this particular way. These lines should never be longer than 75 characters.<br />
# The next line is empty (no whitespace at all)<br />
# A Change-Id: line to let gerrit track this logical change<br />
# A Signed-off-by: line according to [[Development_Guidelines#Sign-off_Procedure|the development guidelines]]<br />
<br />
Please do not create Change-Id: and Signed-off-by: manually because it is boring and error-prone. Instead, please install the commit-msg hook as described [[#Accessing_the_repository|above]], and remember to always use '''git commit -s''' to have git add your Signed-off-by: automatically.<br />
<br />
Here is an example of a well-formatted commit message:<br />
examplecomponent: Refactor duplicated setup into a function<br />
<br />
Setting up the demo device correctly requires the exact same register<br />
values to be written into each of the PCI device functions. Moving the<br />
writes into a function allows also otherexamplecomponent to use them.<br />
<br />
Signed-off-by: Joe Hacker &lt;joe@hacker.email&gt;<br />
<br />
The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.<br />
<br />
=== Guidelines on commit message content ===<br />
<br />
* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without needing to analyze the code code.<br />
* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:<br />
git show<br />
<br />
== Pushing changes ==<br />
You need to have an authenticated connection to review.coreboot.org setup. With ssh, you always need to authenticate with your username, so you're all set. For http, fetch the [http://review.coreboot.org/#settings,http-password http password] and edit (maybe create) a file called .netrc in your home directory ($HOME or ~). In this file, create a line containing<br />
<br />
machine review.coreboot.org login &lt;username&gt; password &lt;http password&gt;<br />
<br />
Then run the following command once, to tell git that by default you want to submit all commits in the currently checked-out branch for review on gerrit:<br />
<br />
git config remote.origin.push HEAD:refs/for/master<br />
<br />
After this, the command to push your changes is:<br />
<br />
git push origin<br />
<br />
If you always push from the same or a few branches the workflow can be simplified further by running once for each branch:<br />
<br />
git config branch.&lt;particularbranchname&gt;.remote origin<br />
<br />
...after which you then push changes with any of the configured branches checked out with a simple:<br />
<br />
git push<br />
<br />
Pushing several commits not yet in the coreboot repository at once will create one review request on gerrit per commit. <br />
<br />
'''NB!''' If you have applied patches from gerrit on a branch and you later push that branch, gerrit will think that you are submitting new versions of the patches that you had applied. This may or may not be what you intend. You can always run<br />
<br />
git log origin/master..<br />
<br />
before '''git push''' to verify which commits you are about to send for review.<br />
<br />
For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].<br />
<br />
== Pushing Drafts ==<br />
git push origin HEAD:refs/drafts/master<br />
== Pushing to Topics ==<br />
git push origin HEAD:refs/for/master/i915-kernel-x60<br />
will push to the i915-kernel-x60 topic.<br />
<br />
== Evolving patches ==<br />
<br />
Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.<br />
<br />
You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, <br />
<br />
git rebase -i master<br />
<br />
then commit and push the updated patch.<br />
<br />
Alternatively, you may amend your local commit and push the updated patch to gerrit:<br />
<br />
git add &lt;path/to/updated/files&gt;<br />
git commit --amend<br />
<br />
then push the updated patch.<br />
<br />
== Further Git reading ==<br />
There are tons of git tutorials out there. Take a look at some of these documents:<br />
* http://git-scm.com/<br />
* http://www.kernel.org/pub/software/scm/git/docs/v1.7.5.4/gittutorial.html<br />
* http://git.or.cz/course/svn.html<br />
* and in particular the [http://progit.org/ Pro Git book]<br />
<br />
Please also feel free to ask Git questions in the [[IRC|coreboot IRC channel]] or on the [[Mailinglist|mailing list]].<br />
<br />
= Browsing the sources =<br />
<br />
See http://review.coreboot.org/gitweb?p=coreboot.git<br />
<br />
= Gerrit =<br />
We use Gerrit on http://review.coreboot.org/ for code review.<br />
<br />
== Register with gerrit ==<br />
For authenticated access (to submit patches) you'll need a gerrit account which you can register at http://review.coreboot.org/.<br />
You also need to add your ssh key(s) (used for authenticating your connections to the repo) and your email address(es) (used to match up Signed-off-by: statements) to your gerrit user data at http://review.coreboot.org/#settings.<br />
<br />
=== OpenID and OAuth2 ===<br />
Gerrit uses OpenID and OAuth2 for authentication. Besides many large web services that provide OpenID identity services (eg. Yahoo), you can run your own, if you want. We support OAuth2 for Google and GitHub accounts.<br />
<br />
Once you have an account, you can link additional identity providers on http://review.coreboot.org/#/settings/web-identities (&quot;Link Another Identity&quot;). Any of these accounts can then be used to access your account. If you simply login with each of the identities, different accounts on gerrit are created, which is probably not the intention.<br />
<br />
Note that gerrit is a bit picky about the OpenID format. Always provide a full URL, including protocol (http:// or https:// prefix). Unfortunately the error messages are non-intuitive.<br />
<br />
== Gerrit workflow ==<br />
Gerrit interprets each Git commit as an individual change. Changes are autobuilt by [http://qa.coreboot.org/ Jenkins], and can be reviewed by developers. Once a change has gotten a positive review and has no build issues, it is applied to the master branch. Thus, no developer directly pushes to master.<br />
<br />
Reviews grant points on a scale from -2 to 2. The meaning is:<br />
* -2: Do not merge (blocks gerrit from merging)<br />
* -1: I'd prefer you don't merge it<br />
* 0: neutral<br />
* +1: Looks good, but I won't make the last call on it<br />
* +2: Looks good, go ahead and merge (gerrit provides a &quot;submit&quot; function to developers once it has a +2 vote)<br />
<br />
-2 is only available to core developers since it has veto power. Contributors with more activity than a one-off commit can request (eg. on IRC) to be added to the Reviewers group which has extended permissions (eg giving +2) over the default access level.<br />
<br />
=== Gerrit and CLI ===<br />
Reviews normally happens through the website.<br />
<br />
Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled. You can find the official Gerrit documentation about its CLI tools [https://gerrit-review.googlesource.com/Documentation/cmd-index.html here].<br />
<br />
=== Gerrit and Email ===<br />
Gerrit has no email integration. We extended it to send a couple of notifications to the coreboot-gerrit mailing list.<br />
<br />
=== Translating Gerrit Change-Ids on the CLI ===<br />
To map Gerrit Change-Ids to git commit ids, this git alias may help:<br />
$ # setup (only needed once)<br />
$ git config --global alias.gerrit-id '!f() { git log |egrep &quot;^(commit | *Change-Id:)&quot; |grep -B1 $1 |head -1 |sed &quot;s,^commit ,,&quot;; }; f'<br />
$ # use:<br />
$ git gerrit-id Ifeb277<br />
a3ea1e45902b64b45e141ebae2f59b94e745d187</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Motherboard_Porting_Guide&diff=17905Motherboard Porting Guide2016-01-26T08:17:12Z<p>PatrickGeorgi: remove references to lspnp. outdated, not very useful, and hard to obtain</p>
<hr />
<div><br />
== Motherboard Porting Guide ==<br />
<br />
Please note that this is WIP work.<br />
<br />
== HOWTO to find a way ==<br />
<br />
* find a model and manufacturer of your mobo<br />
* download these tools:<br />
# git clone http://review.coreboot.org/p/coreboot<br />
# superiotool ( cd coreboot/util/superiotool ; make ; sudo make install )<br />
# inteltool ( cd coreboot/util/inteltool ; make ; sudo make install )<br />
# ectool ( cd coreboot/util/ectool ; make ; sudo make install )<br />
# dmidecode ( cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/dmidecode co dmidecode )<br />
# msrtool ( cd coreboot/util/msrtool ; ./configure ; make ; sudo make install )<br />
# nvramtool ( cd coreboot/util/nvramtool ; make ; sudo make install )<br />
# flashrom ( svn co svn://coreboot.org/flashrom/trunk flashrom )<br />
* make and install them (make; sudo make install) - you need at least libpci/pciutils<br />
* check that your distro have this tools and install them:<br />
# lspci<br />
# dmesg<br />
# acpitool<br />
# lsusb<br />
# acpidump<br />
* # modprobe msr<br />
(this is for one of the steps below) <br />
* Do this commands '''as root''' (# remove for the easy copypasting):<br />
lspci -nnvvvxxxx &gt; lspci.log 2&gt;lspci.err.log<br />
lsusb -vvv &gt; lsusb.log 2&gt;lsusb.err.log<br />
superiotool -deV &gt; superiotool.log 2&gt; superiotool.err.log<br />
inteltool -a &gt; inteltool.log 2&gt; inteltool.err.log<br />
ectool -i &gt; ectool.log 2&gt;ectool.err.log<br />
msrtool &gt; msrtool.log 2&gt;msrtool.err.log<br />
dmidecode &gt; dmidecode.log 2&gt;dmidecode.err.log<br />
biosdecode &gt; biosdecode.log 2&gt;biosdecode.err.log<br />
nvramtool -x &gt; nvramtool.log 2&gt;nvramtool.err.log<br />
dmesg &gt; dmesg.log 2&gt;dmesg.err.log<br />
flashrom -V -p internal:laptop=force_I_want_a_brick &gt; flashrom_info.log 2&gt;flashrom_info.err.log # this won't work on some vendor firmware<br />
flashrom -V -p internal:laptop=force_I_want_a_brick -r rom.bin &gt; flashrom_read.log 2&gt;flashrom_read.err.log # this won't work on some vendor firmware<br />
acpidump &gt; acpidump.log 2&gt;acpidump.err.log<br />
for x in /sys/class/sound/card0/hw*; do cat &quot;$x/init_pin_configs&quot; &gt; pin_&quot;$(basename &quot;$x&quot;)&quot;; done<br />
for x in /proc/asound/card0/codec#*; do cat &quot;$x&quot; &gt; &quot;$(basename &quot;$x&quot;)&quot;; done<br />
cat /proc/cpuinfo &gt; cpuinfo.log 2&gt;cpuinfo.err.log<br />
cat /proc/ioports &gt; ioports.log 2&gt;ioports.err.log<br />
cat /sys/class/input/input*/id/bustype &gt; input_bustypes.log<br />
* Save all logs in safe place, and also rom.bin file. <br />
* Find what chip does your mobo use. The name of the chip is present in flashrom_info.log but is not always exact as some chips have several packaging variants (e.g. SOIC-16, SOIC-8 and TSOP). Consult [[http://flashrom.org/Technology]] for more info on possible chip formats. If possible make a high-resolution (600dpi or higher) scan of motherboard. Make a scan, not a photo as cameras typically don't have enough resolution to identify individual chips.<br />
* try to find information - what EC (if on laptop) or Super I/O chip (if any) is used in your mobo (may be some info in Service Manuals or Disassembly guides)<br />
* try to find your Super I/O / EC chip datasheet<br />
For laptop, additionally:<br />
* if you see that ectool return some fake stuff - like only 'FF' or '00' - so you have custom EC configuration, it's a hard work for support<br />
* if you see that ectool return looks like 'right' output - you have a big chances for support<br />
* you need to find from thease outputs Super I/O / EC chip name, or if not see this - disassembly your laptop<br />
<br />
=== Preparing recovery method ===<br />
<br />
Inevitably when you develop coreboot there will be unbootable builds and so you need a way to unbrick your machine after a failed image. There are several ways to do so. Main ones are:<br />
* In-system Programming. For more info consult [[http://flashrom.org/ISP]]<br />
* Hotswap. Consult [[http://flashrom.org/Technology]]<br />
In any case you have to locate the flash chip. Note the chipname from flashrom output. Teardown your system and find that chip. For how it usually looks like consult [[http://flashrom.org/Technology]]. If you have a scanner, do a high-resolution scan of your board, it may be useful later.<br />
<br />
=== Selecting Similar Board ===<br />
<br />
Most important criteria for finding similar board is chipset. Look at northbridge (device 0:0.0) and southbridge (LPC controller) in the lspci output. grep through coreboot tree to find how those chipsets are named, then grep for chipset name (case-insensitive) to find a board which uses it. If there are several of them, try to match (in order of decreasing importance) system type (desktop/laptop), SuperI/O and manufacturer.<br />
<br />
<br />
=== Adding a new board ===<br />
<br />
This is a two step process. If you mainboard already exists, skip to next section.<br />
<br />
==== Adding a new vendor to tree ====<br />
<br />
Create a directory in src/mainboard with the same name as vendor name. Add to src/mainboard/Kconfig<br />
new vendor entry, the rest of this example uses &quot;foo&quot; vendor.<br />
<br />
config VENDOR_FOO<br />
bool &quot;Foo&quot;<br />
<br />
Add also a include for new Kconfig file which holds the vendor motherboards in the vendor directory<br />
<br />
source &quot;src/mainboard/foo/Kconfig&quot;<br />
<br />
Create a src/mainboard/foo/Kconfig, copy from other vendor, and change the vendor name. Delete all mainboards. <br />
<br />
==== Adding a new motherboard to tree ====<br />
<br />
Asume that vendor name is foo and board type is bar. Add new configuration item in src/mainboard/foo/Kconfig<br />
<br />
config BOARD_FOO_BAR<br />
bool &quot;BAR&quot;<br />
<br />
Add include for board specific config:<br />
<br />
source &quot;src/mainboard/foo/bar/Kconfig&quot;<br />
<br />
==== Adjusting contents of new board directory ====<br />
<br />
Now copy your similar board and start adjusting. Your first stop is the Kconfig.<br />
<br />
* You need to change the condition in the first line to match your board:<br />
<br />
-if BOARD_VENDOR_BAR<br />
+if BOARD_VENDOR_BAZ<br />
<br />
* Change MAINBOARD_DIR and names<br />
* Change device options to match your config<br />
* Next stop go to mainboard.c and adjust GPIO config based on inteltool dump above.<br />
* Now you can flash the image and see what fails. <br />
* Later adjust hda_verb.h to get sound working properly (use initial pin dumps for reference)<br />
<br />
Look through the options and adjust <br />
<br />
Adjust Kconfig to fit the new vendor/model name and dont forget to change MAINBOARD_DIR and MAINBOARD_PART_NUMBER.</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Development_Guidelines&diff=17904Development Guidelines2016-01-25T17:36:35Z<p>PatrickGeorgi: /* Bug-Tracker */</p>
<hr />
<div>= Development Environment =<br />
<br />
== Required Toolchain ==<br />
<br />
The easiest way to get a working toolchain is to run &lt;code&gt;make crossgcc&lt;/code&gt; in the toplevel directory of a coreboot checkout. Distributions usually modify their compilers in ways incompatible with coreboot. If in doubt, use our toolchain.<br />
<br />
The toolchain consists of:<br />
* GNU development environment:<br />
** [http://gcc.gnu.org/ GCC with G++]<br />
** [http://www.kernel.org/pub/linux/devel/binutils/ binutils]<br />
* libncurses*-dev<br />
* [http://www.acpica.org/downloads/ IASL], now part of the '''ACPICA''' download (package ''pmtools'' or ''iasl'' in many distributions)<br />
<br />
= Coding Guidelines =<br />
<br />
== General Guidelines ==<br />
<br />
* Encapsulate and isolate assembly language<br />
* Code shall not be &quot;commented out&quot;<br />
* No use of floating-point arithmetics<br />
* No hiding of identifiers defined in outer scopes<br />
* Typedefs are unique (device_t?)<br />
* Functions shall have prototype declarations<br />
* Local functions should be declared static<br />
* No function definitions in header files<br />
* All variables are assigned before use<br />
* All objects should have fully qualified types (''unsigned int'' instead of ''unsigned'')<br />
* Types which indicate signedness and bitness should be used (''uint32_t'' or ''u32'' instead of ''unsigned int'')<br />
* We suggest trying to import more such rules, such as additional ones described in [http://www.misra.org.uk/index.htm MISRA-C 2012] (''Guidelines for the use of C in critical systems'')<br />
<br />
== Variable types ==<br />
<br />
Whenever possible, please use a variable type which is explicit about the size of data it can hold. For example, use '''uint32_t''' or '''u32''' instead of '''unsigned long''' when referencing a 32-bit wide register.<br />
<br />
=== short int names vs stdint names ===<br />
<br />
There is '''currently no hard rule''' on whether one should use short int types ('''u32'''), or stdint types ('''uint32_t'''). Whichever type you elect to use, please use common sense and stay consistent.<br />
<br />
== Assembly Language ==<br />
<br />
To keep the code consistent across the different supported platforms, AT&amp;T syntax is to be used through-out the project. We are working actively on replacing the existing Intel syntax code with AT&amp;T syntax. No new Intel syntax code is allowed into the project.<br />
<br />
It is highly encouraged to not use inline assembly, but instead to encapsulate and isolate the use of assembly language to pure assembly files.<br />
<br />
== Comments ==<br />
<br />
=== References ===<br />
<br />
If you are referencing a data sheet or other documentation in the code, please add the name or document number in addition to the URL. Vendors just ''love'' to rearrange their websites (and some remove documentation on their old products altogether)! If we have the name/number (or even just the filename of the PDF) at least there's a chance to google for it again (either on the vendor's site or on some archive).<br />
<br />
== Coding Style ==<br />
<br />
* We use the coreboot [[Coding Style]] throughout the project.<br />
* You can use the 'indent' tool to fix the coding style like this:<br />
indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs *.[ch]<br />
:Do not trust 'indent' blindly, though. It sometimes gets things wrong. Manual corrections may be required.<br />
<br />
== The 80 character limit ==<br />
<br />
Lines larger than 80 columns should be broken down into readable pieces. This includes not only source files, but also Makefiles, Kconfig files, and any file meant to be edited by a human. We recommend setting your editor to show the 80th character limit.<br />
This limit is not a relic from long forgotten times, but a very practical and efficient way to organize code and increase productivity. Several files can be edited on the same monitor, without the need to side-scroll. Side-scrolling source files is inefficient, time-consuming, and uncomfortable. On average, 95% of source lines are shorter than 80 characters, so limiting the line length is this manner is not only _not_ an impediment, it also gets you to think on how to best organize the code.<br />
<br />
= Documentation Guidelines =<br />
<br />
== General Guidelines and Tips ==<br />
<br />
* Documentation should be put into the wiki and/or in the code as Doxygen comments<br />
* Avoid using different styles and looks of documentation<br />
* Document ''why'' and ''what'', not ''how'' (No comments like ''/* add one to i */'')<br />
* Document assumptions, stipulations etc...<br />
* Document design and concepts!<br />
* Not lots of documentation but good documentation<br />
* Structured documentation<br />
* Focus: Whom are you addressing in your documentation? Write documentation for users, developers, vendors, ...<br />
<br />
== Automatic documentation ==<br />
<br />
* Doxygen-generated API- and code documentation is available at http://qa.coreboot.org/docs/. This documentation is updated on every 10th checkin.<br />
* To create a Doxygen comment, write<br />
/**<br />
* Sample comment.<br />
*/<br />
:or<br />
/** Sample comment. */<br />
* There are a few commands that describe what kind of comment you are adding:<br />
::@param &amp;mdash; input parameters of a function<br />
::@return &amp;mdash; return value of a function<br />
* A list of all commands is available at http://www.stack.nl/~dimitri/doxygen/commands.html<br />
<br />
Full example:<br />
<br />
/**<br />
* Calculate the length of a string.<br />
*<br />
* @param str The input string.<br />
* @return The length of the string, not including the final NUL character.<br />
*/<br />
static inline size_t strlen(const char *str)<br />
{<br />
/* ... */<br />
}<br />
<br />
= Testing =<br />
<br />
Every commit will be processed by the autobuild and autotest system available at http://qa.coreboot.org/. In addition please run autobuild yourself before submitting patches.<br />
<br />
== autobuild ==<br />
<br />
Autobuild can be found at [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/abuild;hb=HEAD coreboot/util/abuild]. <br />
<br />
Please run ''abuild'' '''before''' you commit.<br />
<br />
Autobuild is also running on every check-in to the repository. The results of this build are also available at http://qa.coreboot.org/.<br />
<br />
== autotest ==<br />
<br />
We can also run automatic tests on boards, if we find contributors willing to have a board automatically managed by our QA system. This requires a permanent connection to the net, a host system and some special circuitry. If interested, please contact us using the [[Mailinglist|mailing list]].<br />
<br />
= How to contribute =<br />
<br />
== Creating Patches ==<br />
<br />
* We use gerrit for change management, using the instance on http://review.coreboot.org/<br />
* While not necessary with gerrit, '''make sure that your change is against current master'''. Patches that fail on merge (after some developer looked at it and approved it) might linger around until '''you''' update it.<br />
* Rebase, if necessary, '''then test''' again. You might be the only contributor with that specific mainboard.<br />
* Make sure all new and modified files contain the [[Development Guidelines#Common_License_Header|proper license headers]] (see below).<br />
* Make sure all added files are actually within the commit.<br />
* Make one commit per logical change.<br />
* For more details on using gerrit, see our [[Git]] documentation. Things are somewhat different (eg. it's normal to rebase changes that were already pushed).<br />
* Double-check that your changes are correct, and that the commit only contains what you think it contains.<br />
<br />
== Sign-off Procedure ==<br />
<br />
We employ a similar sign-off procedure for coreboot <br />
[http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html as the Linux kernel developers] do.<br />
Please add a note such as<br />
Signed-off-by: Random J Developer &lt;random@developer.example.org&gt;<br />
to your email/patch if you agree with the following Developer's Certificate of Origin 1.1.<br />
<br />
Patches without a Signed-off-by cannot be pushed to gerrit!<br />
<br />
&lt;span style=&quot;color:red&quot;&gt;You have to use your real name in the Signed-off-by line and in any copyright notices you add.&lt;/span&gt; Patches without an associated real name cannot be committed!<br />
<br />
'''Developer's Certificate of Origin 1.1:'''<br />
<br />
By making a contribution to this project, I certify that:&lt;br /&gt;<br />
(a) The contribution was created in whole or in part by me and I have<br />
the right to submit it under the open source license indicated in the file; or&lt;br /&gt;<br />
(b) The contribution is based upon previous work that, to the best of my<br />
knowledge, is covered under an appropriate open source license and I have the<br />
right under that license to submit that work with modifications, whether created<br />
in whole or in part by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated in the file; or&lt;br /&gt;<br />
(c) The contribution was provided directly to me by some other person who<br />
certified (a), (b) or (c) and I have not modified it; and&lt;br /&gt;<br />
(d) In the case of each of (a), (b), or (c), I understand and agree that<br />
this project and the contribution are public and that a record of the contribution<br />
(including all personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with this project or the<br />
open source license indicated in the file.<br />
<br />
&lt;small&gt;Note: The [http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html Developer's Certificate of Origin 1.1] is licensed under the terms of the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5 License].&lt;/small&gt;<br />
<br />
== Reviews ==<br />
<br />
* Send your patch to [[Git|gerrit]] for review.<br />
** Provide useful commit messages. Explain what the change does and why. Our short intro to [[Git|git]] explains the format in more detail.<br />
** Add a single line containing your &quot;[[Development Guidelines#Sign-off_Procedure|sign-off]]&quot; after the description of the patch (&lt;code&gt;git commit -s&lt;/code&gt; helps, but make sure you understand and comply with the DCO).<br />
*** Example: ''Signed-off-by: John Doe &lt;john@example.com&gt;''<br />
* The developers will review and/or test your change and send comments or suggestions. Please push updated patches as described in &quot;[[Git#Evolving_patches|evolving patches]]&quot;.<br />
* If the change looks ok to one or more developers, they will approve and submit it to the master branch.<br />
<br />
= Bug-Tracker =<br />
<br />
Issues can be documented at https://ticket.coreboot.org/.<br />
<br />
= License Issues =<br />
<br />
* Contributed code must be GPL'd (preferrably 'GPLv2', but 'GPLv2 or any later version' is fine, too). At the very minimum the code must have a GPLv2-compatible license.<br />
<br />
== Common License Header ==<br />
<br />
Please quote the shortened GPL license header text in every file, as shown below. It should contain:<br />
<br />
* The '''year(s)''' when the code was written or modified and a '''copyright note''' of you (or your company, if you are contributing as part of your employment, and thus the copyright belongs to your company). Also, please provide an '''email address''' if possible so that you can be contacted if questions arise.<br />
** Example:<br />
::''Copyright (C) 2006 John Doe &lt;john@example.com&gt;''<br />
::''Copyright (C) 2004-2006 Company, Inc.''<br />
* The full '''GPL header''' as shown below.<br />
<br />
'''Complete example for *.c and *.h files:'''<br />
<br />
/*<br />
* This file is part of the coreboot project.<br />
*<br />
* Copyright (C) 2003-2005 Jane Doe &lt;jane@example.com&gt;<br />
* Copyright (C) 2006 Company, Inc.<br />
*<br />
* This program is free software; you can redistribute it and/or modify<br />
* it under the terms of the GNU General Public License as published by<br />
* the Free Software Foundation; version 2 of the License.<br />
*<br />
* This program is distributed in the hope that it will be useful,<br />
* but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
* GNU General Public License for more details.<br />
*/<br />
<br />
'''Complete example for Makefiles, config files, Python files, shell scripts etc.:'''<br />
<br />
##<br />
## This file is part of the coreboot project.<br />
##<br />
## Copyright (C) 2003-2005 Jane Doe &lt;jane@example.com&gt;<br />
## Copyright (C) 2006 Company, Inc.<br />
##<br />
## This program is free software; you can redistribute it and/or modify<br />
## it under the terms of the GNU General Public License as published by<br />
## the Free Software Foundation; version 2 of the License.<br />
##<br />
## This program is distributed in the hope that it will be useful,<br />
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
## GNU General Public License for more details.<br />
##</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=ACPI&diff=17665ACPI2016-01-06T15:59:24Z<p>PatrickGeorgi: /* STOP 0xa5 */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=AMD_SimNow&diff=17520AMD SimNow2015-12-05T17:26:39Z<p>PatrickGeorgi: </p>
<hr />
<div>These are the steps I use to download, install, and use the AMD SimNow simulator.<br />
You may not want to do exactly what I did, but it should get you started.<br />
There is PDF documentation that you can download on the same page as the simulator. <br />
<br />
== Download SimNow ==<br />
# Download SimNow from [http://developer.amd.com/tools-and-sdks/cpu-development/simnow-simulator/ AMD's website]<br />
#Untar the .tar.gz file you download in a convenient place (You'll now have a directory called simnow-linux64-4.6.x.pub)<br />
#Follow the instructions from the help section &quot;Setting up Linux&quot; for the Simulator<br />
## To get enough &quot;mmap&quot;able virtual address space, make sure you have a /etc/sysctl.conf file and that it contains the following line:<br />
<br />
&lt;pre&gt;&lt;nowiki&gt; vm.max_map_count = 1048576 &lt;/nowiki&gt;&lt;/pre&gt;<br />
<br />
== Run SimNow ==<br />
#Run ''./simnow'' from the simnow-linux64-4.5.xpub directory<br />
#Inside the SimNow Main Window do File-&gt;Open BSD, browse to the simnow-linux64-4.5.xpub/bsds directory and load either cheetah_1p.bsd or cheetah_1pjh.bsd (jh is dual-core)<br />
&lt;pre&gt;&lt;nowiki&gt;Now you have a single Opteron socket motherboard with:<br />
AMD-8132 PCI-X controller, <br />
AMD-8111 I/O hub, <br />
and Winbond W83627HF SuperIO.&lt;/nowiki&gt;&lt;/pre&gt; <br />
#Copy your coreboot ROM image to simnow-linux64-4.5.xpub/Images for convenience.<br />
#Open the SimNow Device Window (View-&gt;Show Devices)<br />
#Double click on Memory Device #5 (Your BIOS chip)<br />
#Click on the Memory Configuration Tab, and change the Base Address, Size, and File (I use Base Address = fff00000 and Size = 32 because I use a 1 MB image)<br />
#Click OK to save your changes<br />
#Go to the main simulator window and hit Run Simulation (Play button)<br />
<br />
== Serial Port Configuration == <br />
In order to see the console output, go to the terminal you are running ./simnow in. Hit enter. You'll see a simnow&gt; prompt. <br />
# Type ''serial.SetCommPort pipe'' and hit enter.<br />
# Type ''serial.GetCommPort'' and hit enter.<br />
On my machine this returns <br />
path (/home/myles/.simnow/com1), mode (PIPE)<br />
<br />
Open a new terminal and type cat /home/myles/.simnow/com1/simnow_out<br />
If you need to send input to the serial port, echo to /home/myles/.simnow/com1/simnow_in<br />
<br />
=== Using the snserial tool ===<br />
<br />
Alternatively, you can use a tool called 'snserial' to interact with the serial ports. snserial will combine the input and output, and provide access to the combined stream through either a psuedo tty, or a telenet port.<br />
<br />
# Download the snserial tool from http://khepri.openbios.org/~jcrouse/snserial-1.0.tar.gz.<br />
# Extract it: ''tar -zxvf snserial-1.0.tar.gz''<br />
# Build it: ''cd snserial/; make''<br />
<br />
Before running the tool, make sure that you have enabled the serial pipes as detailed above.<br />
<br />
To enable serial through a pseudo TTY, start your simulation and type ''./snserial comX'' in another Linux terminal window (where X is 1 or 2). The program will respond with:<br />
<br />
SimNow Serial pipe Muxer<br />
<br />
Connection established.<br />
Type 'target remote /dev/pts/2' in GDB to connect.<br />
(Press CTRL-C to exit)<br />
<br />
You can now connect your serial application (minicom, or GDB for debugging) to the specified pseudo-tty.<br />
<br />
To enable serial interaction through telnet, start the simulation and type ''./snserial -t comX''. The program will respond with:<br />
<br />
SimNow Serial pipe Muxer<br />
<br />
COM 1: Listening on port 9000<br />
(Press CTRL-C to exit)<br />
<br />
You can now connect to the serial stream by typing 'telnet localhost 9000' in a Linux terminal window.<br />
<br />
'''Note:''' It is a quirk of SimNow that the pipes are not created until the simulation for the BSD is started for the first time. Make sure you start the simulation before running ''snserial'', otherwise you will see this: ''Couldn't stat /home/&lt;user&gt;/.simnow/com1/simnow_out: No such file or directory.'' The best course of action is to start the simulation quickly, attach the snserial program, and then restart the simulation to see the early serial output.<br />
<br />
== Add disks == <br />
#Hit the Stop Simulation button if the simulation is running<br />
##File-&gt;Set IDE Primary Master Image<br />
###Browse to your hard drive (.HDD) image<br />
##File-&gt;Set IDE Secondary Master Image <br />
###Browse to a CD (.ISO) image<br />
#Hit Run Simulation again<br />
<br />
You should get output from the serial port scrolling in one terminal, and be able to watch the VGA output in the main window.<br />
<br />
If you used buildrom to get a BIOS image with coreboot + LAB, you'll end up at a linux prompt where you can mount the disks, etc.<br />
<br />
{{Cc-by-sa-3.0}}</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Widget:Ohloh_Project&diff=17503Widget:Ohloh Project2015-12-03T12:07:41Z<p>PatrickGeorgi: </p>
<hr />
<div>&lt;noinclude&gt;__NOTOC__<br />
This widget allows you to add '''[http://www.ohloh.net/projects/11667/widgets Ohloh Project Widgets]''' to your wiki page.<br />
<br />
It was created by [[mediawikiwiki:User:Sergey Chernyshev|Sergey Chernyshev]].<br />
<br />
To insert this widget, use the following code:<br />
<br />
&lt;nowiki&gt;{{#widget:&lt;/nowiki&gt;{{PAGENAME}}&lt;nowiki&gt;|id=mediawiki-widgets|type=thin_badge}}&lt;/nowiki&gt;<br />
<br />
== Parameters ==<br />
* '''id''' is a number or string in project profile page URL<br />
* '''type''' is a one of the following:<br />
** '''users''' - users voting button<br />
*** use optional '''style''' parameter to change the style of the voting button ('''gray''', '''red''', '''green''', '''blue''', '''rainbow''')<br />
** '''thin_badge''' (default) - Thin Badge<br />
** '''partner_badge''' - Partner Badge<br />
** '''languages''' - Languages summary<br />
** '''cocomo''' - Cocomo cost summary<br />
** '''factoids''' - Project Factoids<br />
** '''basic_stats''' - Project Stats<br />
<br />
{{Template:Copy to your site}}<br />
== Sample result ==<br />
=== Voting button ===<br />
&lt;nowiki&gt;{{#widget:&lt;/nowiki&gt;{{PAGENAME}}&lt;nowiki&gt;|id=mediawiki-widgets|type=users|style=rainbow}}&lt;/nowiki&gt;<br />
{{#widget:{{PAGENAME}}|id=mediawiki-widgets|type=users|style=rainbow}}<br />
=== Thin Badge ===<br />
&lt;nowiki&gt;{{#widget:&lt;/nowiki&gt;{{PAGENAME}}&lt;nowiki&gt;|id=mediawiki-widgets|type=thin_badge}}&lt;/nowiki&gt;<br />
{{#widget:{{PAGENAME}}|id=mediawiki-widgets|type=thin_badge}}<br />
=== Partner Badge ===<br />
&lt;nowiki&gt;{{#widget:&lt;/nowiki&gt;{{PAGENAME}}&lt;nowiki&gt;|id=mediawiki-widgets|type=partner_badge}}&lt;/nowiki&gt;<br />
{{#widget:{{PAGENAME}}|id=mediawiki-widgets|type=partner_badge}}<br />
=== Languages summary ===<br />
&lt;nowiki&gt;{{#widget:&lt;/nowiki&gt;{{PAGENAME}}&lt;nowiki&gt;|id=mediawiki-widgets|type=languages}}&lt;/nowiki&gt;<br />
{{#widget:{{PAGENAME}}|id=mediawiki-widgets|type=languages}}<br />
=== Cocomo cost summary ===<br />
&lt;nowiki&gt;{{#widget:&lt;/nowiki&gt;{{PAGENAME}}&lt;nowiki&gt;|id=mediawiki-widgets|type=cocomo}}&lt;/nowiki&gt;<br />
{{#widget:{{PAGENAME}}|id=mediawiki-widgets|type=cocomo}}<br />
=== Project Factoids ===<br />
&lt;nowiki&gt;{{#widget:&lt;/nowiki&gt;{{PAGENAME}}&lt;nowiki&gt;|id=mediawiki-widgets|type=factoids}}&lt;/nowiki&gt;<br />
{{#widget:{{PAGENAME}}|id=mediawiki-widgets|type=factoids}}<br />
=== Project Stats ===<br />
&lt;nowiki&gt;{{#widget:&lt;/nowiki&gt;{{PAGENAME}}&lt;nowiki&gt;|id=mediawiki-widgets|type=basic_stats}}&lt;/nowiki&gt;<br />
{{#widget:{{PAGENAME}}|id=mediawiki-widgets|type=basic_stats}}<br />
&lt;/noinclude&gt;&lt;includeonly&gt;&lt;!--{if $type ne 'thin_badge' and $type ne 'partner_badge' and $type ne 'languages' and $type ne 'cocomo' and $type ne 'factoids' and $type ne 'basic_stats' and $type ne 'users'}--&gt;&lt;!--{assign var='type' value='thin_badge'}--&gt;&lt;!--{/if}--&gt;&lt;script type=&quot;text/javascript&quot; src=&quot;//www.ohloh.net/projects/&lt;!--{$id|escape:'urlpathinfo'}--&gt;/widgets/project_&lt;!--{$type|escape:'urlpathinfo'|default:'thin_badge'}--&gt;&lt;!--{if isset($style) and $type eq 'users'}--&gt;?style=&lt;!--{$style|escape:'urlpathinfo'}--&gt;&lt;!--{/if}--&gt;&quot;&gt;&lt;/script&gt;&lt;/includeonly&gt;</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Welcome_to_coreboot&diff=17502Welcome to coreboot2015-12-03T11:55:56Z<p>PatrickGeorgi: </p>
<hr />
<div>&lt;table width=&quot;100%&quot; valign=&quot;top&quot;&gt;&lt;tr valign=&quot;top&quot;&gt;&lt;td width=&quot;80%&quot;&gt;<br />
<br />
&lt;div style=&quot;margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br />
'''coreboot''' is an Open Source project aimed at replacing the proprietary [http://wikipedia.org/wiki/BIOS BIOS] (firmware) found in most computers. coreboot performs a little bit of hardware initialization and then executes additional boot logic, called a [[Payloads|payload]].<br />
<br />
With the separation of hardware initialization and later boot logic, coreboot can scale from specialized applications that run directly from firmware, run operating systems in flash, load custom bootloaders, or implement firmware standards, like [[SeaBIOS | PC BIOS services]] or [[TianoCore | UEFI]]. This allows for systems to only include the features necessary in the target application, reducing the amount of code and flash space required.<br />
<br />
coreboot currently supports over '''[[Supported Motherboards|230]]''' different mainboards. Check the [[Support]] page to see if your system is supported.<br />
<br />
&lt;small&gt;<br />
coreboot was formerly known as [http://www.coreboot.org/pipermail/coreboot/2008-January/029135.html LinuxBIOS]. <br />
&lt;/small&gt;<br />
&lt;/div&gt;<br />
<br />
&lt;div style=&quot;margin-top:0.5em; margin-bottom:0.5em; padding:0.5em 0.5em 0.5em 0.5em; background-color:#efefff; align:right; border:1px solid #aabbcc;&quot;&gt;<br />
coreboot uses [[git]] for source control and [http://review.coreboot.org gerrit] as the patch review tool. Please read the [https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=Documentation/gerrit_guidelines.md;hb=HEAD gerrit etiquette] document before submitting or reviewing patches.<br />
&lt;/div&gt;<br />
<br />
{| cellspacing=0 cellpadding=8 border=0 margin=0 padding=0 align=&quot;top&quot; width=100%<br />
|-<br />
|style=&quot;vertical-align:top&quot;|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = yellow|<br />
WIDTH = 100%|<br />
ICON = &lt;small&gt;[[Benefits|More...]]&lt;/small&gt;|<br />
HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Benefits]]&lt;/span&gt;|<br />
CONTENT =<br />
&lt;small&gt;<br />
* 100% Free Software (GPL), no royalties, no license fees!<br />
* Fast boot times (500 milliseconds to verified Linux kernel)<br />
&lt;!-- * Avoids the need for a slow/buggy/proprietary BIOS --&gt;<br />
&lt;!-- * Runs in 32-Bit protected mode almost from the start --&gt;<br />
&lt;!-- * Written in C, contains virtually no assembly code --&gt;<br />
* Supports many [[Supported Motherboards|mainboards]], [[Supported Chipsets and Devices|chipsets]], and [[payloads]]<br />
&lt;!-- * Further features: netboot, serial console, remote flashing, ... --&gt;<br />
&lt;/small&gt;<br />
}}<br />
<br />
|style=&quot;vertical-align:top&quot;|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = #d1adf6|<br />
WIDTH = 100%|<br />
ICON = &lt;small&gt;[[Use Cases|More...]]&lt;/small&gt;|<br />
HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Use Cases]]&lt;/span&gt;|<br />
CONTENT =<br />
&lt;small&gt;<br />
* Desktop PCs, servers, [[Laptop|laptops]]<br />
* [[Clusters]]<br />
&lt;!-- * Set-Top-Boxes, thin clients --&gt;<br />
* Embedded solutions<br />
&lt;!-- * [http://en.wikipedia.org/wiki/Small_form_factor Small form factor computers], [http://en.wikipedia.org/wiki/Home_theater_PC Home-theater PCs] --&gt;<br />
&lt;!-- * No-moving-parts solutions (ROM chip as &quot;disk&quot;) --&gt;<br />
&lt;!-- * Non-standard scenarios (e.g. FPGA in Opteron socket) --&gt;<br />
&lt;/small&gt;<br />
}}<br />
<br />
|style=&quot;vertical-align:top&quot;|<br />
<br />
{{Box|<br />
BORDER = #8898bf|<br />
BACKGROUND = lime|<br />
WIDTH = 100%|<br />
ICON = &lt;small&gt;[[Payloads|More...]]&lt;/small&gt;|<br />
HEADING = &lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Payloads]]&lt;/span&gt;|<br />
CONTENT =<br />
&lt;small&gt;<br />
* [[SeaBIOS]] / [[FILO]] / [[GRUB2]] / [[Payloads|...]] &lt;!-- / [[OpenFirmware]] / [[OpenBIOS]] --&gt;<br />
* [[Linux]] / [[Windows]] / [[FreeBSD]] / [[NetBSD]] / [[Payloads|...]] &lt;!-- / [http://openbsd.org/ OpenBSD]--&gt;<br />
* [[Etherboot]] / [[GPXE]] / [[iPXE]] / [[Payloads|...]]<br />
&lt;!--* [[Memtest86]]<br />
* [[Bayou]] / [[Coreinfo]] / [[Tint]] / [[Libpayload]]--&gt;<br />
&lt;/small&gt;<br />
}}<br />
<br />
|}<br />
<br />
{| cellspacing=5 cellpadding=15 border=0 valign=&quot;top&quot; width=100%<br />
| width=50% style=&quot;vertical-align:top&quot;|<br />
<br />
{|<br />
|style=&quot;vertical-align:top&quot;|<br />
[[Image:chip_cb.png]]<br />
|style=&quot;vertical-align:top&quot;|<br />
'''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;About&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Find out more about coreboot.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Press]] | [[Logo]] | [[History]] | [[Screenshots|Screenshots/Videos]] | [[Contributors]] | [[Sponsors]] | [[Products]] | [[Vendors]]&lt;/small&gt;<br />
|}<br />
<br />
|style=&quot;vertical-align:top&quot;|<br />
<br />
{|<br />
|style=&quot;vertical-align:top&quot;|<br />
[[Image:chip_devel.png]]<br />
|style=&quot;vertical-align:top&quot;|<br />
'''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Developers&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Get involved! Help us make coreboot better.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Development Guidelines]] | [[Developer Manual]] | [http://qa.coreboot.org/docs/doxygen.php Doxygen] | [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree Browse Source] | [[GSoC]] | [[Where to start]] | [[Distributed and Automated Testsystem|Testsystem]]&lt;/small&gt;<br />
|}<br />
<br />
|-<br />
| width=50% style=&quot;vertical-align:top&quot;|<br />
<br />
{|<br />
|style=&quot;vertical-align:top&quot;|<br />
[[Image:chip_status.png]]<br />
|style=&quot;vertical-align:top&quot;|<br />
'''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Status&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Find out whether your hardware is already supported.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Supported Motherboards|Supported Boards]] | [[Supported Chipsets and Devices|Supported Chipsets]] | [[:Category:Tutorials|Board Status Pages]] | [[Blob Matrix|Blob Matrix]] | [http://qa.coreboot.org Build Status]&lt;/small&gt;<br />
|}<br />
<br />
|style=&quot;vertical-align:top&quot;|<br />
<br />
{|<br />
|style=&quot;vertical-align:top&quot;|<br />
[[Image:chip_tools.png]]<br />
|style=&quot;vertical-align:top&quot;|<br />
'''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Related Tools&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Tools and libraries related to coreboot.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[http://www.flashrom.org flashrom] | [[Superiotool]] | [[Nvramtool]] | [[Buildrom]] | [[Mkelfimage]] | [[Inteltool]] | [[Msrtool]] | [[Ectool]] | [[Developer_Manual/Tools|Hardware tools]] | [[Abuild]] | [http://serialice.com SerialICE]&lt;/small&gt;<br />
|}<br />
<br />
|-<br />
| width=50% style=&quot;vertical-align:top&quot;|<br />
<br />
{|<br />
|style=&quot;vertical-align:top&quot;|<br />
[[Image:chip_101.png]]<br />
|style=&quot;vertical-align:top&quot;|<br />
'''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Getting Started&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Download coreboot and get started.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[Build HOWTO]] | [[Download coreboot|Downloads]] | [[Documentation]] | [[QEMU]] | [[AMD SimNow]] | [[Build from Windows]]&lt;/small&gt;<br />
|}<br />
<br />
|style=&quot;vertical-align:top&quot;|<br />
<br />
{|<br />
|style=&quot;vertical-align:top&quot;|<br />
[[Image:chip_support.png]]<br />
|style=&quot;vertical-align:top&quot;|<br />
'''&lt;span style=&quot;font-variant:small-caps; font-size:150%&quot;&gt;Support&lt;/span&gt;'''&lt;br /&gt;&lt;small&gt;Learn how to contact us and find help and support.&lt;/small&gt;&lt;small&gt;&lt;hr /&gt;[[FAQ]] | [[Mailinglist]] | [[IRC]] | [[Glossary]] | [[coreboot Options|coreboot Options]]&lt;/small&gt;<br />
|}<br />
<br />
|}<br />
&lt;/td&gt;&lt;td width=&quot;20%&quot;&gt;<br />
<br />
[[File:Coreboot menuconfig.png|center|thumb|[[Build HOWTO|make menuconfig]] in coreboot]]<br />
<br />
&lt;br clear=all /&gt;<br />
<br />
'''&lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[http://blogs.coreboot.org News (blog)]&lt;/span&gt;'''&lt;hr /&gt;<br />
&lt;small&gt;<br />
&lt;rss max=5&gt;https://blogs.coreboot.org/feed/&lt;/rss&gt;<br />
&lt;/small&gt;<br />
<br />
<br />
'''&lt;span style=&quot;font-variant:small-caps; font-size:120%&quot;&gt;[[Current events|Events]]&lt;/span&gt;'''&lt;hr /&gt;<br />
&lt;!-- List of upcoming events (remove events after they have taken place). --&gt;<br />
&lt;small&gt;<br />
<br />
* '''2016/01''' coreboot booth at [https://fosdem.org/2016/ Fosdem 2016] in Brussels, Belgium<br />
<br />
* '''2016/??''' Hackathon Paris<br />
<br />
&lt;!-- * '''2016/06''' coreboot convention in Mountain View, USA --&gt;<br />
<br />
&lt;!-- * '''2016/09''' coreboot convention in Berlin, Germany --&gt;<br />
<br />
&lt;!-- * Currently none --&gt;<br />
&lt;!--* '''2015/mon/day:''' coreboot event at [[Link]] in somecity --&gt;<br />
&lt;/small&gt;<br />
<br />
<br />
&lt;br clear=all /&gt;<br />
{{#widget:Ohloh Project|id=coreboot|type=partner_badge}}<br />
{{#widget:Ohloh Project|id=coreboot|type=cocomo}}<br />
<br />
<br />
&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;<br />
<br />
__NOTOC__<br />
__NOEDITSECTION__</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Coreboot_conference_Bonn_2015&diff=17063Coreboot conference Bonn 20152015-10-13T13:56:44Z<p>PatrickGeorgi: /* Friday */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Coreboot_conference_Bonn_2015&diff=16988Coreboot conference Bonn 20152015-10-06T14:16:03Z<p>PatrickGeorgi: /* Friday */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Flag_Days&diff=16963Flag Days2015-10-02T10:54:10Z<p>PatrickGeorgi: </p>
<hr />
<div>This page collects sweeping changes on the tree that might have an impact on boards that weren't tested by the developer, or on uncommitted development. It's sorted by date and provides a Changelog to anyone who needs to update older trees.<br />
<br />
= 2015-07-14: commits 45acb34, 4d3e4c4, 2272b80a =<br />
The CBFS master header used to denote the alignment of files within the CBFS image. This is now hard coded to 64 bytes, which was already the default. The master header format didn't change and the field continues to be set to 64, so old code will continue to work with new images. New code will work with old images as long as their alignment is set to 64 bytes.<br />
<br />
= 2015-09-09: commit 6aa8c5bc =<br />
CONFIG_DRIVERS_PS2_KEYBOARD defaults to false now, which means that coreboot doesn't initialize PS/2 keyboards anymore (unless specifically requested). Payloads need to adapt if they can't to initialization on their own (or have it disabled under the assumption that coreboot provided for that).</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Products&diff=16667Products2015-07-27T18:15:53Z<p>PatrickGeorgi: remove obviously dead links</p>
<hr />
<div>Here's a list of vendors and their products or services related to coreboot. Please [[Mailinglist|contact us]] if you wish to add your product/company to the list. <br />
<br />
== Artec Group ==<br />
<br />
[http://www.artecgroup.com Artec Group] runs coreboot on their Geode LX based [http://www.thincan.com DBE61 ThinCan] system.<br />
<br />
== corehost ==<br />
<br />
[http://corehost.us corehost] is the first hosting provider in the world to deploy hardware that runs coreboot. You can rent virtual or dedicated servers based on hardware that runs coreboot.<br />
<br />
== coresystems GmbH ==<br />
<br />
[http://www.coresystems.de/ coresystems GmbH] is offering coreboot based services and products. If you are a hardware/appliance vendor and want your system running coreboot, contact coresystems. As a coreboot contributor, coresystems is hosting the coreboot development repository, mailing list and web page.<br />
<br />
== CW Linux ==<br />
<br />
[http://www.cwlinux.com CW Linux] offers pre-installed coreboot motherboards, SDK and related hardware for people want to use or develop applications on coreboot. It also provides professional services for custom coreboot-based system development. <br />
<br />
== Gluglug ==<br />
<br />
[http://shop.gluglug.org.uk/ Gluglug] sells laptops with [http://libreboot.org/ libreboot] (a variant of coreboot) and [https://trisquel.info/ Trisquel GNU/Linux] pre-installed. The company also offers an installation service for libreboot, where you can ship your libreboot-compatible system to the company to get it flashed.<br />
<br />
== Linutop ==<br />
<br />
[http://linutop.com/ Linutop] is going to ship coreboot on their diskless computers.<br />
<br />
== Linux Labs ==<br />
<br />
[http://www.linuxlabs.com Linux Labs] is selling [http://www.linuxlabs.com/starterclusters.html LinuxBIOS Beowulf clusters] comprised of 1U x86-based nodes with LinuxBIOS installed. <br />
<br />
== LUCIDA ==<br />
<br />
[http://www.lucidatech.com LUCIDA] is shipping several of their thin clients, e.g. the [http://www.lucidatech.com/product/lt2610.htm LT2610] and the [http://www.lucidatech.com/product/lt3712.htm LT3712] with coreboot, according to their website.<br />
<br />
== MikroTik ==<br />
<br />
[http://www.routerboard.com MikroTik] is offering the [http://216.239.59.104/search?q=cache:pT2IZCrEZEsJ:www.routerboard.com/pdf/RouterBOARD200SeriesA4-3-0.pdf+routerboard+linuxbios&amp;hl=de&amp;ct=clnk&amp;cd=1&amp;gl=de Routerboard 200 series] which seems to be shipped with coreboot (devices from other Routerboard series might use coreboot, too).<br />
<br />
== O.N.E. Technologies ==<br />
<br />
[http://www.onelabs.com/ O.N.E. Technologies] offers coreboot on all their x86 products and offers coreboot development services.<br />
<br />
== Sage Electronic Engineering ==<br />
<br />
[http://se-eng.com Sage Electronic Engineering] has developed the Sage SmartProbe and EDK for AMD systems development and debug. Sage also offers coreboot, Linux, and systems development services.<br />
<br />
== Silicon Mechanics ==<br />
<br />
[http://siliconmechanics.com Silicon Mechanics] will ship their [http://www.siliconmechanics.com/i7045/opteron-server.php Rackform nServ A236] with coreboot preinstalled if requested. See [http://coreboot.org/News#2008.2F04.2F04_Silicon_Mechanics_to_ship_servers_with_coreboot_preinstalled our news item from 2008/04/04]. The [http://www.siliconmechanics.com/i9226/quad-core-opteron.php Rackform nServ A255] uses the same motherboard, and is also available with coreboot.<br />
<br />
== TechNexion ==<br />
<br />
[http://www.technexion.com/ TechNexion] offers [http://www.technexion.com/index.php/amd-linux-solutions embedded mainboards with coreboot] which have 32Mbit (4Mbyte) boot flash so that a Linux kernel can easily be used as payload.<br />
<br />
== VIA ==<br />
<br />
[http://www.via.com.tw VIA] is helping the coreboot community support new EPIA mainboards and VIA chipsets with several code donations and open programming guides. With key input from VIA, coreboot will soon support over 30 Mini-ITX mainboards. These mainboards are made by VIA, Jetway, Phitronics and MSI featuring the VIA C7 CPU, CN700 and VT8237 chipset.<br />
<br />
The [http://linux.via.com.tw/support/downloadFiles.action Linux VIA Portal] aims to expand cooperation with open source communities by providing drivers, chipset programming manuals and source code for select Linux distributions to technical software developers.<br />
<br />
__NOTOC__</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Datasheets&diff=16656Datasheets2015-07-22T20:16:23Z<p>PatrickGeorgi: /* AMD Fam16 */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Flag_Days&diff=16652Flag Days2015-07-20T23:30:57Z<p>PatrickGeorgi: </p>
<hr />
<div>This page collects sweeping changes on the tree that might have an impact on boards that weren't tested by the developer, or on uncommitted development. It's sorted by date and provides a Changelog to anyone who needs to update older trees.<br />
<br />
= 2015-07-14: commits 45acb34, 4d3e4c4, 2272b80a =<br />
The CBFS master header used to denote the alignment of files within the CBFS image. This is now hard coded to 64 bytes, which was already the default. The master header format didn't change and the field continues to be set to 64, so old code will continue to work with new images. New code will work with old images as long as their alignment is set to 64 bytes.</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Download_coreboot&diff=16618Download coreboot2015-07-13T20:11:36Z<p>PatrickGeorgi: /* Releases */</p>
<hr />
<div>__NOTOC__<br />
<br />
= Releases =<br />
<br />
coreboot provides no binaries, but there exist some distributions that do so, see [[#coreboot_distributions|below]].<br />
<br />
There are source code releases on http://coreboot.org/releases/<br />
<br />
= Accessing the source code through git =<br />
<br />
coreboot uses git and gerrit for source code management. Please see the [[Git]] page on how to work with git and gerrit in coreboot.<br />
<br />
Previously the project used the subversion SCM, some links to it may still be referred to, but are definitely outdated.<br />
<br />
== Source code browsing ==<br />
<br />
You can browse the coreboot Git repository online using [http://review.coreboot.org/gitweb?p=coreboot.git gitweb] including its [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree tree view] for accessing the files.<br />
<br />
= coreboot distributions =<br />
<br />
While not officially part of the coreboot project, there exist some projects that distribute pre-built (tested) ROM images along with build scripts and user-focused documentation. These &quot;distros&quot; of coreboot will also typically include copies of the source code (or links where to find it) for the version of coreboot used along with payloads such as SeaBIOS, GRUB and so on.<br />
<br />
'''Libreboot'''<br />
* Deblobbed coreboot, officially supporting a handful of devices.<br />
* [http://libreboot.org/ libreboot.org]<br />
<br />
'''John Lewis'''<br />
* Provides coreboot images for several Chromebooks<br />
* [https://johnlewis.ie/custom-chromebook-firmware/rom-download/ johnlewis.ie]<br />
<br />
= Repositories on coreboot.org =<br />
<br />
'''coreboot current Git tree:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
'''coreboot v1 (obsolete):'''<br />
* svn://coreboot.org/coreboot/branches/coreboot-v1<br />
* &lt;nowiki&gt;https://svn.coreboot.org/coreboot/branches/coreboot-v1&lt;/nowiki&gt;<br />
<br />
'''coreboot v3 (obsolete):'''<br />
* svn://coreboot.org/repository/coreboot-v3<br />
* &lt;nowiki&gt;https://svn.coreboot.org/repository/coreboot-v3&lt;/nowiki&gt;<br />
<br />
'''[[FILO]]:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/filo.git&lt;/nowiki&gt;<br />
<br />
'''[[Buildrom]]:'''<br />
* svn://coreboot.org/buildrom/<br />
* &lt;nowiki&gt;https://svn.coreboot.org/buildrom/&lt;/nowiki&gt;<br />
<br />
'''[[Distributed and Automated Testsystem]]:'''<br />
* svn://coreboot.org/testsystem<br />
* &lt;nowiki&gt;https://svn.coreboot.org/testsystem/&lt;/nowiki&gt;</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Download_coreboot&diff=16617Download coreboot2015-07-13T18:20:19Z<p>PatrickGeorgi: </p>
<hr />
<div>__NOTOC__<br />
<br />
= Releases =<br />
<br />
coreboot provides no binaries, but there exist some distributions that do so, see [[#coreboot_distributions|below]].<br />
<br />
= Accessing the source code through git =<br />
<br />
coreboot uses git and gerrit for source code management. Please see the [[Git]] page on how to work with git and gerrit in coreboot.<br />
<br />
Previously the project used the subversion SCM, some links to it may still be referred to, but are definitely outdated.<br />
<br />
== Source code browsing ==<br />
<br />
You can browse the coreboot Git repository online using [http://review.coreboot.org/gitweb?p=coreboot.git gitweb] including its [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree tree view] for accessing the files.<br />
<br />
= coreboot distributions =<br />
<br />
While not officially part of the coreboot project, there exist some projects that distribute pre-built (tested) ROM images along with build scripts and user-focused documentation. These &quot;distros&quot; of coreboot will also typically include copies of the source code (or links where to find it) for the version of coreboot used along with payloads such as SeaBIOS, GRUB and so on.<br />
<br />
'''Libreboot'''<br />
* Deblobbed coreboot, officially supporting a handful of devices.<br />
* [http://libreboot.org/ libreboot.org]<br />
<br />
'''John Lewis'''<br />
* Provides coreboot images for several Chromebooks<br />
* [https://johnlewis.ie/custom-chromebook-firmware/rom-download/ johnlewis.ie]<br />
<br />
= Repositories on coreboot.org =<br />
<br />
'''coreboot current Git tree:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
'''coreboot v1 (obsolete):'''<br />
* svn://coreboot.org/coreboot/branches/coreboot-v1<br />
* &lt;nowiki&gt;https://svn.coreboot.org/coreboot/branches/coreboot-v1&lt;/nowiki&gt;<br />
<br />
'''coreboot v3 (obsolete):'''<br />
* svn://coreboot.org/repository/coreboot-v3<br />
* &lt;nowiki&gt;https://svn.coreboot.org/repository/coreboot-v3&lt;/nowiki&gt;<br />
<br />
'''[[FILO]]:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/filo.git&lt;/nowiki&gt;<br />
<br />
'''[[Buildrom]]:'''<br />
* svn://coreboot.org/buildrom/<br />
* &lt;nowiki&gt;https://svn.coreboot.org/buildrom/&lt;/nowiki&gt;<br />
<br />
'''[[Distributed and Automated Testsystem]]:'''<br />
* svn://coreboot.org/testsystem<br />
* &lt;nowiki&gt;https://svn.coreboot.org/testsystem/&lt;/nowiki&gt;</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Download_coreboot&diff=16616Download coreboot2015-07-13T18:17:31Z<p>PatrickGeorgi: </p>
<hr />
<div>__NOTOC__<br />
<br />
= Releases =<br />
<br />
coreboot provides no binaries, but there exist some distributions that do so, see [[#coreboot_distributions|below]].<br />
<br />
= Git =<br />
<br />
coreboot uses Git and gerrit for source code management. Please see the [[Git]] page on how to work with Git and gerrit in coreboot.<br />
<br />
Previously the project used the subversion SCM, some links to it may still be referred to, but are definitely outdated.<br />
<br />
== Source code browsing ==<br />
<br />
You can browse the coreboot Git repository online using [http://review.coreboot.org/gitweb?p=coreboot.git gitweb] including its [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree tree view] for accessing the files.<br />
<br />
= coreboot distributions =<br />
<br />
While not officially part of the coreboot project, there exist some projects that distribute pre-built (tested) ROM images along with build scripts and user-focused documentation. These &quot;distros&quot; of coreboot will also typically include copies of the source code (or links where to find it) for the version of coreboot used along with payloads such as SeaBIOS, GRUB and so on.<br />
<br />
'''Libreboot'''<br />
* Deblobbed coreboot, officially supporting a handful of devices.<br />
* [http://libreboot.org/ libreboot.org]<br />
<br />
'''John Lewis'''<br />
* Provides coreboot images for several Chromebooks<br />
* [https://johnlewis.ie/custom-chromebook-firmware/rom-download/ johnlewis.ie]<br />
<br />
= Repositories on coreboot.org =<br />
<br />
'''coreboot current Git tree:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
'''coreboot v1 (obsolete):'''<br />
* svn://coreboot.org/coreboot/branches/coreboot-v1<br />
* &lt;nowiki&gt;https://svn.coreboot.org/coreboot/branches/coreboot-v1&lt;/nowiki&gt;<br />
<br />
'''coreboot v3 (obsolete):'''<br />
* svn://coreboot.org/repository/coreboot-v3<br />
* &lt;nowiki&gt;https://svn.coreboot.org/repository/coreboot-v3&lt;/nowiki&gt;<br />
<br />
'''[[FILO]]:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/filo.git&lt;/nowiki&gt;<br />
<br />
'''[[Buildrom]]:'''<br />
* svn://coreboot.org/buildrom/<br />
* &lt;nowiki&gt;https://svn.coreboot.org/buildrom/&lt;/nowiki&gt;<br />
<br />
'''[[Distributed and Automated Testsystem]]:'''<br />
* svn://coreboot.org/testsystem<br />
* &lt;nowiki&gt;https://svn.coreboot.org/testsystem/&lt;/nowiki&gt;</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Download_coreboot&diff=16615Download coreboot2015-07-13T18:17:09Z<p>PatrickGeorgi: </p>
<hr />
<div>__NOTOC__<br />
'''Note: These snapshots are for people, who use Linux as operating system and are able to build software from the source code.''' <br />
<br />
= Releases =<br />
<br />
coreboot provides no binaries, but there exist some distributions that do so, see [[#coreboot_distributions|below]].<br />
<br />
= Git =<br />
<br />
coreboot uses Git and gerrit for source code management. Please see the [[Git]] page on how to work with Git and gerrit in coreboot.<br />
<br />
Previously the project used the subversion SCM, some links to it may still be referred to, but are definitely outdated.<br />
<br />
== Source code browsing ==<br />
<br />
You can browse the coreboot Git repository online using [http://review.coreboot.org/gitweb?p=coreboot.git gitweb] including its [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree tree view] for accessing the files.<br />
<br />
= coreboot distributions =<br />
<br />
While not officially part of the coreboot project, there exist some projects that distribute pre-built (tested) ROM images along with build scripts and user-focused documentation. These &quot;distros&quot; of coreboot will also typically include copies of the source code (or links where to find it) for the version of coreboot used along with payloads such as SeaBIOS, GRUB and so on.<br />
<br />
'''Libreboot'''<br />
* Deblobbed coreboot, officially supporting a handful of devices.<br />
* [http://libreboot.org/ libreboot.org]<br />
<br />
'''John Lewis'''<br />
* Provides coreboot images for several Chromebooks<br />
* [https://johnlewis.ie/custom-chromebook-firmware/rom-download/ johnlewis.ie]<br />
<br />
= Repositories on coreboot.org =<br />
<br />
'''coreboot current Git tree:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
'''coreboot v1 (obsolete):'''<br />
* svn://coreboot.org/coreboot/branches/coreboot-v1<br />
* &lt;nowiki&gt;https://svn.coreboot.org/coreboot/branches/coreboot-v1&lt;/nowiki&gt;<br />
<br />
'''coreboot v3 (obsolete):'''<br />
* svn://coreboot.org/repository/coreboot-v3<br />
* &lt;nowiki&gt;https://svn.coreboot.org/repository/coreboot-v3&lt;/nowiki&gt;<br />
<br />
'''[[FILO]]:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/filo.git&lt;/nowiki&gt;<br />
<br />
'''[[Buildrom]]:'''<br />
* svn://coreboot.org/buildrom/<br />
* &lt;nowiki&gt;https://svn.coreboot.org/buildrom/&lt;/nowiki&gt;<br />
<br />
'''[[Distributed and Automated Testsystem]]:'''<br />
* svn://coreboot.org/testsystem<br />
* &lt;nowiki&gt;https://svn.coreboot.org/testsystem/&lt;/nowiki&gt;</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Download_coreboot&diff=16614Download coreboot2015-07-13T18:16:30Z<p>PatrickGeorgi: </p>
<hr />
<div>__NOTOC__<br />
'''Note: These snapshots are for people, who use Linux as operating system and are able to build software from the source code.''' <br />
<br />
= Releases =<br />
<br />
coreboot provides no binaries, but there exist some distributions that do so, see [[#coreboot_distributions|below]].<br />
<br />
= Git =<br />
<br />
coreboot uses Git and gerrit for source code management. Please see the [[Git]] page on how to work with Git and gerrit in coreboot.<br />
<br />
Previously the project used the subversion SCM, some links to it may still be referred to, but are definitely outdated.<br />
<br />
== Source code browsing ==<br />
<br />
You can browse the coreboot Git repository online using [http://review.coreboot.org/gitweb?p=coreboot.git gitweb] including its [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree tree view] for accessing the files.<br />
<br />
== Repositories on coreboot.org ==<br />
<br />
'''coreboot current Git tree:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
'''coreboot v1 (obsolete):'''<br />
* svn://coreboot.org/coreboot/branches/coreboot-v1<br />
* &lt;nowiki&gt;https://svn.coreboot.org/coreboot/branches/coreboot-v1&lt;/nowiki&gt;<br />
<br />
'''coreboot v3 (obsolete):'''<br />
* svn://coreboot.org/repository/coreboot-v3<br />
* &lt;nowiki&gt;https://svn.coreboot.org/repository/coreboot-v3&lt;/nowiki&gt;<br />
<br />
'''[[FILO]]:'''<br />
* &lt;nowiki&gt;http://review.coreboot.org/filo.git&lt;/nowiki&gt;<br />
<br />
'''[[Buildrom]]:'''<br />
* svn://coreboot.org/buildrom/<br />
* &lt;nowiki&gt;https://svn.coreboot.org/buildrom/&lt;/nowiki&gt;<br />
<br />
'''[[Distributed and Automated Testsystem]]:'''<br />
* svn://coreboot.org/testsystem<br />
* &lt;nowiki&gt;https://svn.coreboot.org/testsystem/&lt;/nowiki&gt;<br />
<br />
= coreboot distributions =<br />
<br />
While not officially part of the coreboot project, there exist some projects that distribute pre-built (tested) ROM images along with build scripts and user-focused documentation. These &quot;distros&quot; of coreboot will also typically include copies of the source code (or links where to find it) for the version of coreboot used along with payloads such as SeaBIOS, GRUB and so on.<br />
<br />
'''Libreboot'''<br />
* Deblobbed coreboot, officially supporting a handful of devices.<br />
* [http://libreboot.org/ libreboot.org]<br />
<br />
'''John Lewis'''<br />
* Provides coreboot images for several Chromebooks<br />
* [https://johnlewis.ie/custom-chromebook-firmware/rom-download/ johnlewis.ie]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Git&diff=16613Git2015-07-13T18:00:07Z<p>PatrickGeorgi: </p>
<hr />
<div>= Accessing the repository =<br />
The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularly interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for &quot;Smart HTTP&quot; transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.<br />
<br />
git clone &lt;nowiki&gt;http://review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
git clone &lt;nowiki&gt;ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot&lt;/nowiki&gt;<br />
<br />
Inside the checkout you should install a commit-msg hook that adds a Change-Id into commit messages, which uniquely identifies the logical change in Gerrit even across multiple iterations of the commit. The hook only needs to be installed once per clone, and installation can be done with<br />
<br />
wget -O .git/hooks/commit-msg &lt;nowiki&gt;http://review.coreboot.org/tools/hooks/commit-msg&lt;/nowiki&gt; &amp;&amp; \<br />
chmod +x .git/hooks/commit-msg<br />
<br />
Or you can also just run<br />
<br />
make gitconfig<br />
<br />
= Working with Git =<br />
<br />
Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065422.html a Git introduction] after the switch to Git had been announced on the mailing list.<br />
<br />
This section provides some more details on how to format commits so they match our style, which happens all locally on your development machine. For information on how to contribute these changes to the project, see the section below on the code review tool we use, [[Git#Gerrit|Gerrit]].<br />
<br />
== Commit messages ==<br />
Git does not enforce a commit message style, although perhaps it should. For all aspects of Git to work the best, it's important to follow these simple guidelines for commit messages:<br />
<br />
# The first line of the commit message has a short (less than 65 characters, absolute maximum is 75) summary<br />
# The second line is empty (no whitespace at all)<br />
# The third and any number of following lines contain a longer description of the commit as is neccessary, including relevant background information and quite possibly rationale for why the issue was solved in this particular way. These lines should never be longer than 75 characters.<br />
# The next line is empty (no whitespace at all)<br />
# A Change-Id: line to let gerrit track this logical change<br />
# A Signed-off-by: line according to [[Development_Guidelines#Sign-off_Procedure|the development guidelines]]<br />
<br />
Please do not create Change-Id: and Signed-off-by: manually because it is boring and error-prone. Instead, please install the commit-msg hook as described [[#Accessing_the_repository|above]], and remember to always use '''git commit -s''' to have git add your Signed-off-by: automatically.<br />
<br />
Here is an example of a well-formatted commit message:<br />
examplecomponent: Refactor duplicated setup into a function<br />
<br />
Setting up the demo device correctly requires the exact same register<br />
values to be written into each of the PCI device functions. Moving the<br />
writes into a function allows also otherexamplecomponent to use them.<br />
<br />
Signed-off-by: Joe Hacker &lt;joe@hacker.email&gt;<br />
<br />
The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.<br />
<br />
=== Guidelines on commit message content ===<br />
<br />
* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without needing to analyze the code code.<br />
* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:<br />
git show<br />
<br />
== Pushing changes ==<br />
You need to have an authenticated connection to review.coreboot.org setup. With ssh, you always need to authenticate with your username, so you're all set. For http, fetch the [http://review.coreboot.org/#settings,http-password http password] and edit (maybe create) a file called .netrc in your home directory ($HOME or ~). In this file, create a line containing<br />
<br />
machine review.coreboot.org login &lt;username&gt; password &lt;http password&gt;<br />
<br />
Then run the following command once, to tell git that by default you want to submit all commits in the currently checked-out branch for review on gerrit:<br />
<br />
git config remote.origin.push HEAD:refs/for/master<br />
<br />
After this, the command to push your changes is:<br />
<br />
git push origin<br />
<br />
If you always push from the same or a few branches the workflow can be simplified further by running once for each branch:<br />
<br />
git config branch.&lt;particularbranchname&gt;.remote origin<br />
<br />
...after which you then push changes with any of the configured branches checked out with a simple:<br />
<br />
git push<br />
<br />
Pushing several commits not yet in the coreboot repository at once will create one review request on gerrit per commit. <br />
<br />
'''NB!''' If you have applied patches from gerrit on a branch and you later push that branch, gerrit will think that you are submitting new versions of the patches that you had applied. This may or may not be what you intend. You can always run<br />
<br />
git log origin/master..<br />
<br />
before '''git push''' to verify which commits you are about to send for review.<br />
<br />
For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].<br />
<br />
== Pushing Drafts ==<br />
git push origin HEAD:refs/drafts/master<br />
== Pushing to Topics ==<br />
git push origin HEAD:refs/for/master/i915-kernel-x60<br />
will push to the i915-kernel-x60 topic.<br />
<br />
== Evolving patches ==<br />
<br />
Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.<br />
<br />
You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, <br />
<br />
git rebase -i master<br />
<br />
then commit and push the updated patch.<br />
<br />
Alternatively, you may amend your local commit and push the updated patch to gerrit:<br />
<br />
git add &lt;path/to/updated/files&gt;<br />
git commit --amend<br />
<br />
then push the updated patch.<br />
<br />
== Further Git reading ==<br />
There are tons of git tutorials out there. Take a look at some of these documents:<br />
* http://git-scm.com/<br />
* http://www.kernel.org/pub/software/scm/git/docs/v1.7.5.4/gittutorial.html<br />
* http://git.or.cz/course/svn.html<br />
* and in particular the [http://progit.org/ Pro Git book]<br />
<br />
Please also feel free to ask Git questions in the [[IRC|coreboot IRC channel]] or on the [[Mailinglist|mailing list]].<br />
<br />
= Browsing the sources =<br />
<br />
See http://review.coreboot.org/gitweb?p=coreboot.git<br />
<br />
= Gerrit =<br />
We use Gerrit on http://review.coreboot.org/ for code review.<br />
<br />
== Register with gerrit ==<br />
For authenticated access (to submit patches) you'll need a gerrit account which you can register at http://review.coreboot.org/.<br />
You also need to add your ssh key(s) (used for authenticating your connections to the repo) and your email address(es) (used to match up Signed-off-by: statements) to your gerrit user data at http://review.coreboot.org/#settings.<br />
<br />
=== OpenID and OAuth2 ===<br />
Gerrit uses OpenID and OAuth2 for authentication. Besides many large web services that provide OpenID identity services (eg. Yahoo), you can run your own, if you want. We support OAuth2 for Google and GitHub accounts.<br />
<br />
Once you have an account, you can link additional identity providers on http://review.coreboot.org/#/settings/web-identities (&quot;Link Another Identity&quot;). Any of these accounts can then be used to access your account. If you simply login with each of the identities, different accounts on gerrit are created, which is probably not the intention.<br />
<br />
Note that gerrit is a bit picky about the OpenID format. Always provide a full URL, including protocol (http:// or https:// prefix). Unfortunately the error messages are non-intuitive.<br />
<br />
== Gerrit workflow ==<br />
Gerrit interprets each Git commit as an individual change. Changes are autobuilt by [http://qa.coreboot.org/ Jenkins], and can be reviewed by developers. Once a change has gotten a positive review and has no build issues, it is applied to the master branch. Thus, no developer directly pushes to master.<br />
<br />
Reviews grant points on a scale from -2 to 2. The meaning is:<br />
* -2: Do not merge (blocks gerrit from merging)<br />
* -1: I'd prefer you don't merge it<br />
* 0: neutral<br />
* +1: Looks good, but I won't make the last call on it<br />
* +2: Looks good, go ahead and merge (gerrit provides a &quot;submit&quot; function to developers once it has a +2 vote)<br />
<br />
-2 is only available to core developers since it has veto power. Contributors with more activity than a one-off commit can request (eg. on IRC) to be added to the Reviewers group which has extended permissions (eg giving +2) over the default access level.<br />
<br />
=== Gerrit and CLI ===<br />
Reviews normally happens through the website.<br />
<br />
Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled. You can find the official Gerrit documentation about its CLI tools [https://gerrit-review.googlesource.com/Documentation/cmd-index.html here].<br />
<br />
=== Gerrit and Email ===<br />
Gerrit has no email integration. We extended it to send a couple of notifications to the coreboot-gerrit mailing list.</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Git&diff=16612Git2015-07-13T17:51:53Z<p>PatrickGeorgi: </p>
<hr />
<div>= Accessing the repository =<br />
The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularly interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for &quot;Smart HTTP&quot; transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.<br />
<br />
git clone ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot<br />
<br />
git clone &lt;nowiki&gt;http://[&lt;username&gt;:&lt;password&gt;@]review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
Inside the checkout you should install a commit-msg hook that adds a Change-Id into commit messages, which uniquely identifies the logical change in Gerrit even across multiple iterations of the commit. The hook only needs to be installed once per clone, and installation can be done with<br />
<br />
wget -O .git/hooks/commit-msg &lt;nowiki&gt;http://review.coreboot.org/tools/hooks/commit-msg&lt;/nowiki&gt; &amp;&amp; \<br />
chmod +x .git/hooks/commit-msg<br />
<br />
Or you can also just run<br />
<br />
make gitconfig<br />
<br />
= Working with Git =<br />
<br />
Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065422.html a Git introduction] after the switch to Git had been announced on the mailing list.<br />
<br />
This section provides some more details on how to format commits so they match our style, which happens all locally on your development machine. For information on how to contribute these changes to the project, see the section below on the code review tool we use, [[Git#Gerrit|Gerrit]].<br />
<br />
== Commit messages ==<br />
Git does not enforce a commit message style, although perhaps it should. For all aspects of Git to work the best, it's important to follow these simple guidelines for commit messages:<br />
<br />
# The first line of the commit message has a short (less than 65 characters, absolute maximum is 75) summary<br />
# The second line is empty (no whitespace at all)<br />
# The third and any number of following lines contain a longer description of the commit as is neccessary, including relevant background information and quite possibly rationale for why the issue was solved in this particular way. These lines should never be longer than 75 characters.<br />
# The next line is empty (no whitespace at all)<br />
# A Change-Id: line to let gerrit track this logical change<br />
# A Signed-off-by: line according to [[Development_Guidelines#Sign-off_Procedure|the development guidelines]]<br />
<br />
Please do not create Change-Id: and Signed-off-by: manually because it is boring and error-prone. Instead, please install the commit-msg hook as described [[#Accessing_the_repository|above]], and remember to always use '''git commit -s''' to have git add your Signed-off-by: automatically.<br />
<br />
Here is an example of a well-formatted commit message:<br />
examplecomponent: Refactor duplicated setup into a function<br />
<br />
Setting up the demo device correctly requires the exact same register<br />
values to be written into each of the PCI device functions. Moving the<br />
writes into a function allows also otherexamplecomponent to use them.<br />
<br />
Signed-off-by: Joe Hacker &lt;joe@hacker.email&gt;<br />
<br />
The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.<br />
<br />
=== Guidelines on commit message content ===<br />
<br />
* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without analyzing the code.<br />
* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:<br />
git show<br />
<br />
== Pushing changes ==<br />
First ensure that the git remote you want to use for pushing refers to an ssh:// URL (see [[Git#Authenticated read/write access|Authenticated read/write access]] above). If you need to change this after the fact, ie. if you registered on gerrit only after having cloned anonymously, you can. Assuming that your remote is called ''origin'' (this is the default) you can run:<br />
<br />
git config remote.origin.url ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot<br />
<br />
Then run the following command once, to tell git that by default you want to submit all commits in the currently checked-out branch for review on gerrit:<br />
<br />
git config remote.origin.push HEAD:refs/for/master<br />
<br />
After this, the command to push your changes is:<br />
<br />
git push origin<br />
<br />
If you always push from the same or a few branches the workflow can be simplified further by running once for each branch:<br />
<br />
git config branch.&lt;particularbranchname&gt;.remote origin<br />
<br />
...after which you then push changes with any of the configured branches checked out with a simple:<br />
<br />
git push<br />
<br />
Pushing several commits not yet in the coreboot repository at once will create one review request on gerrit per commit. <br />
<br />
'''NB!''' If you have applied patches from gerrit on a branch and you later push that branch, gerrit will think that you are submitting new versions of the patches that you had applied. This may or may not be what you intend. You can always run<br />
<br />
git log origin/master..<br />
<br />
before '''git push''' to verify which commits you are about to send for review.<br />
<br />
For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].<br />
<br />
== Pushing Drafts ==<br />
git push origin HEAD:refs/drafts/master<br />
== Pushing to Topics ==<br />
git push origin HEAD:refs/for/master/i915-kernel-x60<br />
will push to the i915-kernel-x60 topic.<br />
<br />
== Evolving patches ==<br />
<br />
Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.<br />
<br />
You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, <br />
<br />
git rebase -i master<br />
<br />
then commit and push the updated patch.<br />
<br />
Alternatively, you may amend your local commit and push the updated patch to gerrit:<br />
<br />
git add &lt;path/to/updated/files&gt;<br />
git commit --amend<br />
<br />
then push the updated patch.<br />
<br />
== Further Git reading ==<br />
There are tons of git tutorials out there. Take a look at some of these documents:<br />
* http://git-scm.com/<br />
* http://www.kernel.org/pub/software/scm/git/docs/v1.7.5.4/gittutorial.html<br />
* http://git.or.cz/course/svn.html<br />
* and in particular the [http://progit.org/ Pro Git book]<br />
<br />
Please also feel free to ask Git questions in the [[IRC|coreboot IRC channel]] or on the [[Mailinglist|mailing list]].<br />
<br />
= Browsing the sources =<br />
<br />
See http://review.coreboot.org/gitweb?p=coreboot.git<br />
<br />
= Gerrit =<br />
We use Gerrit on http://review.coreboot.org/ for code review.<br />
<br />
== Register with gerrit ==<br />
For authenticated access (to submit patches) you'll need a gerrit account which you can register at http://review.coreboot.org/.<br />
You also need to add your ssh key(s) (used for authenticating your connections to the repo) and your email address(es) (used to match up Signed-off-by: statements) to your gerrit user data at http://review.coreboot.org/#settings.<br />
<br />
=== OpenID and OAuth2 ===<br />
Gerrit uses OpenID and OAuth2 for authentication. Besides many large web services that provide OpenID identity services (eg. Yahoo), you can run your own, if you want. We support OAuth2 for Google and GitHub accounts.<br />
<br />
Once you have an account, you can link additional identity providers on http://review.coreboot.org/#/settings/web-identities (&quot;Link Another Identity&quot;). Any of these accounts can then be used to access your account. If you simply login with each of the identities, different accounts on gerrit are created, which is probably not the intention.<br />
<br />
Note that gerrit is a bit picky about the OpenID format. Always provide a full URL, including protocol (http:// or https:// prefix). Unfortunately the error messages are non-intuitive.<br />
<br />
== Gerrit workflow ==<br />
Gerrit interprets each Git commit as an individual change. Changes are autobuilt by [http://qa.coreboot.org/ Jenkins], and can be reviewed by developers. Once a change has gotten a positive review and has no build issues, it is applied to the master branch. Thus, no developer directly pushes to master.<br />
<br />
Reviews grant points on a scale from -2 to 2. The meaning is:<br />
* -2: Do not merge (blocks gerrit from merging)<br />
* -1: I'd prefer you don't merge it<br />
* 0: neutral<br />
* +1: Looks good, but I won't make the last call on it<br />
* +2: Looks good, go ahead and merge (gerrit provides a &quot;submit&quot; function to developers once it has a +2 vote)<br />
<br />
-2 is only available to core developers since it has veto power. Contributors with more activity than a one-off commit can request (eg. on IRC) to be added to the Reviewers group which has extended permissions (eg giving +2) over the default access level.<br />
<br />
=== Gerrit and CLI ===<br />
Reviews normally happens through the website.<br />
<br />
Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled. You can find the official Gerrit documentation about its CLI tools [https://gerrit-review.googlesource.com/Documentation/cmd-index.html here].<br />
<br />
=== Gerrit and Email ===<br />
Gerrit has poor email integration (in fact, it doesn't really have any at all). We send a couple of notifications to the mailing list, but that is a coreboot specific extension. Peter intends to build a mail-to-gerrit gateway should the need arise.<br />
<br />
This gateway will provide:<br />
* no patch submission mechanism (&quot;git push&quot; is CLI friendly)<br />
* patch review (maybe openpgp signed &quot;Acked-by&quot; mails)<br />
* patch submission (automatically with Acked-by?)<br />
* maybe patch rejection? (openpgp signed &quot;Nacked-by&quot; mails)</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=End_of_life&diff=16601End of life2015-07-11T13:21:47Z<p>PatrickGeorgi: /* Examples */</p>
<hr />
<div>== Summary ==<br />
'''End of life''' ('''EOL''') is a known marketing term. It is used in this wiki specifically to describe '''motherboard manufacturing lifespan'''.<br />
<br />
End of boards can often still be found second hand. But this isn't very convenient.<br />
<br />
== Workaround ==<br />
ThinkPenguin.com said &quot;There might be an expensive solution to this problem of motherboards being discontinued before anybody can get Coreboot working on them. There are industrial grade boards that have a multi-year life-spans as opposed to the short six to nine month life-span of consumer grade boards. I'm not saying server boards. I'm saying &quot;industrial boards&quot;. They could be designed for use in point of sale machines and similar- not just for use in servers. They aren't necessarily faster/more powerful/etc like you might want in a server.<br />
<br />
What I was thinking of as a &quot;industrial board&quot; was essentially a motherboard that would continue to be produced over a long period of time.<br />
<br />
I have an example of that here, but I might actually be misinterpreting the info:<br />
<br />
http://www.supermicro.com/products/motherboard/Core/Q87/X10SLV-Q.cfm<br />
<br />
Reregarding say for GIGABYTE Ultra Durable, I think they are talking about the quality when they refer to lifespan here. Not the product lifecycle (ie how long it'll be manufactured/available for sale). <br />
<br />
<br />
So this board has a &quot;7 year product life&quot;. My interpretation of that is it'll continue to be manufactured and made available for purchase for a period of 7 years. Most consumer motherboards are only manufactured and made available for retail sale for a period of 6-9 months before they're discontinued. After that major stocks are depleted and chances are you won't be able to locate any significant quantities other than what might be lying around for future repairs, etc (for example a computer repair shop might maintain a few extra boards to cover warranty repairs). If they decide that they no longer need the stock as there were few repairs after a few years they might unload that stock (ie put 2-3 on ebay, etc).<br />
<br />
Now a company can't really guarantee that there will be no changes whatsoever as everybody is dependent on other companies. There is a supply chain. If you can't get certain chips because the company upstream of you discontinued the chip then certainly you can't manufacture more of the same board with that chip. But in any event the idea is that there will be minimal changes, and certain long-life chipsets will be used so that things like drivers won't need to change generally speaking. This ensures you can release a product today and 5 years down the road you can still swap the board without updating the OS/kernel/drivers. <br />
<br />
<br />
I'm not myself intimately familiar with industrial-type manufacturing processes. I've only looked into it to the extent that we've needed to in an effort to support other companies looking to build GNU/Linux based products. <br />
<br />
<br />
If you can get Coreboot working on one of these motherboards then there is a chance of making this happen. I think its like a 7-year period too. Of course selling a 3-year old board isn't going to sit well with a lot of people. Particularly at significantly higher prices than what they're use to seeing, it might be twice the price for the board mind you.<br />
<br />
<br />
The other option is to simply jump ship on X86 and avoid the BIOS issue altogether. I think this is the best approach. However its not a total solution as you'll still find issues with things like proprietary stage-1 boot loaders and non-free graphics (and in some cases like with the Raspberry Pi it won't even boot without this piece).<br />
<br />
But a computer need a BIOS to boot into say GRUB, right? An x86 system does. You can look at mini ARM boards though and this is not the same. They'll have a stage-1 and stage-2 bootloader, but no BIOS per say.&quot;<br />
<br />
== Examples ==<br />
* http://www.freescale.com/productlongevity<br />
* http://www.kontron.com/products/boards-and-standard-form-factors/motherboards/mini-itx/ktqm77-mitx.html (sells for 7 years) and its support in http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/mainboard/kontron/ktqm77;hb=HEAD<br />
* http://www.amd.com/en-us/products/embedded/processors/g-series (&quot;minimum availability of ten years&quot;, eBrazos until 2021, eKabini into 2024)<br />
* http://www.amd.com/en-gb/products/embedded/processors/r-series (&quot;minimum availability of five years&quot; for eTrinity into 2018, &quot;minimum availability of 10 years&quot; for Bald Eagle until 2024)</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=End_of_life&diff=16600End of life2015-07-11T13:17:07Z<p>PatrickGeorgi: </p>
<hr />
<div>== Summary ==<br />
'''End of life''' ('''EOL''') is a known marketing term. It is used in this wiki specifically to describe '''motherboard manufacturing lifespan'''.<br />
<br />
End of boards can often still be found second hand. But this isn't very convenient.<br />
<br />
== Workaround ==<br />
ThinkPenguin.com said &quot;There might be an expensive solution to this problem of motherboards being discontinued before anybody can get Coreboot working on them. There are industrial grade boards that have a multi-year life-spans as opposed to the short six to nine month life-span of consumer grade boards. I'm not saying server boards. I'm saying &quot;industrial boards&quot;. They could be designed for use in point of sale machines and similar- not just for use in servers. They aren't necessarily faster/more powerful/etc like you might want in a server.<br />
<br />
What I was thinking of as a &quot;industrial board&quot; was essentially a motherboard that would continue to be produced over a long period of time.<br />
<br />
I have an example of that here, but I might actually be misinterpreting the info:<br />
<br />
http://www.supermicro.com/products/motherboard/Core/Q87/X10SLV-Q.cfm<br />
<br />
Reregarding say for GIGABYTE Ultra Durable, I think they are talking about the quality when they refer to lifespan here. Not the product lifecycle (ie how long it'll be manufactured/available for sale). <br />
<br />
<br />
So this board has a &quot;7 year product life&quot;. My interpretation of that is it'll continue to be manufactured and made available for purchase for a period of 7 years. Most consumer motherboards are only manufactured and made available for retail sale for a period of 6-9 months before they're discontinued. After that major stocks are depleted and chances are you won't be able to locate any significant quantities other than what might be lying around for future repairs, etc (for example a computer repair shop might maintain a few extra boards to cover warranty repairs). If they decide that they no longer need the stock as there were few repairs after a few years they might unload that stock (ie put 2-3 on ebay, etc).<br />
<br />
Now a company can't really guarantee that there will be no changes whatsoever as everybody is dependent on other companies. There is a supply chain. If you can't get certain chips because the company upstream of you discontinued the chip then certainly you can't manufacture more of the same board with that chip. But in any event the idea is that there will be minimal changes, and certain long-life chipsets will be used so that things like drivers won't need to change generally speaking. This ensures you can release a product today and 5 years down the road you can still swap the board without updating the OS/kernel/drivers. <br />
<br />
<br />
I'm not myself intimately familiar with industrial-type manufacturing processes. I've only looked into it to the extent that we've needed to in an effort to support other companies looking to build GNU/Linux based products. <br />
<br />
<br />
If you can get Coreboot working on one of these motherboards then there is a chance of making this happen. I think its like a 7-year period too. Of course selling a 3-year old board isn't going to sit well with a lot of people. Particularly at significantly higher prices than what they're use to seeing, it might be twice the price for the board mind you.<br />
<br />
<br />
The other option is to simply jump ship on X86 and avoid the BIOS issue altogether. I think this is the best approach. However its not a total solution as you'll still find issues with things like proprietary stage-1 boot loaders and non-free graphics (and in some cases like with the Raspberry Pi it won't even boot without this piece).<br />
<br />
But a computer need a BIOS to boot into say GRUB, right? An x86 system does. You can look at mini ARM boards though and this is not the same. They'll have a stage-1 and stage-2 bootloader, but no BIOS per say.&quot;<br />
<br />
== Examples ==<br />
* http://www.freescale.com/productlongevity<br />
* http://www.kontron.com/products/boards-and-standard-form-factors/motherboards/mini-itx/ktqm77-mitx.html (sells for 7 years) and its support in http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/mainboard/kontron/ktqm77;hb=HEAD</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Git&diff=16553Git2015-06-24T21:48:47Z<p>PatrickGeorgi: /* Gerrit workflow */</p>
<hr />
<div>= Gerrit =<br />
As part of our move to [https://code.google.com/p/gerrit/ gerrit], [http://gitscm.com/ git] was introduced as primary SCM.<br />
<br />
== Register with gerrit ==<br />
For authenticated access (to submit patches) you'll need a gerrit account which you can register at http://review.coreboot.org/.<br />
You also need to add your ssh key(s) (used for authenticating your connections to the repo) and your email address(es) (used to match up Signed-off-by: statements) to your gerrit user data at http://review.coreboot.org/#settings.<br />
<br />
=== OpenID and OAuth2 ===<br />
Gerrit uses OpenID and OAuth2 for authentication. Besides many large web services that provide OpenID identity services (eg. Yahoo), you can run your own, if you want. We support OAuth2 for Google and GitHub accounts.<br />
<br />
Once you have an account, you can link additional identity providers on http://review.coreboot.org/#/settings/web-identities (&quot;Link Another Identity&quot;). Any of these accounts can then be used to access your account. If you simply login with each of the identities, different accounts on gerrit are created, which is probably not the intention.<br />
<br />
Note that gerrit is a bit picky about the OpenID format. Always provide a full URL, including protocol (http:// or https:// prefix). Unfortunately the error messages are non-intuitive.<br />
<br />
== Gerrit workflow ==<br />
Gerrit interprets each Git commit as an individual change. Changes are autobuilt by [http://qa.coreboot.org/ Jenkins], and can be reviewed by developers. Once a change has gotten a positive review and has no build issues, it is applied to the master branch. Thus, no developer directly pushes to master.<br />
<br />
Reviews grant points on a scale from -2 to 2. The meaning is:<br />
* -2: Do not merge (blocks gerrit from merging)<br />
* -1: I'd prefer you don't merge it<br />
* 0: neutral<br />
* +1: Looks good, but I won't make the last call on it<br />
* +2: Looks good, go ahead and merge (gerrit provides a &quot;submit&quot; function to developers once it has a +2 vote)<br />
<br />
-2 is only available to core developers since it has veto power. Contributors with more activity than a one-off commit can request (eg. on IRC) to be added to the Reviewers group which has extended permissions (eg giving +2) over the default access level.<br />
<br />
=== Gerrit and CLI ===<br />
Reviews normally happens through the website.<br />
<br />
Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled. You can find the official Gerrit documentation about its CLI tools [https://gerrit-review.googlesource.com/Documentation/cmd-index.html here].<br />
<br />
=== Gerrit and Email ===<br />
Gerrit has poor email integration (in fact, it doesn't really have any at all). We send a couple of notifications to the mailing list, but that is a coreboot specific extension. Peter intends to build a mail-to-gerrit gateway should the need arise.<br />
<br />
This gateway will provide:<br />
* no patch submission mechanism (&quot;git push&quot; is CLI friendly)<br />
* patch review (maybe openpgp signed &quot;Acked-by&quot; mails)<br />
* patch submission (automatically with Acked-by?)<br />
* maybe patch rejection? (openpgp signed &quot;Nacked-by&quot; mails)<br />
<br />
= Accessing the repository =<br />
The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularly interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for &quot;Smart HTTP&quot; transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.<br />
<br />
git clone ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot<br />
<br />
git clone &lt;nowiki&gt;http://[&lt;username&gt;:&lt;password&gt;@]review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
Inside the checkout you should install a commit-msg hook that adds a Change-Id into commit messages, which uniquely identifies the logical change in Gerrit even across multiple iterations of the commit. The hook only needs to be installed once per clone, and installation can be done with<br />
<br />
wget -O .git/hooks/commit-msg &lt;nowiki&gt;http://review.coreboot.org/tools/hooks/commit-msg&lt;/nowiki&gt; &amp;&amp; \<br />
chmod +x .git/hooks/commit-msg<br />
<br />
Or you can also just run<br />
<br />
make gitconfig<br />
<br />
= Working with Git =<br />
<br />
Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065422.html a Git introduction] after the switch to Git had been announced on the mailing list.<br />
<br />
== Commit messages ==<br />
Git does not enforce a commit message style, although perhaps it should. For all aspects of Git to work the best, it's important to follow these simple guidelines for commit messages:<br />
<br />
# The first line of the commit message has a short (less than 65 characters, absolute maximum is 75) summary<br />
# The second line is empty (no whitespace at all)<br />
# The third and any number of following lines contain a longer description of the commit as is neccessary, including relevant background information and quite possibly rationale for why the issue was solved in this particular way. These lines should never be longer than 75 characters.<br />
# The next line is empty (no whitespace at all)<br />
# A Change-Id: line to let gerrit track this logical change<br />
# A Signed-off-by: line according to [[Development_Guidelines#Sign-off_Procedure|the development guidelines]]<br />
<br />
Please do not create Change-Id: and Signed-off-by: manually because it is boring and error-prone. Instead, please install the commit-msg hook as described [[#Accessing_the_repository|above]], and remember to always use '''git commit -s''' to have git add your Signed-off-by: automatically.<br />
<br />
Here is an example of a well-formatted commit message:<br />
examplecomponent: Refactor duplicated setup into a function<br />
<br />
Setting up the demo device correctly requires the exact same register<br />
values to be written into each of the PCI device functions. Moving the<br />
writes into a function allows also otherexamplecomponent to use them.<br />
<br />
Signed-off-by: Joe Hacker &lt;joe@hacker.email&gt;<br />
<br />
The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.<br />
<br />
=== Guidelines on commit message content ===<br />
<br />
* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without analyzing the code.<br />
* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:<br />
git show<br />
<br />
== Pushing changes ==<br />
First ensure that the git remote you want to use for pushing refers to an ssh:// URL (see [[Git#Authenticated read/write access|Authenticated read/write access]] above). If you need to change this after the fact, ie. if you registered on gerrit only after having cloned anonymously, you can. Assuming that your remote is called ''origin'' (this is the default) you can run:<br />
<br />
git config remote.origin.url ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot<br />
<br />
Then run the following command once, to tell git that by default you want to submit all commits in the currently checked-out branch for review on gerrit:<br />
<br />
git config remote.origin.push HEAD:refs/for/master<br />
<br />
After this, the command to push your changes is:<br />
<br />
git push origin<br />
<br />
If you always push from the same or a few branches the workflow can be simplified further by running once for each branch:<br />
<br />
git config branch.&lt;particularbranchname&gt;.remote origin<br />
<br />
...after which you then push changes with any of the configured branches checked out with a simple:<br />
<br />
git push<br />
<br />
Pushing several commits not yet in the coreboot repository at once will create one review request on gerrit per commit. <br />
<br />
'''NB!''' If you have applied patches from gerrit on a branch and you later push that branch, gerrit will think that you are submitting new versions of the patches that you had applied. This may or may not be what you intend. You can always run<br />
<br />
git log origin/master..<br />
<br />
before '''git push''' to verify which commits you are about to send for review.<br />
<br />
For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].<br />
<br />
== Pushing Drafts ==<br />
git push origin HEAD:refs/drafts/master<br />
== Pushing to Topics ==<br />
git push origin HEAD:refs/for/master/i915-kernel-x60<br />
will push to the i915-kernel-x60 topic.<br />
<br />
== Evolving patches ==<br />
<br />
Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.<br />
<br />
You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, <br />
<br />
git rebase -i master<br />
<br />
then commit and push the updated patch.<br />
<br />
Alternatively, you may amend your local commit and push the updated patch to gerrit:<br />
<br />
git add &lt;path/to/updated/files&gt;<br />
git commit --amend<br />
<br />
then push the updated patch.<br />
<br />
== Further Git reading ==<br />
There are tons of git tutorials out there. Take a look at some of these documents:<br />
* http://git-scm.com/<br />
* http://www.kernel.org/pub/software/scm/git/docs/v1.7.5.4/gittutorial.html<br />
* http://git.or.cz/course/svn.html<br />
* and in particular the [http://progit.org/ Pro Git book]<br />
<br />
Please also feel free to ask Git questions in the [[IRC|coreboot IRC channel]] or on the [[Mailinglist|mailing list]].<br />
<br />
= Browsing =<br />
<br />
See http://review.coreboot.org/gitweb?p=coreboot.git</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=QEMU_Build_Tutorial&diff=16493QEMU Build Tutorial2015-05-29T17:17:41Z<p>PatrickGeorgi: </p>
<hr />
<div>=== Introduction ===<br />
<br />
If you don't have a mainboard supported by coreboot don't worry: [http://qemu.org/ QEMU] can help you to emulate one. Using coreboot with QEMU may serve the purpose to familiarize you as a developer with coreboot and may be a reference system during development. <br />
<br />
This nice tutorial was written by [mailto:acassis@gmail.com Alan Carvalho de Assis], with additions by [mailto:eswierk@arastra.com Ed Swierk] (but please use the [[Mailinglist|coreboot mailing list]] rather than emailing the authors directly).<br />
<br />
While there are many ways to use coreboot to load and run a Linux kernel, this tutorial covers two of the most common:<br />
<br />
* coreboot with [[SeaBIOS]] as payload, which is the default configuration on coreboot for Intel compatible mainboards.<br />
* coreboot with [[FILO]] as payload, using FILO to load a Linux kernel (and optional initramfs) from a hard disk image. This approach involves a bit more mechanism (it relies on FILO's built-in disk and filesystem drivers) but it produces a tiny coreboot image.<br />
* coreboot with a Linux kernel (and optional initramfs) as payload. This cuts FILO out of the picture, but the main challenge with this approach is squeezing the resulting coreboot image into QEMU's BIOS ROM area (currently 2 MB, but easy to extend by patching QEMU).<br />
<br />
=== Requirements === <br />
<br />
You need the following software packages:<br />
<br />
* [[Download_coreboot|coreboot v4]]<br />
* [http://qemu.org/ Qemu]<br />
* [[FILO]] 0.6 or greater (if using FILO)<br />
<br />
plus a Linux kernel and root filesystem and a working development environment (make, gcc, etc.).<br />
<br />
=== Building or finding a Linux kernel ===<br />
<br />
If you are using FILO, you can simply grab a Linux kernel and initramfs from your favorite distribution.<br />
<br />
For linux as payload, you will probably need to build a kernel and initramfs from scratch, ensuring that the final coreboot image does not exceed QEMU's BIOS size limit (2MB if qemu-bios-size patch applied, 256KB otherwise). Building the kernel and initramfs is beyond the scope of this tutorial; how you configure them depends on your application.<br />
<br />
If you plan to use kexec to chain-boot another Linux kernel, tools from these projects can help automate the process of generating a kernel and initramfs:<br />
* [http://kboot.sourceforge.net/ kboot]<br />
* [http://wiki.laptop.org/go/Building_LinuxBIOS OLPC buildrom]<br />
<br />
=== Using SeaBIOS ===<br />
<br />
Since SeaBIOS is the default payload option, you don't need to change anything in the payload section of the configuration menu, and don't need to download or prepare any source code either - the build system takes care of that.<br />
<br />
=== Building a FILO payload ===<br />
<br />
If you plan to build your Linux kernel and root filesystem directly into coreboot, you can skip this section.<br />
<br />
Download [[FILO]], and cd to the filo directory<br />
<br />
First invocation of make creates the config file.<br />
$ make menuconfig<br />
<br />
Run make again to create build/filo.elf, the ELF FILO image. <br />
$ make <br />
<br />
You will use this file (filo.elf) as the coreboot payload later on.<br />
<br />
=== Building a Linux kernel payload ===<br />
<br />
If you are using FILO, skip this section.<br />
<br />
Specify the Linux as payload type and the Linux kernel (bzImage file), initrd and kernel command line that should be used in `make menuconfig`'s Payload section<br />
<br />
=== Building coreboot ===<br />
<br />
See the [[Build HOWTO]] for information on how to build coreboot for this board.<br />
<br />
This creates the coreboot image (build/coreboot.rom).<br />
<br />
=== Building Qemu ===<br />
Qemu used to require patches to work with coreboot, but any current standard build (as packaged by distributions) should be good enough.<br />
<br />
&lt;!--<br />
==== Building Qemu on FreeBSD ====<br />
Qemu can easily be installed using FreeBSD's Ports tree. The Qemu port lives in emulators/qemu. However, as of version 0.9.1 the FreeBSD port can unfortunately no longer be used with coreboot. The latest working version is 0.9.0 which can be retrieved from the FreeBSD CVS repository. For your convenience, an archive of the last working port version has been uploaded to this wiki. You can download the archive from [http://www.coreboot.org/Image:FreeBSD-Qemu-0.9.0.tgz here]. For some reason, the downloaded archive cannot be extracted with tar only, so use these steps to extract the archive:<br />
<br />
$ gunzip FreeBSD-Qemu-0.9.0.tgz<br />
$ tar -xvf FreeBSD-Qemu.0.9.0.tar<br />
<br />
To build and install the port, do this:<br />
<br />
$ cd qemu<br />
$ make clean install<br />
<br />
Make sure you load the aio(4) kernel module before starting QEMU. Also, QEMU can be build with the kqemu kernel module that enhances QEMU's performance. To load both kernel modules at boot time, add the following lines to &lt;tt&gt;/boot/loader.conf&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
aio_load=&quot;YES&quot;<br />
kqemu_load=&quot;YES&quot;<br />
&lt;/pre&gt;<br />
<br />
You can now use the Qemu binary located in &lt;tt&gt;/usr/local/bin&lt;/tt&gt;.<br />
--&gt;<br />
=== Creating a hard disk image ===<br />
<br />
If you are using FILO, you must create a hard disk image containing the Linux kernel and optional initramfs that FILO loads.<br />
<br />
Whether or not you use FILO, you may also wish to populate the disk image with the root filesystem of whatever Linux distribution you want to run.<br />
<br />
Create an empty disk image:<br />
$ qemu-img create -f raw disk.img 200M<br />
<br />
Format it:<br />
$ mkfs.ext2 -F disk.img <br />
<br />
The remaining steps must be performed as root. Create a temporary mountpoint and mount the image:<br />
# mkdir /mnt/rootfs<br />
# mount -o loop disk.img /mnt/rootfs<br />
<br />
Create a boot directory and copy your Linux kernel (vmlinuz) and initramfs (initrd) to it:<br />
# mkdir /mnt/rootfs/boot<br />
# cp vmlinuz /mnt/rootfs/boot/vmlinuz<br />
# cp initrd /mnt/rootfs/boot/initrd<br />
<br />
At this point, you can also copy a complete root filesystem to the disk image. <br />
# cp -R /* /mnt/rootfs <br />
<br />
Alternatively, with Debian you can use the debootstrap command to create a basic root filesystem:<br />
# debootstrap --arch i386 sarge /mnt/rootfs http://ftp.debian.org/debian/ <br />
<br />
If you are using a debootstrap filesystem, open the file /mnt/rootfs/etc/inittab and change runlevel to level 1:<br />
id:1:initdefault: <br />
<br />
cd out of /mnt/rootfs and umount it:<br />
# umount /mnt/rootfs<br />
<br />
Exit from the root account:<br />
# exit<br />
<br />
=== Starting coreboot in QEMU ===<br />
<br />
Execute QEMU using the following parameters:<br />
$ qemu -bios path/to/coreboot.rom -hda disk.img -nographic<br />
<br />
The -bios option tells QEMU to use path/to/coreboot.rom as its BIOS. The -nographic option suppresses the graphical VGA display and connects the virtual machine's serial port to your console. If you want to keep VGA display, you can use &quot;-serial stdio&quot; instead, which only redirects serial to the console.<br />
<br />
You should now see all sorts of interesting coreboot messages, followed by Linux kernel boot messages or a FILO prompt.<br />
<br />
If you are using FILO, enter at the boot: prompt:<br />
<br />
kernel hda:/boot/vmlinuz root=/dev/hda<br />
initrd hda:/boot/initrd<br />
boot console=ttyS0<br />
<br />
Example:<br />
<br />
[[Image:Screenshot linuxbios boots qemu.png]]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=QEMU_Build_Tutorial&diff=16492QEMU Build Tutorial2015-05-29T17:16:33Z<p>PatrickGeorgi: /* Introduction */</p>
<hr />
<div>=== Introduction ===<br />
<br />
If you don't have a mainboard supported by coreboot don't worry: [http://qemu.org/ QEMU] can help you to emulate one. Using coreboot with QEMU may serve the purpose to familiarize you as a developer with coreboot and may be a reference system during development. <br />
<br />
This nice tutorial was written by [mailto:acassis@gmail.com Alan Carvalho de Assis], with additions by [mailto:eswierk@arastra.com Ed Swierk] (but please use the [[Mailinglist|coreboot mailing list]] rather than emailing the authors directly).<br />
<br />
While there are many ways to use coreboot to load and run a Linux kernel, this tutorial covers two of the most common:<br />
<br />
* coreboot with [[SeaBIOS]] as payload, which is the default configuration on coreboot for Intel compatible mainboards.<br />
* coreboot with [[FILO]] as payload, using FILO to load a Linux kernel (and optional initramfs) from a hard disk image. This approach involves a bit more mechanism (it relies on FILO's built-in disk and filesystem drivers) but it produces a tiny coreboot image.<br />
* coreboot with a Linux kernel (and optional initramfs) as payload. This cuts FILO out of the picture, but the main challenge with this approach is squeezing the resulting coreboot image into QEMU's BIOS ROM area (currently 2 MB, but easy to extend by patching QEMU).<br />
<br />
=== Requirements === <br />
<br />
You need the following software packages:<br />
<br />
* [[Download_coreboot|coreboot v4]]<br />
* [http://qemu.org/ Qemu]<br />
* [[FILO]] 0.6 or greater (if using FILO)<br />
<br />
plus a Linux kernel and root filesystem and a working development environment (make, gcc, etc.).<br />
<br />
=== Building or finding a Linux kernel ===<br />
<br />
If you are using FILO, you can simply grab a Linux kernel and initramfs from your favorite distribution.<br />
<br />
For linux as payload, you will probably need to build a kernel and initramfs from scratch, ensuring that the final coreboot image does not exceed QEMU's BIOS size limit (2MB if qemu-bios-size patch applied, 256KB otherwise). Building the kernel and initramfs is beyond the scope of this tutorial; how you configure them depends on your application.<br />
<br />
If you plan to use kexec to chain-boot another Linux kernel, tools from these projects can help automate the process of generating a kernel and initramfs:<br />
* [http://kboot.sourceforge.net/ kboot]<br />
* [http://wiki.laptop.org/go/Building_LinuxBIOS OLPC buildrom]<br />
<br />
=== Building a FILO payload ===<br />
<br />
If you plan to build your Linux kernel and root filesystem directly into coreboot, you can skip this section.<br />
<br />
Download [[FILO]], and cd to the filo directory<br />
<br />
First invocation of make creates the config file.<br />
$ make menuconfig<br />
<br />
Run make again to create build/filo.elf, the ELF FILO image. <br />
$ make <br />
<br />
You will use this file (filo.elf) as the coreboot payload later on.<br />
<br />
=== Building a Linux kernel payload ===<br />
<br />
If you are using FILO, skip this section.<br />
<br />
Specify the Linux as payload type and the Linux kernel (bzImage file), initrd and kernel command line that should be used in `make menuconfig`'s Payload section<br />
<br />
=== Building coreboot ===<br />
<br />
See the [[Build HOWTO]] for information on how to build coreboot for this board.<br />
<br />
This creates the coreboot image (build/coreboot.rom).<br />
<br />
=== Building Qemu ===<br />
Qemu used to require patches to work with coreboot, but any current standard build (as packaged by distributions) should be good enough.<br />
<br />
&lt;!--<br />
==== Building Qemu on FreeBSD ====<br />
Qemu can easily be installed using FreeBSD's Ports tree. The Qemu port lives in emulators/qemu. However, as of version 0.9.1 the FreeBSD port can unfortunately no longer be used with coreboot. The latest working version is 0.9.0 which can be retrieved from the FreeBSD CVS repository. For your convenience, an archive of the last working port version has been uploaded to this wiki. You can download the archive from [http://www.coreboot.org/Image:FreeBSD-Qemu-0.9.0.tgz here]. For some reason, the downloaded archive cannot be extracted with tar only, so use these steps to extract the archive:<br />
<br />
$ gunzip FreeBSD-Qemu-0.9.0.tgz<br />
$ tar -xvf FreeBSD-Qemu.0.9.0.tar<br />
<br />
To build and install the port, do this:<br />
<br />
$ cd qemu<br />
$ make clean install<br />
<br />
Make sure you load the aio(4) kernel module before starting QEMU. Also, QEMU can be build with the kqemu kernel module that enhances QEMU's performance. To load both kernel modules at boot time, add the following lines to &lt;tt&gt;/boot/loader.conf&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
aio_load=&quot;YES&quot;<br />
kqemu_load=&quot;YES&quot;<br />
&lt;/pre&gt;<br />
<br />
You can now use the Qemu binary located in &lt;tt&gt;/usr/local/bin&lt;/tt&gt;.<br />
--&gt;<br />
=== Creating a hard disk image ===<br />
<br />
If you are using FILO, you must create a hard disk image containing the Linux kernel and optional initramfs that FILO loads.<br />
<br />
Whether or not you use FILO, you may also wish to populate the disk image with the root filesystem of whatever Linux distribution you want to run.<br />
<br />
Create an empty disk image:<br />
$ qemu-img create -f raw disk.img 200M<br />
<br />
Format it:<br />
$ mkfs.ext2 -F disk.img <br />
<br />
The remaining steps must be performed as root. Create a temporary mountpoint and mount the image:<br />
# mkdir /mnt/rootfs<br />
# mount -o loop disk.img /mnt/rootfs<br />
<br />
Create a boot directory and copy your Linux kernel (vmlinuz) and initramfs (initrd) to it:<br />
# mkdir /mnt/rootfs/boot<br />
# cp vmlinuz /mnt/rootfs/boot/vmlinuz<br />
# cp initrd /mnt/rootfs/boot/initrd<br />
<br />
At this point, you can also copy a complete root filesystem to the disk image. <br />
# cp -R /* /mnt/rootfs <br />
<br />
Alternatively, with Debian you can use the debootstrap command to create a basic root filesystem:<br />
# debootstrap --arch i386 sarge /mnt/rootfs http://ftp.debian.org/debian/ <br />
<br />
If you are using a debootstrap filesystem, open the file /mnt/rootfs/etc/inittab and change runlevel to level 1:<br />
id:1:initdefault: <br />
<br />
cd out of /mnt/rootfs and umount it:<br />
# umount /mnt/rootfs<br />
<br />
Exit from the root account:<br />
# exit<br />
<br />
=== Starting coreboot in QEMU ===<br />
<br />
Execute QEMU using the following parameters:<br />
$ qemu -bios path/to/coreboot.rom -hda disk.img -nographic<br />
<br />
The -bios option tells QEMU to use path/to/coreboot.rom as its BIOS. The -nographic option suppresses the graphical VGA display and connects the virtual machine's serial port to your console. If you want to keep VGA display, you can use &quot;-serial stdio&quot; instead, which only redirects serial to the console.<br />
<br />
You should now see all sorts of interesting coreboot messages, followed by Linux kernel boot messages or a FILO prompt.<br />
<br />
If you are using FILO, enter at the boot: prompt:<br />
<br />
kernel hda:/boot/vmlinuz root=/dev/hda<br />
initrd hda:/boot/initrd<br />
boot console=ttyS0<br />
<br />
Example:<br />
<br />
[[Image:Screenshot linuxbios boots qemu.png]]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=QEMU_Build_Tutorial&diff=16491QEMU Build Tutorial2015-05-29T17:15:43Z<p>PatrickGeorgi: /* Building or finding a Linux kernel */</p>
<hr />
<div>=== Introduction ===<br />
<br />
If you don't have a mainboard supported by coreboot don't worry: [http://qemu.org/ QEMU] can help you to emulate one. Using coreboot with QEMU may serve the purpose to familiarize you as a developer with coreboot and may be a reference system during development. <br />
<br />
This nice tutorial was written by [mailto:acassis@gmail.com Alan Carvalho de Assis], with additions by [mailto:eswierk@arastra.com Ed Swierk] (but please use the [[Mailinglist|coreboot mailing list]] rather than emailing the authors directly).<br />
<br />
While there are many ways to use coreboot to load and run a Linux kernel, this tutorial covers two of the most common:<br />
<br />
* coreboot with [[FILO]] as payload, using FILO to load a Linux kernel (and optional initramfs) from a hard disk image. This approach involves a bit more mechanism (it relies on FILO's built-in disk and filesystem drivers) but it produces a tiny coreboot image.<br />
* coreboot with a Linux kernel (and optional initramfs) as payload. This cuts FILO out of the picture, but the main challenge with this approach is squeezing the resulting coreboot image into QEMU's BIOS ROM area (currently 2 MB, but easy to extend by patching QEMU).<br />
<br />
=== Requirements === <br />
<br />
You need the following software packages:<br />
<br />
* [[Download_coreboot|coreboot v4]]<br />
* [http://qemu.org/ Qemu]<br />
* [[FILO]] 0.6 or greater (if using FILO)<br />
<br />
plus a Linux kernel and root filesystem and a working development environment (make, gcc, etc.).<br />
<br />
=== Building or finding a Linux kernel ===<br />
<br />
If you are using FILO, you can simply grab a Linux kernel and initramfs from your favorite distribution.<br />
<br />
For linux as payload, you will probably need to build a kernel and initramfs from scratch, ensuring that the final coreboot image does not exceed QEMU's BIOS size limit (2MB if qemu-bios-size patch applied, 256KB otherwise). Building the kernel and initramfs is beyond the scope of this tutorial; how you configure them depends on your application.<br />
<br />
If you plan to use kexec to chain-boot another Linux kernel, tools from these projects can help automate the process of generating a kernel and initramfs:<br />
* [http://kboot.sourceforge.net/ kboot]<br />
* [http://wiki.laptop.org/go/Building_LinuxBIOS OLPC buildrom]<br />
<br />
=== Building a FILO payload ===<br />
<br />
If you plan to build your Linux kernel and root filesystem directly into coreboot, you can skip this section.<br />
<br />
Download [[FILO]], and cd to the filo directory<br />
<br />
First invocation of make creates the config file.<br />
$ make menuconfig<br />
<br />
Run make again to create build/filo.elf, the ELF FILO image. <br />
$ make <br />
<br />
You will use this file (filo.elf) as the coreboot payload later on.<br />
<br />
=== Building a Linux kernel payload ===<br />
<br />
If you are using FILO, skip this section.<br />
<br />
Specify the Linux as payload type and the Linux kernel (bzImage file), initrd and kernel command line that should be used in `make menuconfig`'s Payload section<br />
<br />
=== Building coreboot ===<br />
<br />
See the [[Build HOWTO]] for information on how to build coreboot for this board.<br />
<br />
This creates the coreboot image (build/coreboot.rom).<br />
<br />
=== Building Qemu ===<br />
Qemu used to require patches to work with coreboot, but any current standard build (as packaged by distributions) should be good enough.<br />
<br />
&lt;!--<br />
==== Building Qemu on FreeBSD ====<br />
Qemu can easily be installed using FreeBSD's Ports tree. The Qemu port lives in emulators/qemu. However, as of version 0.9.1 the FreeBSD port can unfortunately no longer be used with coreboot. The latest working version is 0.9.0 which can be retrieved from the FreeBSD CVS repository. For your convenience, an archive of the last working port version has been uploaded to this wiki. You can download the archive from [http://www.coreboot.org/Image:FreeBSD-Qemu-0.9.0.tgz here]. For some reason, the downloaded archive cannot be extracted with tar only, so use these steps to extract the archive:<br />
<br />
$ gunzip FreeBSD-Qemu-0.9.0.tgz<br />
$ tar -xvf FreeBSD-Qemu.0.9.0.tar<br />
<br />
To build and install the port, do this:<br />
<br />
$ cd qemu<br />
$ make clean install<br />
<br />
Make sure you load the aio(4) kernel module before starting QEMU. Also, QEMU can be build with the kqemu kernel module that enhances QEMU's performance. To load both kernel modules at boot time, add the following lines to &lt;tt&gt;/boot/loader.conf&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
aio_load=&quot;YES&quot;<br />
kqemu_load=&quot;YES&quot;<br />
&lt;/pre&gt;<br />
<br />
You can now use the Qemu binary located in &lt;tt&gt;/usr/local/bin&lt;/tt&gt;.<br />
--&gt;<br />
=== Creating a hard disk image ===<br />
<br />
If you are using FILO, you must create a hard disk image containing the Linux kernel and optional initramfs that FILO loads.<br />
<br />
Whether or not you use FILO, you may also wish to populate the disk image with the root filesystem of whatever Linux distribution you want to run.<br />
<br />
Create an empty disk image:<br />
$ qemu-img create -f raw disk.img 200M<br />
<br />
Format it:<br />
$ mkfs.ext2 -F disk.img <br />
<br />
The remaining steps must be performed as root. Create a temporary mountpoint and mount the image:<br />
# mkdir /mnt/rootfs<br />
# mount -o loop disk.img /mnt/rootfs<br />
<br />
Create a boot directory and copy your Linux kernel (vmlinuz) and initramfs (initrd) to it:<br />
# mkdir /mnt/rootfs/boot<br />
# cp vmlinuz /mnt/rootfs/boot/vmlinuz<br />
# cp initrd /mnt/rootfs/boot/initrd<br />
<br />
At this point, you can also copy a complete root filesystem to the disk image. <br />
# cp -R /* /mnt/rootfs <br />
<br />
Alternatively, with Debian you can use the debootstrap command to create a basic root filesystem:<br />
# debootstrap --arch i386 sarge /mnt/rootfs http://ftp.debian.org/debian/ <br />
<br />
If you are using a debootstrap filesystem, open the file /mnt/rootfs/etc/inittab and change runlevel to level 1:<br />
id:1:initdefault: <br />
<br />
cd out of /mnt/rootfs and umount it:<br />
# umount /mnt/rootfs<br />
<br />
Exit from the root account:<br />
# exit<br />
<br />
=== Starting coreboot in QEMU ===<br />
<br />
Execute QEMU using the following parameters:<br />
$ qemu -bios path/to/coreboot.rom -hda disk.img -nographic<br />
<br />
The -bios option tells QEMU to use path/to/coreboot.rom as its BIOS. The -nographic option suppresses the graphical VGA display and connects the virtual machine's serial port to your console. If you want to keep VGA display, you can use &quot;-serial stdio&quot; instead, which only redirects serial to the console.<br />
<br />
You should now see all sorts of interesting coreboot messages, followed by Linux kernel boot messages or a FILO prompt.<br />
<br />
If you are using FILO, enter at the boot: prompt:<br />
<br />
kernel hda:/boot/vmlinuz root=/dev/hda<br />
initrd hda:/boot/initrd<br />
boot console=ttyS0<br />
<br />
Example:<br />
<br />
[[Image:Screenshot linuxbios boots qemu.png]]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=QEMU_Build_Tutorial&diff=16490QEMU Build Tutorial2015-05-29T17:15:11Z<p>PatrickGeorgi: /* Requirements */</p>
<hr />
<div>=== Introduction ===<br />
<br />
If you don't have a mainboard supported by coreboot don't worry: [http://qemu.org/ QEMU] can help you to emulate one. Using coreboot with QEMU may serve the purpose to familiarize you as a developer with coreboot and may be a reference system during development. <br />
<br />
This nice tutorial was written by [mailto:acassis@gmail.com Alan Carvalho de Assis], with additions by [mailto:eswierk@arastra.com Ed Swierk] (but please use the [[Mailinglist|coreboot mailing list]] rather than emailing the authors directly).<br />
<br />
While there are many ways to use coreboot to load and run a Linux kernel, this tutorial covers two of the most common:<br />
<br />
* coreboot with [[FILO]] as payload, using FILO to load a Linux kernel (and optional initramfs) from a hard disk image. This approach involves a bit more mechanism (it relies on FILO's built-in disk and filesystem drivers) but it produces a tiny coreboot image.<br />
* coreboot with a Linux kernel (and optional initramfs) as payload. This cuts FILO out of the picture, but the main challenge with this approach is squeezing the resulting coreboot image into QEMU's BIOS ROM area (currently 2 MB, but easy to extend by patching QEMU).<br />
<br />
=== Requirements === <br />
<br />
You need the following software packages:<br />
<br />
* [[Download_coreboot|coreboot v4]]<br />
* [http://qemu.org/ Qemu]<br />
* [[FILO]] 0.6 or greater (if using FILO)<br />
<br />
plus a Linux kernel and root filesystem and a working development environment (make, gcc, etc.).<br />
<br />
=== Building or finding a Linux kernel ===<br />
<br />
If you are using FILO, you can simply grab a Linux kernel and initramfs from your favorite distribution.<br />
<br />
Otherwise, you will probably need to build a kernel and initramfs from scratch, ensuring that the final coreboot image does not exceed QEMU's BIOS size limit (2MB if qemu-bios-size patch applied, 256KB otherwise). Building the kernel and initramfs is beyond the scope of this tutorial; how you configure them depends on your application.<br />
<br />
If you plan to use kexec to chain-boot another Linux kernel, tools from these projects can help automate the process of generating a kernel and initramfs:<br />
* [http://kboot.sourceforge.net/ kboot]<br />
* [http://wiki.laptop.org/go/Building_LinuxBIOS OLPC buildrom]<br />
<br />
=== Building a FILO payload ===<br />
<br />
If you plan to build your Linux kernel and root filesystem directly into coreboot, you can skip this section.<br />
<br />
Download [[FILO]], and cd to the filo directory<br />
<br />
First invocation of make creates the config file.<br />
$ make menuconfig<br />
<br />
Run make again to create build/filo.elf, the ELF FILO image. <br />
$ make <br />
<br />
You will use this file (filo.elf) as the coreboot payload later on.<br />
<br />
=== Building a Linux kernel payload ===<br />
<br />
If you are using FILO, skip this section.<br />
<br />
Specify the Linux as payload type and the Linux kernel (bzImage file), initrd and kernel command line that should be used in `make menuconfig`'s Payload section<br />
<br />
=== Building coreboot ===<br />
<br />
See the [[Build HOWTO]] for information on how to build coreboot for this board.<br />
<br />
This creates the coreboot image (build/coreboot.rom).<br />
<br />
=== Building Qemu ===<br />
Qemu used to require patches to work with coreboot, but any current standard build (as packaged by distributions) should be good enough.<br />
<br />
&lt;!--<br />
==== Building Qemu on FreeBSD ====<br />
Qemu can easily be installed using FreeBSD's Ports tree. The Qemu port lives in emulators/qemu. However, as of version 0.9.1 the FreeBSD port can unfortunately no longer be used with coreboot. The latest working version is 0.9.0 which can be retrieved from the FreeBSD CVS repository. For your convenience, an archive of the last working port version has been uploaded to this wiki. You can download the archive from [http://www.coreboot.org/Image:FreeBSD-Qemu-0.9.0.tgz here]. For some reason, the downloaded archive cannot be extracted with tar only, so use these steps to extract the archive:<br />
<br />
$ gunzip FreeBSD-Qemu-0.9.0.tgz<br />
$ tar -xvf FreeBSD-Qemu.0.9.0.tar<br />
<br />
To build and install the port, do this:<br />
<br />
$ cd qemu<br />
$ make clean install<br />
<br />
Make sure you load the aio(4) kernel module before starting QEMU. Also, QEMU can be build with the kqemu kernel module that enhances QEMU's performance. To load both kernel modules at boot time, add the following lines to &lt;tt&gt;/boot/loader.conf&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
aio_load=&quot;YES&quot;<br />
kqemu_load=&quot;YES&quot;<br />
&lt;/pre&gt;<br />
<br />
You can now use the Qemu binary located in &lt;tt&gt;/usr/local/bin&lt;/tt&gt;.<br />
--&gt;<br />
=== Creating a hard disk image ===<br />
<br />
If you are using FILO, you must create a hard disk image containing the Linux kernel and optional initramfs that FILO loads.<br />
<br />
Whether or not you use FILO, you may also wish to populate the disk image with the root filesystem of whatever Linux distribution you want to run.<br />
<br />
Create an empty disk image:<br />
$ qemu-img create -f raw disk.img 200M<br />
<br />
Format it:<br />
$ mkfs.ext2 -F disk.img <br />
<br />
The remaining steps must be performed as root. Create a temporary mountpoint and mount the image:<br />
# mkdir /mnt/rootfs<br />
# mount -o loop disk.img /mnt/rootfs<br />
<br />
Create a boot directory and copy your Linux kernel (vmlinuz) and initramfs (initrd) to it:<br />
# mkdir /mnt/rootfs/boot<br />
# cp vmlinuz /mnt/rootfs/boot/vmlinuz<br />
# cp initrd /mnt/rootfs/boot/initrd<br />
<br />
At this point, you can also copy a complete root filesystem to the disk image. <br />
# cp -R /* /mnt/rootfs <br />
<br />
Alternatively, with Debian you can use the debootstrap command to create a basic root filesystem:<br />
# debootstrap --arch i386 sarge /mnt/rootfs http://ftp.debian.org/debian/ <br />
<br />
If you are using a debootstrap filesystem, open the file /mnt/rootfs/etc/inittab and change runlevel to level 1:<br />
id:1:initdefault: <br />
<br />
cd out of /mnt/rootfs and umount it:<br />
# umount /mnt/rootfs<br />
<br />
Exit from the root account:<br />
# exit<br />
<br />
=== Starting coreboot in QEMU ===<br />
<br />
Execute QEMU using the following parameters:<br />
$ qemu -bios path/to/coreboot.rom -hda disk.img -nographic<br />
<br />
The -bios option tells QEMU to use path/to/coreboot.rom as its BIOS. The -nographic option suppresses the graphical VGA display and connects the virtual machine's serial port to your console. If you want to keep VGA display, you can use &quot;-serial stdio&quot; instead, which only redirects serial to the console.<br />
<br />
You should now see all sorts of interesting coreboot messages, followed by Linux kernel boot messages or a FILO prompt.<br />
<br />
If you are using FILO, enter at the boot: prompt:<br />
<br />
kernel hda:/boot/vmlinuz root=/dev/hda<br />
initrd hda:/boot/initrd<br />
boot console=ttyS0<br />
<br />
Example:<br />
<br />
[[Image:Screenshot linuxbios boots qemu.png]]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=QEMU_Build_Tutorial&diff=16489QEMU Build Tutorial2015-05-29T17:14:37Z<p>PatrickGeorgi: /* Building a Linux kernel payload */</p>
<hr />
<div>=== Introduction ===<br />
<br />
If you don't have a mainboard supported by coreboot don't worry: [http://qemu.org/ QEMU] can help you to emulate one. Using coreboot with QEMU may serve the purpose to familiarize you as a developer with coreboot and may be a reference system during development. <br />
<br />
This nice tutorial was written by [mailto:acassis@gmail.com Alan Carvalho de Assis], with additions by [mailto:eswierk@arastra.com Ed Swierk] (but please use the [[Mailinglist|coreboot mailing list]] rather than emailing the authors directly).<br />
<br />
While there are many ways to use coreboot to load and run a Linux kernel, this tutorial covers two of the most common:<br />
<br />
* coreboot with [[FILO]] as payload, using FILO to load a Linux kernel (and optional initramfs) from a hard disk image. This approach involves a bit more mechanism (it relies on FILO's built-in disk and filesystem drivers) but it produces a tiny coreboot image.<br />
* coreboot with a Linux kernel (and optional initramfs) as payload. This cuts FILO out of the picture, but the main challenge with this approach is squeezing the resulting coreboot image into QEMU's BIOS ROM area (currently 2 MB, but easy to extend by patching QEMU).<br />
<br />
=== Requirements === <br />
<br />
You need the following software packages:<br />
<br />
* [[Download_coreboot|coreboot v4]]<br />
* [http://qemu.org/ Qemu]<br />
* [[FILO]] 0.6 or greater (if using FILO)<br />
* [ftp://ftp.lnxi.com/pub/mkelfImage mkelfImage] 2.7 or greater (if not using FILO)<br />
<br />
plus a Linux kernel and root filesystem and a working development environment (make, gcc, etc.).<br />
<br />
=== Building or finding a Linux kernel ===<br />
<br />
If you are using FILO, you can simply grab a Linux kernel and initramfs from your favorite distribution.<br />
<br />
Otherwise, you will probably need to build a kernel and initramfs from scratch, ensuring that the final coreboot image does not exceed QEMU's BIOS size limit (2MB if qemu-bios-size patch applied, 256KB otherwise). Building the kernel and initramfs is beyond the scope of this tutorial; how you configure them depends on your application.<br />
<br />
If you plan to use kexec to chain-boot another Linux kernel, tools from these projects can help automate the process of generating a kernel and initramfs:<br />
* [http://kboot.sourceforge.net/ kboot]<br />
* [http://wiki.laptop.org/go/Building_LinuxBIOS OLPC buildrom]<br />
<br />
=== Building a FILO payload ===<br />
<br />
If you plan to build your Linux kernel and root filesystem directly into coreboot, you can skip this section.<br />
<br />
Download [[FILO]], and cd to the filo directory<br />
<br />
First invocation of make creates the config file.<br />
$ make menuconfig<br />
<br />
Run make again to create build/filo.elf, the ELF FILO image. <br />
$ make <br />
<br />
You will use this file (filo.elf) as the coreboot payload later on.<br />
<br />
=== Building a Linux kernel payload ===<br />
<br />
If you are using FILO, skip this section.<br />
<br />
Specify the Linux as payload type and the Linux kernel (bzImage file), initrd and kernel command line that should be used in `make menuconfig`'s Payload section<br />
<br />
=== Building coreboot ===<br />
<br />
See the [[Build HOWTO]] for information on how to build coreboot for this board.<br />
<br />
This creates the coreboot image (build/coreboot.rom).<br />
<br />
=== Building Qemu ===<br />
Qemu used to require patches to work with coreboot, but any current standard build (as packaged by distributions) should be good enough.<br />
<br />
&lt;!--<br />
==== Building Qemu on FreeBSD ====<br />
Qemu can easily be installed using FreeBSD's Ports tree. The Qemu port lives in emulators/qemu. However, as of version 0.9.1 the FreeBSD port can unfortunately no longer be used with coreboot. The latest working version is 0.9.0 which can be retrieved from the FreeBSD CVS repository. For your convenience, an archive of the last working port version has been uploaded to this wiki. You can download the archive from [http://www.coreboot.org/Image:FreeBSD-Qemu-0.9.0.tgz here]. For some reason, the downloaded archive cannot be extracted with tar only, so use these steps to extract the archive:<br />
<br />
$ gunzip FreeBSD-Qemu-0.9.0.tgz<br />
$ tar -xvf FreeBSD-Qemu.0.9.0.tar<br />
<br />
To build and install the port, do this:<br />
<br />
$ cd qemu<br />
$ make clean install<br />
<br />
Make sure you load the aio(4) kernel module before starting QEMU. Also, QEMU can be build with the kqemu kernel module that enhances QEMU's performance. To load both kernel modules at boot time, add the following lines to &lt;tt&gt;/boot/loader.conf&lt;/tt&gt;:<br />
<br />
&lt;pre&gt;<br />
aio_load=&quot;YES&quot;<br />
kqemu_load=&quot;YES&quot;<br />
&lt;/pre&gt;<br />
<br />
You can now use the Qemu binary located in &lt;tt&gt;/usr/local/bin&lt;/tt&gt;.<br />
--&gt;<br />
=== Creating a hard disk image ===<br />
<br />
If you are using FILO, you must create a hard disk image containing the Linux kernel and optional initramfs that FILO loads.<br />
<br />
Whether or not you use FILO, you may also wish to populate the disk image with the root filesystem of whatever Linux distribution you want to run.<br />
<br />
Create an empty disk image:<br />
$ qemu-img create -f raw disk.img 200M<br />
<br />
Format it:<br />
$ mkfs.ext2 -F disk.img <br />
<br />
The remaining steps must be performed as root. Create a temporary mountpoint and mount the image:<br />
# mkdir /mnt/rootfs<br />
# mount -o loop disk.img /mnt/rootfs<br />
<br />
Create a boot directory and copy your Linux kernel (vmlinuz) and initramfs (initrd) to it:<br />
# mkdir /mnt/rootfs/boot<br />
# cp vmlinuz /mnt/rootfs/boot/vmlinuz<br />
# cp initrd /mnt/rootfs/boot/initrd<br />
<br />
At this point, you can also copy a complete root filesystem to the disk image. <br />
# cp -R /* /mnt/rootfs <br />
<br />
Alternatively, with Debian you can use the debootstrap command to create a basic root filesystem:<br />
# debootstrap --arch i386 sarge /mnt/rootfs http://ftp.debian.org/debian/ <br />
<br />
If you are using a debootstrap filesystem, open the file /mnt/rootfs/etc/inittab and change runlevel to level 1:<br />
id:1:initdefault: <br />
<br />
cd out of /mnt/rootfs and umount it:<br />
# umount /mnt/rootfs<br />
<br />
Exit from the root account:<br />
# exit<br />
<br />
=== Starting coreboot in QEMU ===<br />
<br />
Execute QEMU using the following parameters:<br />
$ qemu -bios path/to/coreboot.rom -hda disk.img -nographic<br />
<br />
The -bios option tells QEMU to use path/to/coreboot.rom as its BIOS. The -nographic option suppresses the graphical VGA display and connects the virtual machine's serial port to your console. If you want to keep VGA display, you can use &quot;-serial stdio&quot; instead, which only redirects serial to the console.<br />
<br />
You should now see all sorts of interesting coreboot messages, followed by Linux kernel boot messages or a FILO prompt.<br />
<br />
If you are using FILO, enter at the boot: prompt:<br />
<br />
kernel hda:/boot/vmlinuz root=/dev/hda<br />
initrd hda:/boot/initrd<br />
boot console=ttyS0<br />
<br />
Example:<br />
<br />
[[Image:Screenshot linuxbios boots qemu.png]]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Git&diff=16222Git2015-04-23T11:03:14Z<p>PatrickGeorgi: /* OpenID and OAuth2 */</p>
<hr />
<div>= Gerrit =<br />
As part of our move to [https://code.google.com/p/gerrit/ gerrit], [http://gitscm.com/ git] was introduced as primary SCM.<br />
<br />
== Register with gerrit ==<br />
For authenticated access (to submit patches) you'll need a gerrit account which you can register at http://review.coreboot.org/.<br />
You also need to add your ssh key(s) (used for authenticating your connections to the repo) and your email address(es) (used to match up Signed-off-by: statements) to your gerrit user data at http://review.coreboot.org/#settings.<br />
<br />
=== OpenID and OAuth2 ===<br />
Gerrit uses OpenID and OAuth2 for authentication. Besides many large web services that provide OpenID identity services (eg. Yahoo), you can run your own, if you want. We support OAuth2 for Google and GitHub accounts.<br />
<br />
Once you have an account, you can link additional identity providers on http://review.coreboot.org/#/settings/web-identities (&quot;Link Another Identity&quot;). Any of these accounts can then be used to access your account. If you simply login with each of the identities, different accounts on gerrit are created, which is probably not the intention.<br />
<br />
Note that gerrit is a bit picky about the OpenID format. Always provide a full URL, including protocol (http:// or https:// prefix). Unfortunately the error messages are non-intuitive.<br />
<br />
== Gerrit workflow ==<br />
Gerrit interprets each Git commit as an individual change. Changes are autobuilt by [http://qa.coreboot.org/ Jenkins], and can be reviewed by developers. Once a change has gotten a positive review and has no build issues, it is applied to the master branch. Thus, no developer directly pushes to master.<br />
<br />
Reviews grant points on a scale from -2 to 2. The meaning is:<br />
* -2: Do not merge (blocks gerrit from merging)<br />
* -1: I'd prefer you don't merge it<br />
* 0: neutral<br />
* +1: Looks good, but I won't make the last call on it<br />
* +2: Looks good, go ahead and merge (gerrit provides a &quot;submit&quot; function once it has a +2 vote)<br />
<br />
-2 and +2 are only available to core developers as it's comparable to commit rights in SVN.<br />
<br />
=== Gerrit and CLI ===<br />
Reviews normally happens through the website.<br />
<br />
Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled. You can find the official Gerrit documentation about its CLI tools [https://gerrit-review.googlesource.com/Documentation/cmd-index.html here].<br />
<br />
=== Gerrit and Email ===<br />
Gerrit has poor email integration (in fact, it doesn't really have any at all). We send a couple of notifications to the mailing list, but that is a coreboot specific extension. Peter intends to build a mail-to-gerrit gateway should the need arise.<br />
<br />
This gateway will provide:<br />
* no patch submission mechanism (&quot;git push&quot; is CLI friendly)<br />
* patch review (maybe openpgp signed &quot;Acked-by&quot; mails)<br />
* patch submission (automatically with Acked-by?)<br />
* maybe patch rejection? (openpgp signed &quot;Nacked-by&quot; mails)<br />
<br />
= Accessing the repository =<br />
The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularly interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for &quot;Smart HTTP&quot; transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.<br />
<br />
git clone ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot<br />
<br />
git clone &lt;nowiki&gt;http://[&lt;username&gt;:&lt;password&gt;@]review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
Inside the checkout you should install a commit-msg hook that adds a Change-Id into commit messages, which uniquely identifies the logical change in Gerrit even across multiple iterations of the commit. The hook only needs to be installed once per clone, and installation can be done with<br />
<br />
wget -O .git/hooks/commit-msg &lt;nowiki&gt;http://review.coreboot.org/tools/hooks/commit-msg&lt;/nowiki&gt; &amp;&amp; \<br />
chmod +x .git/hooks/commit-msg<br />
<br />
Or you can also just run<br />
<br />
make gitconfig<br />
<br />
= Working with Git =<br />
<br />
Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065422.html a Git introduction] after the switch to Git had been announced on the mailing list.<br />
<br />
== Commit messages ==<br />
Git does not enforce a commit message style, although perhaps it should. For all aspects of Git to work the best, it's important to follow these simple guidelines for commit messages:<br />
<br />
# The first line of the commit message has a short (less than 65 characters, absolute maximum is 75) summary<br />
# The second line is empty (no whitespace at all)<br />
# The third and any number of following lines contain a longer description of the commit as is neccessary, including relevant background information and quite possibly rationale for why the issue was solved in this particular way. These lines should never be longer than 75 characters.<br />
# The next line is empty (no whitespace at all)<br />
# A Change-Id: line to let gerrit track this logical change<br />
# A Signed-off-by: line according to [[Development_Guidelines#Sign-off_Procedure|the development guidelines]]<br />
<br />
Please do not create Change-Id: and Signed-off-by: manually because it is boring and error-prone. Instead, please install the commit-msg hook as described [[#Accessing_the_repository|above]], and remember to always use '''git commit -s''' to have git add your Signed-off-by: automatically.<br />
<br />
Here is an example of a well-formatted commit message:<br />
examplecomponent: Refactor duplicated setup into a function<br />
<br />
Setting up the demo device correctly requires the exact same register<br />
values to be written into each of the PCI device functions. Moving the<br />
writes into a function allows also otherexamplecomponent to use them.<br />
<br />
Signed-off-by: Joe Hacker &lt;joe@hacker.email&gt;<br />
<br />
The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.<br />
<br />
=== Guidelines on commit message content ===<br />
<br />
* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without analyzing the code.<br />
* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:<br />
git show<br />
<br />
== Pushing changes ==<br />
First ensure that the git remote you want to use for pushing refers to an ssh:// URL (see [[Git#Authenticated read/write access|Authenticated read/write access]] above). If you need to change this after the fact, ie. if you registered on gerrit only after having cloned anonymously, you can. Assuming that your remote is called ''origin'' (this is the default) you can run:<br />
<br />
git config remote.origin.url ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot<br />
<br />
Then run the following command once, to tell git that by default you want to submit all commits in the currently checked-out branch for review on gerrit:<br />
<br />
git config remote.origin.push HEAD:refs/for/master<br />
<br />
After this, the command to push your changes is:<br />
<br />
git push origin<br />
<br />
If you always push from the same or a few branches the workflow can be simplified further by running once for each branch:<br />
<br />
git config branch.&lt;particularbranchname&gt;.remote origin<br />
<br />
...after which you then push changes with any of the configured branches checked out with a simple:<br />
<br />
git push<br />
<br />
Pushing several commits not yet in the coreboot repository at once will create one review request on gerrit per commit. <br />
<br />
'''NB!''' If you have applied patches from gerrit on a branch and you later push that branch, gerrit will think that you are submitting new versions of the patches that you had applied. This may or may not be what you intend. You can always run<br />
<br />
git log origin/master..<br />
<br />
before '''git push''' to verify which commits you are about to send for review.<br />
<br />
For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].<br />
<br />
== Pushing Drafts ==<br />
git push origin HEAD:refs/drafts/master<br />
== Pushing to Topics ==<br />
git push origin HEAD:refs/for/master/i915-kernel-x60<br />
will push to the i915-kernel-x60 topic.<br />
<br />
== Evolving patches ==<br />
<br />
Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.<br />
<br />
You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, <br />
<br />
git rebase -i master<br />
<br />
then commit and push the updated patch.<br />
<br />
Alternatively, you may amend your local commit and push the updated patch to gerrit:<br />
<br />
git add &lt;path/to/updated/files&gt;<br />
git commit --amend<br />
<br />
then push the updated patch.<br />
<br />
== Further Git reading ==<br />
There are tons of git tutorials out there. Take a look at some of these documents:<br />
* http://git-scm.com/<br />
* http://www.kernel.org/pub/software/scm/git/docs/v1.7.5.4/gittutorial.html<br />
* http://git.or.cz/course/svn.html<br />
* and in particular the [http://progit.org/ Pro Git book]<br />
<br />
Please also feel free to ask Git questions in the [[IRC|coreboot IRC channel]] or on the [[Mailinglist|mailing list]].<br />
<br />
= Browsing =<br />
<br />
See http://review.coreboot.org/gitweb?p=coreboot.git</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Git&diff=16207Git2015-04-22T12:50:47Z<p>PatrickGeorgi: </p>
<hr />
<div>= Gerrit =<br />
As part of our move to [https://code.google.com/p/gerrit/ gerrit], [http://gitscm.com/ git] was introduced as primary SCM.<br />
<br />
== Register with gerrit ==<br />
For authenticated access (to submit patches) you'll need a gerrit account which you can register at http://review.coreboot.org/.<br />
You also need to add your ssh key(s) (used for authenticating your connections to the repo) and your email address(es) (used to match up Signed-off-by: statements) to your gerrit user data at http://review.coreboot.org/#settings.<br />
<br />
=== OpenID and OAuth2 ===<br />
Gerrit uses OpenID and OAuth2 for authentication. Besides many large web services that provide OpenID identity services (eg. Yahoo), you can run your own, if you want. We support OAuth2 for Google accounts.<br />
<br />
It seems that gerrit is picky about the OpenID format. Always provide a full URL, including protocol (ie. http:// or https:// prefix). Unfortunately the error messages are non-intuitive (but will improve in the future)<br />
<br />
== Gerrit workflow ==<br />
Gerrit interprets each Git commit as an individual change. Changes are autobuilt by [http://qa.coreboot.org/ Jenkins], and can be reviewed by developers. Once a change has gotten a positive review and has no build issues, it is applied to the master branch. Thus, no developer directly pushes to master.<br />
<br />
Reviews grant points on a scale from -2 to 2. The meaning is:<br />
* -2: Do not merge (blocks gerrit from merging)<br />
* -1: I'd prefer you don't merge it<br />
* 0: neutral<br />
* +1: Looks good, but I won't make the last call on it<br />
* +2: Looks good, go ahead and merge (gerrit provides a &quot;submit&quot; function once it has a +2 vote)<br />
<br />
-2 and +2 are only available to core developers as it's comparable to commit rights in SVN.<br />
<br />
=== Gerrit and CLI ===<br />
Reviews normally happens through the website.<br />
<br />
Since gerrit exposes an interface through its ssh daemon, it's also possible to do reviews from CLI or mail. Unfortunately there doesn't seem to be any standing tradition on how to build a workflow around these parts, so we'll document our best practices here once they settled. You can find the official Gerrit documentation about its CLI tools [https://gerrit-review.googlesource.com/Documentation/cmd-index.html here].<br />
<br />
=== Gerrit and Email ===<br />
Gerrit has poor email integration (in fact, it doesn't really have any at all). We send a couple of notifications to the mailing list, but that is a coreboot specific extension. Peter intends to build a mail-to-gerrit gateway should the need arise.<br />
<br />
This gateway will provide:<br />
* no patch submission mechanism (&quot;git push&quot; is CLI friendly)<br />
* patch review (maybe openpgp signed &quot;Acked-by&quot; mails)<br />
* patch submission (automatically with Acked-by?)<br />
* maybe patch rejection? (openpgp signed &quot;Nacked-by&quot; mails)<br />
<br />
= Accessing the repository =<br />
The repository can be accessed using ssh (with public key authentication) or http (anonymous read-only or read-write using user/password authentication). The latter is particularly interesting for people behind firewalls, but requires git to be version 1.6.6 or newer (for &quot;Smart HTTP&quot; transfer). The http password can be generated (and regenerated if necessary) at http://review.coreboot.org/#settings,http-password.<br />
<br />
git clone ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot<br />
<br />
git clone &lt;nowiki&gt;http://[&lt;username&gt;:&lt;password&gt;@]review.coreboot.org/coreboot.git&lt;/nowiki&gt;<br />
<br />
Inside the checkout you should install a commit-msg hook that adds a Change-Id into commit messages, which uniquely identifies the logical change in Gerrit even across multiple iterations of the commit. The hook only needs to be installed once per clone, and installation can be done with<br />
<br />
wget -O .git/hooks/commit-msg &lt;nowiki&gt;http://review.coreboot.org/tools/hooks/commit-msg&lt;/nowiki&gt; &amp;&amp; \<br />
chmod +x .git/hooks/commit-msg<br />
<br />
Or you can also just run<br />
<br />
make gitconfig<br />
<br />
= Working with Git =<br />
<br />
Git is a distributed version control system. This means that you can manage commits and branches completely without restriction in your local clone of the coreboot repository. Peter wrote [http://www.coreboot.org/pipermail/coreboot/2011-June/065422.html a Git introduction] after the switch to Git had been announced on the mailing list.<br />
<br />
== Commit messages ==<br />
Git does not enforce a commit message style, although perhaps it should. For all aspects of Git to work the best, it's important to follow these simple guidelines for commit messages:<br />
<br />
# The first line of the commit message has a short (less than 65 characters, absolute maximum is 75) summary<br />
# The second line is empty (no whitespace at all)<br />
# The third and any number of following lines contain a longer description of the commit as is neccessary, including relevant background information and quite possibly rationale for why the issue was solved in this particular way. These lines should never be longer than 75 characters.<br />
# The next line is empty (no whitespace at all)<br />
# A Change-Id: line to let gerrit track this logical change<br />
# A Signed-off-by: line according to [[Development_Guidelines#Sign-off_Procedure|the development guidelines]]<br />
<br />
Please do not create Change-Id: and Signed-off-by: manually because it is boring and error-prone. Instead, please install the commit-msg hook as described [[#Accessing_the_repository|above]], and remember to always use '''git commit -s''' to have git add your Signed-off-by: automatically.<br />
<br />
Here is an example of a well-formatted commit message:<br />
examplecomponent: Refactor duplicated setup into a function<br />
<br />
Setting up the demo device correctly requires the exact same register<br />
values to be written into each of the PCI device functions. Moving the<br />
writes into a function allows also otherexamplecomponent to use them.<br />
<br />
Signed-off-by: Joe Hacker &lt;joe@hacker.email&gt;<br />
<br />
The example is missing a Change-Id: line. This is OK because Joe Hacker has set up the commit-msg hook [[#Authenticated_read/write_access|as mentioned above]], which adds a Change-Id: automatically when the commit message is saved.<br />
<br />
=== Guidelines on commit message content ===<br />
<br />
* If anyone involved in coreboot reads your comment in a year, she/he shall still be able to understand what your commit is about, without analyzing the code.<br />
* Double-check that you're really committing what you think you are, e.g. by typing the following in the top-level coreboot directory:<br />
git show<br />
<br />
== Pushing changes ==<br />
First ensure that the git remote you want to use for pushing refers to an ssh:// URL (see [[Git#Authenticated read/write access|Authenticated read/write access]] above). If you need to change this after the fact, ie. if you registered on gerrit only after having cloned anonymously, you can. Assuming that your remote is called ''origin'' (this is the default) you can run:<br />
<br />
git config remote.origin.url ssh://&lt;username&gt;@review.coreboot.org:29418/coreboot<br />
<br />
Then run the following command once, to tell git that by default you want to submit all commits in the currently checked-out branch for review on gerrit:<br />
<br />
git config remote.origin.push HEAD:refs/for/master<br />
<br />
After this, the command to push your changes is:<br />
<br />
git push origin<br />
<br />
If you always push from the same or a few branches the workflow can be simplified further by running once for each branch:<br />
<br />
git config branch.&lt;particularbranchname&gt;.remote origin<br />
<br />
...after which you then push changes with any of the configured branches checked out with a simple:<br />
<br />
git push<br />
<br />
Pushing several commits not yet in the coreboot repository at once will create one review request on gerrit per commit. <br />
<br />
'''NB!''' If you have applied patches from gerrit on a branch and you later push that branch, gerrit will think that you are submitting new versions of the patches that you had applied. This may or may not be what you intend. You can always run<br />
<br />
git log origin/master..<br />
<br />
before '''git push''' to verify which commits you are about to send for review.<br />
<br />
For automating patch submission further (ie. more ways of simplifying the command line), see the last paragraph of [http://review.coreboot.org/Documentation/user-upload.html#push_create this gerrit documentation].<br />
<br />
== Pushing Drafts ==<br />
git push origin HEAD:refs/drafts/master<br />
== Pushing to Topics ==<br />
git push origin HEAD:refs/for/master/i915-kernel-x60<br />
will push to the i915-kernel-x60 topic.<br />
<br />
== Evolving patches ==<br />
<br />
Often it might happen that the patch you sent for approval is not good enough from the first attempt. Gerrit and git make it easy to track patch evolution during the review process until patches meet our quality standards and are ready for approval.<br />
<br />
You can easily modify a patch sent to gerrit by you or even by someone else. Just apply it locally using one of the possible ways to do it, make a new local commit that fixes the issues reported by the reviewers, then rebase the change by preserving the same Change-ID. We recommend you to use the git rebase command in interactive mode, <br />
<br />
git rebase -i master<br />
<br />
then commit and push the updated patch.<br />
<br />
Alternatively, you may amend your local commit and push the updated patch to gerrit:<br />
<br />
git add &lt;path/to/updated/files&gt;<br />
git commit --amend<br />
<br />
then push the updated patch.<br />
<br />
== Further Git reading ==<br />
There are tons of git tutorials out there. Take a look at some of these documents:<br />
* http://git-scm.com/<br />
* http://www.kernel.org/pub/software/scm/git/docs/v1.7.5.4/gittutorial.html<br />
* http://git.or.cz/course/svn.html<br />
* and in particular the [http://progit.org/ Pro Git book]<br />
<br />
Please also feel free to ask Git questions in the [[IRC|coreboot IRC channel]] or on the [[Mailinglist|mailing list]].<br />
<br />
= Browsing =<br />
<br />
See http://review.coreboot.org/gitweb?p=coreboot.git</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Chromebooks&diff=15993Chromebooks2015-04-07T11:28:40Z<p>PatrickGeorgi: </p>
<hr />
<div>Flashing your own coreboot-version and [[Payloads|Payload]] onto your device is do-able, but requires some hardware preparation and ignorance in warning messages.<br />
== Start ==<br />
A good place to start is the [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Chromium site]. They have guides howto set your Chromebook into developer-mode and howto disassemble your device. <br />
<br />
Both things will be necessary, if you want to flash your own version of coreboot onto your Chromebook (in-system). <br />
It is necessary to close a circuit on the motherboard via either a switch, jumper or screw to disable the write-protection of the spi chip. And to use the flashing tool [http://flashrom.org/Flashrom flashrom] in Chrome OS, you have to be in the developer-mode. If you already installed a Gnu/Linux-system or likely you can also use the flashrom from there (but then you would be in developer-mode anyway).<br />
<br />
Note: The first three Chromebooks that were made are '''not''' supported by coreboot, but flashrom should be working. Mario, Alex and ZGB are running Insyde H2C UEFI. Snow has [http://en.wikipedia.org/wiki/Das_U-Boot das U-Boot] natively installed, but a coreboot port is available. '''All the others come shipped with coreboot.'''<br />
{| border=&quot;0&quot; style=&quot;font-size: smaller&quot;<br />
|- bgcolor=&quot;#6699ff&quot;<br />
! align=&quot;left&quot; | Release date <br />
! align=&quot;left&quot; | Manufacturer<br />
! align=&quot;left&quot; | Model<br />
! align=&quot;left&quot; | Project Code Name<br />
! align=&quot;left&quot; | Close cicuit via<br />
! align=&quot;left&quot; | Location for Jumper/Screw<br />
! align=&quot;left&quot; | SPI-Chip<br />
<br />
|- bgcolor=&quot;#eeeeee&quot;<br />
| May 2012 <br />
| Samsung <br />
| Series 3 Chromebox<br />
| Stumpy<br />
<br />
| Jumper<br />
| between the Battery and Ram<br />
|<br />
<br />
|- bgcolor=&quot;#dddddd&quot;<br />
| May 2012<br />
| Samsung Series <br />
| [[Samsung XE550C22-H02US|550 Chromebook]]:<br />
| Lumpy<br />
<br />
| Jumper<br />
| between the Battery and Ram<br />
|<br />
<br />
|- bgcolor=&quot;#eeeeee&quot;<br />
| October 2012<br />
| Samsung<br />
| ARM Chromebook<br />
| Snow (aka Daisy)<br />
<br />
| Screw<br />
| next to usb3.0-port<br />
|<br />
<br />
|- bgcolor=&quot;#dddddd&quot;<br />
| November 2012<br />
| Acer<br />
| C7 Chromebook<br />
| Parrot<br />
<br />
| Jumper<br />
| between CPU and Fan under plastic<br />
|<br />
<br />
|- bgcolor=&quot;#eeeeee&quot;<br />
| January 2013<br />
| Lenovo<br />
| Thinkpad X131e Chromebook<br />
| Stout<br />
<br />
| ?<br />
|<br />
|<br />
<br />
|- bgcolor=&quot;#dddddd&quot;<br />
| February 2013<br />
| HP<br />
| [[Board:google/butterfly|Pavilion 14 Chromebook]]<br />
| Butterfly<br />
<br />
| Switch<br />
| rightside behind the usb-ports<br />
|<br />
<br />
|- bgcolor=&quot;#eeeeee&quot;<br />
| February 2013<br />
| Google<br />
| [[Google Chromebook Pixel|Chromebook Pixel]]<br />
| Link<br />
<br />
| Screw<br />
| next to front-most USB connector<br />
|<br />
|<br />
<br />
|- bgcolor=&quot;#dddddd&quot;<br />
|September 2014<br />
|Toshiba<br />
|Chromebook 2<br />
|Swanky<br />
|Screw + Heat shield<br />
|Remove screw and prevent heat shield from completing short as well. <br />
Images: [[:File:ToshibaChromebook2FarAwayShort.jpg|(1)]] and [[:File:ToshibaChromebook2CloseUpShort.jpg|(2)]]<br />
|Winbond &quot;W25Q64.W&quot;<br />
|}<br />
<br />
== General Hardware Preperation ==<br />
Use the [http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/ disassembly guides] to disassemble your Chromebook <br />
till you see the place were you can put on a jumper, screw in a bolt or flip a switch. Check out the pictures in the disassembly guides to find the right spot. Either screw, switch or plug on now. For example in Lumpy and Stumpy you have to put a jumper on place between the Battery and Ram next to the Keyboard-Connector. Now assemble again (follow the guide). Now you are ready to flash your own coreboot-version onto your Chromebook.<br />
<br />
== Building your own coreboot-version and Payload ==<br />
First, you cannot do that inside the Chrome OS. Use your GNU/Linux-system and follow the [[Build HOWTO|Build HOWTO]]. There is also a model specific [[Chromebooks/550 Chromebook Build HOWTO|550 Chromebook Build HOWTO]].<br />
<br />
== firmware chips ==<br />
The firmware roms are highlighted on the pictures of the disassembly guides:<br />
<br />
Series 5 550 Chromebook (Lumpy) - Two firmware ROMs (one for EC, one for CPU+PCH) are located next to where the heat pipe meets the exhaust manifold. CPU+PCH firmware ROM is 8MB, EC firmware ROM is 256KB.<br />
<br />
Samsung XE303CE ARM Chromebook (snow) - AP firmware ROM is located next next to USB 2.0 port. The EC firmware ROM is embedded in the EC itself and can only be accessed through the mainboard debug port. AP firmware ROM is 4MB.<br />
<br />
Acer C7 Chromebook (parrot) - Firmware ROMs are underneath the keyboard, left of the touchpad. CPU+PCH firmware ROM is 8MB, EC firmware ROM is 256KB.<br />
<br />
Lenovo X131E (Stout) - CPU+PCH actually has two firmware ROMs, but only one is used. The are located next to the DRAM slots on the bottom of the board. The one which is used is 8MB, the unused one is 4MB. The EC ROM is on the top-side next to the EC (underneath the keyboard, to the right of where the touchpad sits) and is 1MB.<br />
<br />
HP Pavillion 14 (Butterfly) - CPU+PCH firmware ROM is on the bottom near the SD card slot and is 8MB. The EC firmware ROM is next to the EC, which is on the top side to the right of where the touchpad sits. The EC firmware ROM is 512KB.<br />
<br />
Chromebook Pixel (Link) - CPU+PCH firmware ROM next to mini-displayport connector. The EC firmware ROM is embedded in the EC itself and can only be accessed through the mainboard debug port. CPU+PCH firmware ROM is 8MB.<br />
<br />
== Recovery/external programming ==<br />
Ok, you fucked things up, but on the other hand this will give you the opprotunity to learn external chip-programming, so cheer-up. <br />
First you will need to locate the SPI-Chip. If you done that you will need an [http://flashrom.org/Supported_programmers external flashrom programmer] (for example the [http://en.wikipedia.org/wiki/Open_hardware open-hardware] tool [http://en.wikipedia.org/wiki/Bus_Pirate Bus Pirate]). At the moment ask at the coreboot/flashrom mailing list for further details.</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Board:asus/m4a785-m&diff=15902Board:asus/m4a785-m2015-03-28T10:38:25Z<p>PatrickGeorgi: drop tutorial referring to subversion (that's gone for 4 years)</p>
<hr />
<div>== Status (may be outdated) ==<br />
<br />
{{Status|<br />
<br />
|CPU_status = OK<br />
|CPU_comments = Tested: AMD Athlon64 X2 240e.<br />
|CPU_L1_status = OK<br />
|CPU_L1_comments = -<br />
|CPU_L2_status = OK<br />
|CPU_L2_comments = -<br />
|CPU_L3_status = N/A<br />
|CPU_multiple_status = N/A<br />
|CPU_multicore_status = OK<br />
|CPU_virt_status = OK<br />
|CPU_virt_comments = Tested: Virtualbox <br />
<br />
|RAM_EDO_status = N/A<br />
|RAM_SDRAM_status = N/A<br />
|RAM_SODIMM_status = N/A<br />
|RAM_DDR_status = N/A<br />
|RAM_DDR_comments = N/A<br />
|RAM_DDR2_status = WiP<br />
|RAM_DDR2_comments = 2G works, 4G or more does not.<br />
|RAM_DDR3_status = N/A<br />
|RAM_dualchannel_status = Untested<br />
|RAM_ecc_status = Untested<br />
|RAM_ecc_comments = <br />
<br />
|IDE_status = OK<br />
|IDE_comments = Tested: CDROM, SSD <br />
|IDE_25_status = N/A<br />
|IDE_CF_status = untested <br />
|IDE_CF_comments = <br />
|CDROM_DVD_status = OK<br />
|CDROM_DVD_comments = <br />
|SATA_status = OK<br />
|SATA_comments = Tested: SATA ports 1-4. Ports 5-6 untested.<br />
|USB_status = <br />
|USB_comments = <br />
|Onboard_VGA_status = OK<br />
|Onboard_VGA_comments = Tested: DVI. Untested: HDMI, analog VGA.<br />
|Onboard_ethernet_status = OK<br />
|Onboard_audio_status = No<br />
|Onboard_audio_comments = Linux driver crashes.<br />
|Onboard_modem_status = N/A<br />
|Onboard_firewire_status = N/A<br />
|Smartcard_status = N/A<br />
|Onboard_CF_status = N/A<br />
|Onboard_PCMCIA_status = N/A<br />
<br />
|ISA_cards_status = N/A<br />
|AMR_cards_status = N/A<br />
|PCI_cards_status = OK<br />
|PCI_cards_comments = See [[#Known issues|known issues]].<br />
|Mini_PCI_cards_status = N/A<br />
|PCIX_cards_status = N/A<br />
|AGP_cards_status = N/A<br />
|PCIE_x1_status = <br />
|PCIE_x1_comments = <br />
|PCIE_x2_status = N/A<br />
|PCIE_x4_status = Untested<br />
|PCIE_x8_status = N/A<br />
|PCIE_x16_status = Untested<br />
|PCIE_x16_comments = <br />
|PCIE_x32_status = N/A<br />
|HTX_status = N/A<br />
<br />
|Floppy_status = N/A<br />
|Floppy_comments = There is no floppy connector at all.<br />
|COM1_status = OK<br />
|COM1_comments = COM1 is only pin header on board. DB-9 serial connector is available, but not included with board.<br />
|COM2_status = N/A<br />
|PP_status = Untested<br />
|PP_comments = No connector, pins on board only<br />
|PS2_keyboard_status = OK<br />
|PS2_keyboard_comments = <br />
|PS2_mouse_status = Untested<br />
|PS2_mouse_comments = <br />
|Game_port_status = N/A<br />
|IR_status = N/A<br />
|Speaker_status = Untested<br />
|DiskOnChip_status = N/A<br />
<br />
|Sensors_status = Untested<br />
|Sensors_comments = <br />
|Watchdog_status = N/A<br />
|CAN_bus_status = N/A<br />
|CPUfreq_status = Untested<br />
|CPUfreq_comments = <br />
|Powersave_status = Untested<br />
|ACPI_status = Partial<br />
|ACPI_comments = Linux recognizes ACPI at boot, but operation unknown.<br />
|Reboot_status = No<br />
|Poweroff_status = No<br />
|LEDs_status = <br />
|LEDs_comments = <br />
|HPET_status = <br />
|HPET_comments = <br />
|RNG_status = Untested<br />
|WakeOnModem_status = Untested<br />
|WakeOnLAN_status = <br />
|WakeOnKeyboard_status = Untested<br />
|WakeOnMouse_status = Untested<br />
|Flashrom_status = OK<br />
|Flashrom_comments = <br />
<br />
}}</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Supported_Chipsets_and_Devices&diff=15892Supported Chipsets and Devices2015-03-27T16:15:04Z<p>PatrickGeorgi: /* Devices supported in coreboot v4 */</p>
<hr />
<div>'''coreboot v4''' is the current stable coreboot tree recommended for productive use and for porting new boards.<br />
* If a device is not supported by coreboot v4, try [[Supported_Chipsets_and_Devices/v1|checking coreboot v1]] or [[Supported_Chipsets_and_Devices/v3|coreboot v3]] for support.<br />
* In general it is '''not''' recommended to use coreboot v3 &amp;mdash; this was an experimental development tree which is gradually being merged into v4.<br />
* Also, coreboot v1 should be avoided (if v4 can be used instead for your board), as it has been unmaintained for a long time. However, it is definitely desirable to port boards from v1 to v4 whereever possible.<br />
<br />
See also [[Supported Motherboards]].<br />
<br />
== Devices supported in coreboot v4 ==<br />
<br />
{| border=&quot;0&quot; valign=&quot;top&quot;<br />
| valign=&quot;top&quot;|<br />
<br />
'''Northbridges'''<br />
<br />
{| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br />
|- bgcolor=&quot;#6699dd&quot;<br />
! align=&quot;left&quot; | Vendor<br />
! align=&quot;left&quot; | Northbridge<br />
! align=&quot;left&quot; | Status<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| Fam15h (Trinity) - R-Series<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| Fam15h (Orochi)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| Fam14h (Ontario) - G-Series<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| Fam12h (Llano)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| Fam10h<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;16&lt;/sup&gt;<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| K8<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| GX1<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| GX&amp;nbsp;(GX2)<br />
| style=&quot;background: lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| LX<br />
| style=&quot;background: lime&quot; | OK<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| E7501<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| E7505<br />
| style=&quot;background: lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| E7520<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| E7525<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 3100<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 5000P<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82443BX&amp;nbsp;(440BX)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82810<br />
| style=&quot;background:yellow&quot; | WIP&lt;sup&gt;9&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82830<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82855<br />
| style=&quot;background:yellow&quot; | WIP<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| EP80579 (Tolapai)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 945GM/GC<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| SCH US15W (Poulsbo)<br />
| style=&quot;background:lime&quot; | OK<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| SiS<br />
| SiS761GX<br />
| style=&quot;background:lime&quot; | OK<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT8601 (PLE133)<br />
| style=&quot;background:yellow&quot; | WIP<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT8623 (CLE266)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| K8T890<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| K8M890<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| CN400<br />
| ?<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| CN700<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;14&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| CX700<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VX800<br />
| style=&quot;background:yellow&quot; | WIP<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VX900<br />
| style=&quot;background:yellow&quot; | OK<br />
<br />
|}<br />
<br />
| valign=&quot;top&quot;|<br />
<br />
'''Southbridges'''<br />
<br />
{| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br />
|- bgcolor=&quot;#6699dd&quot;<br />
! align=&quot;left&quot; | Vendor<br />
! align=&quot;left&quot; | Southbridge<br />
! align=&quot;left&quot; | Status<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| AMD8111<br />
| style=&quot;background: lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| AMD8131<br />
| style=&quot;background: lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| AMD8132<br />
| style=&quot;background: lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| AMD8151<br />
| style=&quot;background: lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| CS5530/CS5530A<br />
| style=&quot;background:yellow&quot; | WIP<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| CS5535<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| CS5536<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| RS690<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| SB600<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| RS780/RS785<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| SB700/SB7x0<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| SR56x0<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| SB5100<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| SB800 / Hudson 1<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| SB900 / Hudson 2/3 &lt;sup&gt;21&lt;/sup&gt;<br />
| style=&quot;background: lime &quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| A85X / Hudson D4<br />
| style=&quot;background:#eeeeee &quot; | In tree<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Broadcom<br />
| BCM21000<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Broadcom<br />
| BCM5780<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Broadcom<br />
| BCM5785<br />
| style=&quot;background:lime&quot; | OK<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 6300ESB (ESB6300)<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 3100<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82371EB&amp;nbsp;(PIIX4E)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82801AA/AB&amp;nbsp;(ICH/ICH0)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82801BA/BAM&amp;nbsp;(ICH2/ICH2-M)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82801CA/CAM&amp;nbsp;(ICH3-S/ICH3-M)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82801DB/DBL/DBM&lt;br/&gt;(ICH4/ICH4-L/ICH4-M)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82801EB/ER&amp;nbsp;(ICH5/ICH5R)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82801GX&amp;nbsp;(ICH7)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 82870<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| PXHD<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| EP80579 (Tolapai)<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| SCH US15W (Poulsbo)<br />
| style=&quot;background:lime&quot; | OK<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| NVIDIA<br />
| CK804<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;17&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| NVIDIA<br />
| MCP55<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;17&lt;/sup&gt;<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Ricoh<br />
| RL5C476<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SiS<br />
| SiS966(L)<br />
| style=&quot;background:lime&quot; | OK<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT8231<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT8235<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT8237R<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT8237A<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT8237S<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT82C686<br />
| style=&quot;background:yellow&quot; | WIP<br />
<br />
|}<br />
<br />
| valign=&quot;top&quot;|<br />
<br />
'''Super I/Os'''<br />
<br />
{| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br />
|- bgcolor=&quot;#6699dd&quot;<br />
! align=&quot;left&quot; | Vendor<br />
! align=&quot;left&quot; | Super&amp;nbsp;I/O<br />
! align=&quot;left&quot; | Status<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| ASUS<br />
| A8000<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;, &lt;sup&gt;13&lt;/sup&gt;<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Fintek<br />
| F71805F/FG<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Fintek<br />
| F71859<br />
| style=&quot;background:yellow&quot; | OK&lt;sup&gt;19&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Fintek<br />
| F71863F/FG<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Fintek<br />
| F71872F/FG<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Fintek<br />
| F71869AD<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Fintek<br />
| F71889<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Fintek<br />
| F81865F<br />
| style=&quot;background:yellow&quot; | WIP<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| ITE<br />
| IT8661F<br />
| style=&quot;background:yellow&quot; | OK&lt;sup&gt;5&lt;/sup&gt;<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| ITE<br />
| IT8671F<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| ITE<br />
| IT8673F<br />
| style=&quot;background:yellow&quot; | OK&lt;sup&gt;5&lt;/sup&gt;<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| ITE<br />
| IT8705F<br />
| style=&quot;background:yellow&quot; | OK&lt;sup&gt;5&lt;/sup&gt;<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| ITE<br />
| IT8712F<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| ITE<br />
| IT8716F<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| ITE<br />
| IT8718F<br />
| style=&quot;background:yellow&quot; | OK&lt;sup&gt;5&lt;/sup&gt;<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| 3100<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;15&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| EP80579 (Tolapai)<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;15&lt;/sup&gt;<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC8374<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87309<br />
| style=&quot;background:yellow&quot; | OK&lt;sup&gt;5&lt;/sup&gt;<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87351<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87360<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87366<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87382<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87384<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87392<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87417<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC87427<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC97307 <br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| NSC<br />
| PC97317<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| ServerEngines<br />
| PILOT<br />
| style=&quot;background:yellow&quot; | OK&lt;sup&gt;18&lt;/sup&gt;<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| FDC37M70x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| FDC37B80x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| FDC37B78x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| FDC37B72x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| FDC37B81x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| FDC37M60x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| LPC47B27x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| LPC47M10x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| LPC47M112<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| LPC47M13x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| LPC47M15x<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| LPC47M192<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| LPC47B397<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| DME1737<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| SCH5307<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;12&lt;/sup&gt;<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| SMSC&amp;reg;<br />
| LPC47N217<br />
| style=&quot;background:#dddddd&quot; | ?<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT1211<br />
| style=&quot;background:#eeeeee&quot; | ?<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| VIA<br />
| VT82C686(A/B)<br />
| style=&quot;background:yellow&quot; | OK&lt;sup&gt;5&lt;/sup&gt;<br />
<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Winbond&amp;trade;<br />
| W83627DHG<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Winbond&amp;trade;<br />
| W83627UHG<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Winbond&amp;trade;<br />
| W83627EHG/HF/EHF/THF<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Winbond&amp;trade;<br />
| W83697HF/HG<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Winbond&amp;trade;<br />
| W83627THF/THG<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Winbond&amp;trade;<br />
| W83977F<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Winbond&amp;trade;<br />
| W83977TF<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Winbond&amp;trade;<br />
| W83977EF<br />
| style=&quot;background:lime&quot; | OK&lt;sup&gt;4&lt;/sup&gt;<br />
|}<br />
<br />
| valign=&quot;top&quot;|<br />
<br />
'''CPUs'''<br />
<br />
{| border=&quot;0&quot; style=&quot;font-size: smaller&quot;<br />
|- bgcolor=&quot;#6699dd&quot;<br />
! align=&quot;left&quot; | Type<br />
! align=&quot;left&quot; | CPU<br />
! align=&quot;left&quot; | Status<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| x86<br />
| AMD<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| x86<br />
| Intel&amp;reg;<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| x86<br />
| VIA<br />
| style=&quot;background:lime&quot; | OK<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| Emulated<br />
| QEMU<br />
| style=&quot;background:lime&quot; | OK<br />
|}<br />
<br />
'''SOCs'''<br />
<br />
{| border=&quot;0&quot; style=&quot;font-size: smaller&quot; valign=&quot;top&quot;<br />
|- bgcolor=&quot;#6699dd&quot;<br />
! align=&quot;left&quot; | Vendor<br />
! align=&quot;left&quot; | SOC<br />
! align=&quot;left&quot; | Status<br />
<br />
|- bgcolor=&quot;#eeeeee&quot; valign=&quot;top&quot;<br />
| AMD<br />
| Elan SC520<br />
| style=&quot;background: lime&quot; | OK<br />
|- bgcolor=&quot;#dddddd&quot; valign=&quot;top&quot;<br />
| Intel&amp;reg;<br />
| EP80579 (Tolapai)<br />
| style=&quot;background: yellow&quot; | OK&lt;sup&gt;20&lt;/sup&gt;<br />
|}<br />
<br />
|}<br />
<br />
&lt;small&gt;<br />
&lt;sup&gt;4&lt;/sup&gt; The W83977EF works fine with the W83977TF code (the pre-RAM serial part at least).&lt;br /&gt;<br />
&lt;sup&gt;5&lt;/sup&gt; Pre-RAM serial output works fine, but nothing else, yet.&lt;br /&gt;<br />
&lt;sup&gt;9&lt;/sup&gt; Works mostly, but currently there are some limitations as to which RAM DIMMs can be used.&lt;br /&gt;<br />
&lt;sup&gt;12&lt;/sup&gt; All these Super I/O chips should be supported by the &quot;smscsuperio&quot; driver. Only the ASUS A8000 is tested, though. The floppy disk controller, the parallel port, the serial ports (COM1 + COM2), and the keyboard should work for all chips. More advanced stuff may need more work, though.&lt;br /&gt;<br />
&lt;sup&gt;13&lt;/sup&gt; The ASUS A8000 Super I/O seems to be a rebranded SMSC DME1737.&lt;br /&gt;<br />
&lt;sup&gt;14&lt;/sup&gt; Working, but not widely tested, yet. Works with single DIMM DDR2.&lt;br /&gt;<br />
&lt;sup&gt;15&lt;/sup&gt; The Intel 3100/EP80579 UARTs and watchdog timer are integrated as a Super I/O-like device; only the UARTs have been tested so far.&lt;br /&gt;<br />
&lt;sup&gt;16&lt;/sup&gt; Two implementations: Rev B-C supported in coreboot, Rev D-E support via AGESA&lt;br /&gt;<br />
&lt;sup&gt;17&lt;/sup&gt; MCP55 and CK804 are supported, but no open documents are available from NVIDIA.&lt;br /&gt;<br />
&lt;sup&gt;18&lt;/sup&gt; Partially supported, but not all features implemented.&lt;br /&gt;<br />
&lt;sup&gt;19&lt;/sup&gt; Only support for serial port 1 implemented, everything else is unsupported so far due to lack of datasheet.&lt;br /&gt;<br />
&lt;sup&gt;20&lt;/sup&gt; Working, but not widely tested, yet. Works with single DIMM DDR2.&lt;br /&gt;<br />
&lt;sup&gt;21&lt;/sup&gt; Two Implementations: CIMX SB900 &amp; Hudson 2 and AGESA Hudson 2/3. The AGESA implementation is for Fam15tn and newer.&lt;br /&gt;<br />
&lt;/small&gt;<br />
<br />
__FORCETOC__</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Project_Ideas&diff=15832Project Ideas2015-03-19T18:25:15Z<p>PatrickGeorgi: /* coreboot mainboard test suite */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Development_Guidelines&diff=15751Development Guidelines2015-03-12T16:31:54Z<p>PatrickGeorgi: /* Common License Header */ after talking to lawyers: strip the FSF's address, keep the rest.</p>
<hr />
<div>= Development Environment =<br />
<br />
== Required Toolchain ==<br />
<br />
The easiest way to get a working toolchain is to run &lt;code&gt;make crossgcc&lt;/code&gt; in the toplevel directory of a coreboot checkout. Distributions usually modify their compilers in ways incompatible with coreboot. If in doubt, use our toolchain.<br />
<br />
The toolchain consists of:<br />
* GNU development environment:<br />
** [http://gcc.gnu.org/ GCC with G++]<br />
** [http://www.kernel.org/pub/linux/devel/binutils/ binutils]<br />
* libncurses*-dev<br />
* [http://www.acpica.org/downloads/ IASL], now part of the '''ACPICA''' download (package ''pmtools'' or ''iasl'' in many distributions)<br />
<br />
= Coding Guidelines =<br />
<br />
== General Guidelines ==<br />
<br />
* Encapsulate and isolate assembly language<br />
* Code shall not be &quot;commented out&quot;<br />
* No use of floating-point arithmetics<br />
* No hiding of identifiers defined in outer scopes<br />
* Typedefs are unique (device_t?)<br />
* Functions shall have prototype declarations<br />
* Local functions should be declared static<br />
* No definitions in header files<br />
* All variables are assigned before use<br />
* All objects should have fully qualified types (''unsigned int'' instead of ''unsigned'')<br />
* Types which indicate signedness and bitness should be used (''uint32_t'' or ''u32'' instead of ''unsigned int'')<br />
* We suggest trying to import more such rules, such as additional ones described in [http://www.misra.org.uk/index.htm MISRA-C 2012] (''Guidelines for the use of C in critical systems'')<br />
<br />
== Variable types ==<br />
<br />
Whenever possible, please use a variable type which is explicit about the size of data it can hold. For example, use '''uint32_t''' or '''u32''' instead of '''unsigned long''' when referencing a 32-bit wide register.<br />
<br />
=== short int names vs stdint names ===<br />
<br />
There is '''currently no hard rule''' on whether one should use short int types ('''u32'''), or stdint types ('''uint32_t'''). Whichever type you elect to use, please use common sense and stay consistent.<br />
<br />
== Comments ==<br />
<br />
=== References ===<br />
<br />
If you are referencing a data sheet or other documentation in the code, please add the name or document number in addition to the URL. Vendors just ''love'' to rearrange their websites (and some remove documentation on their old products altogether)! If we have the name/number (or even just the filename of the PDF) at least there's a chance to google for it again (either on the vendor's site or on some archive).<br />
<br />
== Coding Style ==<br />
<br />
* We use the coreboot [[Coding Style]] throughout the project.<br />
* You can use the 'indent' tool to fix the coding style like this:<br />
indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs *.[ch]<br />
:Do not trust 'indent' blindly, though. It sometimes gets things wrong. Manual corrections may be required.<br />
<br />
== The 80 character limit ==<br />
<br />
Lines larger than 80 columns should be broken down into readable pieces. This includes not only source files, but also Makefiles, Kconfig files, and any file meant to be edited by a human. We recommend setting your editor to show the 80th character limit.<br />
This limit is not a relic from long forgotten times, but a very practical and efficient way to organize code and increase productivity. Several files can be edited on the same monitor, without the need to side-scroll. Side-scrolling source files is inefficient, time-consuming, and uncomfortable. On average, 95% of source lines are shorter than 80 characters, so limiting the line length is this manner is not only _not_ an impediment, it also gets you to think on how to best organize the code.<br />
<br />
= Documentation Guidelines =<br />
<br />
== General Guidelines and Tips ==<br />
<br />
* Documentation should be put into the wiki and/or in the code as Doxygen comments<br />
* Avoid using different styles and looks of documentation<br />
* Document ''why'' and ''what'', not ''how'' (No comments like ''/* add one to i */'')<br />
* Document assumptions, stipulations etc...<br />
* Document design and concepts!<br />
* Not lots of documentation but good documentation<br />
* Structured documentation<br />
* Focus: Whom are you addressing in your documentation? Write documentation for users, developers, vendors, ...<br />
<br />
== Automatic documentation ==<br />
<br />
* Doxygen-generated API- and code documentation is available at http://qa.coreboot.org/docs/. This documentation is updated on every 10th checkin.<br />
* To create a Doxygen comment, write<br />
/**<br />
* Sample comment.<br />
*/<br />
:or<br />
/** Sample comment. */<br />
* There are a few commands that describe what kind of comment you are adding:<br />
::@param &amp;mdash; input parameters of a function<br />
::@return &amp;mdash; return value of a function<br />
* A list of all commands is available at http://www.stack.nl/~dimitri/doxygen/commands.html<br />
<br />
Full example:<br />
<br />
/**<br />
* Calculate the length of a string.<br />
*<br />
* @param str The input string.<br />
* @return The length of the string, not including the final NUL character.<br />
*/<br />
static inline size_t strlen(const char *str)<br />
{<br />
/* ... */<br />
}<br />
<br />
= Testing =<br />
<br />
Every commit will be processed by the autobuild and autotest system available at http://qa.coreboot.org/. In addition please run autobuild yourself before submitting patches.<br />
<br />
== autobuild ==<br />
<br />
Autobuild can be found at [http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/abuild;hb=HEAD coreboot/util/abuild]. <br />
<br />
Please run ''abuild'' '''before''' you commit.<br />
<br />
Autobuild is also running on every check-in to the repository. The results of this build are also available at http://qa.coreboot.org/.<br />
<br />
== autotest ==<br />
<br />
We can also run automatic tests on boards, if we find contributors willing to have a board automatically managed by our QA system. This requires a permanent connection to the net, a host system and some special circuitry. If interested, please contact us using the [[Mailinglist|mailing list]].<br />
<br />
= How to contribute =<br />
<br />
== Creating Patches ==<br />
<br />
* We use gerrit for change management, using the instance on http://review.coreboot.org/<br />
* While not necessary with gerrit, '''make sure that your change is against current master'''. Patches that fail on merge (after some developer looked at it and approved it) might linger around until '''you''' update it.<br />
* Rebase, if necessary, '''then test''' again. You might be the only contributor with that specific mainboard.<br />
* Make sure all new and modified files contain the [[Development Guidelines#Common_License_Header|proper license headers]] (see below).<br />
* Make sure all added files are actually within the commit.<br />
* Make one commit per logical change.<br />
* For more details on using gerrit, see our [[Git]] documentation. Things are somewhat different (eg. it's normal to rebase changes that were already pushed).<br />
* Double-check that your changes are correct, and that the commit only contains what you think it contains.<br />
<br />
== Sign-off Procedure ==<br />
<br />
We employ a similar sign-off procedure for coreboot <br />
[http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html as the Linux kernel developers] do.<br />
Please add a note such as<br />
Signed-off-by: Random J Developer &lt;random@developer.example.org&gt;<br />
to your email/patch if you agree with the following Developer's Certificate of Origin 1.1.<br />
<br />
Patches without a Signed-off-by cannot be pushed to gerrit!<br />
<br />
&lt;span style=&quot;color:red&quot;&gt;You have to use your real name in the Signed-off-by line and in any copyright notices you add.&lt;/span&gt; Patches without an associated real name cannot be committed!<br />
<br />
'''Developer's Certificate of Origin 1.1:'''<br />
<br />
By making a contribution to this project, I certify that:&lt;br /&gt;<br />
(a) The contribution was created in whole or in part by me and I have<br />
the right to submit it under the open source license indicated in the file; or&lt;br /&gt;<br />
(b) The contribution is based upon previous work that, to the best of my<br />
knowledge, is covered under an appropriate open source license and I have the<br />
right under that license to submit that work with modifications, whether created<br />
in whole or in part by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated in the file; or&lt;br /&gt;<br />
(c) The contribution was provided directly to me by some other person who<br />
certified (a), (b) or (c) and I have not modified it; and&lt;br /&gt;<br />
(d) In the case of each of (a), (b), or (c), I understand and agree that<br />
this project and the contribution are public and that a record of the contribution<br />
(including all personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with this project or the<br />
open source license indicated in the file.<br />
<br />
&lt;small&gt;Note: The [http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_releases/2004/2004_05_24_dco.html Developer's Certificate of Origin 1.1] is licensed under the terms of the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5 License].&lt;/small&gt;<br />
<br />
== Reviews ==<br />
<br />
* Send your patch to [[Git|gerrit]] for review.<br />
** Provide useful commit messages. Explain what the change does and why. Our short intro to [[Git|git]] explains the format in more detail.<br />
** Add a single line containing your &quot;[[Development Guidelines#Sign-off_Procedure|sign-off]]&quot; after the description of the patch (&lt;code&gt;git commit -s&lt;/code&gt; helps, but make sure you understand and comply with the DCO).<br />
*** Example: ''Signed-off-by: John Doe &lt;john@example.com&gt;''<br />
* The developers will review and/or test your change and send comments or suggestions. Please push updated patches as described in &quot;[[Git#Evolving_patches|evolving patches]]&quot;.<br />
* If the change looks ok to one or more developers, they will approve and submit it to the master branch.<br />
<br />
= Bug-Tracker =<br />
<br />
'''note: the bug tracker is dead. more or less.'''<br />
<br />
= License Issues =<br />
<br />
* Contributed code must be GPL'd (preferrably 'GPLv2 or any later version', but 'GPLv2' is fine, too). At the very minimum the code must have a GPL-compatible license.<br />
<br />
== Common License Header ==<br />
<br />
Please quote the full GPL license header text in every file, as shown below. It should contain:<br />
<br />
* The '''year(s)''' when the code was written or modified and a '''copyright note''' of you (or your company, if you are contributing as part of your employment, and thus the copyright belongs to your company). Also, please provide an '''email address''' so that you can be contacted if questions arise.<br />
** Example:<br />
::''Copyright (C) 2006 John Doe &lt;john@example.com&gt;''<br />
::''Copyright (C) 2004-2006 Company, Inc.''<br />
* An extra line which lists the '''author of the code, if the copyright holder is not the same as the author''' (e.g. if you work for a company and the company owns the copyright).<br />
** Example:<br />
::''Copyright (C) 2004-2006 Company, Inc.''<br />
::''(Written by Janet Doe &lt;janet@example.com&gt; for Company, Inc.)''<br />
* The full '''GPL header''' as shown below.<br />
<br />
'''Complete example for *.c and *.h files:'''<br />
<br />
/*<br />
* This file is part of the coreboot project.<br />
*<br />
* Copyright (C) 2003-2005 John Doe &lt;john@example.com&gt;<br />
* Copyright (C) 2005 Jane Doe &lt;jane@example.com&gt;<br />
* Copyright (C) 2006 Company, Inc.<br />
* (Written by Janet Doe &lt;janet@example.com&gt; for Company, Inc.)<br />
* Copyright (C) 2007 Joe Doe &lt;joe@example.com&gt;<br />
*<br />
* This program is free software; you can redistribute it and/or modify<br />
* it under the terms of the GNU General Public License as published by<br />
* the Free Software Foundation; either version 2 of the License, or<br />
* (at your option) any later version.<br />
*<br />
* This program is distributed in the hope that it will be useful,<br />
* but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
* GNU General Public License for more details.<br />
*<br />
* You should have received a copy of the GNU General Public License<br />
* along with this program; if not, write to the Free Software<br />
* Foundation, Inc.<br />
*/<br />
<br />
'''Complete example for Makefiles, config files, Python files, shell scripts etc.:'''<br />
<br />
##<br />
## This file is part of the coreboot project.<br />
##<br />
## Copyright (C) 2003-2005 John Doe &lt;john@example.com&gt;<br />
## Copyright (C) 2005 Jane Doe &lt;jane@example.com&gt;<br />
## Copyright (C) 2006 Company, Inc.<br />
## (Written by Janet Doe &lt;janet@example.com&gt; for Company, Inc.)<br />
## Copyright (C) 2007 Joe Doe &lt;joe@example.com&gt;<br />
##<br />
## This program is free software; you can redistribute it and/or modify<br />
## it under the terms of the GNU General Public License as published by<br />
## the Free Software Foundation; either version 2 of the License, or<br />
## (at your option) any later version.<br />
##<br />
## This program is distributed in the hope that it will be useful,<br />
## but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
## GNU General Public License for more details.<br />
##<br />
## You should have received a copy of the GNU General Public License<br />
## along with this program; if not, write to the Free Software<br />
## Foundation, Inc.<br />
##</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Project_Ideas&diff=15747Project Ideas2015-03-11T06:29:03Z<p>PatrickGeorgi: /* Tianocore as payload */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Project_Ideas&diff=15746Project Ideas2015-03-11T06:28:37Z<p>PatrickGeorgi: /* Tianocore as payload */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Project_Ideas&diff=15745Project Ideas2015-03-11T06:25:55Z<p>PatrickGeorgi: /* Tianocore as payload */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Blob_Matrix&diff=15734Blob Matrix2015-03-09T16:17:28Z<p>PatrickGeorgi: /* Blob Matrix */</p>
<hr />
<div>== Introduction ==<br />
This the the Blob Matrix. What is the Blob Matrix? It is a table in which we define, for different systems, what blobs there are. The goal is to have a common reference of types of blobs. Until we're sure we have the right list we don't need the matrix yet.<br />
<br />
Consider, for example, the Google Pixel laptop. We can identify the following CPUs that affect coreboot or that it uses:<br />
EC, <br />
ME, <br />
main CPU.<br />
<br />
For this example, we have the following blobs:<br />
ME, blob from Intel (replaceable, signed);<br />
main CPU: microcode (not practically replaceable), MRC (not practically replaceable), VGA BIOS (replaceable, proof of concept in repo).<br />
<br />
Here is another system, the Snow Chromebook. It has an EC and a main CPU. The blobs are<br />
main CPU: BL0 (not replaceable), and BL1 (replaceable, signed). <br />
<br />
My old x60, with coreboot on it:<br />
EC: EC OS (not replaceable);<br />
main CPU: microcode, BIOS, VGA BIOS<br />
<br />
Let's consider the first coreboot systems, the l440gx, PowerPC, and Alpha<br />
<br />
The l440GX had no CPUs save the main CPU, and all of linuxbios was open. There was no ACPI or SMM. <br />
<br />
The PowerPC was, similarly, blob free.<br />
<br />
We think the Alpha had an EC, which was closed and had a blob; it was otherwise blob free.<br />
<br />
== Blob Matrix ==<br />
{| border=&quot;0&quot; style=&quot;font-size: smaller&quot;<br />
|- bgcolor=&quot;#6699ff&quot;<br />
! rowspan=&quot;2&quot; align=&quot;left&quot; | Mainboard<br />
! rowspan=&quot;2&quot; align=&quot;left&quot; | Chipset<br />
! colspan=&quot;9&quot; align=&quot;center&quot; | Blobs<br />
! rowspan=&quot;2&quot; align=&quot;left&quot; | Notes<br />
|-<br />
|- bgcolor=&quot;#6699ff&quot;<br />
! align=&quot;left&quot; | [[Embedded_controller|EC]]<br />
! align=&quot;left&quot; | ME / Signed &amp; Type<br />
! align=&quot;left&quot; | Mask ROM<br />
! align=&quot;left&quot; | Reset vector / Signed?<br />
! align=&quot;left&quot; | Microcode<br />
! align=&quot;left&quot; | [[VGA support|VGA]]<br />
! align=&quot;left&quot; | [https://en.wikipedia.org/wiki/System_Management_Mode SMM]<br />
! align=&quot;left&quot; | [https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface ACPI]<br />
! align=&quot;left&quot; | Runtime <br />
|- bgcolor=&quot;#dddddd&quot;<br />
| Google Pixel<br />
| Sandybridge<br />
| {{ButNo|[https://git.chromium.org/git/chromiumos/platform/ec.git FLOSS]}}<br />
| {{Panic|level=high|Yes / Yes; Unknown}}<br />
| No<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
|<br />
<br />
|- bgcolor=&quot;#dddddd&quot;<br />
| Intel Galileo<br />
| Quark<br />
| {{ButNo|No EC}}<br />
| {{ButNo|No ME&lt;ref name=&quot;Galileo-RMU&quot;&gt;but a Remote Management Unit&lt;/ref&gt;}}<br />
| Yes<br />
| No&lt;ref name=&quot;Galileo-signatures&quot;&gt;Intel Quark exists in two different versions, a &quot;Base&quot; SKU and a &quot;Secure&quot; SKU. The following applies to the Secure SKU, but Galileo comes with the &quot;Base&quot; model.<br />
<br />
We make a key, Intel signs the key, we use the signing tool to sign our binary.<br />
The signing utility is part of the BSP on communities.intel.com.<br />
( https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23197)<br />
The Customer is required to provide a public RSA key that is derived from a Private key that conforms to the following:<br />
* Each RSA keypair shall be 2048 bits in length.<br />
* Each RSA keypair shall be formatted as an ASN1 RSAPrivateKey DER certificate as defined in the RSA PKCS#1 document.<br />
<br />
We expect to receive a .pem file that contains only the public components of the Customer RSA 2048 key.<br />
&lt;/ref&gt;<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes: EFI<br />
|<br />
|- bgcolor=&quot;#dddddd&quot;<br />
| Lenovo<br />
* x60<br />
* x60s<br />
* x60t<br />
| i945<br />
| Yes, probably inside the ec's flash.<br />
| {{ButNo|No ME}}<br />
|<br />
* [[Intel_82573_Ethernet_controller#Hardware_description|NIC]]<br />
| {{ButNo|None}}<br />
| Yes &lt;ref name=&quot;microcode&quot;&gt;Intel microcode, some CPU do work without it, but they will be affected by the erratas fixed by the microcode. Note that selecting &quot;Include CPU microcode in CBFS (Do not include microcode updates)&quot; often still includes the microcode. The microcode is removed by [http://libreboot.org/ libreboot.org] &lt;/ref&gt;<br />
| Can be replaced&lt;ref name=&quot;patches-remaining&quot;&gt;Can be replaced in coreboot. Some remaining patches need to be merged.&lt;/ref&gt;<br />
| {{ButNo|None}}<br />
| {{ButNo|None}}<br />
| {{ButNo|None}}<br />
| <br />
|}<br />
<br />
== References ==<br />
&lt;references/&gt;<br />
<br />
[[Category:Blobs|Blobs]]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Blob_Matrix&diff=15733Blob Matrix2015-03-09T16:14:31Z<p>PatrickGeorgi: /* Blob Matrix */</p>
<hr />
<div>== Introduction ==<br />
This the the Blob Matrix. What is the Blob Matrix? It is a table in which we define, for different systems, what blobs there are. The goal is to have a common reference of types of blobs. Until we're sure we have the right list we don't need the matrix yet.<br />
<br />
Consider, for example, the Google Pixel laptop. We can identify the following CPUs that affect coreboot or that it uses:<br />
EC, <br />
ME, <br />
main CPU.<br />
<br />
For this example, we have the following blobs:<br />
ME, blob from Intel (replaceable, signed);<br />
main CPU: microcode (not practically replaceable), MRC (not practically replaceable), VGA BIOS (replaceable, proof of concept in repo).<br />
<br />
Here is another system, the Snow Chromebook. It has an EC and a main CPU. The blobs are<br />
main CPU: BL0 (not replaceable), and BL1 (replaceable, signed). <br />
<br />
My old x60, with coreboot on it:<br />
EC: EC OS (not replaceable);<br />
main CPU: microcode, BIOS, VGA BIOS<br />
<br />
Let's consider the first coreboot systems, the l440gx, PowerPC, and Alpha<br />
<br />
The l440GX had no CPUs save the main CPU, and all of linuxbios was open. There was no ACPI or SMM. <br />
<br />
The PowerPC was, similarly, blob free.<br />
<br />
We think the Alpha had an EC, which was closed and had a blob; it was otherwise blob free.<br />
<br />
== Blob Matrix ==<br />
{| border=&quot;0&quot; style=&quot;font-size: smaller&quot;<br />
|- bgcolor=&quot;#6699ff&quot;<br />
! rowspan=&quot;2&quot; align=&quot;left&quot; | Mainboard<br />
! rowspan=&quot;2&quot; align=&quot;left&quot; | Chipset<br />
! colspan=&quot;9&quot; align=&quot;center&quot; | Blobs<br />
! rowspan=&quot;2&quot; align=&quot;left&quot; | Notes<br />
|-<br />
|- bgcolor=&quot;#6699ff&quot;<br />
! align=&quot;left&quot; | [[Embedded_controller|EC]]<br />
! align=&quot;left&quot; | ME / Signed &amp; Type<br />
! align=&quot;left&quot; | Mask ROM<br />
! align=&quot;left&quot; | Reset vector / Signed?<br />
! align=&quot;left&quot; | Microcode<br />
! align=&quot;left&quot; | [[VGA support|VGA]]<br />
! align=&quot;left&quot; | [https://en.wikipedia.org/wiki/System_Management_Mode SMM]<br />
! align=&quot;left&quot; | [https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface ACPI]<br />
! align=&quot;left&quot; | Runtime <br />
|- bgcolor=&quot;#dddddd&quot;<br />
| Google Pixel<br />
| Sandybridge<br />
| {{ButNo|[https://git.chromium.org/git/chromiumos/platform/ec.git FLOSS]}}<br />
| {{Panic|level=high|Yes / Yes; Unknown}}<br />
| No<br />
| No<br />
| Yes<br />
| Yes<br />
| No<br />
| No<br />
| No<br />
|<br />
<br />
|- bgcolor=&quot;#dddddd&quot;<br />
| Intel Galileo<br />
| Quark<br />
| {{ButNo|No EC}}<br />
| {{ButNo|No ME&lt;ref name=&quot;Galileo-RMU&quot;&gt;but a Remote Management Unit&lt;/ref&gt;}}<br />
| Yes<br />
| Yes&lt;ref name=&quot;Galileo-signatures&quot;&gt;Intel Quark exists in two different versions, a &quot;Base&quot; SKU and a &quot;Secure&quot; SKU. The following applies to the Secure SKU, but Galileo comes with the &quot;Base&quot; model.<br />
<br />
We make a key, Intel signs the key, we use the signing tool to sign our binary.<br />
The signing utility is part of the BSP on communities.intel.com.<br />
( https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23197)<br />
The Customer is required to provide a public RSA key that is derived from a Private key that conforms to the following:<br />
* Each RSA keypair shall be 2048 bits in length.<br />
* Each RSA keypair shall be formatted as an ASN1 RSAPrivateKey DER certificate as defined in the RSA PKCS#1 document.<br />
<br />
We expect to receive a .pem file that contains only the public components of the Customer RSA 2048 key.<br />
&lt;/ref&gt;<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes<br />
| Yes: EFI<br />
|<br />
|- bgcolor=&quot;#dddddd&quot;<br />
| Lenovo<br />
* x60<br />
* x60s<br />
* x60t<br />
| i945<br />
| Yes, probably inside the ec's flash.<br />
| {{ButNo|No ME}}<br />
|<br />
* [[Intel_82573_Ethernet_controller#Hardware_description|NIC]]<br />
| {{ButNo|None}}<br />
| Yes &lt;ref name=&quot;microcode&quot;&gt;Intel microcode, some CPU do work without it, but they will be affected by the erratas fixed by the microcode. Note that selecting &quot;Include CPU microcode in CBFS (Do not include microcode updates)&quot; often still includes the microcode. The microcode is removed by [http://libreboot.org/ libreboot.org] &lt;/ref&gt;<br />
| Can be replaced&lt;ref name=&quot;patches-remaining&quot;&gt;Can be replaced in coreboot. Some remaining patches need to be merged.&lt;/ref&gt;<br />
| {{ButNo|None}}<br />
| {{ButNo|None}}<br />
| {{ButNo|None}}<br />
| <br />
|}<br />
<br />
== References ==<br />
&lt;references/&gt;<br />
<br />
[[Category:Blobs|Blobs]]</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=Project_Ideas&diff=15646Project Ideas2015-02-28T21:33:10Z<p>PatrickGeorgi: /* coreboot mainboard test suite */</p>
<hr />
<div></div>PatrickGeorgihttp://www.coreboot.org/index.php?title=User_talk:PatrickGeorgi&diff=15637User talk:PatrickGeorgi2015-02-19T07:54:39Z<p>PatrickGeorgi: /* Bad faith typically doesn't play a part in the scheme of things */</p>
<hr />
<div>= Community Code of Conduct =<br />
<br />
This is a work in progress. Might or might not become applicable to the project. As in, ever. We'll see.<br />
<br />
Problems with the CoC: It's specific to US issues and sensibilities, ignoring that coreboot is a global project. That its base document (the citizen code of conduct) is more targetted at events (and not online communities) shines through the cracks more than envisioned.<br />
<br />
Objectives: a set of reminders to keep our community civil even when debating contentious topics.<br />
<br />
== Principles of the CCoC ==<br />
Online communities like ours are not like physical communities. There are things that work well in real life, that aren't quite as suitable in the coreboot community.<br />
<br />
=== We're global and that breaks lots of assumptions ===<br />
People may be sensitive to different topics than what you're used to. There are language barriers and cultural differences. While it's hard-to-impossible to keep track of everything at all times, be prepared that your hilarious joke might face a luke-warm reaction (or worse).<br />
<br />
=== Most of the time, there's a person at the other end ===<br />
Even when jumping at the throat of an online service someone in our community set up, there's someone maintaining it. They might not appreciate you going ballistic at the work they do for the community, often in their spare time. Same applies to code, which leads to:<br />
<br />
=== Don't assume incompetence in others (and their contributions) ===<br />
Just because a piece of code is unsuitable for your purpose doesn't mean that it's entirely broken, completely useless, and so on. And just because it's broken now doesn't mean it never worked. Chances are that every piece of code in our repository worked at some point in some configuration.<br />
<br />
Diminishing the efforts of others is discouraging, and a community gets healther by encouragement. Improving the code? Sure, that's great. Assuming everything in the tree is crap - please no.<br />
<br />
As a side note, even when people are acting stupid in conversation, there are many more options to deal with that besides publicly heaping scorn on them, among them: teaching them, ignoring them, or discussing the matter privately (which may lead to one of the others).<br />
<br />
=== Bad faith typically doesn't play a part in the scheme of things ===<br />
There are trolls out there on the internet, but they're usually clearly visible from a long distance. Especially in a highly technical project like coreboot where &quot;faking it&quot; is rather hard. Other than that, most people actually try to do good, not bad. In some cases, incompetence or a lack of care about coreboot is can be mistaken as bad faith.<br />
<br />
=== Representing the community should show us at our best ===<br />
Try not to offend others if you speak on behalf of the coreboot project. Some people will be offended by the mere suggestion that coreboot is better than their BIOS/EFI, but that can't be helped. Some people are professionals at being offended, don't let them derail you. It might help to avoid showing non-technical pictures or referring to any societal issues.</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=User_talk:PatrickGeorgi&diff=15636User talk:PatrickGeorgi2015-02-19T07:53:16Z<p>PatrickGeorgi: /* Don't assume incompetence in others (and their contributions) */</p>
<hr />
<div>= Community Code of Conduct =<br />
<br />
This is a work in progress. Might or might not become applicable to the project. As in, ever. We'll see.<br />
<br />
Problems with the CoC: It's specific to US issues and sensibilities, ignoring that coreboot is a global project. That its base document (the citizen code of conduct) is more targetted at events (and not online communities) shines through the cracks more than envisioned.<br />
<br />
Objectives: a set of reminders to keep our community civil even when debating contentious topics.<br />
<br />
== Principles of the CCoC ==<br />
Online communities like ours are not like physical communities. There are things that work well in real life, that aren't quite as suitable in the coreboot community.<br />
<br />
=== We're global and that breaks lots of assumptions ===<br />
People may be sensitive to different topics than what you're used to. There are language barriers and cultural differences. While it's hard-to-impossible to keep track of everything at all times, be prepared that your hilarious joke might face a luke-warm reaction (or worse).<br />
<br />
=== Most of the time, there's a person at the other end ===<br />
Even when jumping at the throat of an online service someone in our community set up, there's someone maintaining it. They might not appreciate you going ballistic at the work they do for the community, often in their spare time. Same applies to code, which leads to:<br />
<br />
=== Don't assume incompetence in others (and their contributions) ===<br />
Just because a piece of code is unsuitable for your purpose doesn't mean that it's entirely broken, completely useless, and so on. And just because it's broken now doesn't mean it never worked. Chances are that every piece of code in our repository worked at some point in some configuration.<br />
<br />
Diminishing the efforts of others is discouraging, and a community gets healther by encouragement. Improving the code? Sure, that's great. Assuming everything in the tree is crap - please no.<br />
<br />
As a side note, even when people are acting stupid in conversation, there are many more options to deal with that besides publicly heaping scorn on them, among them: teaching them, ignoring them, or discussing the matter privately (which may lead to one of the others).<br />
<br />
=== Bad faith typically doesn't play a part in the scheme of things ===<br />
There are trolls out there on the internet, but they're usually clearly visible from a long distance. Especially in a highly technical project like coreboot where &quot;faking it&quot; is rather hard. Other than that, most people actually try to do good, not bad. In some cases, incompetence or lack of care about coreboot is indistinguishable from bad faith.<br />
<br />
=== Representing the community should show us at our best ===<br />
Try not to offend others if you speak on behalf of the coreboot project. Some people will be offended by the mere suggestion that coreboot is better than their BIOS/EFI, but that can't be helped. Some people are professionals at being offended, don't let them derail you. It might help to avoid showing non-technical pictures or referring to any societal issues.</div>PatrickGeorgihttp://www.coreboot.org/index.php?title=User_talk:PatrickGeorgi&diff=15630User talk:PatrickGeorgi2015-02-19T00:05:11Z<p>PatrickGeorgi: </p>
<hr />
<div>= Community Code of Conduct =<br />
<br />
This is a work in progress. Might or might not become applicable to the project. As in, ever. We'll see.<br />
<br />
Problems with the CoC: It's specific to US issues and sensibilities, ignoring that coreboot is a global project. That its base document (the citizen code of conduct) is more targetted at events (and not online communities) shines through the cracks more than envisioned.<br />
<br />
Objectives: a set of reminders to keep our community civil even when debating contentious topics.<br />
<br />
== Principles of the CCoC ==<br />
Online communities like ours are not like physical communities. There are things that work well in real life, that aren't quite as suitable in the coreboot community.<br />
<br />
=== We're global and that breaks lots of assumptions ===<br />
People may be sensitive to different topics than what you're used to. There are language barriers and cultural differences. While it's hard-to-impossible to keep track of everything at all times, be prepared that your hilarious joke might face a luke-warm reaction (or worse).<br />
<br />
=== Most of the time, there's a person at the other end ===<br />
Even when jumping at the throat of an online service someone in our community set up, there's someone maintaining it. They might not appreciate you going ballistic at the work they do for the community, often in their spare time. Same applies to code, which leads to:<br />
<br />
=== Don't assume incompetence in others (and their contributions) ===<br />
Just because a piece of code is unsuitable for your purpose doesn't mean that it's entirely broken, completely useless, and so on. And just because it's broken now doesn't mean it never worked. Chances are that every piece of code in our repository worked at some point in some configuration.<br />
<br />
Diminishing the efforts of others is discouraging, and a community gets healther by encouragement. Improving the code? Sure, that's great. Assuming everything in the tree is crap - please no.<br />
<br />
=== Bad faith typically doesn't play a part in the scheme of things ===<br />
There are trolls out there on the internet, but they're usually clearly visible from a long distance. Especially in a highly technical project like coreboot where &quot;faking it&quot; is rather hard. Other than that, most people actually try to do good, not bad.</div>PatrickGeorgi