Re: [coreboot] Rebuilding coreboot image generation

[Patrick Georgi via coreboot]

2015-11-09 21:47 GMT+01:00 Julius Werner :
> If Intel's architectural requirements force us to have a component
> that must be linked at an exact spot in the image, I think it would
> only be consistent to use the tool that we have which is meant for
> these sorts of things... FMAP.
It must be linked to the location it was relocated to. That could even
change over time. Just like x86s execute-in-place romstage.

Updates may end up at a different location, and they will likely have
a different size. For all we know, updates may grow beyond the space
we reserve for FSP in FMAP (which is read-only on Chromebooks). It
would be unfortunate to have empty space, just in the wrong region,
and run into problems doing an update because of that.

I don't think the layout constraints we can impose on files in CBFS
are much of a problem, and there's not much overlap: As I understand
things, FMAP exists for higher-order partitioning; for things that the
current instance of coreboot need not to care about, like a separate
copy of coreboot in flash, or chipset data that is none of the CPU
firmware's business (ME and the like). FMAP is also suitable for
writable fixed-size sections (like MRC cache) that we want to keep far
away from the CBFS chain.

The other reason (besides file constraints) for this proposal is to
enable the payload's build system to describe the files they need to
add to CBFS themselves (and without knowing which FMAP regions the
payload needs to end up in). depthcharge definitely needs something
along those lines so we can get rid of that spaghetti code that is
bundle_firmware.py. I think grub2 (and to some degree, seabios) could
also benefit from dealing with their configuration files themselves in
a structured way.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting up a bug tracker

[Stefan Reinauer]

* Timothy Pearson  [151103 20:55]:
> Is Bugzilla out of the question?
 
I would like Bugzilla, too. 

Stefan
 

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ASUS KCMA-D8 workstation board port offer

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

After reviewing some of the comments on the ASUS KGPE-D16 being
essentially too large of a system and too expensive for many people, and
the fact that modern, blob-free systems are not really available in the
mid-range arena, Raptor Engineering would like to offer to create a
native initalization blob-free port for the ASUS KCMA-D8, which is
essentially the KGPE-D16's ATX-compatible "little brother".

We would be asking $15,000 for the port, including upstreaming to the
master coreboot tree.  We already have extensive experience with these
Family 10h/15h boards, and would be able to create a port of similar
quality to the existing KGPE-D16 source in terms of both code quality
and overall functionality.

If this is something you might be interested in please let me know.  We
are able to accept multiple payments from various sources for the same
project (within limits), so if this is something your local Linux groups
or similar might be interested in we should be able to keep the cost on
any one individual or organization to a reasonable level.

Thank you for your consideration,

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWQROpAAoJEK+E3vEXDOFbR2cH/3FTqGFH+cU/HVrBUPcoKjii
h9OC7SGeXdyoLZvob/YayG+g47Yppkg2um4pAC7dmGl/OXtkGh13hlsrQ8BNiYcz
g0kQUdNKYh9dmBC3YnlxU6a7psh473TdyuLILrl7/8WgI8DZnRtjy62Oo5k6XAKW
jfYb/bGC8I3tArYrgQDmFxz2dOejuTZit56I+mbWNtvbuQov2BDmrPPMLRuEvG3M
QHCAo/Pjaajzl4rmtrgu0GHcxHsgAnJcnrcPkFYeSDKt7QxSTNOB6NqhcnYdh1SY
RiA5Z/3enuDs+XNhS+6qMeKOcrEuf+Ccs7sGsgq5tWm20JA+bBoByvrXhHqVUxU=
=DKfR
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting up a bug tracker

[Stefan Reinauer]

* Patrick Georgi  [151105 19:00]:
> 2015-11-04 16:57 GMT+01:00 Martin Roth :
> > - Are there any required login methods? Does it need to support the
> > login types that review.coreboot.org supports?
> redmine has an omniauth plugin that should allow OpenID and OAuth2
> (Google/Github flavor).
> I'd prefer using that over yet another account database.

+2!

