Re: [coreboot] RFC: coding style: "standard" defines

[Alex G.]

On 02/08/2016 11:29 AM, Julius Werner wrote:
>>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote:
 2016-02-04 10:35 GMT+01:00 Patrick Georgi :
> during the review of some commits that are in the process of being
> upstreamed from Chrome OS, people noticed that chipset drivers like to
> define their own TRUE/FALSE defines (sometimes prefixed to), and I
> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
> be the house rules in some firmware communities.
 Seems like for the BIT defines, all variants are popular. Any
 objection with moving them to src/include instead of having various
 copies across the tree?
>>> How about something like src/include/please_dont_use.h ?
>>>
>> I don't know about that but I'd have no objection to a comment in the file
>> itself that these are vile constructs.
> 
> If we agree on what not to use, why not just fix it completely?
> coccinelle is great for that sort of thing.
> (For the record, I don't mind BIT(x) too much but I also prefer (1 <<
> x), since it's more consistent with multi-bit fields like (5 << x).)

Other than BITxx macros, really, what's the purpose of this? Sure,
standardization sounds great, but can anyone point to reasons why _not_
standardizing results in loss of productivity? As I've said before, we
do import code from other codebases, which oftentimes are not even
self-consistent. There's loss in productivity from being forced to
convert one style of bit macro to another.

Just from that, it seems that trying to "standardize" is a net loss.
Pretty code is useless when it's slow and clumsy to write.

Alex

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

Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines

[Alex G.]

On 02/01/2016 11:36 AM, Martin Roth wrote:
> What I don't read in that blog post is anything about the
> coreboot project being a democracy.

I'd normally find such a statement very disappointing, but I'm pretty
certain you're off on that one. I'm not sure how involved you've been in
coreboot public before leaving SAGE -- I've mostly known your name from
patches Marc submitted. What I can tell you with great confidence is
that the picture you try to portray of coreboot has historically not
been true.

I've been around for a long time, maybe too long, and I remember many an
issue having been publicly discussed. I remember cases where things were
brought up for discussion, and the so-called leadership team decided the
exact opposite of what it had intended. I remember the switch to git and
gerrit, and I remember seeing quite some back and forth on the issue.

I'm not sure why you have such a dark picture of coreboot in your mind.
I've haven't heard anyone from the so-called "coreboot leadership" team
make the claims you do. I'm sorry you feel that way, but that shouldn't
be a reason to shut down Paul's proposal

> Please note that these are just my own personal thoughts on these
> subjects

Exactly!

Alex

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

Re: [coreboot] RFC: coding style: "standard" defines

[Alex G.]

Hi there,

This seems pretty simple.

On 02/04/2016 01:35 AM, Patrick Georgi via coreboot wrote:
> Hi all,
> 
> during the review of some commits that are in the process of being
> upstreamed from Chrome OS, people noticed that chipset drivers like to
> define their own TRUE/FALSE defines (sometimes prefixed to), and I
> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
> be the house rules in some firmware communities.
> 
> I think we should seek uniformity here: decide on some style,
> recommend it, clean up the tree to match, and help people stay
> consistent through lint tests. What I don't know however is what that
> style should look like.
> 
> So, two topics:
> 
> 1. TRUE/FALSE
> Do we want such defines? If so, TRUE/FALSE, or true/false, or
> True/False, or ...?

Standardize on stdbool.h, bool, true, false. It's the logical choice.

> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
> I don't think it makes sense to go for a single one of these (0x3ff is
> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
> BIT16 and BIT(16).

BIT16, no. Who wants 64 defines? Seriously, this sort of stuff raises
blood pressure.

BIT(16), sure. Actually, I used this trick a while back on the allwinner
port. BIT(16) meant "just a bit", whereas (1 << 16) meant an enum
(usually also paired close to 2 << 16, 3 << 16, etc).

0x1 also fine. If it's in a list of defines, why not?

#define RON 0x8000
#define JOHN 0x1
#define MARY 0x2


We all know Chromium guys like to copy paste code from all over the
interwebs, and quite frankly, why make their lives harder with harsh
guidelines? These are small inconsistencies that I don't think bother
anyone too much.

Alex

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

Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines

[Alex G.]

On 01/30/2016 11:30 AM, ron minnich wrote:
> The change to the guidelines is hence a codification of a practice that
> goes back to the project's beginnings.

I find that statement inaccurate. This practice had not been an issue in
the past, on patches that you yourself approved. Mixed syntaxes have
been present in the codebase for a while. See EXHIBIT A.

EXHIBIT B shows a patch, mid last year, when a new intel_syntax code was
introduced. There was only one comment (following) about the syntax. The
patch was approved by you, Ron, without mentioning what you claim has
been a practice.

> Patrick Georgi, Jul 13, 2015
> follow up patch: we don't really want two _syntaxes in one file_, right?
(emphasis added)

The comment clearly addresses the issue of mixing two syntaxes within a
file. It does not mention "a practice that goes back to the project's
beginnings", nor does it mention that either "AT syntax is to be used
through-out the project", or "No new Intel syntax code is allowed into
the project."


EXHIBIT C, shows another such patch that, you, have also approved, Ron.
The comment got no replies.

> Ronald G. Minnich, Oct 30 10:43 AM
> why intel syntax _in a file that is att syntax_? it's a real
oportunity for a buggy time.+2'ing because you promised me you're
rewrite it.
(emphasis added)

Notice how the issue here is strictly the mixing of syntaxes within the
same file.

EXHIBIT D shows another such patch, this time approved by me. I have
made a comment about the issue of mixed syntax.

> Alexandru Gagniuc, Jul 17, 2015
> Really? Mixed syntax in the same file?

This also addresses strictly the issue of mixing of syntaxes within the
same file.

EXHIBIT E shows another patch, that you yourself approved. This time,
there was not even a mention of mixed syntaxes.


I conclude from these, that your assertion that this has been an
unspoken rule, is not true. Furthermore, I believe that this arbitrary
change was done as an act of spite towards a set of engineers. Also,
since you, and the rest of the coreboot leadership have shown a pattern
of first discussing changes to the project publicly, on the mailing
list, I conclude that a discussion about this issue was deliberately
avoided in order to prevent those engineers, as well as other coreboot
community members, from presenting their arguments.

Alex


### EXHIBIT A: Presence of .intel_syntax ###

* 4a30ab9 cpu/amd: remove .intel_syntax
* 0302b06 arch/x86: remove .intel_syntax
* c7b2b7c cbfstool: Fix potential error when using hash attribute

$ git reset --hard c7b2b7c67dc8afb52c3dc8e9297e5ed81fa22674


$  git grep intel_syntax
src/arch/x86/boot.c:".intel_syntax noprefix\n\t"
src/arch/x86/c_start.S:.intel_syntax noprefix
src/arch/x86/wakeup.S:  .intel_syntax noprefix
src/cpu/amd/agesa/cache_as_ram.inc:  .intel_syntax noprefix
src/cpu/amd/pi/cache_as_ram.inc:  .intel_syntax noprefix


### EXHIBIT B: src/arch/x86/[boot.c, c_start.S] ###

$ git blame src/arch/x86/boot.c |grep intel_syntax
9693885a src/arch/x86/boot/boot.c  (Stefan Reinauer 2015-06-18 01:23:48
-0700  63)  ".intel_syntax noprefix\n\t"

$ git blame src/arch/x86/c_start.S |grep intel_syntax
9693885a src/arch/x86/lib/c_start.S  (Stefan Reinauer
2015-06-18 01:23:48 -0700 403) .intel_syntax noprefix

$ git show 9693885a
commit 9693885ad88d21ead7bd9ebc32f3e4901841b18b
Author: Stefan Reinauer 
Date:   Thu Jun 18 01:23:48 2015 -0700

x86: Port x86 over to compile cleanly with x86-64

Change-Id: I26f1bbf027435be593f11bce4780111dcaf7cb86
Signed-off-by: Stefan Reinauer 
Signed-off-by: Scott Duplichan 
Reviewed-on: http://review.coreboot.org/10586
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand

Reviewed-by: Ronald G. Minnich 

### EXHIBIT C: src/arch/x86/wakeup.S ###

$ git blame src/arch/x86/wakeup.S |grep intel_syntax
ac901e6b src/arch/x86/wakeup.S   (Stefan Reinauer 2015-07-31
16:46:28 -0700  32).intel_syntax noprefix

$ git show ac901e6b
commit ac901e6bedc98d115ebb8089afd8f67aef39c000
Author: Stefan Reinauer 
Date:   Fri Jul 31 16:46:28 2015 -0700

wakeup: Switch back to 32bit mode first

On x86_64 we need to leave long mode before we can switch to 16bit
mode. Oh joy! When's my 64bit resume pointer coming?

Why didn't this get caught earlier? Seems the Asrock E350M2 didn't
do Suspend/Resume?

Yes, I know it's Intel syntax. Will be converted to AT syntax
as soon as the whole thing actually works.. 8)

Change-Id: Ic51869cf67d842041f8842cd9964d72a024c335f
Signed-off-by: Stefan Reinauer 
Reviewed-on: http://review.coreboot.org/11106
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich 


### EXHIBIT D: src/cpu/amd/agesa/cache_as_ram.inc ###

$ git blame 

Re: [coreboot] [RFC] Common license header guideline should prefer GPLv2+ over GPLv2 only

[Alex G.]

On 01/22/2016 08:21 AM, Patrick Georgi wrote:
> I'm uneasy
> with recommending that when not strictly necessary (I'd consider a
> project that's based on "or later" licensing to be such a case).

I'm not sure if you mean "something I'm uneasy about", or "an example
I'd consider" when you say "project that's based on 'or later'". u-boot
is v2+. Does that count?

Alex

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

[coreboot] [RFC] Common license header guideline should prefer GPLv2+ over GPLv2 only

[Alex G.]

I think this would be a good move for interoperability, so that GPLv3
projects (e.g. SeaBIOS) may take code from coreboot where needed (e.g.
device drivers). I'm strictly talking about listing the preferred
license; it's still up to contributors whether they want v2 or v2+.

[1] Listed GPLv2+ as preferred, but it was recently changed without any
explanation. Stefan, do you have more details on that?

Alex

[1] https://www.coreboot.org/Development_Guidelines#Common_License_Header

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

Re: [coreboot] romcc issue with loop execution?

[Alex G.]

On 01/20/2016 09:23 AM, Andrey Korolyov wrote:
> Hello,
> 
> during initial bootstrap of an ancient Geode board I found that the
> romstage hangs at

After observing several issues with romcc, when the same code worked as
expected with GCC, our team decided to discontinue use of ROMCC. It was
determined it would be less effort to write all of the bootblock in
assembly than to work around romcc issues. romcc was issuing nonsensical
instructions, like "mov eax, eax".

You could try to disassemble your bootblock with "objdump -d" and see if
the resulting code makes sense.

> src/northbridge/amd/lx/raminit.c:
> 
> 750 volatile unsigned long *ptr;

> 751 for (i = 0; i < 5; i++) {
> 752 ptr = (void *)i;
> 753 *ptr = (unsigned long)i;

Well, the first iteration of the loop causes a NULL pointer dereference.
If that's not enough, you also have three unaligned 32-bit writes.  I'm
not sure how well romcc understands undefined behavior, but disassemby
is your best friend here. Make sure the resulting asm does what you
think the C code tells it to do.

Alex

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

Re: [coreboot] X86 considered harmfull vs Coreboot

[Alex G.]

On 01/19/2016 12:46 PM, NTPT wrote:
> Hi all 
> 
> I found a paper 
> Intel x86 considered harmful
> Joanna Rutkowska

She's screaming, and screaming, louder and louder, yet sadly very few
people are actually paying attention.

There isn't much we can do from a firmware point of view when the
hardware nowadays hides things from us. It's sad, but it's the reality.
And it's not just x86 that's doing this; it seems to be an industry-wide
trend.

Some people are hoping that RISC-V and OpenPOWER will not fall into the
same trend, but it's all just hopes at this point.

Alex

> http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
> 
> describing  things that are belived are security shorcommings of x86 
> architecture. Many of them are bios / mb  and boot process related. 
> 
> I am just awandering how coreboot as a  "opensource bios"  deal with this... 
> 
> Any information ?  I would glad to hear Yours opinion . Thanx
> 
> 
> 

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

Re: [coreboot] Where is the first instrucion?

[Alex G.]

On 01/10/2016 10:23 AM, ron minnich wrote:
> One thing I think you'd enjoy doing is building the qemu target, setting
> up qemu with gdb, and just watching what happens, instruction by
> instruction, as the system boots.

One exercise I liked doing was to rewrite the entire boot flow, from
reset vector to protected mode entry. Tested on qemu, put it on
hardware, nothing burned.

Alex

> ron
> 
> On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
>  > wrote:
> 
> Hi Peter and Rudolf.
> Thanks for the answers and tips. They are realy helpfull !
> I'll take a look.
> 
> Rafael R. Machado
> 
> 
> Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek  > escreveu:
> 
> Hi,
> 
> I guess your question is more general than the coreboot related
> right?
> 
> If you have a firmware image dump of the flash (not the file you
> download from
> board vendor) then yes, first location to be executed is the
> instruction located
> 16 bytes before end of the image.
> 
> In coreboot see in build/ bootblock_inc.S which also has
> reset16.inc and
> entry16.inc which is a real start. Consult the Intel or AMD
> manual to see the
> CPU state after reset. The CPU starts in real mode, but CS base
> is shifted to
> last 64KB before end of 4GB address space. In general your CPU
> starts in
> compatible mode with 8086 manufactured in 1978.
> 
> Thanks
> Rudolf
> 
> --
> coreboot mailing list: coreboot@coreboot.org
> 
> http://www.coreboot.org/mailman/listinfo/coreboot
> 
> 
> 

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

Re: [coreboot] HP M6-1035dx vga bios option rom

[Alex G.]

On 01/02/2016 01:47 PM, Peter Stuge wrote:
> KR Tejeda wrote:
>> I cannot seem to restore the stock bios rom from the HP site in any
>> reasonable way. I've tried flashing it via flashrom, and I've also
>> tried extracting the contents of the stock rom with no luck.
> 
> What did you try, exactly? If you have a pointer to the factory BIOS
> image then someone might be able to help you extract the VGA BIOS.

Just noting, the way I extracted the vga rom on that machine was dd from
/dev/mem with vendor bios.

Alex

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

Re: [coreboot] [RFC] Prepending *Original* to tags from other repositories

[Alex G.]

On 12/31/2015 08:53 AM, Paul Menzel wrote:
> change set #12804 [1] proposes the following addition to the file
> `Documentation/gerrit_guidelines.md`.
> 
> Unfortunately, I do not fully understand the reasoning yet. 

The core idea is to have a record of what happened where, and
accountability.

Commercial members oftentimes have different standards and guidelines
than coreboot.org. I was able to convince my team to write patches as if
they were to be submitted to coreboot.org, even though the customer
would have accepted working patches with much less attention to detail.
What I've noticed was that people were familiar with the customer's
tools, guidelines, and repositories, but had no idea of the coreboot.org
guidelines.

Another thing I've noticed, and this is key, is that products have to
ship, and when the deadlines draw near, the attention to detail fades in
exchange of getting things out the door. There are cases when people are
about to finish a project, and are about to advance to the next project,
but they have to complete that one last thing. There's the pressure from
the old project to finish, and there's the pressure from the new project
to start work.

That's the reason external patches must go through review, just like any
other patch. The catch here is that oftentimes, it's members of the same
team that approve patches in both places, so naturally, things get missed.

This means that, as time goes on, we need to be able to look at what
went wrong, and update the guidelines and rules accordingly. You don't
need the Original- as an absolute must, but it sure makes things a lot
easier. It also makes sense in terms of keeping a logical separation of
those tags. If people didn't consider it important, they wouldn't have
written a script to automate it.

Alex

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

Re: [coreboot] CBFS file format changed but documentation not updated

[Alex G.]

Hi Kevin,

Please accept our apologies for this oversight. This should have been
caught during review, but it was missed. I'll try to get a patch
together to update the documentation.

Alex

On 11/17/2015 12:36 PM, Kevin O'Connor wrote:
> I noticed that commit 0d618afc modified the CBFS file format.  (It
> looks like the "checksum" field was replaced with a new file
> "attributes" feature.)  However, the CBFS documentation in the
> repository (Documentation/cbfs.txt) was not updated.
> 
> It would be great if the documentation could be kept in sync with the
> CBFS implementation.  (Or, if that's not feasible, I think it would be
> preferable to remove Documentation/cbfs.txt .)  Having up to date
> specifications helps other projects (eg, SeaBIOS) keep up with
> changes.
> 
> Also, I didn't see any emails for the above change on the mailing
> list.  What is the best way to keep up with notable architectural
> changes in coreboot?
> 
> -Kevin
> 

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

[coreboot] commit messages and their suitability for coreboot.org

[Alex G.]

There's a trend I've been noticing about commit messages which is to
follow google's format for everything coreboot. Please stop this.

Here's why google's format is not suitable in many respects. For the
sake of example, I will pick on a RABDOM commit message which follows
the format:

commonlib: add cbfs_vb2_hash_contents()

Provide a common routine to hash the contents of a cbfs
region. The cbfs region is hashed in the following order:
1. potential cbfs header at offset 0
2. potential cbfs header retlative offset at cbfs size - 4
3. For each file the metadata of the file and it is not
   an empty file then the data as well.

BUG=chrome-os-partner:48412
BUG=chromium:445938
BRANCH=None
TEST=TBD

## Summary line ##

So what's wrong with this? Let's look at the first line.
* indicates component, check
* sentence not capitalized, let not pick on this point here
* Sentence content:
And this is where I want to get. What does cbfs_vb2_hash_contents() do?
Does it hash an entire imagine? multiple cbfses? only one file? These
are things that someone looking over a git shortlog must not ask -- it
just wastes time. A much better description is:

"commonlib: Add function to hash contents of a CBFS region"

Here's what I did different:
* I used english, not C to describe the change
* I used wording that makes sense for people less technical than me
* I didn't just throw C names in the summarry

This ties into the "document what, not how" idea. Stretching that a
little, I documented what the function does, not how it's named.

## Commit message body ##

The body does a decent job of explaining the content in more detail. We
could go into whether a certain piece belongs in a source comment, or
commit message, but that's besides the point I'm trying to make here.

### BUG tags ###

Now we get to the tags. Why are tags considered harmful? First off,
"BUG=chrome-os-partner:48412" is not publicly accessible. As a result,
that information is completely useless to coreboot.org.

So how would one go about this? Instead of a pointer to effectively
unusable data, say "This fixes a bug where ...".

Now we come to the "BUG=chromium:445938" line. That is publicly
accessible. When referring to external bug trackers, please include a
short description of the bug, such as:
"This fixes a bug where ...(chromium bug #445938)".
If the "bug report" in question is a feature request, then just leave
out references to it. It's not a bug in the correct sense of the word,
and in the coreboot sense of the word.

### BRANCH tags ###

coreboot.org does not use branches. Even if it did, any reference to a
"BRANCH" does not make sense, as git is responsible for handling
branches. Please leave these lines out entirely.

### TEST tags ###

The general attitude towards a patch is "if people have to ask how you
tested it, then you probably need to include it in the commit message".
There's no hard rule towards the format of the commit message body, so
TEST tags are perfectly fine.

What is not fine is TEST tags that have no useful information. In this
case, a feature is introduced, and some later patch, the feature is
used. Where should the feature get tested? The patch that adds the
feature? The patch that uses the feature? There are cases where patches
have to be tested in bulk, and that's fine. Please describe the testing
methodology only on the last patch of the series.

A very common TEST tag says "built and booted ". That's lazy.
First, every coreboot commit is build-tested build jenkins for each
board. Restating that the patch builds for a specific board is redundant.

What does "booted" mean? Does it mean boot to ramstage? Does it mean
boot to payload? Which payload? Does it mean boot to kernel? Which
kernel? Does kernel crash or reach shell? Does it bluescreen? Does it
reach a shell? Graphical shell? Console shell? Is the console over
serial? Is it over network? Does USB work? Can you access SATA drives?
>From what media was your kernel loaded?

You get the point. "booted" provides no meaningful information. If your
testing involved "building and booting" a specific board, then please
leave out the TEST tag from your commit message, or remove it before
pushing the commit to coreboot.org.


### -centrism ###

Many times, commits look like:

funnychip: Enable flux capacitor calibration
funnyboard: Enable flux capacitor in devicetree

When they should actually look like:

soc/funnychip: Enable flux capacitor calibration
funnyvendor/funnyboard: Enable flux capacitor in devicetree

It's understandable that a vendor works only on a very limited part of
the codebase, and for them referring by codename alone is obvious.
However, if your internal policy is not to follow coreboot.org
namespacing policy, when those patches are pushed to coreboot.org,
please make sure they are properly namespace.

For example, if you tell me that you enable clock gating on an mcp509,
how will someone know if that is a southbridge, soc, or SPI chip? By
prefixing, and 

Re: [coreboot] baytrail + fsp_baytrail

[Alex G.]

Gerrit is open for business 24/7

On 12/14/2015 08:08 PM, Peter Stuge wrote:
> ron minnich wrote:
 nobody cared enough to really do the work
>>>
>>> That's the problem - not the solution. Don't build infrastructure to
>>> support complacency, build infrastructure to support desirable activity.
>>
>> I'm not even sure what this means :-)
> 
> It means that code needs to be structured well so that it is easy and
> natural to consistently use good structure.
> 
> As opposed to the code being less well structured and having a lot of
> scaffolding to compensate for that lack of structure. As the code
> gets messier the scaffolding grows increasingly powerful, and thus
> encourages doing further wrong things in new code.
> 
> 
> //Peter
> 

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

Re: [coreboot] baytrail + fsp_baytrail

[Alex G.]

On 12/07/2015 07:55 AM, Martin Roth wrote:
> Here are my suggested steps:
> 1) Look for commonalities between baytrail and other chipsets and move
> pieces things into soc/intel/common

A word of caution about soc/intel/common: it's a misnomer. It's very
specific to FSP 1.1.

Alex

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

Re: [coreboot] baytrail + fsp_baytrail

[Alex G.]

On 12/07/2015 06:34 PM, Alex G. wrote:
> On 12/07/2015 07:55 AM, Martin Roth wrote:
>> Here are my suggested steps:
>> 1) Look for commonalities between baytrail and other chipsets and move
>> pieces things into soc/intel/common
> 
> A word of caution about soc/intel/common: it's a misnomer. It's very
> specific to FSP 1.1.