> > - Is (anonymous) public reporting desired, or do we want to require
> > sign-in and user validation first? (I'd vote for sign in)
> We're lucky with gerrit (or maybe OpenID is enough of a hurdle), but
> anonymous bug trackers tend to be extremely maintenance heavy to sort
> out the spam.
> I'd go for requesting OpenID/OAuth accounts, similar to gerrit.

Looking at how long it took for people to stop sending award bios
disassemblies around to the mailing list, I strongly encourage not
having an anonymous service. It's not doing the project a good service.

Stefan


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting up a bug tracker

[Alexander Couzens]

Hi,

I've started to setup a redmine. 
The openid integration seems to need more improvements,
but it should work as soon ssl works (and a another patch applied).

@Stefan/Patrick Can you create a CName for ticket.coreboot.org -> 
coreboot.dtn10.de

Next question is, how we handle the ssl stuff. Should we try let's encrypt?

Best
lynxis

On Thu, 5 Nov 2015 09:15:41 -0800
"Alex G."  wrote:
> Let's try it.

-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgpyaf5EpRcjg.pgp
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] coreboot leadership meeting notes for October 29, 2015

[Martin Roth]

The coreboot leadership is making a number of changes to be more open
than they have been in the past. Releasing the minutes of the
discussions that are being held regularly is another step towards this
goal.  The first couple sets of minutes are delayed a bit while
figuring out the process, but going forward, the plan is to release
the minutes by the Monday following the meeting.

Please feel free to make comments and ask questions.


Attendance:
---
Ron, Stefan, Patrick, Martin, Marc, Furquan


Discussion:
---
* Blobs policy document:
- Paul was the main commenter so far
 - Q: What's the point of contact?   A: Use the mailing list
- Marcj to post pointer to the doc in gerrit to the mailing list

* Document: Gerrit policies and expectations
- Document was reviewed.
- Martin will post it on gerrit and to the mailing list for wider review.

* Document: Things the coreboot community can improve
- What are our priorities?
 - Martin would love to see more documentation (and form a doc team)
- Discussed promoting John Lewis, libreboot, and autoboot on the
coreboot.org landing page.
- This list of things the community can improve can be seen on page 8
of Marcj's community involvement presentation from Bonn:
https://goo.gl/XYLHja

* Discuss next coreboot meetings (Paris, Americas, Bonn 2016)
- Paris in April 2016, US meeting in October 2016, Bonn in April 2017?
- requires more lead time for travel scheduling at orgs
- e.g. Some USG orgs need to know foreign travel on Dec. 31 of previous year
- Need some kind of conference org team
- Need a strategy to reuse planning docs for future events
 - Martin will make a shared GDrive folder.

* Deleting mainboards / code
- ibm e325/e326 should go. (says the guy who put them there originally)
- newisys khepri should go.
- Stefan contacted Via to see if they want to keep some old stuff alive.

* Branch strategy - Do we need a plan for branching off a portion of
the  existing code and mainboards to reduce maintenance and make it
easier  to go forward?  5.0 branch?
- short-term proposal: boards that aren’t in board-status are deleted
after release 4.4. This gives 6 months to get boards into
board-status.
- long-term proposal: in 3 years (eg. 2019-01-01), boards need to be
testable for every commit (eg. REACTS). Ideally, vendors should be
able to run board-testing on their own.

* coreboot 4.2 release
- Finish it this week
- Need to do some testing across hardware

* Tool for dealing with subsystem maintainers
- Stefan will send out more information on what needs to be done

* Releasing meeting notes
- Martin to format and release meeting notes.

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Rebuilding coreboot image generation

[Julius Werner]

> Again then this becomes an inconsistency on Chrome OS. FSP lives in
> RO, RW-A, and RW-B regions. RW-A and RW-B will be CBFS. So do make it
> it partly CBFS and partly FMAP such that the code is consistent to use
> FMAP APIs throughout? In my opinion that isn't appropriate. From a
> "change this little bit of code here" thing it's doable. But from
> looking at source code I standpoint such it's inconsistent. Sure FMAP
> would be used in certain places, but I'd argue those are in the
> infrastructure parts that many people porting things don't deal with.
> I don't want people to head scratch where something should live and
> then figure out 1. how to access it and 2. how to add it properly. The
> latter is still not plumbed in anywhere in the build system.