Oh! Nice to see some of that got fixed[1] recently.

[1] * 94b856e FSP 1.1: Move common FSP code

Alex

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

Re: [coreboot] baytrail + fsp_baytrail

[Alex G.]

On 12/06/2015 08:18 AM, Alexander Couzens wrote:
> hi,
> 
> baytrail and fsp_baytrail shares a lot of code.
> Any ideas how we can merge these?

That's not a very good idea. There are different sets of interest which
use those two code paths, and trying to unify that will only get people
stepping on each others toes.

At most, you can make fsp_baytrail/ use the CPU part of baytrail/, but
leave the northbridge and southbridge parts alone.

My advice, just stash the fsp_baytrail/ in some dark basement and forget
about it. If it gets in the way or gives you trouble, let me know, but
otherwise, just pretend it doesn't exist

Alex

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

Re: [coreboot] Payload that can do mmio32/pciserial UART on x86

[Alex G.]

Hi Patrick,

Thanks! Someone else had also suggested this in a private email. I have
one thing to say, and one thing only:

AW YEAAA!

Alex

On 11/19/2015 12:12 AM, Patrick Georgi wrote:
> 2015-11-19 4:49 GMT+01:00 Alex G. <mr.nuke...@gmail.com>:
>> So, is there something?
> FILO.
> 
> It uses libpayload for drivers which has uart8250_mmio32.c.
> 
> 
> Patrick
> 

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

[coreboot] Payload that can do mmio32/pciserial UART on x86

[Alex G.]

Is there such a payload? Seabios is stuck with IO UARTs. Not sure if
grub can handle it (and if so, how). Depthcharge is out of the question
because it is unbelievably difficult to build outside chromium os's
uber-cumbersome build system.

So, is there something?

Alex

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

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

[Alex G.]

This is something I'd be interested in: Making a 501(c) (tax-deductible)
contribution towards this goal. Is there a way to make this happen? Can
the FSF get involved in this somehow? (they have 501(c)(3) status).

Alex

On 11/09/2015 07:50 PM, Francis Rowe wrote:
> 
> 
> 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.
> 
> 

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

Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

[Alex G.]

On 11/06/2015 02:11 AM, Vladimir wrote:
> * Did you know that Lenovo G505S is still widely available at some parts
> of the world? (e.g. in Russia, 50+ online shops are still selling it)

Yeah, I wrote most of the code for that.

> * Did you know that Francis Rowe, head Libreboot developer, has proposed
> the addition of G505S to Coreboot LTS Candidates list of laptops?

Did you know that G505s is unsuitable for libreboot due to the many
blobs it needs (VBIOS, SMU, IMC, make your pick) ?

> * Did you know that Compal will still be making LA-A091P laptop
> motherboard, the primary component of G505S, at least until the end of
> 2018 year?

And this is based on what?

> It is unbelievable that some people here want to take alive-and-kicking
> motherboard and 'remove it'

I wrote most of the code to get it running in the first place.

> or degrade it into a 'second class citizen' - by branching

Geesh! Why don't you take over full maintainership of AGESA before
whining why people who worked on that code no longer want to support it?

> it off to some abandoned branch that nobody would care about.

You would obviously care about it, so that's a moot point.

> Don't know which is worse...

I agreed to leave these discussions behind. I don't know why people
_still_ keep bringing it up.

 Someone wrote:

That was me

>> I'm looking forward to seeing the draft of the removal plans. Maybe
>> removal is even better than branching


Yes. Because everything is black and white. We either keep everything in
a "master" branch, or it's dead.


> If Someone doesn't care about those boards which he doesn't own own, if
> Someone has no idea how to set up makefiles so that they will not make
> builds for boards that he doesn't care about, if Someone can't wait a
> few more extra minutes of compilation because he is in a 'great hurry':

I also happen to run one of the build servers. Here's a deal, you pay
for 60% of the running costs of the server (the amount of time agesa
builds take out of total time), and I'll stop whining. You owe me $1300
for the year 2015, pal.

> then he should start his 'Removal Quest' from old boards like Intel I945
> and AMD K8 - if nobody runs coreboot on them anymore.
> Or from his own board, if his own board is EOL and old...

WOW! Guess what. You didn't git log AGESA boards. Hint: I'm "removing"
(your words, not mine) a lot of the code that I worked on.

> PLEASE do NOT submit proposals that will negatively affect a support for
> alive boards, because

If you want to treat logical separation as removal, that's on you. I'd
appreciate it if you stopped throwing baseless accusations around
because you feel that makes your argument stronger.

> such malevolent plans

Sure, I'm the enemy. I'm certain Stefan will love this one!

> are a great insult

I'm insulted by your portrayal of me as aforementioned. I've invested a
lot of my personal time and resources into coreboot, with nothing but
good intentions. I don't feel you truly have a grasp of all the facts
and headaches of doing coreboot on such a scale. So I'd really
appreciate you taking a step back and trying to get an overview every
once in a while.

Alex

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

Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

[Alex G.]

On 11/07/2015 09:23 AM, ron minnich wrote:
> Can we calm down? Vladimir, your note came out after I -2'ed Alex's
> proposal and we have made it clear that the proposal to "Remove" AGESA
> is just that -- a proposal. It's not going to happen. 

Please, let me troll on this one. I'm having so much fun.

Alex

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

Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

[Alex G.]

On 11/07/2015 06:12 AM, Vladimir wrote:
> That is why Francis suggested adding it to coreboot LTS Candidates list,
> not to Libreboot list - because, while Lenovo G505S seems to be a great
> coreboot LTS Candidate , it is still not ready for Libreboot.

LTS requirements were meant to weed in hardware that is truly free. We
failed at that. libreboot succeeded where we failed. If it's not in
libreboot, it doesn't qualify for the LTS list.

Also, I doubt Francis appreciates people using his name and the
libreboot name in a way which makes it seem like he, or the libreboot
project endorses blobbed hardware. The libreboot project does not
endorse the Lenovo G505s.

> Which is a real pity, because there are no AMD laptops supported by Libreboot

And there most likely won't be. I did the bringup for the first AMD
laptop ever to be supported by coreboot. The g505 is almost an identical
copy of my work. I used AGESA, and spent over half the time debugging
and fixing AGESA to make it suitable for the task. I am very intimate
with the details of that hardware, and why the chances of it ever
hitting libreboot are infinitesimal.

> yet...

Nope. I've tried. You need linux to use the integrated GPU without a
VBIOS in order for this to work to libreboot standards. The maintainers
of the radeon driver have made it very clear that they will have none of
that. In plain english, the coreboot image will have to bundle the VBIOS
in order for the machine to work as intended.

> In any case, Lenovo G505S matches all the requirements for it to
> be considered among the Coreboot LTS Candidates list :
> 
> * RYF-certifiable - [V] check

Nope. See above.

> * Sturdy - [V] check

Really? I was going to buy one a few years back. It did not feel sturdy
at all.

> * Long shelf life - [V] check

Less than three years left? I think the bar here is closer to ten years.

> * Cool factor - [V] check

The low-end lenovo machines are anything but cool, but then this is a
subjective matter, so I'll let you win this point.

> Actually it was you who came up with these requirements :
> 
> http://www.coreboot.org/User_talk:MrNuke/LTS_Candidates#Requirements:

Yup. Yours truly.

> Sorry, but it is a really bad idea to treat LTS Candidate as a second
> grade citizen

The LTS idea died over a year ago because there wasn't any hardware to
match the requirements. The libreboot project took those ideals and
whatever hardware they support is essentially LTS.

If you want hardware that is true in spirit to the LTS requirements,
then please head over to http://minifree.org/ .

> Lenovo is open to requests of motherboards (as well as requests for
> [...]
> sale tax), so any physical person could get them even at 1pcs quantities ;)

Do you have a link to Lenovo's policy on such?

> Undoubtedly, Francis Rowe

I will stop trying to prevent people from tarnishing his or libreboot's
reputation by suggesting he or the libreboot project endorses blobbed
hardware. Just pointing out that they don't endorse it.

> please keep in mind that coreboot is GNU GPL project, and

Thank you master for enlightening me! Let's see... coreboot is _not_ a
GNU project. It is licensed to you under the terms of the GPLv2.

> you have transferred your G505S code to public domain

I did? I was pretty certain I reserved all rights and licensed it to
other people (you included). Maybe GPLv2+ got lost somewhere in translation.

> Imagine, what if someone would suddenly decide to revert/branch off all
> his significant contributions to a Linux kernel? People simply would not
> let it happen! So I doubt that you can do anything you want with your
> important commits to coreboot repository, be it a branch or anything
> else as significant,

> without considering the opinion of other coreboot people

There are coreboot users, coreboot developers, and coreboot developers
whom I have worked with in the past, and whom have earned my trust and
respect. The mostly care of the opinions and thoughts of the latter,
while also being sensitive to the needs of the middle, and trying to
accommodate the former.

But you'll have to find someone else to support you in your endeavors
with the code in question. You can't require that I continue to support
you. I'm on the Tim Pearson bandwagon now, with native init, and much
cleaner and easier to integrate code.

> First of all, it would be interesting to see a detailed report
> describing a process of how you came up with such a round value ( $1300> )

electricity costs : $50/month * 12 months = $600
Flying in for maintenance:
unpaid workday: $400 + plane ticket cost $520 = $920
replacement hardware costs $170 x 3 = 510
Total: $2030
60% if that is $1218, so I was off by $82. sue me.

Note that that doesn't include vehicle rental costs, gas costs,
transportation to/from airport, etc.

> It is not that fair for you to ask $1300 from a single person

My asking for payment for my running costs was a rhetorical statement on
the issue of making efficient use of 

Re: [coreboot] setting up a bug tracker

[Alex G.]

On 11/04/2015 12:10 AM, Patrick Georgi wrote:
> So, redmine?

Let's try it.

Alex

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

Re: [coreboot] Rebuilding coreboot image generation

[Alex G.]

On 11/05/2015 09:55 PM, Julius Werner wrote:
> HOST_FIRMWARE@0xff80 8M {
> SI_ALL 2M {
> SI_DESC 4K
> SI_ME 0x1ff000
> }
> SI_BIOS {
> RW_A 0xf {
> VBLOCK_A 64K
> RW_MAIN_A
> RW_FWID_A 0x40
> }
> RW_B 0xf {
> VBLOCK_B 64K
> RW_MAIN_B
> RW_FWID_B 0x40
> }
> RO@4M {
> RO_VPD 16K
> FMAP@0x1 2K
> RO_FRID 0x40
> GBB@0x11000
> RO_MAIN 1M
> }
> }
> }

Yes, that's exactly what I was referring to! I like that.

Alex

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

Re: [coreboot] Rebuilding coreboot image generation

[Alex G.]

My main concern with this is that we're introducing another language,
with something that may just as well end up being cmos.layout 2.0.

I see where the manifest language is coming from. It's sort of like a
FMAP dts, but then it really isn't.  I understand that we don't want to
use a per-board fmap.dts in order to prevent the duplication we ended up
having last time we did this (cmos.layout).

>From reading the manifest examples, these are the few things that jumped
out at as being unwanted:
(1) mixing region descriptors with rules. As soon as we agree to move
some rules to manifests and some to makefiles, we risk ending up with a
mess that's inconsistent between platforms, and hard to track down/debug.
(2) Undermining some of the existing infrastructure. We can extend the
concept of cbfs-files-y, to fmap-regions-y, whereas the FMAP regions are
dynamically declared. Of course, this is in stark contrast to the
per-module descriptors (which I also like, assuming they are pure
fmap.dts format). However, this inconsistency worries me.
(3) It changes everything we've learnt so far about building a firmware
image. Some platforms will end up using the new manifests, others will
use the existing build infrastructure. I'm worried we'll end up with an
inconsistent build system. Who is going to convert all the old hardware
to manifests?

Now to the good parts. I mentioned briefly the possibility of a
fmap-regions-y macro. Quite honestly, I much better like seeing the
fmap.dts in one place in order to get an idea of the flash layout.

What I'd like to see come out of this is a dts-like set of flash
descriptors, with the rules left in the makefiles. At the very least,
dts is not a new language.

Do you think we can do that without making a mess out of it?

Alex


On 11/05/2015 03:42 AM, Patrick Georgi wrote:
> Hey coreboot folks,
> 
> I'm looking for an approach to make building Chrome OS style coreboot
> images easier to do with regular coreboot tools, instead of the rather
> large post-processing pipeline we have in the Chrome OS build system.
> 
> The rationale is that we also push the Chrome OS capabilities (eg.
> verified boot) upstream, and actually using them shouldn't depend on
> checking out yet another custom build environment.
> 
> I wrote a proposal on how to do that, which can be found and commented
> at 
> https://docs.google.com/document/d/1o2bFl5HCHDFPccQsOwa-75A8TWojjFiGK3r0yeIc7Vo/edit
> 
> If this is to be implemented, I'd do that as part of coreboot's build
> system, and work on supporting the regular image types (with a
> "simple" bootblock and a fallback/normal switch configuration) we
> currently have.
> 
> I appreciate comments and concerns how this fits in with other use cases.
> 
> 
> Thanks,
> Patrick
> 

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

Re: [coreboot] A case for branching AGESA

[Alex G.]

On 11/01/2015 12:49 AM, Patrick Georgi wrote:
> Just a note: the only reason why current Intel fares better

I didn't say Intel fares better. FSP is on my (rather long) hitlist, but
that's not within the scope of this discussion.

>> 7 min vs 20 min on empty ccache, and 2 min vs 6 min on primed ccache.
>> Those are speedups of 2x to 3x.
> Thank you for doing the measurements.

Thank you for creating the 'what-jenkins-does' make target.

>> Patch trains from google and other contributions to non-AGESA code gain a 2x 
>> to 3x
>> speedup in server time, while users of AGESA can continue to contribute
>> and work on the codebase.
> ... and diverge...

And that's expected. Convergence is a dream. AGESA boards use BuildOpts
for configuration, and not much Kconfig/devicetree.cb, versus most other
boards in the tree. Except for VX900 and sandybridge, every chipset
implements its own SPD parsing routines. I can go on and on. Even within
one branch, significant divergence exists, so non-divergence is a moot
point.

Alex

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

[coreboot] A case for branching AGESA

[Alex G.]

AGESA is a very heavy beast, at over one and a half million lines of
code. Although contributions to the AGESA codebase (boards and
supporting chipset/cpu code) have slowed down significantly over the
years, we still rebuild this behemoth for every version of a patch.

This causes quite a bit of strain on our build infrastructure, and even
with an army of four state-of-the art build machines, some people (wink,
wink, Martin) are concerned with long patch trains and verification
times. I can't speak for other machines, but after replacement hardware
costs, flying in, and a lost day of work, I've realized that maintaining
this infrastructure is not cheap.

This made me think if we can make more efficient use of the
infrastructure we have available today, and allow builders to use
less-powerful machines without increased latency.

I've run a few timing tests without AGESA being built, and took
historical data to compare build times for when AGESA is included in the
build.

>From averaging build times on nuclearis2, with a primed page cache and
ccache a compete abuild run takes on average, five to six minutes. A
build without a useful ccache cache takes around fifteen to twenty
minutes (I don't have a reliable way of timing this, hence the high
variance).

Now, if we build a tree without AGESA, we get the following:

First run:
[mrnuke@nuclearis2 coreboot]$ ccache -C #clear ccache
[mrnuke@nuclearis2 coreboot]$ time CPUS=12 make what-jenkins-does
real6m46.778s

Second run:
[mrnuke@nuclearis2 coreboot]$ time CPUS=12 make what-jenkins-does
real2m7.889s

7 min vs 20 min on empty ccache, and 2 min vs 6 min on primed ccache.
Those are speedups of 2x to 3x. Also note that the local builds were not
done on a tmpfs, like the actual jenkins builds. I expect similar
speedups on the other builders.

The obvious solution is to separate AGESA into its branch. Patch trains
from google and other contributions to non-AGESA code gain a 2x to 3x
speedup in server time, while users of AGESA can continue to contribute
and work on the codebase.

Of course, the AGESA branch would also have the non-AGESA boards and
code trimmed so as to make efficient use of the server resources. There
is some common code, and overlap between the two code paths, but it
doesn't seem to be anywhere near as significant as the behemoth that
AGESA is.

Since 4.2 was just released, we can do this today without much fanare.
This also allows other people to donate CPU cycles without needing to
own over-priced server-class machines, and without increasing the
verification latency (compared to the one today).

To anyone saying that putting code in a branch is a death sentence,
please don't treat this as TL;DR and read the above paragraphs.

Alex

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

Re: [coreboot] coreboot binary policy

[Alex G.]

On 10/29/2015 09:48 AM, Marc Jones wrote:
> Hello coreboot,

Hi Marc

> Please limit comments to specific items in this version. If you have
> additions for the next version (if needed), the draft document is open
> for comment.
> 
> https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTCrOwU/edit?usp=sharing

That looks pretty good. I think you've done a great job of clarifying
the requirements of ISA vs non-ISA blobs compared to the last version.
I've made some comments on it to ask for clarification about the
versioning requirements.

While not necessarily specific to this version, are we still considering
forbidding "no-reverse engineering" and "no-modification" clauses for blobs?

Alex

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

Re: [coreboot] Document for review: coreboot Gerrit Etiquette and Guidelines

[Alex G.]

On 10/29/2015 09:28 PM, ron minnich wrote:
> It's a CL.

Ooh, I thought it was a coreboot policy change that attempted to solve
long-standing issues within coreboot. My bad.

> It would be very helpful if you want to propose specific changes.

I did. Refresh the page :)

Alex

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

Re: [coreboot] Document for review: coreboot Gerrit Etiquette and Guidelines

[Alex G.]

Hi Martin,

It seems that the first part of your document ("Summary", and "More
detail") is written in direct response to the removal of FSP 1.0 a month
or so ago. As such, it's very situation-centric, and fails to address
some more fundamental issues.

The concept of a "maintainer" is central to a large number of the
definitions and guidelines posted, but that concept is very ill-defined.
According to your definition of "maintainer", someone who touched that
code, even with a simple refactoring patch, can now be construed to be a
"maintainer". Then, the "maintainer" is given almost absolute veto power
in all matters relating to that code.

There are also no responsibilities defined for a "maintainer", despite
such person being given near-inter-stellar of power. This only
exacerbates some of the long-standing problems we've had in coreboot.

One such problem is code parking, whereas a contributor merges a piece
of code, but then doesn't do his due diligence in taking care of that
code. If the code causes issues, or prevents other refactorings from
happening, the original contributor disappears, and it's up to the
reacaftoring contributor to fix that code as well.

To that, you now add the requirement that the refactoring contribution
leaves the broken platform in a functioning state. That places the
entire burden on the new contributor, while the original submitter can
come in at any time and say "veto".

This creates a counter-constructive disproportion of powers and
responsibilities. You want to make it such that both original submitter
and new contributor have balanced amounts of power and responsibility
over the piece of code in question.

We might want to learn from what other projects have done here, most
notably linux distributions. Take a look at Fedora's nonresponsive
maintainer policy [1] as an example. Give "maintainers"
responsibilities, not just plain stupid absolute power. We're not
solving any issues otherwise.

Another issue that's not addressed here is the problem of people in the
same team submitting and merging patches. This has been a recurring
theme with google contributions. x...@g.com submits the patch, y...@g.com
approves and merges it. Concerns from external reviewers often get
ignored or brushed off as "don't care". @g.com patches that create merge
conflicts for other contributors are sometimes rushed so @g.com doesn't
have to rebase. I've seen plenty of cases where patches have been -2'd
by w...@g.com until other @g.com patches were merged, only for the -2 to be
removed once it was on the contributor to rebase his work.

This then creates another significant issue: the bar for contributions
from such teams is very low, while anyone else experiences a much higher
bar. This has many times resulted in sub-optimal code being merged, and
great contributions getting delayed and abandoned.

This is actually a huge issue that we're dealing with. I don't remember
the exact numbers, but Raptor Eng. was asking around $15000 to upstream
their fam15 work. That's because it's painfully difficult for anyone
outside those teams to merge their contributions. Considering that
there's one guy paying Raptor for all this work, one guy who believes
in, and wants to support coreboot. We've cost him $15000 dollars (of his
own money!). All of a sudden, we've made coreboot a very expensive
project to support.

Then there's talk about a vague "coreboot leadership" who can make
arbitrary decisions about X and Y. There's no concise guideline really,
but it does allow a mysterious group to make any decisions about
contributions and contributors, and leave too much open to the whim of
someone's personal thoughts or the goodness or badness of his day.

I don't think that's acceptable. This needs more work.

Alex

[1]
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

On 10/29/2015 11:55 AM, Martin Roth wrote:
> As the community has grown, so has the need to formalize some of the
> guidelines that the community lives by. When the community was small,
> it was easy to communicate these things just from one person to
> another.
> 
> Now, with more people joining the community every day, it seems that
> it's time to write some of these things down, allowing people to
> understand our policies immediately instead of making them learn our
> practices as they make mistakes.
> 
> As it says in the document: The following rules are the requirements
> for behavior in the coreboot codebase in gerrit. These have mainly
> been unwritten rules up to this point, and should be familiar to most
> users who have been active in coreboot for a period of time. Following
> these rules will help reduce friction in the community.
> 
> This has been posted to gerrit for review:
> http://review.coreboot.org/#/c/12256/
> 
> Please post your thoughts and comments either as a reply to this email
> or in gerrit.
> 
> Thanks.
> Martin
> 
> 
> 
> coreboot Gerrit Etiquette and Guidelines
> 

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

[Alex G.]

On 10/28/2015 07:00 AM, Peter Stuge wrote:
> Patrick Georgi wrote:
>> branches are where commits are pushed to die.
> 
> Yes, this is a very important point, and is why I don't support Alex'
> proposal of moving some things to live only on a branch, and not on master.

So, tagging and removing is better than a branch where people can
continue to work, and submit patches via coreboot.org? I guess we'd much
rather just remove stuff than allow people to continue using it, right?
I guess we want to disallow people the ability to backport features to
their hardware, and just remove it instead.

> Branches *can* work really well, but only when there is a person
> and/or team actively maintaining that branch, and for that to work
> well, the branch needs to have a fairly clear policy. The best
> example of this is the Linux kernel.

If branches die out they die out. That means there isn't interest in
that hardware. Big deal.

> We don't have the manpower of the Linux kernel however. And I don't
> that you're volunteering to maintain the branch, Alex?

Do you offer to maintain the problematic code going forward?

> I'd like to propose that without a designated maintainer stepping up
> we don't create branches other than per the release process that
> we're starting to get into.

I'd like to propose that without a designated maintainer stepping up, we
just remove the code. Experience tells us that people are silent until
their (broken) toys are taken away, and only then start crying. Just
look at the fiasco (in no particular order) Marc, Martin, and Ron caused
after sandybrdge fsp got removed. Branches might prevent that.

> The AGESA code and older FSP and the other things you list are yes
> older and less shiny than the new native code, but also more proven.

The need to make changes to core code whenever a new mainboard is added
is proven indeed.

Alex

-- 
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

[Alex G.]

On 10/27/2015 01:36 PM, Vladimir wrote:
> Although I agree with you that AMD is not innocent as well, if you would
> check a "Binary situation" page at coreboot's wiki, you would see that
> Intel is in three times more evil

Probably "evil" is a bad term. I doubt that there's an ill intent. There
are customer (read OEMs) who want such "features". Remember the Lenovo
laptops that only allowed you to connect white-listed wifi cards before
they would boot? [1]

The real issue is that some of those "features" cannot be disabled, but
that's a technical argument, and has nothing to do with evil vs good.

> (still could not understand why some
> incredibly talented coreboot developers are spending so much time
> fighting Intel's ME issues,

I can't speak for others, but that allows me to continue to work on
coreboot, while also paying the bills. In fact, there is a significant
number of developers who pay their bills by working on coreboot. That's
progress that coreboot wouldn't otherwise see.

> In any case, it would be very sad to see the AMD code gone from the
> master branch. Even the code for some unpopular boards like Intel
> Atom-based EOL "Mohron Peak" was allowed to stay!

There are two reasons for that, one technical, and another one
political. On the technical side, there are users, and people stepped up
to maintain that code. That's usually sufficient to allow code back in.

On the non-technical side, one or two of the developers who originally
committed that code got very offended, angry, and blindsighted by the
fact that it was removed. I won't go into the details.

> Why AMD boards are considered worse? The sole idea of AMD code going away,

Who said AMD is worse? And who said AMD is going away? The whole idea is
to move it to a separate branch. This has two advantages:
 * it's only concerned with agesa boards, so it's not constrained by the
needs of other hardware
 * the master branch is no longer held back by the integration issues of
agesa

Positive side-effects:
 * No longer need to build-verify AGESA for unrelated changes (AGESA
boards take up more than half the server time)

> which will affect many alive-and-kicking coreboot-supported AMD boards,

How will moving code around affect supported boards?

> is beyond my comprehension

BRANCH NOT EQUALS REMOVAL

Does that help?

Someone in this thread (was it you Stefan?) was also suggesting we wait
until 4.3 release before we "remove" AGESA code. I know this whole
discussion started as "removing" stuff, but nobody wants to remove
anything anymore. We've gotten smarter. We just make the effort more
distributed and less centralized. I think moving to branches should be
done sooner rather than later.

Here's a list of things I think should be moved to branches, right after
the 4.2 release:

* AGESA
reason: integration issues

* binaryPI
reason: integration issues

* FSP 1.0
reason: integration issues

* MRC boards
reason: sandy/ivy already has native init path. Some chromebooks have
already been converted.

See the pattern? Now remember, this assumes branches are as first class
citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
That shows it can work.

If people apply that pattern, there are a few other things that could be
branched, but I intentionally excluded:

* ROMCC-only boards:
why not: x86 bootblock still uses ROMCC, so there's no immediate value
in removing boards that also need ROMCC for romstage. Maybe we should
think of it for some future release, once we get more hardware to use
CAR setup in the bootlock.

* google FSP boards (informally, FSP 1.1)
why not: the FSP spec that's used on those boards is subject to change
(and become 1.2, 1.3, etc), and there's no indication that we'll see
significant integration issues if that happens/after it goes live.

Hope this clears things up,
Alex

[1] http://www.coreboot.org/images/6/68/Network_card_bios.jpg

> 
> On 27 October 2015 at 23:15, Timothy Pearson
>  > wrote:
> 
> On 10/27/2015 03:10 PM, Vladimir wrote:
>> It would be really wrong to remove the whole AGESA code: there are
>> AMD-based products which are still very alive and actively sold (at the
>> developing markets) Moving the support for these products to a separate
>> coreboot branch, could create many inconveniences for those AMD product
>> owners who would like to test & use the latest and greatest coreboot
>> build: they will have to backport all the commits of code that's used by
>> all the boards, to that separate abandoned branch - which would cause a
>> lot of hassle and would basically cut them off from the development
> 
>> I agree that removing could be done to some 2009 VIA-based EOL boards
>> that nobody cares about, but it would be a mistake to do that to all the
>> AMD products, some of which are still produced to this date and used
>> together with coreboot by lots of people from this mailing list
> 
>> Also, that action 

Re: [coreboot] SPD binaries in coreboot

[Alex G.]

On 10/23/2015 04:22 PM, Nico Huber wrote:
> What I care about is that we shouldn't serialize in the first place if
> we can avoid it. 

That makes sense, assuming we have access to internal data
representation of the raminit code. For FSP and MRC (the biggest
consumers of on-board SPD-less DRAM), we don't.

> Even if we don't serialize at runtime but use a binary,
> we'd still waste runtime cycles deserializing later.


Alex

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

Re: [coreboot] SPD binaries in coreboot

[Alex G.]

On 10/23/2015 08:32 AM, ron minnich wrote:
> Build the tool in go.

Not everybody knows or wants to learn go.

> It's trivial. If you have an idea how it ought to
> work I can set it up in the playground in a few minutes.
> 
> ron
> 
> On Fri, Oct 23, 2015 at 8:24 AM Patrick Georgi  > wrote:
> 
> Hi,
> 
> Some mainboards come with soldered-on memory without SPD ROM. For
> these, we carry the SPD data in coreboot.
> 
> Currently, they're stored in a hexdump format that is then converted
> to binary at build time. The various mechanisms of doing so fail on
> some platform or another:
>  - "echo -e -n $stuff" isn't well-liked by some shells (emits "e -n
> $stuff")
>  - "printf '\x42'" isn't well-liked by some shells (or /usr/bin/printf
> tools) that don't support hexadecimal formats
>  - "printf '\0377'" isn't well-liked by some non-conforming, but
> existing shells
>  - xxd -rg1 $file > $file.bin requires xxd, which comes with vim and
> may just not exist
> 
> I see essentially two ways out of this, before we can start reducing
> duplication across the tree in that area:
> We could build our own tool to parse hex files and dump binary, or we
> could ship SPD data as binary from the start (and only have to
> concatenate them).
> 
> The second option has the appeal of being much simpler (and there
> isn't really a "preferred form" for editing SPD data that I'm aware of
> - is there?), but looks icky at a glance because it's binary (but it's
> really just as impenetrable as the equivalent hexdump).
> 
> So what do these files contain? Parameters (as in: facts) about the
> hardware's size, layout, and timing, and a bunch of vendor/model
> identifier strings.
> 
> 
> So, is there a third option that I'm missing? Other opinions?
> 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
> 
> 
> 

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

Re: [coreboot] SPD binaries in coreboot

[Alex G.]

On 10/23/2015 01:59 PM, Nico Huber wrote:
> Thanks for the support. One remark: I would really prefer serializing
> during runtime

Why waste runtime cycles (and code space) doing something you can
already do at build time?

> over compiling a C struct to a binary.

We're not doing that either.

Alex

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

Re: [coreboot] SPD binaries in coreboot

[Alex G.]

On 10/23/2015 12:54 PM, Aaron Durbin wrote:
> Do people realize these binaries sit in cbfs? Are we going to compile
> random c files into object files then objcopy them? Then add to cbfs?
> Also, the SPD format is quite silly as it is w.r.t. values crossing
> multiple fields in a byte, etc. There's not really a good way to
> encode that in a C struct.

Nobody said "encode" that in a C struct. The proposal, AFAIU is to have
dynamic code that serializes/deserializes from struct to SPD. Last time
someone tried to compile a C struct into a binary SPD, it didn't turn
out too well (and it's probably why we don't do it).

Not that I agree with the proposal, but we already have deserialization
code in the tree. It's not a stretch to write the inverse operation.

Alex

> 
>>
>>
>> Regards,
>> Carl-Daniel
>>
>>> On Fri, Oct 23, 2015 at 12:44 PM, ron minnich  wrote:
 Aaron is my hero :-)

 ron

 On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin  wrote:
> This one's for Ron.
>
> On Fri, Oct 23, 2015 at 10:32 AM, ron minnich  wrote:
>> Build the tool in go. It's trivial. If you have an idea how it ought to
>> work
>> I can set it up in the playground in a few minutes.
>>
>> ron
>>
>> On Fri, Oct 23, 2015 at 8:24 AM Patrick Georgi 
>> wrote:
>>> Hi,
>>>
>>> Some mainboards come with soldered-on memory without SPD ROM. For
>>> these, we carry the SPD data in coreboot.
>>>
>>> Currently, they're stored in a hexdump format that is then converted
>>> to binary at build time. The various mechanisms of doing so fail on
>>> some platform or another:
>>>  - "echo -e -n $stuff" isn't well-liked by some shells (emits "e -n
>>> $stuff")
>>>  - "printf '\x42'" isn't well-liked by some shells (or /usr/bin/printf
>>> tools) that don't support hexadecimal formats
>>>  - "printf '\0377'" isn't well-liked by some non-conforming, but
>>> existing
>>> shells
>>>  - xxd -rg1 $file > $file.bin requires xxd, which comes with vim and
>>> may just not exist
>>>
>>> I see essentially two ways out of this, before we can start reducing
>>> duplication across the tree in that area:
>>> We could build our own tool to parse hex files and dump binary, or we
>>> could ship SPD data as binary from the start (and only have to
>>> concatenate them).
>>>
>>> The second option has the appeal of being much simpler (and there
>>> isn't really a "preferred form" for editing SPD data that I'm aware of
>>> - is there?), but looks icky at a glance because it's binary (but it's
>>> really just as impenetrable as the equivalent hexdump).
>>>
>>> So what do these files contain? Parameters (as in: facts) about the
>>> hardware's size, layout, and timing, and a bunch of vendor/model
>>> identifier strings.
>>>
>>>
>>> So, is there a third option that I'm missing? Other opinions?
>>> Patrick
>>>
>>
> 

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

Re: [coreboot] GPL license headers

[Alex G.]

On 10/22/2015 11:00 AM, Stefan Reinauer wrote:
> From my previous discussions with lawyers on the topic, the third
> paragraph is unproblematic to remove.

> With resolutions of today's monitors 

And if you're running a 4k screen, do you really want $100 of
real-estate being occupied by boilerplate? (Those monitors aren't cheap)

> and keyboards often having a page down key,

My macbookpro doesn't have a PgDn key.

> keeping the second
> paragraph seems like a good compromise to stay friends with the legal
> experts and err on the safe side.

(Realistic) sarcasm aside, I am sensitive to the legal concerns, and I
do agree with Patrick's concern that we should do our due diligence to
make sure we don't break lawyer's tools. That being said, I think we can
all agree that taking 'licensecheck' as the lowest common denominator is
not unreasonable.

Considering that this lowest common denominator has no issues
identifying the terms with just the first paragraph, a human being
should have no problem with this. I think it's worth the extra effort to
simplify the headers, and ultimately focus on coding, not boilerplating.
I'd also like to see a short (one to three lines) description of _what_
a file does above the license headers.

Alex

> Stefan
> 
> * ron minnich <rminn...@gmail.com> [151021 05:41]:
>> Let me ask around.
>>
>> ron
>>
>> On Tue, Oct 20, 2015 at 7:20 PM Martin Roth <gauml...@gmail.com> wrote:
>>
>> I haven't seen any disagreement that we get rid of the entire third
>> paragraph.
>>
>> Alex votes that we should get rid of the second paragraph of the
>> header as well, and what Ron posted SEEMS to support that we can,
>> although the wording in that license header might be different enough
>> that it doesn't apply to our case.
>>
>> Personally, I'm in favor of keeping the second paragraph.  It looks to
>> me like the first paragraph just discusses distribution, not
>> liability.  I don't really see any NEED to get rid of the second
>> paragraph.
>>
>>     Are there any other thoughts either way on getting rid of the second
>> paragraph?
>>
>> Martin
>>
>>
>>
>> On Tue, Oct 20, 2015 at 6:47 PM, Alex G. <mr.nuke...@gmail.com> wrote:
>> > On 10/20/2015 10:54 AM, ron minnich wrote:
>> >> Eben Moglen, who ought to know, guided us on the release rules for the
>> >> Plan 9 GPL release.
>> >>
>> >> Here is what he told us could go in each file:
>> >> /*
>> >>  * This file is part of the UCB release of Plan 9. It is subject to 
>> the
>> >> license
>> >>  * terms in the LICENSE file found in the top-level directory of this
>> >>  * distribution and at 
>> http://akaros.cs.berkeley.edu/files/Plan9License.
>> No
>> >>  * part of the UCB release of Plan 9, including this file, may be
>> copied,
>> >>  * modified, propagated, or distributed except according to the terms
>> >> contained
>> >>  * in the LICENSE file.
>> >>  */
>> >
>> > +2
>> >
>> >> On Tue, Oct 20, 2015 at 10:30 AM Patrick Georgi <pgeo...@google.com
>> >> <mailto:pgeo...@google.com>> wrote:
>> >> Get (the right set of) lawyers to sign off on that.
>> >
>> > You were saying, Patrick?
>> >
>> > Alex
>> >
>> > --
>> > coreboot mailing list: coreboot@coreboot.org
>> > http://www.coreboot.org/mailman/listinfo/coreboot
>>
> 
>> -- 
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
> 

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

Re: [coreboot] GPL license headers

[Alex G.]

On 10/21/2015 12:11 AM, Patrick Georgi wrote:
> One issue brought up the last time we had this discussion was that
> lawyers prefer to have their tools (eg. license scanners) continue to
> work, which is why we shouldn't reduce the length too much

Do those tools do the following?
 if (contains(file->pathname, "linux")) {
file->license = "GPLv2";
break;
 }

I ask because I've seen a lot of two-, or even one-liners in the linux
tree. uboot is even crazier, with one-liners and a three-letter
designation for the license.

'licensecheck' correctly identifies and versions GPL with just the first
paragraph.

> (we had a number of proposals with just two lines back then).

I might be partially guilty for that.

Alex

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

Re: [coreboot] GPL license headers

[Alex G.]

On 10/20/2015 10:54 AM, ron minnich wrote:
> Eben Moglen, who ought to know, guided us on the release rules for the
> Plan 9 GPL release. 
> 
> Here is what he told us could go in each file:
> /*
>  * This file is part of the UCB release of Plan 9. It is subject to the
> license
>  * terms in the LICENSE file found in the top-level directory of this
>  * distribution and at http://akaros.cs.berkeley.edu/files/Plan9License. No
>  * part of the UCB release of Plan 9, including this file, may be copied,
>  * modified, propagated, or distributed except according to the terms
> contained
>  * in the LICENSE file.
>  */

+2

> On Tue, Oct 20, 2015 at 10:30 AM Patrick Georgi  > wrote:
> Get (the right set of) lawyers to sign off on that.

You were saying, Patrick?

Alex

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

Re: [coreboot] GPL license headers

[Alex G.]

On 10/19/2015 11:44 AM, Patrick Georgi wrote:
> Hi all,
> 
> we recently removed the FSF addresses from license headers in our
> files to avoid the maintenance of updating them every time the FSF
> decides to move their office.

+2

> Now we also added checkpatch.pl that comes from Linux to automatically
> ensure some consistency across the tree, and it looks for removal of
> the entire paragraph.

+2

> Now, that may just make sense and I'm willing to update the scripts to
> do that and update the tree.

+2

> Opinions?

I'd go as far as removing the last two paragraphs completely. The "this
comes with no warranty" boilerplate is only binding because it is also
included in the GPL proper, not because it's slapped in developers'
faces all so often.

> Patrick

Alex

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

[coreboot] Possible work from home coreboot developer position

[Alex G.]

I got a call yesterday from a staffing company about a coreboot position
with AMD's Austin, Texas office. It's a work-from-home, 12 month
contract with something to do with "AMD embedded processors". That's all
I know.

I turned down the guy, because I've got my own plate full of exciting
coreboot adventures, but I promised the guy I'll ask around. If that
sounds like something you might want you do, and the following apply to
you, drop me an email:
* you spell coreboot with a lowercase "c"
* you use git
* you use an external programmer
* you don't think of a california city when people say "pomona"
* you have fried at least one CPU, chipset, and memory module
* you have submitted contributions to coreboot in the past

Funny remarks aside, I'll get you and the recruiter in contact. I can't
promise anything beyond that.

Alex

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

Re: [coreboot] Rangeley SoC FSP and Mohon Peak board support

[Alex G.]

Hi David,

Martin suggested that we make this a standalone patch, so I've moved the
update to MAINTAINERS here [1].
[1] http://review.coreboot.org/11894

When is the FSP1.0 microcode handling patch expected to reach gerrit
code review on coreboot.org?

Alex

On 10/13/2015 03:04 AM, Guckian, David wrote:
> Hi Alex,
> 
> As per our chat yesterday with CSIG and IOTG:
> Fei Wang (Wang, Fei Z <fei.z.w...@intel.com>) and myself will be maintainers 
> for Rangeley/Mohon Peak.
> Jin Huang and York Yang will be maintainers for FSP1.0 & FSP1.1.
> Andrey Petrov will also be maintainer for FSP1.1.
> 
> Thanks.
> David.
> 
> -Original Message-
> From: Alex G. [mailto:mr.nuke...@gmail.com] 
> Sent: Tuesday, October 13, 2015 5:14 AM
> To: Guckian, David; coreboot@coreboot.org; gauml...@gmail.com
> Subject: Re: Rangeley SoC FSP and Mohon Peak board support
> 
> Hi David,
> 
> We had some chats today with CSG and IOTG teams, and from what I understood 
> Huang Jin, and York Yang wanted to be the maintainers. If that changed, 
> that's fine. We've started the process [1] of re-merging Rangeley [1], but we 
> need confirmation on who the maintainers [2] are going to be.
> 
> Alex
> 
> [1] http://review.coreboot.org/11860
> [2] http://review.coreboot.org/#/c/11860/3/MAINTAINERS
> 
> On 10/12/2015 10:55 AM, Guckian, David wrote:
>> Hi,
>>
>>  
>>
>> I saw recently that Rangeley SoC FSP and Mohon Peak board support has 
>> been removed from Coreboot.
>>
>> One of the reasons for the removal is that this is not used by anyone.
>>
>> That is not the case as there are users of this SoC and board.
>>
>> I have tested out a patch on Mohon Peak that will enable us to easily 
>> integrate with the latest microcode infrastructure.
>>
>> Going forward I can be the maintainer for Rangeley / Mohon Peak.
>>
>> I would like to work with the community to get this code added back in 
>> to Coreboot.
>>
>> A patch will be forthcoming in gerrit for your review.
>>
>> Thanks.
>>
>>  
>>
>> Regards,
>>
>> David
>>
>>  
>>
>>  
>>
>> --
>> Intel Shannon Limited
>> Registered in Ireland
>> Registered Office: Collinstown Industrial Park, Leixlip, County 
>> Kildare Registered Number: 308263 Business address: Dromore House, 
>> East Park, Shannon, Co. Clare
>>
>> This e-mail and any attachments may contain confidential material for 
>> the sole use of the intended recipient(s). Any review or distribution 
>> by others is strictly prohibited. If you are not the intended 
>> recipient, please contact the sender and delete all copies.
>>
> --
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
> 
> This e-mail and any attachments may contain confidential material for the 
> sole use of the intended recipient(s). Any review or distribution by others 
> is strictly prohibited. If you are not the intended recipient, please contact 
> the sender and delete all copies.
> 
> 

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

Re: [coreboot] Rangeley SoC FSP and Mohon Peak board support

[Alex G.]

Hi David,

We had some chats today with CSG and IOTG teams, and from what I
understood Huang Jin, and York Yang wanted to be the maintainers. If
that changed, that's fine. We've started the process [1] of re-merging
Rangeley [1], but we need confirmation on who the maintainers [2] are
going to be.

Alex

[1] http://review.coreboot.org/11860
[2] http://review.coreboot.org/#/c/11860/3/MAINTAINERS

On 10/12/2015 10:55 AM, Guckian, David wrote:
> Hi,
> 
>  
> 
> I saw recently that Rangeley SoC FSP and Mohon Peak board support has
> been removed from Coreboot.
> 
> One of the reasons for the removal is that this is not used by anyone.
> 
> That is not the case as there are users of this SoC and board.
> 
> I have tested out a patch on Mohon Peak that will enable us to easily
> integrate with the latest microcode infrastructure.
> 
> Going forward I can be the maintainer for Rangeley / Mohon Peak.
> 
> I would like to work with the community to get this code added back in
> to Coreboot.
> 
> A patch will be forthcoming in gerrit for your review.
> 
> Thanks.
> 
>  
> 
> Regards,
> 
> David
> 
>  
> 
>  
> 
> --
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution by
> others is strictly prohibited. If you are not the intended recipient,
> please contact the sender and delete all copies.
> 

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

Re: [coreboot] RFC: draft policy for accepting blob contributions to 3rdparty/blobs

[Alex G.]

Hi all,

I like that we're talking about a policy, but I really feel the policy,
as written right now, is specific to ISA blobs, and some of the points
do not map very well to non-ISA blobs. I've made some inline comments om
that.

A point about ISA blobs and their licensing, is that whatever legalese
they come with should not have restrictive clauses. E.g:
- no-reverse-engineering/decompilation clause(s)
- no-modification clause(s)
- only-use-on--hardware clause(s)
Abstracting the lack of source code, any clause which is incompatible
with the freedoms afforded by the GPL should be rejected. I realize this
sets a high bar, but I think protecting our contributors who do exactly
the things I've exemplified should take priority.

Alex

On 10/11/2015 08:35 AM, Patrick Georgi wrote:
> Hi all,
> 
> on the coreboot conference, we discussed a draft of a policy for
> inclusion of binaries into the 3rdparty/blobs repository.
> 
> If binaries are required, we want them redistributable in
> 3rdparty/blobs to make users' lives easier, and make it possible to
> deal with them as good as it is possible with binaries.
> Having clear rules should also make it easier for the developers at
> vendors who try to maintain these binaries - no more back-and-forth on
> gerrit that some more documentation is necessary and so on.
> Other rules are simply necessary (eg. a license allowing
> redistribution) for practical reasons.
> 
> This doesn't mean we encourage the use of binaries, and to use them,
> because they still need to be integrated through code in the coreboot
> repository.
> 
> The current draft can be found at
> https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTCrOwU/edit,
> and is open for comments.
> 
> The idea is to instate this policy (or something like this) once we
> found agreement. We can still revise the policy over time.
> 
> 
> Patrick
> 

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

Re: [coreboot] STACK_SIZE pcengines apu1

[Alex G.]

> In either case it's in AGESA.

Of course it's AGESA. Good job on figuring out which part of AGESA (this
 is usually the hard part).

Alex

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

Re: [coreboot] Unifying IO accessor macros

[Alex G.]

On 02/18/2015 12:52 PM, Julius Werner wrote:
 FWIW I sightly prefer write32(a, v)

Then go for it.

Alex


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

Re: [coreboot] [RFH] ACPI testers needed! -- free food*

[Alex G.]

On 02/11/2015 11:41 AM, Timothy Pearson wrote:
 All,
 
 I have recently updated the coreboot ACPI autogeneration code to
 generate valid processor _PSS objects when more than 10 cores are
 installed in one system.
 
 Unfortunately this required a rather large update to multiple boards in
 order to change the _PSS object name from CPUn to CPnn.  We would like
 some feedback to make sure this update didn't break anything before
 committing.
 
 The patch is available at: http://review.coreboot.org/8422
 
We're planning to merge that patch, but I'd like to give people a little
more time to make sure there aren't any outstanding or obvious issues.

Of course, the idea of free food usually gets people interested.

Alex

(*) free food for thought

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

[coreboot] Fwd: Re: New interface for I2C in coreboot

[Alex G.]

I knew there was something wrong to typing that from an Android phone.
It didn't get sent to the list.


 Forwarded Message 

On Feb 10, 2015 2:19 AM, Patrick Georgi  wrote:
 Am 10.02.2015 um 08:56 schrieb Alexandru Gagniuc:
  That's actually the way I2C is designed to work, and this sort of
API models
  it more accurately. Linux uses it. libeopencm uses it. spidev uses it.
 But hardware doesn't. The API is fine when you bitbang everything, but
 not when there's a controller that takes over some of the work, like
 programming the address.

 On such a controller, you have to pick apart struct i2c_seg* to figure
 out which elements are addresses and which are data, and split things
 into different registers.

Is that proper i2c or smbus controllers? Smbus is a different beast that
we really shouldn't simplify to i2c++ .

Assuming it's i2c proper, how do we handle such cases? I2c is i2c and it
makes more sense to abstract the nature of the hardware in an i2c
centric way. A silicon-specific API is the wrong way here.

I have patches in my pipeline to introduce generic i2c over displayport
aux channel code. That makes use of the low level nature of i2c_seg to
properly break down the AUX bus transactions in a hardware-agnostic way.

 I really don't see how it's useful to keep the data structures as low
 level as possible and then require drivers for more capable devices to
 uplift them to a higher abstraction level.

See section about abstracting hardware details above. There's no
measurable penalty for internal abstraction. There is however a penalty
for driving the hardware in a suboptimal way. That's the driver's job.

Sure, we can make a context based i2c API based on ops. Then we can
check the direct_read pointer and use that if it's not null. Though most
people will get it wrong when writing drivers. KISS.

Alex




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

Re: [coreboot] updating coreboot SeaBIOS on an Acer C720

[Alex G.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/08/2015 01:03 PM, Matthias Apitz wrote:
 
 Hello,
 
 I'm new to this list and do not even know if it is the right place
 to ask my question. So please be patient and/or forgive me.
 
 I'm running FreeBSD 11-HEAD on an Acer C720 Chromebook, booting
 directly into SeaBIOS. I'm facing seldom (let's say once a week
 with 12h++ uptime per day) problems of complete power-off of the
 device. I.e. the problem is not related to ChromeOS (because it is
 not running anymore in my C720) and perhaps unrelated to FreeBSD
 (because I see with Google Linux users with the same problem).
 

Suspect number one is the device overheating. The shutdown is
triggered by the EC. I don't know how you can enable ACPI debug output
on BSD though. On linux, it would be echo 1 
/sys/module/acpi/parameters/aml_debug_output, so whatever the FreeBSD
equivalent of that is.

If you can see lines like EC: LID OPEN in wherever the system log
is, then you know that's working. Look for things like EC: THERMAL
OVERLOAD or EC: THERMAL SHUTDOWN in said system log, right after a
shutdown.

Alex

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJU18nGAAoJELCXTU3o76/OHAMQAL11y4KxAVjgxsy4IoCtXCnB
HDVbLltPRol9LuQ29DqWGkfXWO6aPXyyWRfsoxALDG+a5cD9fp485/nW+RcPHbmK
m6A+X8cF+qVR0HqHr5iS/AA8EtsSNouGUl14Q/k1LdclW3tGSrvKL4TmtVgoiasF
HiEGTtgjipId0ZfKpAU+XqgAAUSdZ45nbooMHEJ++e2R0xPrz8Y/UBkxutoAVo11
Oo8e6o/MEDsFjYA6QhSGnkurX8zqj/e6+RKe5E6afJHvCEa7dcgyOxNZJ7QrFaXr
ls75ANhn0+tCyNjVEmEhoey6PwP7sL5PbdTHz0GkG11Ye7u+Dtu2kkpS7EfTB+o8
HWsIQBg43P8MbzPfBKeNshfgtsyHbIuxvATZ0+TBqrpAvuabtKTCO2UDxlGQAHbS
ueZM1oPTNhsB0gt0p8eAUsmg05uWtHUAdl0Z01l1Q3Y08wVMbnymKKImPaEzJUhu
vCOo4Wb7d4b9ZcvNseP88WFTZpwWWVKhoyiDlnRRQiABCwELDEgfOFMLHoJlrVNp
Cc/KyVkChQ/H3oxtFseS+COyYFffLN2p+es95TuhRcSfTjpdwGwHbsrtkEnTsPaZ
H5LqukqvnJKpOpBEsUaRefTPPV1a6SkNeEsxU2/JHTnkiizbaSKeo+2OXJ9XlmuF
OHq/G//DYaFV322VWU7q
=Elxi
-END PGP SIGNATURE-

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

Re: [coreboot] Changes to the coreboot Project Structure

[Alex G.]

David,

When you go out of line with a private email, expect to find yourself on
a public list.

Alex

On 03/23/2014 05:04 AM, David Hubbard wrote:
 On Sun, Mar 23, 2014 at 1:26 AM, mrnuke mr.nuke...@gmail.com
 mailto:mr.nuke...@gmail.com wrote:
 
 On Sunday, March 23, 2014 07:34:32 AM Vladimir 'φ-coder/phcoder'
 Serbinenko
 wrote:
  On 23.03.2014 04:10, Peter Stuge wrote:
   That isn't too different from creating a fork?
 
  Fork is better. With fork we don't have to deal with the same
 people who
  pushed the community out in the first place.
 
 Can you guys stop fucking worrying about a fork for the time being?
 We'll fork
 if we have to, but right now, we should be focused on refactoring the
 development process. If we do the latter rather than the former,
 chances are
 we'll find a mutually agreeable and better process.
 
 Stop pulling out rulers and unzipping your pants.
 
 
 Honestly, Alex, we'll fork if we have to, and you'll be ignored.
 
 When we fork, it'll be you holding the ruler. Contributing to coreboot
 hasn't made us any money, any glory, and that's perfect. Coreboot for me
 is about not paying $100 to Microsoft to get a license to boot my OS on
 my computer.
 
 David


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

Re: [coreboot] [announce] coreboot for the 21st century

[Alex G.]

On 03/21/2014 05:28 PM, ron minnich wrote:
 On Fri, Mar 21, 2014 at 1:33 PM, mrnuke mr.nuke...@gmail.com wrote:
 On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote:
 Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem
 if without romcc. :(

 Is there any way whatsoever to temporarily use the cache as SRAM?
 
 when we did the first real CAR work MTRRs were not needed. I'm not
 sure if they would be on the vortex. We might want to test the very
 early CAR code and see how it goes. It's actually quite simple.
 
It would be nice to make sure modern hardware uses modern infrastructure.

 Also, let's just take it a little easy here. These are proposals,
 nothing is ever perfect on first release, the world is not ending,
 Google is not showing up at coreboot.org in skimasks and unmarked
 uniforms ...
 
Damn! I was hoping to steal some ski gear from them.

 I think a fork would harm everyone

Sure, if you stab the person hard enough.

 and would be destructive of our
 common goals. Please remember that we are all trying to do the right
 thing, and our different situations give us different perspectives.
 
When Stefan sounds so serious, it's hard to tell whether he is just
proposing, or announcing changes. Remember, he's the guy that can port a
new board with his eyes closed [1]. People take him too seriously sometimes.

 Nobody is coming in here with bad motives. We're just trying to muddle
 our way through the many demands of different stakeholders now that
 coreboot, thanks to the efforts of some pretty dedicated people, has
 become a runaway success.
 
The bad-ness or good-ness of motives is relative. Note that I'm not
using bad in the sense of evil. Let's look at the six gatekeeper idea:
 * Easier for commercial entities to upstream code, therefore faster
progress for coreboot (good motive). (a)
 * Easier for commercial entities to upstream code, therefore we can get
lazy even if code quality drops (bad motive). (b)

So, in your 15 years of doing this, which option should prevail?

Alex

[1] http://www.coreboot.org/Coreboot_Developer_Facts

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

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

[Alex G.]

On 02/09/2014 07:34 AM, Paul Menzel wrote:
 Sorry, no idea. I thought there were some. At least not all boards 
 have been tested to my knowledge.
 
Please stop just throwing half-thoght proposals out there when you
have no idea (your words, not mine).

Alex


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

Re: [coreboot] Pavilion Chromebook 14 (Butterfly) QA session

[Alex G.]

On 01/20/2014 01:36 PM, David Hubbard wrote:
 Is this a typo? Did you mean the SATA is speed limited to 3Gbps?

Yeah. SATA speed is limited to 3 (three) Gbps.

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

[coreboot] Systemagent hangs on PCH init with H61 chipset

[Alex G.]

Is there anything special that systemagent needs before it will actually
do something useful. I've tried to run it on a board with a H61 chipset,
and it just hangs at System Agent: Initializing PCH. I remember Damien
had a similar problem a few months back.

Alex

coreboot-4.0-5198-g2588498-dirty Mon Jan  6 02:30:48 CST 2014 starting...
Setting up static southbridge registers... done.
Disabling Watchdog reboot... done.
Setting up static northbridge registers... done.
Graphics not supported by this CPU/chipset.
Back from sandybridge_early_initialization()
POST: 0x38
SMBus controller enabled.
POST: 0x39
POST: 0x3a
CPU id(306a9): Intel(R) Celeron(R) CPU G1610 @ 2.60GHz
AES NOT supported, TXT NOT supported, VT supported
PCH type: H61, device id: 1c5c, rev id 5
Intel ME early init
Intel ME firmware is ready
ME: Requested 16MB UMA
Starting UEFI PEI System Agent
Read scrambler seed0xb341 from CMOS 0x98
Read S3 scrambler seed 0x9b9a from CMOS 0x9c
find_current_mrc_cache_local: No valid MRC cache found.
System Agent: Starting up...
System Agent: Initializing PCH

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Alex G.]

On 12/27/2013 04:43 AM, Oliver Schinagl wrote:
 That said, how is A13, A20 support for coreboot?
 
Non-existent. On A10, we're still figuring out how to read from MMC
(partially working with code stolen from uboot), and how to init DRAM
(hangs with code stolen from uboot).  We don't have an infrastructure
for block devices, let alone MMC. Our ARM support is still wearing diapers.

Alex


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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Alex G.]

On 12/27/2013 01:29 PM, David Hendricks wrote:
 Just to clarify a couple things...
 
 We don't have an infrastructure for block devices, let alone MMC.
 
 Up until now this has been considered the work of the payload. The
 existing ARM platforms supported in coreboot use SPI ROM to store the
 firmware.
  
And I'd really love if this could continue to be the work of the
payload. Sadly, when the firmware is stored on a block device (as is the
case with the cubieboard) this becomes our job.

 
 Our ARM support is still wearing diapers.
 
 In a generic sense, ARM support is working quite well. We've used it on
 a few different SoCs already, not just in the Exynos family. Most of
 that code is quite simple and portable.
 
Is any ARM board shipping with coreboot?

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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Alex G.]

On 12/22/2013 11:45 PM, Olliver Schinagl wrote:
 It is 9k and has no RAM access and as far as we can tell not invoked
 after u-boot (sorry no coreboot (yet?) :p) takes over.

I must have missed the memo about no coreboot.

Alex


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

Re: [coreboot] Are any Chromebooks able to run fully libre?

[Alex G.]

On 12/24/2013 07:31 PM, Gregg Levine wrote:
 Hello!
 He's complaining about a missing memo regarding Coreboot and such like.
 
[...]
 I must have missed the memo about no coreboot.

 Fancy unpacking that statement for those of us who prefer less cryptic
 expression? :)

Guys! This is getting ridiculous. Somebody forgot to tell me to NOT work
on A10 support[1].

[1]
http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:cubieboard/a10,n,z

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

Re: [coreboot] BadBIOS Thoughts

[Alex G.]

On 11/20/2013 09:23 AM, ron minnich wrote:
 I've got a student coming in January and he's going to work on
 ChromeOS on AMD CPUs, starting with the Gizmo. If, at that time,
 someone has a suggestion for an AMD laptop which might be suitable,
 let me know.

Would you care to elaborate on that?
As much as I hate HP, they do seem to have some of the best AMD-based
laptops. I would look at the ProBook 655 G1 / 645 G1 or the HP ProBook
6475b.

Alex

P.S. One fornicating annoying downside is that HP's firmware really
sucks. Suspend-and-not-crash-and-overheat (TM) is sometimes working,
while Resume-and-not-defecate (TM) seems to be slightly more reliable.

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

Re: [coreboot] BadBIOS Thoughts

[Alex G.]

On 11/20/2013 08:57 AM, Oliver Schinagl wrote:
 On 20-11-13 10:48, mrnuke wrote:
 On 11/20/2013 03:19 AM, Oliver Schinagl wrote:
 What happened to decline the EULA and demand your money back? Nobody
 does that anymore?

 Did YOU ever do it?

 I haven't bought (nor used at home) a windows license in well over
 20? ... never. The only license I have is that came with my laptop,
 which was supplied by Uni, which is their volume key. I've built my own
 PC's for 20 years and when the day comes that I need to buy a new
 laptop, which isn't a hand down, I will definitely do this. I have no
 use nor desire for the license or the product.
 
In short, NO. Please don't speak out of body parts and without factual
knowledge. More often than not, the manufacturer has offered to buy back
the system, but outright refused to refund just the software. Closest I
ever got was a $20 refund on a $400 laptop, but this was an attempt at
stopping me from returning the whole device.

Alex

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

Re: [coreboot] Petition to Google: Please produce a midrange Chromebook

[Alex G.]

On 11/20/2013 10:13 PM, ron minnich wrote:
 Alex, you are of course free to submit such a petition. And, anyone
 who wishes can sign it.
 
 I've received an off-list request from one of our other enthusiasts
 (i.e. not a company or from a company) to remind you that you are not
 in a position to speak for the coreboot community. Possibly you
 should call yourselves an independent group of coreboot enthusiasts.
 
I apologize for the mis-wording. I did not mean to impose.

Alex

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

Re: [coreboot] BadBIOS Thoughts

[Alex G.]

On 11/17/2013 03:45 PM, ron minnich wrote:
 
 I've tried before with some of those guys They're not going to help
 because they are not designers. Below a fairly high level, they don't
 know what's in their systems. Sure, it's a nice shiny skin. But all
 the real work is done by the ODM.
 
Then what can be done?

 This is a really hard problem. Google is the first company, aside from
 Linux NetworX, to really commit to a product that uses coreboot. It's
 been nice to see.
 
Is Google's plan with the chromebooks to enter the laptop market, or are
chromebooks meant to create a new market? It they are meant to enter the
laptop market, Google is doing it wrong, and I've never seen Google do
things wrong.

 It bothers me that so few people know what's inside their computers,
 but maybe it should not: most people don't know how their cars work
 either. Maybe the days of really understanding your hardware are gone.
 
It bothers me that Google is touting golf carts as taking you to work
and back. Jokes aside. When 7/6 people have problems with fractions and
1 out of 10 people don't understand binary, how can one expect the
majority of people to understand PC hardware?

Alex


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

Re: [coreboot] Generate microcode from tree not working

[Alex G.]

On 07/15/2013 05:39 AM, Alec Ari wrote:
 Hello! Someone recently contacted me directly about my MA785GM-US2H coreboot 
 port, and they weren't able to get the microcode to generate:
 
 HOSTCC cbfstool/cbfstool (link)
 LD cpu_microcode_blob.o
 coreboot/util/crossgcc/xgcc/bin/i386-elf-ld: no input files
 make: *** [build/cpu_microcode_blob.o] Error 1
 
Oh nom nom nom. Your CPU has not been ported to loading microcode from CBFS.

 I've tested the compilation process here too and I get the same problem, not 
 sure how to fix it. It doesn't work for me no matter what board I select in 
 Kconfig.
 
We're a bunch of old wizard farts using grep blackmagic.

config CPU_MICROCODE_IN_CBFS
default CPU_MICROCODE_CBFS_GENERATE if CPU_MICROCODE_IN_CBFS
default CPU_MICROCODE_CBFS_NONE if !CPU_MICROCODE_IN_CBFS

The rest is left as an excercise to the reader.

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

Re: [coreboot] Supported laptops (again), treacherous computing

[Alex G.]

On 07/22/2013 01:25 PM, Denis 'GNUtoo' Carikli wrote:
 On Mon, 15 Jul 2013 08:14:22 -0700
 ron minnich rminn...@gmail.com wrote:
 
 I don't see how excluding the new, fixed version from coreboot helps
 anything. Further, it means you don't have bug-fixed microcode, which
 seems bad.
 It is at least a licensing problem:
 That microcode has a proprietary license in its header,
 with some terms that are incompatible with the GPLv2...
 And coreboot is released under the GPLv2.
 
Denis,

We have in place a pretty darn good infrastructure of separating the
microcode from the coreboot stages. It's very easy to store microcode as
a _separate_ CBFS file. Not all CPUs use this, but changing this is
trivial. Patches welcome.

Alex

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

Re: [coreboot] Best Supported Laptop

[Alex G.]

On 06/04/2013 12:36 AM, David Hendricks wrote:
 On Mon, Jun 3, 2013 at 1:57 PM, Alex G. mr.nuke...@gmail.com wrote:

 On 06/03/2013 03:10 PM, Oliver Schinagl wrote:
 On 06/03/13 16:03, Denis 'GNUtoo' Carikli wrote:
 Hi,

 On Sun, 2 Jun 2013 20:54:04 -0500
 slhac tivistslhactiv...@gmail.com  wrote:

 Which supported laptop is the most free?
 The Lenovo X60.
 Strange that an Intel Part has the best support.


 I find the same thing depressing.

 When A) AMD officially supports coreboot

 There really aren't that many laptops with AMD CPUs. I think that's the
 root of the problem here.
 
 
 AMD CPUs are generally very well supported by coreboot.
 
 But as you point out, the number of laptops with AMD CPUs is somewhat
 low. And to make matters more complicated, the number of laptops with
 an AMD CPU *and* a well-understood embedded controller* are even
 lower. Maybe someone knows of a good AMD target laptop with a workable EC?
 
Add an A10 processor, backlit keyboard, and IPS display. I'd love to get
one of those.

Alex

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

Re: [coreboot] Best Supported Laptop

[Alex G.]

On 06/03/2013 03:10 PM, Oliver Schinagl wrote:
 On 06/03/13 16:03, Denis 'GNUtoo' Carikli wrote:
 Hi,

 On Sun, 2 Jun 2013 20:54:04 -0500
 slhac tivistslhactiv...@gmail.com  wrote:

 Which supported laptop is the most free?
 The Lenovo X60.
 Strange that an Intel Part has the best support.
 

I find the same thing depressing.

 When A) AMD officially supports coreboot

There really aren't that many laptops with AMD CPUs. I think that's the
root of the problem here.

 B) Intel requires closed blobs for certain chips for RAM init.
 
Sandybridge and friends require it. The Lenovo x60 uses an older CPU and
chipset, and those don't require blobs, AFAIK.

Alex

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

[coreboot] Hijacking (was Trying to get coreboot running on VIA EPIA-M (lzma: Decoding error = 1) )

[Alex G.]

On 05/20/2013 10:16 AM, Marius Schäfer wrote:
 Hello,
 
 I just want to play around with coreboot on my old VIA EPIA-M, as it
 should be supportet and a good place to start. I just followed the Build
 HOWTO. But I always end up with 'lzma: Decoding error = 1'.
 I clonded coreboot from git, in menuconfig I choose the VIA EPIA-M board
 and built everything
 
Hello Marius,

I'm sorry to hijack this thread. Let's call it a fork of the original
thread.

I couldn't help but notice you have a VIA southbridge. I'm currently
working on de-duplicating SMBus code, and also have a VIA chipset handy.
I see the SMBus of the 8235 is hellishly similar to the VX900 I'm
working on. I have a patch which adds a generic SMBus implementation for
VIA chipstes here:

http://review.coreboot.org/#/c/144/

If you have the time and patience, could I ask you to pull that patch
and mess with the 8235 early_smbus.c and Makefile.inc to take advantage
of that code?

Alex


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

[coreboot] Rebasing a 2009 branch on current master (VX900 anyone?)

[Alex G.]

Hi,

I am that guy that never seems to get VX900 working properly. I've
recently received some code[1] for the VX900 from VIA. It is based on a
coreboot fork from about 2009.

Rather than try to continue my own VX900 effort, I think it is better to
use the code provided by VIA, and clean that one up.

I don't have the SVN history for the code, but Cristi was able to trace
it back to somewhere around hash a9c5ea08d07d343d32d4c083a232107bd84d8064

VIA has no interest in maintaining or rebasing the code, so we're on our
own here. The good news is that using this code will reduce the time
needed to complete the VX900 port significantly.

I therefore ask the gurus, What is the best way to go about this?

Let's hope we can get this code working with our current master. If we
manage to rebase it, I can clean it up, and optimize it a bit.

Alex


[1] http://g-tech.no-ip.org/~mrnuke/coreboot_vx900_vt8595a.tgz

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

[coreboot] Microsoft Antitrust behaviour

[Alex G.]

To the United States Department of Justice,

I would like to bring to your attention a matter of anticompetitive
behaviour, which, in my honest opinion, will have a deep negative impact
on the personal computer (PC) market.

== What are the names of companies, individuals, or organizations that
are involved? ==

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

== How do you believe they have violated the federal antitrust laws?
(For details on federal antitrust laws, see Antitrust Laws and You.) ==

Microsoft is using its market power in the PC operating system (OS)
market to coerce computer hardware manufacturers to include a technology
(SecureBoot) which, under its current form, will prevent consumers from
installing and using the OS of their choice on their computers.


== Can you give examples of the conduct that you believe violates the
antitrust laws? If so, please provide as much detail as possible. ==

Microsoft is including SecureBoot with its upcoming Windows 8 OS, and
is requiring that hardware manufacturers support this feature.
SecureBoot requires that the computer's hardware initialization software
(firmware) performs a cryptographic check of the OS before starting the
OS. As part of SecureBoot, the OS loader (bootloader) must be signed
with a cryptographic key, and the firmware checks this signature before
loading the OS to ensure that it has not been modified by malicious
software (malware).

Microsoft claims that SecureBoot is designed as a security feature
against malware. However, as part of its requirements for SecureBoot,
Microsoft only specifies that the bootloader must be verified against a
Microsoft key. It does not specify any of the following:
1) The user being able to disable SecureBoot at his or her option
2) The user being able to specify his or her key and boot the OS of his
or her choice
As we have seen in the past, most manufacturers will adhere only to the
minimum requirements set by Microsoft, and thus neither point (1) nor
point (2) will be implemented in an overwhelming majority of firmware.
This effectively prevents the user from using any other OS than
Microsoft's Window 8, strengthening Microsoft's artificial monopoly in
the OS market. Microsoft is well aware of the implications of not
addressing points (1) and (2), but has remained silent on the issue.


== What is the product or service affected by this conduct? Where is the
product manufactured or sold, or where is the service provided? ==

All future PC systems will be affected by this conduct.


== Who are the major competitors that sell the product or provide the
service? ==

Apple sells its MacOS operating system with its macintosh line of
computers. While Apple does not allow use of MacOS on non-Apple
computers, it allows any OS to be installed and used on its line of
computers. Since Apple computers are priced high, and are not as
configurable as a regular PC, buying a Macintosh in order to be able to
use the OS of their choice is not an option for the majority of users.

RedHat and Novell both sell their flavor of the GNU/Linux operating
system. Their business relies on the user being able to install the OS
of his or her choice, and they will be negatively impacted by
Microsoft's conduct.


== What is your role in the situation in question? ==

I am a user of free and open source software (FOSS), including, but not
limited to linux, GNU, KDE, apache, etc. I am also a software developer
which has contributed to many of these projects (by improving their
source code).


== Who is harmed by the alleged violations? How are they harmed? ==

All users of FOSS are harmed. By not being able to install the OS of
their choice, they will be forced into using Microsoft's OS, or buying
computers which implement points (1) or (2). Considering the
proliferation of linux in the server and workstation segment, I do
expect some manufacturers to implement either (1) or (2) in their server
and/or workstation products; however, servers and workstations are
significantly more expensive than regular PC systems. Thusly, FOSS users
will be forced to either use Microsoft's OS, or spend a significantly
higher amount of money on PC hardware in order to be able to use the OS
and software of their choice.


I do believe that, if implemented ethically, SecureBoot has the
potential to be a great technology, and a very effective way to defend
against certain types of malware. However, in order for my previous
statement to have any value, the user must be given the choice to use
the OS of their choice on _any_ computer he or she chooses to buy. I
very strongly believe that, the best way to ensure the users' freedom
remains unaffected, is to have Microsoft modify its SecureBoot
specification such that both the following are mandated by the
specification:
1) The user, should he or she chose to do so, must be able to specify
the cryptographic keys to use to use as part of the bootloader
verification process (including having the 

Re: [coreboot] new Trinity APUs supported?

[Alex G.]

On 09/28/2012 03:47 AM, Rudolf Marek wrote:
 Hi all
 
 I'm considering to buy FM2 A10 CPU  Asus F2A85-V PRO (or some cheaper
 variant)
 
 http://www.asus.com/Motherboards/AMD_Socket_FM2/F2A85M_PRO/ (looks it
 has also serial port).
 
 The CPU is I think family 12h. I checked the coreboot sources and there
 seems to be only LLANO mentioned.
 
 Any clue?
 
 Thanks
 Rudolf
 
I own an A10-4600M laptop and /proc/cpuinfo says it's fam 15. (Pretty
awesome CPU, very happy with it).

AGESA should be able to handle A10s nicely, and I see no reason why at
least raminit shouldn't work.

Alex

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

[coreboot] Fwd: Microsoft Antitrust behaviour

[Alex G.]

What are your thoughts? Do you think any action will be taken?

Alex


 Original Message 
Subject: Microsoft Antitrust behaviour
Date: Mon, 24 Sep 2012 14:39:19 -0500
From: Alex G. mr.nuke...@gmail.com
To: antitrust.complai...@usdoj.gov

To the United States Department of Justice,

I would like to bring to your attention a matter of anticompetitive
behaviour, which, in my honest opinion, will have a deep negative impact
on the personal computer (PC) market.

== What are the names of companies, individuals, or organizations that
are involved? ==

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

== How do you believe they have violated the federal antitrust laws?
(For details on federal antitrust laws, see Antitrust Laws and You.) ==

Microsoft is using its market power in the PC operating system (OS)
market to coerce computer hardware manufacturers to include a technology
(SecureBoot) which, under its current form, will prevent consumers from
installing and using the OS of their choice on their computers.


== Can you give examples of the conduct that you believe violates the
antitrust laws? If so, please provide as much detail as possible. ==

Microsoft is including SecureBoot with its upcoming Windows 8 OS, and
is requiring that hardware manufacturers support this feature.
SecureBoot requires that the computer's hardware initialization software
(firmware) performs a cryptographic check of the OS before starting the
OS. As part of SecureBoot, the OS loader (bootloader) must be signed
with a cryptographic key, and the firmware checks this signature before
loading the OS to ensure that it has not been modified by malicious
software (malware).

Microsoft claims that SecureBoot is designed as a security feature
against malware. However, as part of its requirements for SecureBoot,
Microsoft only specifies that the bootloader must be verified against a
Microsoft key. It does not specify any of the following:
1) The user being able to disable SecureBoot at his or her option
2) The user being able to specify his or her key and boot the OS of his
or her choice
As we have seen in the past, most manufacturers will adhere only to the
minimum requirements set by Microsoft, and thus neither point (1) nor
point (2) will be implemented in an overwhelming majority of firmware.
This effectively prevents the user from using any other OS than
Microsoft's Window 8, strengthening Microsoft's artificial monopoly in
the OS market. Microsoft is well aware of the implications of not
addressing points (1) and (2), but has remained silent on the issue.


== What is the product or service affected by this conduct? Where is the
product manufactured or sold, or where is the service provided? ==

All future PC systems will be affected by this conduct.


== Who are the major competitors that sell the product or provide the
service? ==

Apple sells its MacOS operating system with its macintosh line of
computers. While Apple does not allow use of MacOS on non-Apple
computers, it allows any OS to be installed and used on its line of
computers. Since Apple computers are priced high, and are not as
configurable as a regular PC, buying a Macintosh in order to be able to
use the OS of their choice is not an option for the majority of users.

RedHat and Novell both sell their flavor of the GNU/Linux operating
system. Their business relies on the user being able to install the OS
of his or her choice, and they will be negatively impacted by
Microsoft's conduct.


== What is your role in the situation in question? ==

I am a user of free and open source software (FOSS), including, but not
limited to linux, GNU, KDE, apache, etc. I am also a software developer
which has contributed to many of these projects (by improving their
source code).


== Who is harmed by the alleged violations? How are they harmed? ==

All users of FOSS are harmed. By not being able to install the OS of
their choice, they will be forced into using Microsoft's OS, or buying
computers which implement points (1) or (2). Considering the
proliferation of linux in the server and workstation segment, I do
expect some manufacturers to implement either (1) or (2) in their server
and/or workstation products; however, servers and workstations are
significantly more expensive than regular PC systems. Thusly, FOSS users
will be forced to either use Microsoft's OS, or spend a significantly
higher amount of money on PC hardware in order to be able to use the OS
and software of their choice.


I do believe that, if implemented ethically, SecureBoot has the
potential to be a great technology, and a very effective way to defend
against certain types of malware. However, in order for my previous
statement to have any value, the user must be given the choice to use
the OS of their choice on _any_ computer he or she chooses to buy. I
very strongly believe that, the best way to ensure the users' freedom
remains unaffected, is to have Microsoft modify its SecureBoot

Re: [coreboot] Support for a desired Motherboard

[Alex G.]

On 09/16/2012 12:58 PM, g...@habmalnefrage.de wrote:
 Hallo,
 
 I am interested in buying a new motherboard: ASUS Sabertooth 990FX or 
 Gigabyte GA-990FXA-UD7 and wanted to use coreboot on it.
 In the released supported boards-List is none of them mentioned. Are there 
 any further plans for one of the boards?
 
 Peter

I guess you're the one that has an answer about further plans.

To quote our IRC topic:
Your board is not in the list?
(http://www.coreboot.org/Supported_Motherboards) It will not be unless
you do the port.

Alex

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

Re: [coreboot] git commit problem

[Alex G.]

We need the complete git command(s) and complete git output.

Alex

On 09/04/2012 12:33 AM, Wang, SiYuan wrote:
 Hi,
 there is problem when I use git commit to commit changes. the message says:
 
 test failed:
 'build/.../static.c build/.../static.c build/.../static.ramstage.o 
 build/.../static.romstage.o' should be 'build/.../static.c build/.../static.c 
 build/.../static.ramstage.o build/.../static.romstage.o'
 
 then I discard all my changes, but the problem is still there.
 would somebody can help me? thank you!
 
 --
 WANG Siyuan
 


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

Re: [coreboot] drivers/generic/ioapic enable_dev not called

[Alex G.]

IIRC:
CPU - K8M890 == HT bus
K8M890 - VT8237x == VIA V4 bus

Since your problems come from the devices in VT8237x, I doubt HT is the
offender. HT and PCI code uses very similar algorithms to locate and
sort devices. Don't convince yourself that HT is the issue, or that
_this_ code is the issue until you find it :)

I think it's most likely a misplaced end in devicetree.cb, but I
didn't find any myself. Best to push your changes to gerrit, and use the
nice and shiny pretty print that the forefathers implemented for
devicetree files. ;)

Alex


On 08/29/2012 01:22 AM, Rudolf Marek wrote:
 Hi,
 
 Thanks for the hint, but please note there is the HT: it means that
 hypertransport.c is relevant here and not the pci_device.c.
 
 Thanks
 Rudolf


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

Re: [coreboot] drivers/generic/ioapic enable_dev not called

[Alex G.]

On 08/28/2012 05:18 PM, Rudolf Marek wrote:
 Hi all,
 
 Just an update to this problem. It was missing scan_static_bus in parent
 device. Thanks goes to MrNuke ;)
 
 I have now another problem related to that work. For some reason HT bus
 thinks there are some left over devices:
 
 Capability: type 0x08 @ 0x60
 flags: 0x0060
 PCI: 00:00.0 count: 0003 static_count: 0010
 PCI: 00:00.0 [1106/0336] enabled next_unitid: 0010
 PCI: 00:0f.0
 PCI: 00:10.0
 PCI: 00:10.1
 PCI: 00:10.2
 PCI: 00:10.3
 PCI: 00:10.4
 PCI: 00:11.0
 PCI: 00:12.0
 PCI: 00:13.0
 PCI: 00:13.1
 HT: Leftover static devices. Check your devicetree.cb
 
 For this reason second SB IOAPIC is not used too. I dont know what could
 be possibly wrong with my devicetree. Im attaching bootlogs and
 devicetree to this mail. If someone knows plz help.
 
 Thanks
 Rudolf
 
 


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

Re: [coreboot] drivers/generic/ioapic enable_dev not called

[Alex G.]

For some reason, it seems that coreboot cannot find devices at those
devfn. Normally, I'd say are you sure you aren't setting/unsetting a
bit that disables those devices but there are just too many leftover
devices.

As a first step, pci_scan_get_dev() seems to be the offender. I would
put a printk to get both the argument devfn, and
(*list)-path.pci.devfn, and try to figure out why the offending
devices are not located. This should at least shed some light on where
to look next.

Alex

On 08/28/2012 05:18 PM, Rudolf Marek wrote:
 Hi all,
 
 Just an update to this problem. It was missing scan_static_bus in parent
 device. Thanks goes to MrNuke ;)
 
 I have now another problem related to that work. For some reason HT bus
 thinks there are some left over devices:
 
 Capability: type 0x08 @ 0x60
 flags: 0x0060
 PCI: 00:00.0 count: 0003 static_count: 0010
 PCI: 00:00.0 [1106/0336] enabled next_unitid: 0010
 PCI: 00:0f.0
 PCI: 00:10.0
 PCI: 00:10.1
 PCI: 00:10.2
 PCI: 00:10.3
 PCI: 00:10.4
 PCI: 00:11.0
 PCI: 00:12.0
 PCI: 00:13.0
 PCI: 00:13.1
 HT: Leftover static devices. Check your devicetree.cb
 
 For this reason second SB IOAPIC is not used too. I dont know what could
 be possibly wrong with my devicetree. Im attaching bootlogs and
 devicetree to this mail. If someone knows plz help.
 
 Thanks
 Rudolf
 
 


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

Re: [coreboot] drivers/generic/ioapic enable_dev not called

[Alex G.]

Hi Rudolf,

You need to have the ioapic driver compiled in.

select DRIVERS_GENERIC_IOAPI

In your mainboard's Kconfig should do the trick.

Alex

On 08/17/2012 09:30 AM, Rudolf Marek wrote:
 Hi all,
 
 I'm working on ioapic_irq support on M2V-MX SE. While at it, I wanted to
 factor out SB and NB ioapic initialization and use the generic ioapic
 driver. However I never see that code from drivers/generic/ioapic.c is
 called.
 
 I tried various devicetree combinations, but nothing works. I'm out of
 ideas, possibly this has to do something that I do this on AMD system.
 
 My first question is what is the difference between .enable and
 .enable_dev anyway?
 
 I'm pasting here my simple devicetree.cb, the commented version does
 not work either and I get complains that it is left over static device
 and no PCI device.
 
 I think in both cases I got IOAPIC: 09 missing read_resources
 And enable_dev is never called. I put there a printk.
 
 Please can someone sched some light?
 
 Thanks
 Rudolf
 
 chip northbridge/amd/amdk8/root_complex # Root complex
   device lapic_cluster 0 on # APIC cluster
 chip cpu/amd/socket_AM2 # CPU
   device lapic 0 on end # APIC
 end
   end
   device pci_domain 0 on# PCI domain
 subsystemid 0x1043 0 inherit
 chip northbridge/amd/amdk8  # mc0
   device pci 18.0 on# Northbridge
 # Devices on link 0, link 0 == LDT 0
 
 chip southbridge/via/k8t890 # Southbridge K8M890
 
   device pci 0.0 on end # HT
   device pci 0.5 on
 chip drivers/generic/ioapic
 register irq_on_fsb = 1
 register base = 0xfecc
 device ioapic 9 on end
 end
   end
 
 end #end NB chip
   end #end LDT0
 
   device pci 18.0 on end #LDT1
   device pci 18.0 on end #LDT2
 
   device pci 18.1 on end
   device pci 18.2 on end
   device pci 18.3 on end
 end #mc0
 
 #chip drivers/generic/ioapic
 #register irq_on_fsb = 1
 #register base = 0xfecc
 #device ioapic 9 on end
 #end
 
   end #pci_domain
 end #root complex
 


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

[coreboot] Documenting the process of Timestamp collection during romstage

[Alex G.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The idea of collecting timestamps during romstage is awesome. the only
problem is that the code that does that is completely undocumented.
Some stuff you figure out by looking at the code.
Then there's timestamp_init(tsc_t), whose argument is read by the
mainboard from some mysterious registers.
Then there's also:

build/lib/timestamp.romstage.o: In function `timestamp_init':
/home/mrnuke/Sources/coreboot/src/lib/timestamp.c:40: undefined
reference to `cbmem_add'
build/lib/timestamp.romstage.o: In function `timestamp_add':
/home/mrnuke/Sources/coreboot/src/lib/timestamp.c:58: undefined
reference to `cbmem_find'


Can someone please explain the proper procedure of getting timestamp
collection running. I'll even sacrifice myself and add doxygen-style
documentation for the next poor fella trying to implement this.

Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQKd/IAAoJEL0kPHNPXJJKwQkP/jcz93TZXyCkg9vJMixk5vQB
CGifXjPcJGyAE0IfFZZivTk4mKDt6KWuFYDRHmtK4zcEaW/u3j8JBgTq2/QSbsS9
7z93BuRg4ei3HeTvxq5mEmRu/F3cikdHew17pZcLaX+4uuCli76ZnUVNachpIpwo
f6j5imnoLGGAmc5xdUhivZ+AGtpgFLPBWyksikpiXdmdPJAV8WT5j6G8sIMMy7Ji
RStOR+/zYEvpadGk76+RJ1uumpmhPWWS6eeSjabJ2wn65zaOzqmejRjR1tVHDeJm
v2pgciqNxr8c8Ch4YKwFjkJGanhe7EoI3GmW82WnzvzeVLatEBrVEtc1WaxcMx47
JNRCuJGG7TiaWnANYBlKEdWv6QQ1ZzaVvUfanzls8m9SDDlGElJFEGEBlp/4SpGR
PaCAzGRikf+bPFQ43tS2vl0kY7BIIdT0huvC/mrWNFkx+ubvRUeatp1nTLwoZhXX
73BLNw7Vp7yXU/ngknSlQ8XlZBoCIiM+MAec2BLnpvUDI7JAj2XuiJYaVplC92Gw
UzzkC+HtcAFIdUuKU3iEYs+0rjm3LSNGBA7AgPe/O+TMeRAehLIjW8+WXIDMItXZ
t2jljDpR8va0vKeEuXbedhds+raCJyvxmesbmQpUlK1yplSlJMlHdHFL6Mj9EoZn
67D/FNswHk/xLqWh8QuU
=LP+r
-END PGP SIGNATURE-

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

Re: [coreboot] User interface on coreboot

[Alex G.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/10/2012 03:09 AM, Lap Ngo Doan wrote:
 Hi all, As you may know, when we enter to BIOS, we can use the 
 keyboard to change some settings such as : enable/disable 
 something, change boot devices priority It is kind of user 
 interface on BIOS. In the coreboot website, they said *coreboot* 
 is a Free Software project aimed at *replacing the 
 proprietary**BIOS*
This statement is unfortunately misleading. It's not our fault really.
It comes from the tendency to name the firmware BIOS, which is in
fact hardware initialization, then the actual BIOS.
Coreboot is the hardware initialization part.

 If we want to add some interactions with hardware like BIOS 
 firmware provided us (use keyboard to enable/disable some 
 options),  how could we do it with coreboot?

Keep those settings in NVRAM, and write a payload to read and modify
NVRAM. libpayload is there for the taking; the biggest hurdle may be
figuring out how to parse NVRAM (different hardware stores different
settings in different places). You might also need to modify parts of
coreboot to make it use NVRAM for settings.
Some to most boards have a cmos.layout file. You can find a way to
make that available to your payload. You have a bunch of options to
play with.

Then SeaBIOS can boot from CBFS, and you'd just have to use its boot
menu to load your payload. For all others, there's debit bayou.

This sounds like a cool project, and a nice way to get your hands
dirty with coreboot, learn your way around.

Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQKDDgAAoJEL0kPHNPXJJKSdMP/jIJ5NMpaDSHydv1SVPOXmPt
D4uuUogV+8sDk+dqaSoTfwpXlW9UMSaAXjFbMfoF+zA0iIU9uyNyVfzuVtabNRoO
TsvhF7VM+UfIHsGoNBDdwAfdAqswdvx8gQ9RlpsUv9jTI9uC00iX/FWB30NKI5Sf
oic4kxqTkU5+Akhz3htk0Hn71ZozmdaNy/xS50X1bMeeiYRSEZMsCVNX9KR2rmHX
P2fTA697xXkpv1ZtnwvhTAZ4cbpPMsYaEBKOw41uF441XA0TmvV9qbHpG5NFOODz
1YueHPgieFXQzvV3gsFF/vBWcBe60CSId9WwlIJuWnMakBULXfVJWCAx3LCRpq5m
/iiS188ENXQ24dSkKjmOcf4Hxdfbat+szZRW4dBFdx9/LKl6XaVsvVRDmcjsrqKu
YbLxyJGRCWSXViE99Cf4/jcSB20w8+wLwWgfqVSagj0A2RGD6V1l6j/YyK0vj02j
BVko7oKial4NQczBT7JzExhw20+HmYNE4b0VZtTwRGqjI3aVn02Y+bk8c+sAx0th
p5r5FLAsq01Z7TyoKnPVMUenTWFP2FsV9uEFEHqx1fAXAkBp/G9xaHVaQGhcQW+y
Gp1p0whgVIOJHvqvH7YVrXwjTf01FY3unwTnZhZnEFsZ8I+yvz7zKnOHDgCfFv0s
twX/0lgHUW2HDSZ1NwcD
=Dftw
-END PGP SIGNATURE-

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

[coreboot] Moving gerrit to an separate mailing list

[Alex G.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've brought this up today on IRC. My main argument is that the
coreboot mailing list should be a place for discussion, for newcomers
asking for help, talking about the future of the project, etc.
Definitely more for discussion and less for patch review.

We have gerrit for patch review. Some (actually, a lot) of people
prefer to do their reviews by replying to the gerrit emails. It's
awesome to have this option. The more the merrier, right? Right.

Back in the days -- I mean wy back, think patchwork and svn --
doing patch review on the list, with some deficiencies, worked fine.
We switched to git and gerrit. We eventually got to the problem that
gerrit traffic accounts for most of the traffic on the mailing list.
It makes the list irritatingly clobbered for some people, to the point
they just stop using it.

The argument from the I like gerrit in the mailinglist camp is
setting up your own filter to keep out gerrit message is easy. We
can't really force people to do this. They (myself included) would
rather stoThp using the mailing list.

All I've said and refuted above are arguments and rants we like to use
to tease each other. I strongly believe that it makes sense, now more
than ever, to separate development and discussion traffic into two
separate lists. I hope you all agree.

Alex
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQItoNAAoJEL0kPHNPXJJK+UIP/2yVfa/UziIDeQRJdhhUOs1C
UlGji9eLHw4rPxm9NS+3n+s3bmQDdnOMZkOZ0mbXCO/ufTCZurbZ7uOlDQasTYtt
rPyU5GeMnILhH159ZIAo8KBI53HrBH+RdxOyxY0gVvSw5Vb2Ye4LVCTvrfDIZJo3
p+h7aPeAaR8mApwo24PAqJX9NDYZjytfuOFZ91Jw8YS5BXykH8oa8Xj32ezqt7fV
lxOqew7UjNdVT26aCuHnTqlPYUw/Nl97iluWrebd8Rre6PLai03dxXqVlvgHHVXJ
UzJFflwAn4gEjnYrOfd4qu/sCkWJkCQDfYx/DAiJtkPjUeY1FNw1Dnibsi6mP+F3
IleLl/SWxv21UnZM6OJ999CxYTdXD2sNytlM65d67UniGfeN6v1ARPZG0l2FzsRC
PfUhrcPKryAsVCf4otWI64QUT0r0KgxU6qUdX6ZOvFerKcE+ono8ERJCL4v9TBB+
DVJGV2Dil+67FPzPriRhcLufPfQ14+B8BRNcFYbYOkmgjBtRmrZk/WvaEU5uVvII
sbXbEzfSKrCKGr/K00XPRti0CRg7wn6MVeVsLTxvA5HMIkuGxd9FfmG9EPrC0JXZ
tljwICM4AJkbQ6EkDg2Z66SUWnPBtfiCLNyPs8IfK5rfYkhkreqnWRtwxl8Ua7SE
Lk13bwHJ/Jyf5r3RDAJU
=543W
-END PGP SIGNATURE-

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

[coreboot] Help needed on VX900 port

[Alex G.]

I have been working on a VIA VX900 port for over a year. Main problem is, I 
can't
get the memory running properly.

If you have a VX900 board, I would definitely appreciate some help. The 
datasheet
for the VX900 is available from http://linux.via.com.tw/. I also have some code
provided by VIA, which unfortunately, is missing lots of #define, and lookup
tables, so it's not a plug in solution, but has been a useful resource in
correcting many problems with my code.

If you are interested, I can provide my branch of the code, and the code 
provided
by VIA (which was given to me under GPLv2). I cannot provide any documentation,
other than the comments I have made in the code, sorry.

So far I've got CAR working. This is actually just the CAR code from the VIA C7,
but it plays nicely with the VIA Nano.
Serial console is working on my EPIA M-850, and of course, so is the SMBUS.

I've got the memory init code running up to the point that some memory banks 
(bank
= chip_on_the_dimm) are returning correct data, and some, just garbage.

I ran out of ideas last night, and I could definitely use a fresh perspective. 
If
anyone is interested in the VX900, please let me know.

Alex

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

Re: [coreboot] potentially wrong uses of ifdef/if defined

[Alex G.]

On 04/19/2011 04:33 AM, Stefan Reinauer wrote:
 ./src/northbridge/amd/amdk8/coherent_ht.c:#ifndef CONFIG_K8_HT_FREQ_1G_SUPPORT
#ifndef CONFIG_K8_HT_FREQ_1G_SUPPORT
#define CONFIG_K8_HT_FREQ_1G_SUPPORT 0
#endif

 ./src/northbridge/amd/amdk8/coherent_ht.c:#ifndef
 CONFIG_MAX_PHYSICAL_CPUS_4_BUT_MORE_INSTALLED
#ifndef CONFIG_MAX_PHYSICAL_CPUS_4_BUT_MORE_INSTALLED
#define CONFIG_MAX_PHYSICAL_CPUS_4_BUT_MORE_INSTALLED 0
#endif

 ./src/northbridge/amd/amdk8/coherent_ht.c:#ifndef CONFIG_ENABLE_APIC_EXT_ID
#ifndef CONFIG_ENABLE_APIC_EXT_ID
#define CONFIG_ENABLE_APIC_EXT_ID 0
#endif

These lines can just be deleted.
Alex

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

Re: [coreboot] where can i ask detailed technical questions about hardware?

[Alex G.]

On 04/06/2011 02:19 PM, Peter Stuge wrote:
 ali hagigat wrote:
 Is there any active site to discuss Intel data sheets?
 
 Not really. :\
Well, now and then there might be some people on #coreboot that have a
nibble of extra knowledge on a specific topic, but nothing that would
sum up to the end goal of writing firmware (read writing firmware for
_intel_ hardware).

 You'll also need to sign a couple
 of NDAs.
Just a couple? I heard it takes way over 6(six) months to get the
paperwork done.

Alex

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

Re: [coreboot] where can i ask detailed technical questions about hardware?

[Alex G.]

If you can redistribute those datasheets, I assume they are not under
NDA, which means they are the public datasheets available on Intel's site.

If they are public datasheets, you can simply reference the link and the
page number.
If they are not public, but you have the right to quote them, you may
quote the ambiguous sections (within context) on the mailing list.

Alex


On 04/06/2011 02:35 PM, ali hagigat wrote:
 Hello Peter,
 
 Thank you very much to respond. I have the necessary data sheets now
 but some lines of the documents are ambiguous and obscure. I do not
 want to take up your time much but I wonder if I can ask you these
 questions. I can send you the data sheets and specify the lines we are
 going to talk about.
 
 Regards
 PS. If anybody else can help me, please let me know and please specify
 if I contact you personally or by Coreboot mailing list.
 


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

Re: [coreboot] [RFC][PATCHv2]add WIP_ARM config entry

[Alex G.]

 P.S. Can I use git diff to generate the patch?
Why not? It isn't _that_ difficult to patch -p1 instead of -p0. :)
I've seen a few git diff patches flying around, and no one complained.

Alex

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

Re: [coreboot] [RFC][PATCHv2]add WIP_ARM config entry

[Alex G.]

On 04/06/2011 05:25 PM, Paul Menzel wrote:
 PPS: Is this a good time to move to Git altogether? A mirror already
 exists. ;-) Since I am not doing any development, I am not the one to
 make that call.

It's nice to have a git mirror, but contributors shouldn't be forced to
use git, especially since subversion has been used for aeons with
coreboot. Personally, I would be very unhappy to be forced to use git.
-1 to gitification



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

Re: [coreboot] [PATCH 2/2] BUILD: preprocess devicetree

[Alex G.]

On 03/27/2011 01:02 PM, Sven Schnelle wrote:
 pass devicetree.cb trough cpp before parse it with
 sconfig. This has the advantage that we can use Kconfig
 variables in devicetree.cb.
 
 Signed-off-by: Sven Schnelle sv...@stackframe.org
 ---

I like the idea.

If abuild doesn't complain, then
Acked-by: Alexandru Gagniuc mr.nuke...@gmail.com

Alex

P.S. Next time please send the patch as an attachment, not in the body
of the email. I'm certain a few devs right now are cursing at their mail
clients crashing ;).

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

Re: [coreboot] [PATCH 1/2] BUILD: add config.h dependency

[Alex G.]

On 03/27/2011 01:02 PM, Sven Schnelle wrote:
 Signed-off-by: Sven Schnelle sv...@stackframe.org
 ---
Acked-by: Alexandru Gagniuc mr.nuke...@gmail.com

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

[coreboot] Conflicting default options - option ROM exec and SeaBIOS

[Alex G.]

Right now, the default options in Kconfig are to pull SeaBIOS stable,
AND enable option ROM execution. This leaves people with a system that
has option ROMs executing twice.  As you might have imagined, this
results in undefined behavior. Some people are lucky and their systems
still run, while others,...

Default options should be changed to disable option ROM execution when
SeaBIOS is built in-tree.

Alex

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

Re: [coreboot] [PATCH 1/7] SuperMicro H8SCM support (AMD SR5650)

[Alex G.]

On 03/23/2011 08:56 AM, Bao, Zheng wrote:
 Add AMD SR56x0 support.
 
 Signed-off-by: Zheng Bao zheng@amd.com
 
 
Socket C32. Thank you!

Thanked-by: Alexandru Gagniuc mr.nuke...@gmail.com

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

Re: [coreboot] Support for Core i3 and better

[Alex G.]

On 03/11/2011 12:19 PM, Oleg Gvozdev wrote:
 Hello
 Could you, please, advise what motherboard I should use with coreboot to
 support Core i3, i5 or i7 CPU ?
Yes.

 And if any of these CPUs is not supported for now, where they will be
 supported?
In their momma's gusset.

 As an alternative: do you support Core 2 Duo and with what motheboard ?

A little word of advice. Coming and asking us about what hardware to buy
from a vendor that is more evil and uncooperative than Satan, is not
going to bring you happy respondents. We're getting tired of having to
tell people that Intel does not provide the documentation needed to
support their hardware.

So, suck it up, and look at AMD's offering instead.

Alex

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

Re: [coreboot] Support for Core i3 and better

[Alex G.]

On 03/11/2011 01:50 PM, Oleg Gvozdev wrote:
 I look now at Gygabyte GA-MA785GMT-UD2H and AM3 socket.
 
And this is the board I would have suggested. It's the only officially
suppported board with AM3 and DDR3.
http://www.coreboot.org/GIGABYTE_GA-MA785GMT-UD2H

The problem with this board is that it comes in several versions.
We've had people having difficulties getting other versions to run, but
most of the hard work is done. With a bit of patience at worst, you
should be able to get it running.

You could theoretically get any AM3 board and port it; this will be
extra work, however.

 1. Does Coreboot work with Phenom II  Thuban CPU ? I want 6-core CPU of
 Phenom2
 
It's supported.

 2. If it does not, what do you suggest from quadcores Phenom2 AM3 or
 AM+.. (i wrote your sentence about Satan,but i dont want to spend money
 on unworking system)
 
AM3 six-core is porbably the best bet for anyone wanting to run coreboot
on a modern system.

 I just need as much powerfull CPU as it can be to use with Coreboot.
 
Well, there is Socket G34, which is mostly the same silicon as the
Phenom II, and it comes in 8 or 12-core variants (and 1, 2 or 4 sockets
-- up to 48 cores total) _*_BUT_*_ this will need serious work to get
running.  Even with AMD's excellent cooperation, this is no easy task.
Such a job will turn you into a coreboot developer. ;)

Alex


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

Re: [coreboot] [PATCH] [3/4] [The 604 CAR crusades] Episode III - Revenge of the Abuild

[Alex G.]

On 03/12/2011 01:19 AM, Stefan Reinauer wrote:
 The S2735 is a dual Xeon server board. While I am pretty sure that this
 one worked nicely at some point, I don't think that this suggests that
 we should enable the same CAR code on all other socket 604 boards
 without testing.

Umh, the same CAR code is used for all supported Intel CPUs. I don't
know why you guys are so skeptical on this. It's code that's been proven
to work on numerous CPUs, including the socket that this patch is
referring to.

Alex

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

Re: [coreboot] [PATCH] [3/4] [The 604 CAR crusades] Episode III - Revenge of the Abuild

[Alex G.]

On 03/12/2011 03:02 AM, Stefan Reinauer wrote:
 * Alex G. mr.nuke...@gmail.com [110312 00:32]:
 Umh, the same CAR code is used for all supported Intel CPUs. 
 
 No, it's not. It just happens to live in a directory that seems to imply
 this. There are quire a number of Intel CPUs that don't work with that
 code (Intel Core/Core 2 and Atom being some of the ones that are
 supported by special code). In fact, I think the code in cpu/intel/car
 only supports a very small number of Intel CPUs.

You'sa point is well seen; however, your previous arguments about
thrashing these patches are not. As far as debating those arguments, I'm
just too tired to pointlessly try to get people to do something useful. :(

Alex


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

[coreboot] [The 604 CAR crusades][Master Yoda style] Preludium

[Alex G.]

Hi everyone,

The Tyan S2735 a Socket 604 (Intel) board it is which CAR it uses I
found. Why care I should? yourself you ask. Because eight boards which
socket 604 use, ROMCC they are.

dell/s1850
intel/jarrell
intel/xe7501devkit
supermicro/x6dai_g
supermicro/x6dhe_g
supermicro/x6dhe_g2
supermicro/x6dhr_ig
supermicro/x6dhr_ig2

This a bug to be considered is. Any 604 board as CAR work it should this
means. Move them all to CAR we should.

Alex


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

[coreboot] [PATCH] [1/4] [The 604 CAR crusades] Episode I - The Superio Menace

[Alex G.]

See patch.
Enable the NSC PC87427 early_init to be used with CAR boards.

The regular coompiler will complain about unused variables or
unused functions. Remove unused variables, and only include unused
functions if __ROMCC__ is defined.

Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com

Index: src/superio/nsc/pc87427/early_init.c
===
--- src/superio/nsc/pc87427/early_init.c	(revision 6429)
+++ src/superio/nsc/pc87427/early_init.c	(working copy)
@@ -22,12 +22,13 @@
 #include arch/romcc_io.h
 #include pc87427.h
 
+#ifdef __ROMCC__
 static void pc87427_disable_dev(device_t dev)
 {
 	pnp_set_logical_device(dev);
 	pnp_set_enable(dev, 0);
 }
-
+#endif
 static void pc87427_enable_dev(device_t dev, u16 iobase)
 {
 	pnp_set_logical_device(dev);
@@ -36,9 +37,10 @@
 	pnp_set_enable(dev, 1);
 }
 
+#ifdef __ROMCC__
 static void xbus_cfg(device_t dev)
 {
-	u8 i, data;
+	u8 i;
 	u16 xbus_index;
 
 	pnp_set_logical_device(dev);
@@ -52,3 +54,4 @@
 	for (i = 0; i = 0xf; i++)
 		outb((i  4), xbus_index + PC87427_HAP0);
 }
+#endif

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

[coreboot] [PATCH] [3/4] [The 604 CAR crusades] Episode III - Revenge of the Abuild

[Alex G.]

While the previous two patches were innocently trivial and abuild
tested, this one _will_ break the build for several Socket 604 boards.
We want the build to be broken until we can port those to CAR.

See patch for verbosity.
The Tyan s2735 is a Socket 604 board that uses CAR.
cache_as_ram.inc is included specifically for this board in
src/arch/x86/Makefile.inc .

This patch makes the option generic to all Socket 604 boards.

Expect the build for the following boards to be broken by this patch:

 dell/s1850
 intel/jarrell
 intel/xe7501devkit
 supermicro/x6dai_g
 supermicro/x6dhe_g
 supermicro/x6dhe_g2
 supermicro/x6dhr_ig
 supermicro/x6dhr_ig2

These boards need to be individually ported to CAR. The job is as
simple as removing select ROMCC from each board's Kconfig and
fixing the build errors that appear.

Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com


Index: src/mainboard/tyan/s2735/Kconfig
===
--- src/mainboard/tyan/s2735/Kconfig	(revision 6429)
+++ src/mainboard/tyan/s2735/Kconfig	(working copy)
@@ -13,7 +13,6 @@
 	select HAVE_MP_TABLE
 	select UDELAY_TSC
 	select HAVE_OPTION_TABLE
-	select CACHE_AS_RAM
 	select USE_WATCHDOG_ON_BOOT
 	select BOARD_ROMSIZE_KB_512
 
Index: src/cpu/intel/socket_mPGA604/Kconfig
===
--- src/cpu/intel/socket_mPGA604/Kconfig	(revision 6429)
+++ src/cpu/intel/socket_mPGA604/Kconfig	(working copy)
@@ -1,3 +1,23 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2011 Alexandru Gagniuc mr.nuke...@gmail.com
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
 config CPU_INTEL_SOCKET_MPGA604
 	bool
 	select CPU_INTEL_MODEL_F2X
@@ -6,6 +26,7 @@
 	select MMX
 	select SSE
 	select UDELAY_TSC
+	select CACHE_AS_RAM
 
 # mPGA604 are usually Intel Netburst CPUs which should have SSE2
 # but the ramtest.c code on the Dell S1850 seems to choke on
@@ -14,3 +35,8 @@
 	bool
 	default n
 	depends on CPU_INTEL_SOCKET_MPGA604
+
+# We need to specify this in order for cache_as_ram.inc to assemble
+config DCACHE_RAM_SIZE
+	hex
+	default 0x1000
Index: src/cpu/intel/socket_mPGA604/Makefile.inc
===
--- src/cpu/intel/socket_mPGA604/Makefile.inc	(revision 6429)
+++ src/cpu/intel/socket_mPGA604/Makefile.inc	(working copy)
@@ -1,3 +1,23 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2011 Alexandru Gagniuc mr.nuke...@gmail.com
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
 ramstage-y += socket_mPGA604.c
 subdirs-y += ../model_f2x
 subdirs-y += ../model_f3x
@@ -10,3 +30,5 @@
 subdirs-y += ../microcode
 subdirs-y += ../hyperthreading
 
+# This is a CAR capable socket god damn it!!!
+cpu_incs += $(src)/cpu/intel/car/cache_as_ram.inc
Index: src/arch/x86/Makefile.inc
===
--- src/arch/x86/Makefile.inc	(revision 6429)
+++ src/arch/x86/Makefile.inc	(working copy)
@@ -186,13 +186,6 @@
 
 crt0s += $(cpu_incs)
 
-#
-# FIXME move to CPU_INTEL_SOCKET_MPGA604
-#
-ifeq ($(CONFIG_BOARD_TYAN_S2735),y)
-crt0s += $(src)/cpu/intel/car/cache_as_ram.inc
-endif
-
 ifeq ($(CONFIG_LLSHELL),y)
 crt0s += $(src)/arch/x86/llshell/llshell.inc
 endif
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH][2/4][The 604 CAR crusades] Episode II - The Northbridge Wars

[Alex G.]

See patch.
We need to do two things to allow the intel e7520 to be used by CAR
boards.

Remove unused variables.
Add a declaration for sdram_initialize().

Signed-off-by: Alexandru Gagniuc mr.nuke...@gmail.com

Index: src/northbridge/intel/e7520/raminit.c
===
--- src/northbridge/intel/e7520/raminit.c	(revision 6429)
+++ src/northbridge/intel/e7520/raminit.c	(working copy)
@@ -653,7 +653,7 @@
 
 	goto out;
 
- val_err:
+ /* val_err: */
 	die(Bad SPD value\n);
 	/* If an hw_error occurs report that I have no memory */
 hw_err:
@@ -804,7 +804,6 @@
 	unsigned int dimm;
 	unsigned int edge;
 	int32_t data32;
-	uint32_t data32_dram;
 	uint32_t dcal_data32_0;
 	uint32_t dcal_data32_1;
 	uint32_t dcal_data32_2;
@@ -1036,10 +1035,6 @@
 	uint32_t data32;
 	uint32_t mode_reg;
 	uint32_t *iptr;
-	volatile unsigned long *iptrv;
-	msr_t msr;
-	uint32_t scratch;
-	uint8_t byte;
 	uint16_t data16;
 	static const struct {
 		uint32_t clkgr[4];
@@ -1091,8 +1086,8 @@
 	data32 = data32 | (1  5);  /* temp turn off of ODT */
   	/* Set gearing, then dram controller mode */
   	/* drc bits 1:0 = DIMM speed, bits 3:2 = FSB speed */
-  	for(iptr = gearing[(drc3)+drc2)3)-1)*3)].clkgr,cnt=0;
-			cnt4;cnt++) {
+	iptr = (uint32_t*)gearing[(drc3)+drc2)3)-1)*3)].clkgr;
+  	for(cnt=0; cnt4; cnt++) {
   		pci_write_config32(PCI_DEV(0, 0x00, 0), 0xa0+(cnt*4), iptr[cnt]);
 	}
 	/* 0x7c DRC */
Index: src/northbridge/intel/e7520/raminit.h
===
--- src/northbridge/intel/e7520/raminit.h	(revision 6429)
+++ src/northbridge/intel/e7520/raminit.h	(working copy)
@@ -9,4 +9,12 @@
 	u16 channel1[DIMM_SOCKETS];
 };
 
+#ifndef __ROMCC__
+#if defined(__PRE_RAM__)  CONFIG_RAMINIT_SYSINFO
+void sdram_initialize(int controllers, const struct mem_controller *ctrl, void *sysinfo);
+#else
+void sdram_initialize(int controllers, const struct mem_controller *ctrl);
+#endif
+#endif /* ROMCC */
+
 #endif /* RAMINIT_H */
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH] [4/4] [The 604 CAR crusades] Episode IV - A new board

[Alex G.]

See patch.
Fixes the build errors that occur when compiling the Supermicro
X6DHE-G2 as a CAR board.

Unused variables are removed, and unused functions are excluded
with #if/#endif

Signed-off-by: Alexandru Gagniuc mr/nuke...@gmail.com

Index: src/mainboard/supermicro/x6dhe_g2/Kconfig
===
--- src/mainboard/supermicro/x6dhe_g2/Kconfig	(revision 6429)
+++ src/mainboard/supermicro/x6dhe_g2/Kconfig	(working copy)
@@ -8,7 +8,6 @@
 	select SOUTHBRIDGE_INTEL_I82801EX
 	select SOUTHBRIDGE_INTEL_PXHD
 	select SUPERIO_NSC_PC87427
-	select ROMCC
 	select HAVE_HARD_RESET
 	select BOARD_HAS_HARD_RESET
 	select HAVE_OPTION_TABLE
Index: src/mainboard/supermicro/x6dhe_g2/watchdog.c
===
--- src/mainboard/supermicro/x6dhe_g2/watchdog.c	(revision 6429)
+++ src/mainboard/supermicro/x6dhe_g2/watchdog.c	(working copy)
@@ -5,6 +5,7 @@
 #define ESB6300_WDBASE 0x400
 #define ESB6300_GPIOBASE 0x500
 
+#ifdef DEFINED_BUT_NOT_USED
 static void disable_sio_watchdog(device_t dev)
 {
 #if 0
@@ -17,7 +18,7 @@
 	pnp_set_enable(dev, 0);
 #endif
 }
-
+#endif
 static void disable_esb6300_watchdog(void)
 {
 	/* FIXME move me somewhere more appropriate */
@@ -46,7 +47,7 @@
 	outw(0x0008, base + 0x04);
 	outw(0x0002, base + 0x06);
 }
-
+#ifdef DEFINED_BUT_NOT_USED
 static void disable_jarell_frb3(void)
 {
 #if 0
@@ -88,7 +89,7 @@
 	outl(value, base + 0x38);
 #endif
 }
-
+#endif
 static void disable_watchdogs(void)
 {
 //	disable_sio_watchdog(NSC_WD_DEV);
Index: src/mainboard/supermicro/x6dhe_g2/romstage.c
===
--- src/mainboard/supermicro/x6dhe_g2/romstage.c	(revision 6429)
+++ src/mainboard/supermicro/x6dhe_g2/romstage.c	(working copy)
@@ -9,14 +9,12 @@
 #include southbridge/intel/i82801ex/early_smbus.c
 #include northbridge/intel/e7520/raminit.h
 #include superio/nsc/pc87427/pc87427.h
-#include cpu/x86/lapic/boot_cpu.c
 #include cpu/x86/mtrr/earlymtrr.c
 #include debug.c
 #include watchdog.c
 #include reset.c
 #include superio/nsc/pc87427/early_init.c
 #include northbridge/intel/e7520/memory_initialized.c
-#include cpu/x86/bist.h
 #include spd.h
 
 #define CONSOLE_SERIAL_DEV PNP_DEV(0x2e, PC87427_SP1)
@@ -31,9 +29,7 @@
 	0 )
 #define DEVPRES1_CONFIG (DEVPRES1_D0F1 | DEVPRES1_D8F0)
 
-static void mch_reset(void) {}
 static void mainboard_set_e7520_pll(unsigned bits) {}
-static void mainboard_set_e7520_leds(void) {}
 
 static inline int spd_read_byte(unsigned device, unsigned address)
 {
@@ -42,9 +38,8 @@
 
 #include northbridge/intel/e7520/raminit.c
 #include lib/generic_sdram.c
-#include arch/x86/lib/stages.c
 
-static void main(unsigned long bist)
+void main(unsigned long bist)
 {
 	static const struct mem_controller mch[] = {
 		{
@@ -56,9 +51,9 @@
 
 	if (bist == 0) {
 		/* Skip this if there was a built in self test failure */
-		early_mtrr_init();
+		/* MTRR init is handled as part of cache_as_ram.inc */
 		if (memory_initialized())
-			skip_romstage();
+			return;
 	}
 
 	/* Setup the console */
@@ -98,11 +93,4 @@
 //	dump_ipmi_registers();
 //	mainboard_set_e7520_leds();
 	sdram_initialize(ARRAY_SIZE(mch), mch);
-#if 0
-	dump_pci_devices();
-#endif
-#if 1
-	dump_pci_device(PCI_DEV(0, 0x00, 0));
-	//dump_bar14(PCI_DEV(0, 0x00, 0));
-#endif
 }
Index: src/mainboard/supermicro/x6dhe_g2/debug.c
===
--- src/mainboard/supermicro/x6dhe_g2/debug.c	(revision 6429)
+++ src/mainboard/supermicro/x6dhe_g2/debug.c	(working copy)
@@ -1,5 +1,5 @@
 #include spd.h
-
+#ifdef DEFINED_BUT_NOT_USED
 static void print_reg(unsigned char index)
 {
 unsigned char data;
@@ -137,27 +137,7 @@
 	}
 }
 
-static void dump_pci_device(unsigned dev)
-{
-	int i;
-	print_debug_pci_dev(dev);
-	print_debug(\n);
 
-	for(i = 0; i = 255; i++) {
-		unsigned char val;
-		if ((i  0x0f) == 0) {
-			print_debug_hex8(i);
-			print_debug_char(':');
-		}
-		val = pci_read_config8(dev, i);
-		print_debug_char(' ');
-		print_debug_hex8(val);
-		if ((i  0x0f) == 0x0f) {
-			print_debug(\n);
-		}
-	}
-}
-
 static void dump_bar14(unsigned dev)
 {
 	int i;
@@ -202,7 +182,7 @@
 		dump_pci_device(dev);
 	}
 }
-
+#endif
 #if 0
 static void dump_spd_registers(const struct mem_controller *ctrl)
 {
@@ -264,7 +244,6 @@
 		}
 	}
 }
-#endif
 
 void dump_spd_registers(void)
 {
@@ -278,7 +257,6 @@
 		print_debug_hex8(device);
 
 for(i = 0; (i  256) ; i++) {
-	unsigned char byte;
 if ((i % 16) == 0) {
 print_debug(\n);
 print_debug_hex8(i);
@@ -311,7 +289,6 @@
 		print_debug_hex8(device);
 
 for(i = 0; (i  8) ; i++) {
-	unsigned char byte;
 			status = smbus_read_byte(device, 2);
 if (status  0) {
 			 print_debug(bad device: );
@@ -326,3 +303,4 @@
 		print_debug(\n);
 	}
 }
+#endif
\ No newline at end of file
--