Okay, I guess we disagree on that one, then. In my opinion, the
biggest problem and inconsistency here is that we have a CBFS file
that needs to be placed at an exact offset (breaking the whole concept
of CBFS as a "file system" that can transparently manage its space
allocation). I think this is something that was done in the past for
lack of a better option, but that can and should be fixed when a
better tool (FMAP) is available. In my recollection/perspective, this
was the biggest reason we decided to combine CBFS and FMAP in the same
image in the first place (as opposed to porting all the Chrome OS /
vboot tools over to access CBFS and have the whole Chrome OS image be
a single (enhanced) CBFS)... because we acknowledged that FMAP's
strengths (global lookup table, rigid regions that can be exactly
aligned to custom offsets or erase blocks) are completely different
and complementary to CBFS's strengths (organizing many small files in
a compact, easy to manage format with automatic, opaque layout).

If Intel's architectural requirements force us to have a component
that must be linked at an exact spot in the image, I think it would
only be consistent to use the tool that we have which is meant for
these sorts of things... FMAP. It makes the intention (of placing it
*exactly there*) very explicit, and it frees up CBFS from weird
requirements that you wouldn't expect (e.g. the RO CBFS must encompass
that region, you need to pay attention to the order you add files in,
etc.). If that makes the code that handles it more complicated that's
unfortunate, and we should try to mitigate it where we can (maybe hide
differences with an extra FSP access API, or have all chipsets keep it
in its own FMAP section (maybe even in RW?) even though only some
really need that, or find a way / ask Intel to separate the
location-dependent part out into a separate blob)... but it still
seems like a smaller price to me than keeping the separation of duties
between FMAP and CBFS muddied and imposing all of those weird
restrictions on the latter for this one special case.

I should probably stop arguing this because I don't even know the
Intel code this is for... if you and all other x86 developers think
the FSP really must go in CBFS I'll shut up. It's also really only
tangentially related to the original discussion about the build system
architecture... but I brought it up because some of the benefits
Patrick's approach is trying to achieve (being able to better control
CBFS file ordering) should be irrelevant in my opinion, and only even
exist because of this problem.

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus M2N-E no boot, post codes A5 80 73

[Balázs Vinarz]

Hi,
the first postlog is the same, so A5-80 in an endless loop, there was one
time when its end with 79 then shuts down itself, thistime the memory is in
the B1 slot.
I was made a video at 60fps, and its more accurate, so the sequence is
FF-88-80-88-78-72-28-29-24-29-25-55-89-73 than a shutdown, this time the
memory is in the A1 slot.
Im using a single-core Athlon64 3000+. I will have a try with the 2012
source, if i found one. Sadly im working on ramdisk, and the toolchain
compile takes a while even if 4 cores :) Im also considering to build a
parmanents toolchain, but thats my own problem at the moment.

Best regards.
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] New on blogs.coreboot.org: coreboot changelog

[WordPress]

A new post titled "coreboot changelog" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2015/11/05/coreboot-changelog-4/

This changelog covers 2 weeks up to November 1st, during which coreboot-4.2 was released.
In that timeframe, the repository saw 214 commits spanning d98471c..f6dc544.
Before we get to the stuff that the tech media gets excited about, the first thing to report about is a bunch of efforts to improve the reliability of our tree and the automated testing we conduct.
abuild, the utility for automatically building the default configuration of every board in the tree, learned to deal with mainboard directories that cover multiple variants of a board. This brings back build test coverage for google/veyron.
Various programs in the util/ hierarchy of the tree are now automatically tested by our build test infrastructure, and the related code saw some refactoring to make testing more tools really simple. During that development, some Makefiles below util/ were also cleaned up.
Another area of clean ups was the conversion of `#ifdef` statements to using the `IS_ENABLED` macro. This ensures that even unused code paths are syntactically validated before the optimizer drops them, leading to the same binary output with better build test coverage.
In preparation of future improvements, we gained a lint tool for Kconfig files. It will be hooked up to the build system once the tree is clean, until then it provides a way to see what’s still missing. Check out `util/lint/kconfig_lint` if you’re curious.
As a proof of concept, util/fuzz-tests now provides an environment to test the jpeg decoder we ship for splash screens using [afl-fuzz](http://lcamtuf.coredump.cx/afl/). The same approach can be applied to other coreboot components to find potential crash bugs (or worse).
Finally, several chip drivers were removed because they had no user in the tree anymore and thus saw no testing at all. Some of them will likely come back together with new mainboards that use them.
In addition to the code development to improve code quality, `util/scripts/maintainers.go` provides a way to query the MAINTAINERS database that we’re building, as one piece of a larger effort to improve code quality through formal submodule maintainership.
Another formal clean-up was the tree-wide removal of the last paragraph of the GPL license header in files, the one denoting where to obtain the license text. First, we ship it in the tree, second, it’s probably easier to get with a quick search engine request than by writing a letter to a US post address that may or may not be current.
Rockchip’s RK3288 gained support for additional power/clock states and a more robust EDID handling.
The ongoing effort to support booting in long mode (64 bit) on AMD64 progressed by the integration of changes to make SMM handling and AMD chipset drivers 64bit clean.
Some ACPI for older Intel chipsets was consolidated and is now used for multiple chipset generations.
The Intel GMA driver has also seen improvements, allowing brightness levels for laptop panels to be configured per board, and to disable the graphics chip entirely.
In terms of drivers, the aspeed driver provides native VGA text, and there were improvements to superio and i2c chip drivers, supporting more of their features.
Sandybridge now initializes CPUs serially for robustness reasons, and Intel FSP supports loading microcode from coreboot.
cbfstool now extracts stages and rmodules as ELF files, including relocation information for the former, so that roundtrips of add-stage/extract/add-stage become possible. It now also compiles more reliably on Cygwin.
libpayload saw the additional of a graphics library to layout images on a framebuffer using framebuffer independent coordinates, and some bug fixes to its USB drivers.
In addition to all those cleanups and little new features, coreboot also provides support for a couple new boards, in particular two Intel Skylake based boards by Google (google/chell and google/lars) as well as Asus KFSN4-DRE with K8 CPUs and Asus KGPE-D16 with more recent AMD CPUs (Fam10h and Fam15h).
All related chipsets also saw significant improvements, of which the still ongoing effort to provide non-AGESA implementations for the Fam15h CPU, as well as a ton (metric, in case you’re curious) of bugfixes and feature developments (for example Suspend to RAM) for all AMD CPUs starting with K8 is particularly notable.
Besides those changes, and minor (but valuable) contributions to improve the code style, there’s a bucket list of improvements across the entire tree: more robust SMM entry on i945, fixes to our SMBIOS table generation, changes to the resource allocator to become more robust and IOMMU friendly and to measure the time it takes, and improvements to the robustness of our build process.


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Asus M2N-E no boot, post codes A5 80 73

[Balázs Vinarz]

Hi,
the first postlog is the same, so A5-80 in an endless loop, there was one
time when its end with 79 then shuts down itself, thistime the memory is in
the B1 slot.
I was made a video at 60fps, and its more accurate, so the sequence is
FF-88-80-88-78-72-28-29-24-29-25-55-89-73 than a shutdown, this time the
memory is in the A1 slot.
Im using a single-core Athlon64 3000+. I will have a try with the 2012
source, if i found one. Sadly im working on ramdisk, and the toolchain
compile takes a while even if 4 cores :)

Best regards.

2015-11-05 9:06 GMT+01:00 Kyösti Mälkki :

> Please reply to list.
>
> Yes, you need better development setup than ramdisk.
>
> Kyösti
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KCMA-D8 workstation board port offer

[Francis Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 09/11/15 21:44, Timothy Pearson wrote:
> All,
> 
> After reviewing some of the comments on the ASUS KGPE-D16 being 
> essentially too large of a system and too expensive for many
> people, and the fact that modern, blob-free systems are not really
> available in the mid-range arena, Raptor Engineering would like to
> offer to create a native initalization blob-free port for the ASUS
> KCMA-D8, which is essentially the KGPE-D16's ATX-compatible "little
> brother".
> 
> We would be asking $15,000 for the port, including upstreaming to
> the master coreboot tree.  We already have extensive experience
> with these Family 10h/15h boards, and would be able to create a
> port of similar quality to the existing KGPE-D16 source in terms of
> both code quality and overall functionality.
> 
> If this is something you might be interested in please let me know.
> We are able to accept multiple payments from various sources for
> the same project (within limits), so if this is something your
> local Linux groups or similar might be interested in we should be
> able to keep the cost on any one individual or organization to a
> reasonable level.
> 
> Thank you for your consideration,
> 
> 

To be clear, Timothy is trying to gauge potential interest in a
collective crowd funding source, between interested parties within the
coreboot project.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJWQWmAAAoJEP9Ft0z50c+UwsAIAK4KOWHaUNVnm0GDIE/U1a8z
FldJ/uXCvrb+BpLaQgE7FReDeJnawwxcBypo16qaq2pC3kKfawV0baOWBkQXhbau
gvO7kye7KvTIGguGPokyGuLdXp0ZwDJUnQgI34gn2cynDR53uOwwzdxi5qNdshJu
DK2f/c713AP1APqE8pnlFYFgenZMXeOCoq+Oz7gBFv28AzAEC7FqiX+dKhQes1wM
cov3alODt8IZsXIrt0A9T5Zpy1STu0zju38A9pzMaKsuaGBLAIb69fduZgOZjh7K
SR0+WaXYOouflEJA/BG7LHC2i9PqQjCfLiVv1r5A8Ef0rpHnJQpjC6gT27/j/nk=
=yNCo
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Stefan Reinauer]

* Stefan Reinauer  [151027 21:39]:
> I want to add the following boards (and their chipsets and super ios)
> that have been in the tree and basically unmaintained for 10+ys:
> 
>  * arima/hdama
>  * digitallogic/adl855pc
>  * ibm/e325
>  * ibm/e326
>  * iwill/dk8s2
>  * iwill/dk8x
>  * newisys/khepri
>  * tyan/s2735 
>  * tyan/s2850 
>  * tyan/s2875 
>  * tyan/s2880 
>  * tyan/s2881
>  * tyan/s2882  
>  * tyan/s2885  
>  * tyan/s2891  
>  * tyan/s2892  
>  * tyan/s2895  
>  * tyan/s4880  
>  * tyan/s4882

CLs are up:

http://review.coreboot.org/#/c/12368/ and following.

Stefan



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting up a bug tracker

[ron minnich]

Let's not do anon service. Our last bug tracker became a transit point for
all kinds of junk.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting up a bug tracker

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/09/2015 05:04 PM, ron minnich wrote:
> Let's not do anon service. Our last bug tracker became a transit point
> for all kinds of junk.
> 
> ron
> 

Agreed.  OpenID or similar only please.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWQSjdAAoJEK+E3vEXDOFbvKMIALPZ1AZzCBVcoU3JmVgRC9/G
Mud2JUQiVLUFX1TiOxmu8f5CIf0Zt6T+XvQH1TtxgkQ8ytnjSyZdEgSmjS8XU63T
XZ2qQBHFZOpVrcLRSD71FOc5Q4u3xfBCzF+ldrGTSWDRXvwDuEGG+UcA8hwVTlUW
rUWhZeLdPL9aJTOBg4pCqorfxuIGs6BBKiyNqk006duxN2FPiNNQOwg8FUugK7Rn
1wo/lMzSNE2sKv5U1b2UqXVQcvbpMx7PS7S9MffnEYu/DD78IQotTQqmPZWpxxjA
v4dPTXPQouXiFkM2kF+ExkE/nZx6Na//bWaks30qSis8ARO7MzL40kgPDm+yoHs=
=8uxg
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Remove empty mainboard.c files up for review

[Stefan Reinauer]

* Paul Menzel  [151109 23:42]:
> Dear coreboot folks,
> 
> I pushed change set I379e4b1e1b1725648c6231bc6954ac3cc655a596
> (mainboard: Remove empty mainboard.c files) [1] for review.
> 
> ```
> mainboard: Remove empty mainboard.c files
> 
> All the deleted mainboard files contain no code besides some print
> statements denoting, that the init is executed.
> 
> If such statements are desired, this should be done in common code so it
> does not have to be added to each mainboard.
> 
> Therefore, also delete files with just print statements.
> ```
 
This is much appreciated. These files are really only boilerplate
(which could indicate that all of these ports are really incomplete,
but that's a different story ;)

I am going to submit the patch.

Stefan


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFC] Remove empty mainboard.c files up for review

[Paul Menzel]

Dear coreboot folks,


I pushed change set I379e4b1e1b1725648c6231bc6954ac3cc655a596
(mainboard: Remove empty mainboard.c files) [1] for review.

```
mainboard: Remove empty mainboard.c files

All the deleted mainboard files contain no code besides some print
statements denoting, that the init is executed.

If such statements are desired, this should be done in common code so it
does not have to be added to each mainboard.

Therefore, also delete files with just print statements.
```

Please voice any objections.


Thanks,

Paul


[1] http://review.coreboot.org/#/c/12355/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot