From no-reply at raptorengineeringinc.com  Tue Dec  1 00:35:26 2015
From: no-reply at raptorengineeringinc.com (Raptor Engineering Automated Coreboot Test Stand)
Date: Mon, 30 Nov 2015 17:35:26 -0600
Subject: [coreboot] ASUS KFSN4-DRE (K8) Automated Test Failure
Message-ID: <20151130233525.GA24201@cb-test-ctl>

The ASUS KFSN4-DRE (K8) fails verification as of commit bd88fa0ef62339bfc3027423d230a6ffcd1419ae

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
bd88fa0 fsp_baytrail: Remove use of BAYTRAIL_SMM Kconfig symbol
4013469 build system: add dependencies for SeaBIOS output
3093038 nb/amd/amdmct/mct_ddr3: Use StopOnError to decrease training time
9586dc7 mainboard/intel: Add Little Plains
b4b298c mainboard/asus/kgpe-d16: Limit HT speed to 2.6GHz

<7 commits skipped>

551b383 build system: move defconfig creation into a cbfs-files filter
10420cc build system: break overly long lines into logical units
c35bd54 build system: Move manual cbfstool add* invocations to cbfs-files
1eee076 build system: don't try to add cbfs-files with no backing file
9b5b536 build system: establish priority levels for CBFS file additions

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE (K8) test stand
Want to test on your own equipment?  Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit https://www.raptorengineeringinc.com for more information

Please contact Timothy Pearson at Raptor Engineering <tpearson at raptorengineeringinc.com> regarding any issues stemming from this notification
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1448926493-2-automaster.log.bz2
Type: application/octet-stream
Size: 14461 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151130/b12cabe6/attachment.obj>

From no-reply at raptorengineeringinc.com  Tue Dec  1 00:36:43 2015
From: no-reply at raptorengineeringinc.com (Raptor Engineering Automated Coreboot Test Stand)
Date: Mon, 30 Nov 2015 17:36:43 -0600
Subject: [coreboot] ASUS KFSN4-DRE Automated Test Failure
Message-ID: <20151130233643.GA25303@cb-test-ctl>

The ASUS KFSN4-DRE fails verification as of commit bd88fa0ef62339bfc3027423d230a6ffcd1419ae

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
bd88fa0 fsp_baytrail: Remove use of BAYTRAIL_SMM Kconfig symbol
4013469 build system: add dependencies for SeaBIOS output
3093038 nb/amd/amdmct/mct_ddr3: Use StopOnError to decrease training time
9586dc7 mainboard/intel: Add Little Plains
b4b298c mainboard/asus/kgpe-d16: Limit HT speed to 2.6GHz

<7 commits skipped>

551b383 build system: move defconfig creation into a cbfs-files filter
10420cc build system: break overly long lines into logical units
c35bd54 build system: Move manual cbfstool add* invocations to cbfs-files
1eee076 build system: don't try to add cbfs-files with no backing file
9b5b536 build system: establish priority levels for CBFS file additions

See attached log for details

This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand
Want to test on your own equipment?  Check out https://www.raptorengineeringinc.com/content/REACTS/intro.html

Raptor Engineering also offers coreboot consulting services!  Please visit https://www.raptorengineeringinc.com for more information

Please contact Timothy Pearson at Raptor Engineering <tpearson at raptorengineeringinc.com> regarding any issues stemming from this notification
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1448926572-0-automaster.log.bz2
Type: application/octet-stream
Size: 24105 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151130/8e9d3ba0/attachment-0001.obj>

From lynxis at fe80.eu  Sun Dec  6 17:18:30 2015
From: lynxis at fe80.eu (Alexander Couzens)
Date: Sun, 6 Dec 2015 17:18:30 +0100
Subject: [coreboot] baytrail + fsp_baytrail
Message-ID: <20151206171830.0513b507@lazus.yip>

hi,

baytrail and fsp_baytrail shares a lot of code.
Any ideas how we can merge these?

best,
lynxis

-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151206/ff702512/attachment.sig>

From rminnich at gmail.com  Sun Dec  6 18:13:35 2015
From: rminnich at gmail.com (ron minnich)
Date: Sun, 06 Dec 2015 17:13:35 +0000
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <20151206171830.0513b507@lazus.yip>
References: <20151206171830.0513b507@lazus.yip>
Message-ID: <CAP6exY+p64v_GFzboMQQNK5Xpuie6rgagf0rbwiLAu89PdZkPA@mail.gmail.com>

as long as it does not turn into #ifdef spaghetti it's worth a look.

ron

On Sun, Dec 6, 2015 at 8:19 AM Alexander Couzens <lynxis at fe80.eu> wrote:

> hi,
>
> baytrail and fsp_baytrail shares a lot of code.
> Any ideas how we can merge these?
>
> best,
> lynxis
>
> --
> Alexander Couzens
>
> mail: lynxis at fe80.eu
> jabber: lynxis at fe80.eu
> mobile: +4915123277221
> gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151206/07f581e4/attachment.html>

From mr.nuke.me at gmail.com  Mon Dec  7 07:54:40 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Sun, 6 Dec 2015 22:54:40 -0800
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <20151206171830.0513b507@lazus.yip>
References: <20151206171830.0513b507@lazus.yip>
Message-ID: <56652D30.3000303@gmail.com>

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


From gaumless at gmail.com  Mon Dec  7 16:55:43 2015
From: gaumless at gmail.com (Martin Roth)
Date: Mon, 7 Dec 2015 08:55:43 -0700
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <56652D30.3000303@gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
Message-ID: <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>

I think we can cut down on some of the code redundancy, but as Alex
says, they are different chipsets, and we need to be careful about
trying to combine too much.

Here are my suggested steps:
1) Look for commonalities between baytrail and other chipsets and move
pieces things into soc/intel/common or southbridge/intel/common.
Let's not do a bunch of work just for baytrail that could help all the
intel chipsets.  I think this should be done regardless of anything
that we decide about Bay Trail.

2) Figure out which changes in each directory should go to the other.
Each have gotten some fixes that should be shared with the other
directory.

3) Make the baytrail directory structures look as similar again -
rename the soc/fsp_baytrail/baytrail include directory to
soc/fsp_baytrail/soc/include to match what was done with soc/baytrail.
Or we can rename them both to just soc/(fsp_)baytrail/include.
Something, so long as they match.

4) Create a soc/intel/baytrail_common or soc/intel/baytrail/common
directory and move pieces that are the same for both chipsets into
those directories.  Work on consolidation, and getting as much as is
reasonable into that directory.  I'd prefer not to just leave files in
soc/intel/baytrail because then it's not obvious that the files are
shared between the two platforms.


Similar steps could be done for the other fsp/non-fsp directories:
cpu/(fsp_)model_206ax, northbridge/(fsp_)sandybridge, and
southbridge/intel/(fsp_)bd82x6x.

Ben, Michael, Since you seem to be actively working in this code, how
do you feel about this?

Martin

On Sun, Dec 6, 2015 at 11:54 PM, Alex G. <mr.nuke.me at gmail.com> wrote:
> 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 at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From gardner.ben at gmail.com  Tue Dec  8 01:08:00 2015
From: gardner.ben at gmail.com (Ben Gardner)
Date: Mon, 7 Dec 2015 18:08:00 -0600
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
Message-ID: <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>

On Mon, Dec 7, 2015 at 9:55 AM, Martin Roth <gaumless at gmail.com> wrote:
> I think we can cut down on some of the code redundancy, but as Alex
> says, they are different chipsets, and we need to be careful about
> trying to combine too much.
>
> Here are my suggested steps:
> 1) Look for commonalities between baytrail and other chipsets and move
> pieces things into soc/intel/common or southbridge/intel/common.
> Let's not do a bunch of work just for baytrail that could help all the
> intel chipsets.  I think this should be done regardless of anything
> that we decide about Bay Trail.
>
> 2) Figure out which changes in each directory should go to the other.
> Each have gotten some fixes that should be shared with the other
> directory.
>
> 3) Make the baytrail directory structures look as similar again -
> rename the soc/fsp_baytrail/baytrail include directory to
> soc/fsp_baytrail/soc/include to match what was done with soc/baytrail.
> Or we can rename them both to just soc/(fsp_)baytrail/include.
> Something, so long as they match.
>
> 4) Create a soc/intel/baytrail_common or soc/intel/baytrail/common
> directory and move pieces that are the same for both chipsets into
> those directories.  Work on consolidation, and getting as much as is
> reasonable into that directory.  I'd prefer not to just leave files in
> soc/intel/baytrail because then it's not obvious that the files are
> shared between the two platforms.
>
>
> Similar steps could be done for the other fsp/non-fsp directories:
> cpu/(fsp_)model_206ax, northbridge/(fsp_)sandybridge, and
> southbridge/intel/(fsp_)bd82x6x.
>
> Ben, Michael, Since you seem to be actively working in this code, how
> do you feel about this?

I'm OK with reducing duplication and unnecessary differences.
There seems to be plenty of duplicate header files.
Without a similar tree structure and filenames, it is difficult to
compare the trees, so I'd sync that first.

I'd prefer seeing common baytrail stuff in soc/intel/baytrail_common/
vs under baytrail/common.

Ben

> Martin
>
> On Sun, Dec 6, 2015 at 11:54 PM, Alex G. <mr.nuke.me at gmail.com> wrote:
>> 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 at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot


From rminnich at gmail.com  Tue Dec  8 01:19:48 2015
From: rminnich at gmail.com (ron minnich)
Date: Tue, 08 Dec 2015 00:19:48 +0000
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
 <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
Message-ID: <CAP6exYKZg5i3PmuSu3OQphgTrSxogSPT=bNH1mwUzceH85k7kA@mail.gmail.com>

there's another way to do this that few people use.

Back in the E7500 days, the 7505 came along. We experimented with this:
src/northbridge/intel/e750x
and put the common files in there.
Under e750x we had
e7500
e7505

for the different files.
so, src/northbridge/intel/e750x/{e7500,e7505}
worked fine. nobody cared enough to really do the work of putting it all
together, we were just happy that
the build system supported the naming in the files and so on.
Part of the trick is this: in the mainboard file, the part becomes
src/northbridge/intel/e750x/e7500
and in e7500 you include parts from src/northbridge/intel/e750x

So you don't make e750x the northbridge directory; rather you make
e750x/e7505 and e750x/e7500 the directory.
That way, no condition includes or anything. It's a pretty standard build
setup.

this is similar to what we did on the ARM parts a few years back.

ron

On Mon, Dec 7, 2015 at 4:08 PM Ben Gardner <gardner.ben at gmail.com> wrote:

> On Mon, Dec 7, 2015 at 9:55 AM, Martin Roth <gaumless at gmail.com> wrote:
> > I think we can cut down on some of the code redundancy, but as Alex
> > says, they are different chipsets, and we need to be careful about
> > trying to combine too much.
> >
> > Here are my suggested steps:
> > 1) Look for commonalities between baytrail and other chipsets and move
> > pieces things into soc/intel/common or southbridge/intel/common.
> > Let's not do a bunch of work just for baytrail that could help all the
> > intel chipsets.  I think this should be done regardless of anything
> > that we decide about Bay Trail.
> >
> > 2) Figure out which changes in each directory should go to the other.
> > Each have gotten some fixes that should be shared with the other
> > directory.
> >
> > 3) Make the baytrail directory structures look as similar again -
> > rename the soc/fsp_baytrail/baytrail include directory to
> > soc/fsp_baytrail/soc/include to match what was done with soc/baytrail.
> > Or we can rename them both to just soc/(fsp_)baytrail/include.
> > Something, so long as they match.
> >
> > 4) Create a soc/intel/baytrail_common or soc/intel/baytrail/common
> > directory and move pieces that are the same for both chipsets into
> > those directories.  Work on consolidation, and getting as much as is
> > reasonable into that directory.  I'd prefer not to just leave files in
> > soc/intel/baytrail because then it's not obvious that the files are
> > shared between the two platforms.
> >
> >
> > Similar steps could be done for the other fsp/non-fsp directories:
> > cpu/(fsp_)model_206ax, northbridge/(fsp_)sandybridge, and
> > southbridge/intel/(fsp_)bd82x6x.
> >
> > Ben, Michael, Since you seem to be actively working in this code, how
> > do you feel about this?
>
> I'm OK with reducing duplication and unnecessary differences.
> There seems to be plenty of duplicate header files.
> Without a similar tree structure and filenames, it is difficult to
> compare the trees, so I'd sync that first.
>
> I'd prefer seeing common baytrail stuff in soc/intel/baytrail_common/
> vs under baytrail/common.
>
> Ben
>
> > Martin
> >
> > On Sun, Dec 6, 2015 at 11:54 PM, Alex G. <mr.nuke.me at gmail.com> wrote:
> >> 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 at coreboot.org
> >> http://www.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151208/adf2a96a/attachment.html>

From mr.nuke.me at gmail.com  Tue Dec  8 03:34:57 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Mon, 7 Dec 2015 18:34:57 -0800
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
Message-ID: <566641D1.9050107@gmail.com>

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


From mr.nuke.me at gmail.com  Tue Dec  8 03:37:45 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Mon, 7 Dec 2015 18:37:45 -0800
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <566641D1.9050107@gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
 <566641D1.9050107@gmail.com>
Message-ID: <56664279.4010402@gmail.com>



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


From peter at stuge.se  Tue Dec  8 07:15:50 2015
From: peter at stuge.se (Peter Stuge)
Date: Tue, 8 Dec 2015 07:15:50 +0100
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <CAP6exYKZg5i3PmuSu3OQphgTrSxogSPT=bNH1mwUzceH85k7kA@mail.gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
 <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
 <CAP6exYKZg5i3PmuSu3OQphgTrSxogSPT=bNH1mwUzceH85k7kA@mail.gmail.com>
Message-ID: <20151208061550.10195.qmail@stuge.se>

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.


//Peter


From rminnich at gmail.com  Tue Dec  8 19:04:12 2015
From: rminnich at gmail.com (ron minnich)
Date: Tue, 08 Dec 2015 18:04:12 +0000
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <20151208061550.10195.qmail@stuge.se>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
 <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
 <CAP6exYKZg5i3PmuSu3OQphgTrSxogSPT=bNH1mwUzceH85k7kA@mail.gmail.com>
 <20151208061550.10195.qmail@stuge.se>
Message-ID: <CAP6exYK5nK4BLL1r_6eGiR2v8hJwQvHOedNMYNhJFnWSoLnP4Q@mail.gmail.com>

On Mon, Dec 7, 2015 at 10:16 PM Peter Stuge <peter at stuge.se> 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 :-)

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151208/5d2518c5/attachment.html>

From gardner.ben at gmail.com  Tue Dec  8 19:26:05 2015
From: gardner.ben at gmail.com (Ben Gardner)
Date: Tue, 8 Dec 2015 12:26:05 -0600
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
 <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
Message-ID: <CAE7DoPZkRTwLncZoCbxYeafB4mco7Rpxf4=2iC0dhXyqR2-98g@mail.gmail.com>

>> 3) Make the baytrail directory structures look as similar again -
>> rename the soc/fsp_baytrail/baytrail include directory to
>> soc/fsp_baytrail/soc/include to match what was done with soc/baytrail.
>> Or we can rename them both to just soc/(fsp_)baytrail/include.
>> Something, so long as they match.
>
> I'm OK with reducing duplication and unnecessary differences.
> There seems to be plenty of duplicate header files.
> Without a similar tree structure and filenames, it is difficult to
> compare the trees, so I'd sync that first.

I submitted a patch to rename the fsp_baytrail/baytrail folder to
fsp_baytrail/include/soc.
https://review.coreboot.org/12686

It touched a lot of code that I don't normally compile, so I'm waiting
on the build results to see what may have broke.

It is all automated with grep and sed (commands in the commit
message), except for the Makefile.inc change to add the folder to the
include path.
Please take a look.

Thanks,
Ben


From dcrammer at gmail.com  Wed Dec  9 17:18:42 2015
From: dcrammer at gmail.com (David Crammer)
Date: Wed, 9 Dec 2015 10:18:42 -0600
Subject: [coreboot] FSPInitiNot Returning
Message-ID: <CANvsogB-xOH9xkziT8qfMW97cqon84vNgyaj-6yiCn1-_XdQag@mail.gmail.com>

Hello All,

    I?m running into a rather strange error and I?m hoping someone has had
experience with this or may know about what I?m seeing.



I?m working with an Intel I5 5350U on an ADLINK platform.  I?m getting to
the part of the boot sequence where FspInit is called but it never returns
to the specified return function.  The system resets 3 times with a post
code (codes inserted before and in return function) indicating that it got
to the FspInit call and reset.  After the third time, it settles on a post
code of 0xBE.  I can?t find reference to the post code anywhere.



Any help would be greatly appreciated.  In case anyone is interested, I?ll
reply with any updates.


--David Crammer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151209/04bfed4d/attachment.html>

From huang.jin at intel.com  Wed Dec  9 18:19:51 2015
From: huang.jin at intel.com (Jin, Huang)
Date: Wed, 9 Dec 2015 17:19:51 +0000
Subject: [coreboot] FSPInitiNot Returning
In-Reply-To: <CANvsogB-xOH9xkziT8qfMW97cqon84vNgyaj-6yiCn1-_XdQag@mail.gmail.com>
References: <CANvsogB-xOH9xkziT8qfMW97cqon84vNgyaj-6yiCn1-_XdQag@mail.gmail.com>
Message-ID: <2B8B3D5FC0A331498DD76A40C375426D92DF6C8C@ORSMSX101.amr.corp.intel.com>

Hi David,

I am assuming you are using a Broadwell platform and Broadwell FSP. Could you please share some logs? I might be able to help you.

Thanks,
Huang

From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of David Crammer
Sent: Wednesday, December 09, 2015 8:19 AM
To: coreboot at coreboot.org
Subject: [coreboot] FSPInitiNot Returning

Hello All,
    I?m running into a rather strange error and I?m hoping someone has had experience with this or may know about what I?m seeing.

I?m working with an Intel I5 5350U on an ADLINK platform.  I?m getting to the part of the boot sequence where FspInit is called but it never returns to the specified return function.  The system resets 3 times with a post code (codes inserted before and in return function) indicating that it got to the FspInit call and reset.  After the third time, it settles on a post code of 0xBE.  I can?t find reference to the post code anywhere.

Any help would be greatly appreciated.  In case anyone is interested, I?ll reply with any updates.

--David Crammer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151209/2406c389/attachment.html>

From dcrammer at gmail.com  Wed Dec  9 20:05:21 2015
From: dcrammer at gmail.com (David Crammer)
Date: Wed, 9 Dec 2015 13:05:21 -0600
Subject: [coreboot] FSPInitiNot Returning
In-Reply-To: <2B8B3D5FC0A331498DD76A40C375426D92DF6C8C@ORSMSX101.amr.corp.intel.com>
References: <CANvsogB-xOH9xkziT8qfMW97cqon84vNgyaj-6yiCn1-_XdQag@mail.gmail.com>
 <2B8B3D5FC0A331498DD76A40C375426D92DF6C8C@ORSMSX101.amr.corp.intel.com>
Message-ID: <CANvsogBzFC4Gu-R51Uf+Mt7u23ijmyvohBBpKnUGfJMmeXVcQQ@mail.gmail.com>

Yes. This is a broadwell platform.  I removed the UPD settings and left
them default (passed NULL for that pointer in the parameters to FspInit).
It seems to get past that point now.  I did notice that the SMBus addresses
for the DIMMs were being set to different values than what is listed in the
binary configuration tool.  This and the PMBASE settings were really the
only things changed in the coreboot source.  Maybe this is the cause?

I don't really have any logs as I'm only debugging with port 0x80 values.

On Wed, Dec 9, 2015 at 11:19 AM, Jin, Huang <huang.jin at intel.com> wrote:

> Hi David,
>
>
>
> I am assuming you are using a Broadwell platform and Broadwell FSP. Could
> you please share some logs? I might be able to help you.
>
>
>
> Thanks,
>
> Huang
>
>
>
> *From:* coreboot [mailto:coreboot-bounces at coreboot.org] *On Behalf Of *David
> Crammer
> *Sent:* Wednesday, December 09, 2015 8:19 AM
> *To:* coreboot at coreboot.org
> *Subject:* [coreboot] FSPInitiNot Returning
>
>
>
> Hello All,
>
>     I?m running into a rather strange error and I?m hoping someone has had
> experience with this or may know about what I?m seeing.
>
>
>
> I?m working with an Intel I5 5350U on an ADLINK platform.  I?m getting to
> the part of the boot sequence where FspInit is called but it never returns
> to the specified return function.  The system resets 3 times with a post
> code (codes inserted before and in return function) indicating that it got
> to the FspInit call and reset.  After the third time, it settles on a post
> code of 0xBE.  I can?t find reference to the post code anywhere.
>
>
>
> Any help would be greatly appreciated.  In case anyone is interested, I?ll
> reply with any updates.
>
>
>
> --David Crammer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151209/eab151e3/attachment.html>

From huang.jin at intel.com  Wed Dec  9 21:00:53 2015
From: huang.jin at intel.com (Jin, Huang)
Date: Wed, 9 Dec 2015 20:00:53 +0000
Subject: [coreboot] FSPInitiNot Returning
In-Reply-To: <CANvsogBzFC4Gu-R51Uf+Mt7u23ijmyvohBBpKnUGfJMmeXVcQQ@mail.gmail.com>
References: <CANvsogB-xOH9xkziT8qfMW97cqon84vNgyaj-6yiCn1-_XdQag@mail.gmail.com>
 <2B8B3D5FC0A331498DD76A40C375426D92DF6C8C@ORSMSX101.amr.corp.intel.com>
 <CANvsogBzFC4Gu-R51Uf+Mt7u23ijmyvohBBpKnUGfJMmeXVcQQ@mail.gmail.com>
Message-ID: <2B8B3D5FC0A331498DD76A40C375426D92DF6DD0@ORSMSX101.amr.corp.intel.com>

Hi David,

May I know which FSP version are you using? If it is not difficult, enabling early serial output in coreboot before calling FSP will be helpful for trouble shooting your problem, and your development in the long run.

Thanks,
Huang

From: David Crammer [mailto:dcrammer at gmail.com]
Sent: Wednesday, December 09, 2015 11:05 AM
To: Jin, Huang
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] FSPInitiNot Returning

Yes. This is a broadwell platform.  I removed the UPD settings and left them default (passed NULL for that pointer in the parameters to FspInit).  It seems to get past that point now.  I did notice that the SMBus addresses for the DIMMs were being set to different values than what is listed in the binary configuration tool.  This and the PMBASE settings were really the only things changed in the coreboot source.  Maybe this is the cause?
I don't really have any logs as I'm only debugging with port 0x80 values.

On Wed, Dec 9, 2015 at 11:19 AM, Jin, Huang <huang.jin at intel.com<mailto:huang.jin at intel.com>> wrote:
Hi David,

I am assuming you are using a Broadwell platform and Broadwell FSP. Could you please share some logs? I might be able to help you.

Thanks,
Huang

From: coreboot [mailto:coreboot-bounces at coreboot.org<mailto:coreboot-bounces at coreboot.org>] On Behalf Of David Crammer
Sent: Wednesday, December 09, 2015 8:19 AM
To: coreboot at coreboot.org<mailto:coreboot at coreboot.org>
Subject: [coreboot] FSPInitiNot Returning

Hello All,
    I?m running into a rather strange error and I?m hoping someone has had experience with this or may know about what I?m seeing.

I?m working with an Intel I5 5350U on an ADLINK platform.  I?m getting to the part of the boot sequence where FspInit is called but it never returns to the specified return function.  The system resets 3 times with a post code (codes inserted before and in return function) indicating that it got to the FspInit call and reset.  After the third time, it settles on a post code of 0xBE.  I can?t find reference to the post code anywhere.

Any help would be greatly appreciated.  In case anyone is interested, I?ll reply with any updates.

--David Crammer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151209/5aade2a4/attachment-0001.html>

From D.Crammer at astronautics.com  Wed Dec  9 21:59:08 2015
From: D.Crammer at astronautics.com (David Crammer)
Date: Wed, 9 Dec 2015 14:59:08 -0600
Subject: [coreboot] FSPInitiNot Returning
In-Reply-To: <2B8B3D5FC0A331498DD76A40C375426D92DF6DD0@ORSMSX101.amr.corp.intel.com>
References: <CANvsogB-xOH9xkziT8qfMW97cqon84vNgyaj-6yiCn1-_XdQag@mail.gmail.com>
 <2B8B3D5FC0A331498DD76A40C375426D92DF6C8C@ORSMSX101.amr.corp.intel.com>
 <CANvsogBzFC4Gu-R51Uf+Mt7u23ijmyvohBBpKnUGfJMmeXVcQQ@mail.gmail.com>
 <2B8B3D5FC0A331498DD76A40C375426D92DF6DD0@ORSMSX101.amr.corp.intel.com>
Message-ID: <956DEAE1C79ED14EB3351A2FE39AEF22849CE5898D@HQSTORE.aca.astronautics.com>

This is FSP 1.1.  I?ll work on getting serial output.  It shouldn?t be difficult assuming this dev board has it routed.  I agree that it will make debug easier.

--David Crammer

From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Jin, Huang
Sent: Wednesday, December 09, 2015 2:01 PM
To: David Crammer
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] FSPInitiNot Returning

Hi David,

May I know which FSP version are you using? If it is not difficult, enabling early serial output in coreboot before calling FSP will be helpful for trouble shooting your problem, and your development in the long run.

Thanks,
Huang

From: David Crammer [mailto:dcrammer at gmail.com]
Sent: Wednesday, December 09, 2015 11:05 AM
To: Jin, Huang
Cc: coreboot at coreboot.org<mailto:coreboot at coreboot.org>
Subject: Re: [coreboot] FSPInitiNot Returning

Yes. This is a broadwell platform.  I removed the UPD settings and left them default (passed NULL for that pointer in the parameters to FspInit).  It seems to get past that point now.  I did notice that the SMBus addresses for the DIMMs were being set to different values than what is listed in the binary configuration tool.  This and the PMBASE settings were really the only things changed in the coreboot source.  Maybe this is the cause?
I don't really have any logs as I'm only debugging with port 0x80 values.

On Wed, Dec 9, 2015 at 11:19 AM, Jin, Huang <huang.jin at intel.com<mailto:huang.jin at intel.com>> wrote:
Hi David,

I am assuming you are using a Broadwell platform and Broadwell FSP. Could you please share some logs? I might be able to help you.

Thanks,
Huang

From: coreboot [mailto:coreboot-bounces at coreboot.org<mailto:coreboot-bounces at coreboot.org>] On Behalf Of David Crammer
Sent: Wednesday, December 09, 2015 8:19 AM
To: coreboot at coreboot.org<mailto:coreboot at coreboot.org>
Subject: [coreboot] FSPInitiNot Returning

Hello All,
    I?m running into a rather strange error and I?m hoping someone has had experience with this or may know about what I?m seeing.

I?m working with an Intel I5 5350U on an ADLINK platform.  I?m getting to the part of the boot sequence where FspInit is called but it never returns to the specified return function.  The system resets 3 times with a post code (codes inserted before and in return function) indicating that it got to the FspInit call and reset.  After the third time, it settles on a post code of 0xBE.  I can?t find reference to the post code anywhere.

Any help would be greatly appreciated.  In case anyone is interested, I?ll reply with any updates.

--David Crammer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151209/8de60b12/attachment.html>

From gappy1502 at gmx.net  Sun Dec 13 12:25:42 2015
From: gappy1502 at gmx.net (Gerhard Gappmeier)
Date: Sun, 13 Dec 2015 12:25:42 +0100
Subject: [coreboot] Lenovo Carbon X1
Message-ID: <1844557.1EWA0ai5iR@tux>

Hi,

I want to start a port on the Lenovo Carbon X1. I'm a BIOS newbie and don't 
know much about chipsets, so I'll need your support here.
But I've enough C programming experience to get the job done with your 
help (I hope).

At the moment I'm collecting information about the hardware:

The mainboard has two flash chips:
EN25QH64: 8MB Flash
MX25L3206E: 4MB Flash

I know already from IRC that "Intel Corporation 3rd Gen Core processor" 
means Ivy bridge. That's all for now.

Hopefully somebody can help me with identifying all necessary chipset info 
from the lspci and dmidecode output below.

Then I've a lot of questions:

1.) What is the minimum configuration to get started and a linux kernel 
booted?
northbridge, southbridge, RAM init? what else?
Because the kernel can be a payload in the flash even SATA controller is 
not necessary, right?
Advanced stuff as network boot is not necessary.

2.) From my basic understanding I believe as soon as the kernel gets 
executed everything else gets initialized by the kernel and the BIOS is not 
needed anymore. Is that right?

3.) For diagnostics I think VGA output is necessary.
This board has no UART, only USB, and this would require initializing USB 
controller and communicating using a usb/serial converter.
What do you think is the easier way for debug output?

I've already read this article here: http://www.coreboot.org/VGA_support[1] 
And it seems like extracting the VGA ROM via the kernel works here:

lspci -tv:
-[0000:00]-+-00.0  Intel Corporation 3rd Gen Core processor DRAM 
Controller
           +-02.0  Intel Corporation 3rd Gen Core processor Graphics 
...

ls -l /sys/devices/pci0000:00/0000:00:02.0/rom
-rw------- 1 root root 131072 Dec 13 12:16 
/sys/devices/pci0000:00/0000:00:02.0/rom

echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
cp /sys/devices/pci0000:00/0000:00:02.0/rom vgabios.bin
hexdump -C vgabios.bin > vgabios.bin.hex

Here are the 1st 10 lines of the vgabios hexdump:
00000000  55 aa 80 e9 78 ea 30 30  30 30 30 30 30 30 30 30  |
U...x.0000000000|
00000010  30 30 40 25 e9 59 24 97  40 00 b0 0a 30 30 49 42  |
00@%.Y$. at ...00IB|
00000020  4d 20 56 47 41 20 43 6f  6d 70 61 74 69 62 6c 65  |M VGA 
Compatible|
00000030  20 42 49 4f 53 2e 20 03  6e 00 7e 00 8c 00 8b c0  | BIOS. 
.n.~.....|
00000040  50 43 49 52 86 80 06 01  1c 00 1c 00 03 00 00 03  |
PCIR............|
00000050  80 00 00 00 00 80 80 00  00 00 00 00 06 01 16 01  |................|
00000060  26 01 56 01 66 01 76 01  86 01 00 00 6e 03 00 c0  |
&.V.f.v.....n...|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 88 00 00 c0  |................|
00000080  00 00 00 00 00 00 00 00  1a 00 37 03 00 c0 00 00  
|..........7.....|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

looks promising ;-)

More info about the HW comes here:

lspci output:
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM 
Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core 
processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series 
Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset 
Family KT Controller (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family 
High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family 
PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family 
PCI Express Root Port 2 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QS77 Express Chipset LPC Controller 
(rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port 
SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus 
Controller (rev 04)
02:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller 
(rev 07)
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 
[Taylor Peak] (rev 96)

lsusb output:
Bus 002 Device 003: ID 0bdb:1926 Ericsson Business Mobile Networks BV 
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching 
Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 04f2:b315 Chicony Electronics Co., Ltd 
Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 
4.0 [ThinkPad]
Bus 001 Device 003: ID 147e:2020 Upek TouchChip Fingerprint 
Coprocessor (WBF advanced mode)
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching 
Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

dmidecode output:
# dmidecode 2.12
SMBIOS 2.7 present.
71 structures occupying 2762 bytes.
Table at 0xDAE9D000.

Handle 0x0000, DMI type 134, 16 bytes
OEM-specific Type
	Header and Data:
		86 10 00 00 00 53 54 4D 20 01 01 00 00 03 01 
02
	Strings:
		TPM INFO
		System Reserved

Handle 0x0001, DMI type 4, 42 bytes
Processor Information
	Socket Designation: CPU Socket - U3E1
	Type: Central Processor
	Family: Core i7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151213/20e21738/attachment-0001.html>

From gappy1502 at gmx.net  Sun Dec 13 13:06:54 2015
From: gappy1502 at gmx.net (Gerhard Gappmeier)
Date: Sun, 13 Dec 2015 13:06:54 +0100
Subject: [coreboot] Lenovo Carbon X1
In-Reply-To: <CALWv5jQRTv0NW5cnf63OaXS-8XY3S92HhjJuueUzgLXg10e9_g@mail.gmail.com>
References: <1844557.1EWA0ai5iR@tux>
 <CALWv5jQRTv0NW5cnf63OaXS-8XY3S92HhjJuueUzgLXg10e9_g@mail.gmail.com>
Message-ID: <4466326.Tun3lSuFtg@tux>

Thx, I thought you're kidding when I read this, but this tool realy exists 
Awesome.
I'll give it a try an post the results here.

On Sunday, December 13, 2015 07:52:31 PM Iru Cai wrote:
> Try util/autoport and it can be easier.
> 

-- 
mit freundlichen Gr??en / best regards

Gerhard Gappmeier
GPG-KeyId: 5AAC50C4
GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4



From webmaster at noq2.net  Sun Dec 13 13:59:57 2015
From: webmaster at noq2.net (NOQ2 Webmaster)
Date: Sun, 13 Dec 2015 13:59:57 +0100
Subject: [coreboot] Lenovo Carbon X1
In-Reply-To: <1844557.1EWA0ai5iR@tux>
References: <1844557.1EWA0ai5iR@tux>
Message-ID: <566D6BCD.2060903@noq2.net>

Hi Gerhard,

Great idea, maybe some of the code can be recycled from the x230 port 
which features similar Ivy Bridge hardware? Would also be great if you 
could document your proceedings with the code and the flash procedure 
(e.g. on a blog article). There is still a severe lack of coreboot 
howtos imo - especially regarding newer, post-X200 Thinkpads.

greetings noq2


From gappy1502 at gmx.net  Sun Dec 13 22:51:16 2015
From: gappy1502 at gmx.net (Gerhard Gappmeier)
Date: Sun, 13 Dec 2015 22:51:16 +0100
Subject: [coreboot] Lenovo Carbon X1
In-Reply-To: <566D6BCD.2060903@noq2.net>
References: <1844557.1EWA0ai5iR@tux> <566D6BCD.2060903@noq2.net>
Message-ID: <5300274.ozU8idtllJ@lt-gergap>

Hi noq2,

yes, I'll document my steps and progress.
A soon as there is something to write about I'll put it on my blog.

For now I only have a simple note on how to get autoport working.
All deps can be installed via package manager, except acpitool (on 
gentoo).
You need to go into the kernel sources and build it there.
su
cd /usr/src/linux/tools
make acpi

This could be mentioned in util/autoport/readme.md

Cheers.

On Sunday, December 13, 2015 01:59:57 PM NOQ2 Webmaster wrote:
> Hi Gerhard,
> 
> Great idea, maybe some of the code can be recycled from the x230 port
> which features similar Ivy Bridge hardware? Would also be great if you
> could document your proceedings with the code and the flash 
procedure
> (e.g. on a blog article). There is still a severe lack of coreboot
> howtos imo - especially regarding newer, post-X200 Thinkpads.
> 
> greetings noq2



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151213/8a1735d0/attachment.html>

From gappy1502 at gmx.net  Sun Dec 13 22:44:52 2015
From: gappy1502 at gmx.net (Gerhard Gappmeier)
Date: Sun, 13 Dec 2015 22:44:52 +0100
Subject: [coreboot] Lenovo Carbon X1
In-Reply-To: <CALWv5jQRTv0NW5cnf63OaXS-8XY3S92HhjJuueUzgLXg10e9_g@mail.gmail.com>
References: <1844557.1EWA0ai5iR@tux>
 <CALWv5jQRTv0NW5cnf63OaXS-8XY3S92HhjJuueUzgLXg10e9_g@mail.gmail.com>
Message-ID: <1520181.UbY9j23lOk@lt-gergap>

Hi all,

unfortunately autoport didn't work well.

This is the output on the 1st run:
Unsupported PCI device 8086:1e56
Unknown PCI device 8086:0085, assuming removable
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x40a157]

goroutine 1 [running]:
main.LenovoEC(0xc20801edc0, 0x19, 0xc20801eec0, 0x1f, 0xc20804638f, 
0x6, 0xc20804640a, 0x12, 0xc20803d9e0, 0x2d, ...)
        /home/gergap/work/opensource/coreboot/util/autoport/ec_lenovo.go:
20 +0x1d37
main.ScanRoot(0xc20801edc0, 0x19, 0xc20801eec0, 0x1f, 0xc20804638f, 
0x6, 0xc20804640a, 0x12, 0xc20803d9e0, 0x2d, ...)
        /home/gergap/work/opensource/coreboot/util/autoport/root.go:33 
+0x52a
main.main()
        /home/gergap/work/opensource/coreboot/util/autoport/main.go:727 
+0x683


On further runs the system freezes.
To fix the tree again I run
sudo -R gergap .
git clean -fdx
git reset --hard

This way I could reproduce the above output.

The created log files can be found here:
https://www.dropbox.com/s/1r2dvbk7rj68fuv/logs.tar.gz?dl=0

The created mainboard folder is not really useful,
but if you are interested here is the patch:
https://www.dropbox.com/s/2ejds3ppae0y5md/0001-Add-lenovo-thinkpad_x1_carbon.patch?dl=0

Any help is appreciated.

On Sunday, December 13, 2015 07:52:31 PM you wrote:
> Try util/autoport and it can be easier.

-- 
mfg,
Gerhard Gappmeier


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151213/f37131a1/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Tue Dec 15 00:37:00 2015
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 15 Dec 2015 00:37:00 +0100
Subject: [coreboot] Fwd: Your stand proposal for FOSDEM 2016 has been
	accepted
In-Reply-To: <20151214195515.C04A3CB582@mailhost.gletsjer.net>
References: <20151214195515.C04A3CB582@mailhost.gletsjer.net>
Message-ID: <566F529C.2000600@gmx.net>

Hello everyone,

let's make this our best FOSDEM stand presence ever!
https://www.coreboot.org/FOSDEM_2016

Please fill in https://www.coreboot.org/Talk:FOSDEM_2016 if you're coming.

Regards,
Carl-Daniel

-------- Forwarded Message --------
From:     FOSDEM Stands Team <stands at fosdem.org>
To:     Carl-Daniel <c-d.hailfinger.devel.2006 at gmx.net>
Subject:     Your stand proposal for FOSDEM 2016 has been accepted
Message-Id:     <20151214195515.C04A3CB582 at mailhost.gletsjer.net>
Date:     Mon, 14 Dec 2015 20:54:56 +0100 (CET)

Hi Carl-Daniel,

The FOSDEM stands team is glad to be able to inform you that your request
for a stand for 'coreboot_flashrom' has been accepted.
There will be two tables reserved for you.

Like most years, we received roughly twice as many requests for stands
as we have tables available. We have aimed to grant as many requests as
feasible and to increase the diversity of the accepted stands. Because
of this, we have unfortunately had to reduce the space available for a
number of regular attendees, as well as reject some projects that have
been present in previous years years.

You will receive further information about what's expected of you closer
to the event date.

Looking forward to seeing you at FOSDEM 2016!

Kind regards,

Wynke Stulemeijer
FOSDEM stands team



From peter at stuge.se  Tue Dec 15 05:08:38 2015
From: peter at stuge.se (Peter Stuge)
Date: Tue, 15 Dec 2015 05:08:38 +0100
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <CAP6exYK5nK4BLL1r_6eGiR2v8hJwQvHOedNMYNhJFnWSoLnP4Q@mail.gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
 <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
 <CAP6exYKZg5i3PmuSu3OQphgTrSxogSPT=bNH1mwUzceH85k7kA@mail.gmail.com>
 <20151208061550.10195.qmail@stuge.se>
 <CAP6exYK5nK4BLL1r_6eGiR2v8hJwQvHOedNMYNhJFnWSoLnP4Q@mail.gmail.com>
Message-ID: <20151215040838.29041.qmail@stuge.se>

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


From mr.nuke.me at gmail.com  Wed Dec 16 03:19:14 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Tue, 15 Dec 2015 18:19:14 -0800
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <20151215040838.29041.qmail@stuge.se>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
 <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
 <CAP6exYKZg5i3PmuSu3OQphgTrSxogSPT=bNH1mwUzceH85k7kA@mail.gmail.com>
 <20151208061550.10195.qmail@stuge.se>
 <CAP6exYK5nK4BLL1r_6eGiR2v8hJwQvHOedNMYNhJFnWSoLnP4Q@mail.gmail.com>
 <20151215040838.29041.qmail@stuge.se>
Message-ID: <5670CA22.3060303@gmail.com>

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
> 


From peter at stuge.se  Thu Dec 17 12:42:27 2015
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Dec 2015 12:42:27 +0100
Subject: [coreboot] baytrail + fsp_baytrail
In-Reply-To: <5670CA22.3060303@gmail.com>
References: <20151206171830.0513b507@lazus.yip> <56652D30.3000303@gmail.com>
 <CA+e+Ov5_5RkZZCe7NZchRVAizD3B3bz68s2q+MUOPZbTphDjKA@mail.gmail.com>
 <CAE7DoPZADKr+Vjfx3giKs9w0umUsrncwmgrD9PgEs1UUn8s0Tg@mail.gmail.com>
 <CAP6exYKZg5i3PmuSu3OQphgTrSxogSPT=bNH1mwUzceH85k7kA@mail.gmail.com>
 <20151208061550.10195.qmail@stuge.se>
 <CAP6exYK5nK4BLL1r_6eGiR2v8hJwQvHOedNMYNhJFnWSoLnP4Q@mail.gmail.com>
 <20151215040838.29041.qmail@stuge.se> <5670CA22.3060303@gmail.com>
Message-ID: <20151217114227.17137.qmail@stuge.se>

Alex G. wrote:
> Gerrit is open for business 24/7

Yes. And consistently making our codebase better rather than worse is
the responsibility of every developer and reviewer. So fun!


//Peter


From gardner.ben at gmail.com  Thu Dec 17 17:17:11 2015
From: gardner.ben at gmail.com (Ben Gardner)
Date: Thu, 17 Dec 2015 10:17:11 -0600
Subject: [coreboot] Minnowmax: Has anyone used the XDP debug port with
	coreboot?
Message-ID: <CAE7DoPaB+D4q1QQzVnqqa3LyOO26-f8hFsgvLRXe=xgMXYY87w@mail.gmail.com>

I'm trying to get the XDP debug port working with a custom board that
is very similar to the Minnowmax board.

Has anyone used the XDP connection with the Minnowmax board with coreboot?

Thanks,
Ben


From Brett.Testerman at cobham.com  Thu Dec 17 17:25:23 2015
From: Brett.Testerman at cobham.com (Testerman, Brett (US COM))
Date: Thu, 17 Dec 2015 16:25:23 +0000
Subject: [coreboot] Minnowmax: Has anyone used the XDP debug port
	with	coreboot?
In-Reply-To: <CAE7DoPaB+D4q1QQzVnqqa3LyOO26-f8hFsgvLRXe=xgMXYY87w@mail.gmail.com>
References: <CAE7DoPaB+D4q1QQzVnqqa3LyOO26-f8hFsgvLRXe=xgMXYY87w@mail.gmail.com>
Message-ID: <1142408A68D00D4F9162A8F3AFF1970A823BDF64@NHC2-WHT-MBX02.white.cobham.local>

I have a custom E38xx design (Baytrail) that I ported Coreboot on to. XDP works fine but you must install the TXE image in the boot flash else the port is locked out.

Brett



From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Ben Gardner
Sent: Thursday, December 17, 2015 9:17 AM
To: coreboot
Subject: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot?


** Please note that the Sender of this email is from outside the Cobham NA IT Hub **
I'm trying to get the XDP debug port working with a custom board that
is very similar to the Minnowmax board.

Has anyone used the XDP connection with the Minnowmax board with coreboot?

Thanks,
Ben

--
coreboot mailing list: coreboot at coreboot.org<mailto:coreboot at coreboot.org>
http://www.coreboot.org/mailman/listinfo/coreboot<http://www.coreboot.org/mailman/listinfo/coreboot>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151217/267318c9/attachment.html>

From gardner.ben at gmail.com  Thu Dec 17 18:30:00 2015
From: gardner.ben at gmail.com (Ben Gardner)
Date: Thu, 17 Dec 2015 11:30:00 -0600
Subject: [coreboot] Minnowmax: Has anyone used the XDP debug port with
	coreboot?
In-Reply-To: <1142408A68D00D4F9162A8F3AFF1970A823BDF64@NHC2-WHT-MBX02.white.cobham.local>
References: <CAE7DoPaB+D4q1QQzVnqqa3LyOO26-f8hFsgvLRXe=xgMXYY87w@mail.gmail.com>
 <1142408A68D00D4F9162A8F3AFF1970A823BDF64@NHC2-WHT-MBX02.white.cobham.local>
Message-ID: <CAE7DoPa=5R_=rEEmktS9pJaQ4stBeaRCgYNuEFmb=xA9O4Sonw@mail.gmail.com>

Hi Brett,

If you don't mind, I have a few more questions about your setup.

On Thu, Dec 17, 2015 at 10:25 AM, Testerman, Brett (US COM)
<Brett.Testerman at cobham.com> wrote:
> I have a custom E38xx design (Baytrail) that I ported Coreboot on to. XDP
> works fine but you must install the TXE image in the boot flash else the
> port is locked out.

We don't need secure boot, so we are chose the 'SLIM' TXE image.
Did you have to do anything to configure the TXE image, like setting
FUSE_FILE_OEM_KEY_HASH_1?

The Intel System Debugger indicates that the "JTAG connection was
established but the target appears to have security-restricted JTAG.
Please try disabling JTAG security in the platform firmware."
(That was with FSP Gold v3. I haven't yet tested with FSP Gold v4. The
XDP hardware is at another location, so testing is a bit difficult.)

Out Intel rep says that we have to send the "Set Debug State" FMI
command to the TXE engine to enable debug.
The problem I ran into with that is that the FspInitEntry (Goldv4)
call hides the TXE PCI device (1a.0) and it doesn't seem like I can
send a FMI command without RAM first being initialized.

Does any of that sound familiar? Or did it "just work" for your board?
I would expect it to "just work" if secure boot was disabled.

Last question about your gpio.c file:
It looks like GPIO_S5[22-30] are used for XDP.
Minnowmax has GPIO_S5[22] as GPIO_NC and GPIO_S5[23-30] set as
GPIO_FUNC(0, PULL_UP, 20K).

Is that how you configured the XDP-related pins?
If not, would you mind sending you gpio.c file so I can compare?

Thanks,
Ben


From Brett.Testerman at cobham.com  Thu Dec 17 21:23:38 2015
From: Brett.Testerman at cobham.com (Testerman, Brett (US COM))
Date: Thu, 17 Dec 2015 20:23:38 +0000
Subject: [coreboot] Minnowmax: Has anyone used the XDP debug port with
 coreboot?
In-Reply-To: <CAE7DoPa=5R_=rEEmktS9pJaQ4stBeaRCgYNuEFmb=xA9O4Sonw@mail.gmail.com>
References: <CAE7DoPaB+D4q1QQzVnqqa3LyOO26-f8hFsgvLRXe=xgMXYY87w@mail.gmail.com>
 <1142408A68D00D4F9162A8F3AFF1970A823BDF64@NHC2-WHT-MBX02.white.cobham.local>
 <CAE7DoPa=5R_=rEEmktS9pJaQ4stBeaRCgYNuEFmb=xA9O4Sonw@mail.gmail.com>
Message-ID: <1142408A68D00D4F9162A8F3AFF1970A823BDFE9@NHC2-WHT-MBX02.white.cobham.local>

Ben,

You are fighting all the things I had to go through 5 months ago. Not fun. Learned the hard way things like the first steppings of the processor would boot in non-descriptor mode the later ones will not. Even the docs state it one way then correct themselves a few sentences later. And that the processor will boot without a TXE image but like I said before, XDP is disabled. And good luck getting information on writing a SPI driver. The register map is there but nothing on how to use it. Closest equivalent I could find was a PXA270 which is an ARM chip but they obviously reused the IP for the silicon. 

We are an embedded product so things like Secure Boot does nothing but get in our way. Was finally able to get it down to just loading the 'SLIM' TXE but making no other changes. Pretty much just zeroed all the TXE setting in the FITC tool for things like the UUID and ODM ID. I did not have to configure any hash's nor do I have to issue any FMI commands. Like you say, by the time you could issue a command coreboot has long since completed. I use an Asset XDP debugger and it catches a power cycle perfectly, halting the CPU as it is about to fetch the reset vector.

I didn't do the hardware design so it would take me quite a while to figure out which GPIO get mapped to the XDP port, especially since they go through a bunch of muxes. If you had something specific I could look early next week as I am out tomorrow. I know the hardware guy did try to follow all the Intel recommendations for the Hooks and such.

We did not make any changes to the GPIO settings the Coreboot defaults to. We do that in the custom payload we load.

Brett





-----Original Message-----
From: Ben Gardner [mailto:gardner.ben at gmail.com] 
Sent: Thursday, December 17, 2015 10:30 AM
To: Testerman, Brett (US COM)
Cc: coreboot
Subject: Re: [coreboot] Minnowmax: Has anyone used the XDP debug port with coreboot?

** Please note that the Sender of this email is from outside the Cobham NA IT Hub **

Hi Brett,

If you don't mind, I have a few more questions about your setup.

On Thu, Dec 17, 2015 at 10:25 AM, Testerman, Brett (US COM) <Brett.Testerman at cobham.com> wrote:
> I have a custom E38xx design (Baytrail) that I ported Coreboot on to. 
> XDP works fine but you must install the TXE image in the boot flash 
> else the port is locked out.

We don't need secure boot, so we are chose the 'SLIM' TXE image.
Did you have to do anything to configure the TXE image, like setting FUSE_FILE_OEM_KEY_HASH_1?

The Intel System Debugger indicates that the "JTAG connection was established but the target appears to have security-restricted JTAG.
Please try disabling JTAG security in the platform firmware."
(That was with FSP Gold v3. I haven't yet tested with FSP Gold v4. The XDP hardware is at another location, so testing is a bit difficult.)

Out Intel rep says that we have to send the "Set Debug State" FMI command to the TXE engine to enable debug.
The problem I ran into with that is that the FspInitEntry (Goldv4) call hides the TXE PCI device (1a.0) and it doesn't seem like I can send a FMI command without RAM first being initialized.

Does any of that sound familiar? Or did it "just work" for your board?
I would expect it to "just work" if secure boot was disabled.

Last question about your gpio.c file:
It looks like GPIO_S5[22-30] are used for XDP.
Minnowmax has GPIO_S5[22] as GPIO_NC and GPIO_S5[23-30] set as GPIO_FUNC(0, PULL_UP, 20K).

Is that how you configured the XDP-related pins?
If not, would you mind sending you gpio.c file so I can compare?

Thanks,
Ben


From zoran.stojsavljevic at intel.com  Fri Dec 18 09:43:37 2015
From: zoran.stojsavljevic at intel.com (Stojsavljevic, Zoran)
Date: Fri, 18 Dec 2015 08:43:37 +0000
Subject: [coreboot] 5 basic features provided by CSM,
	which SeaBIOS does provide?
Message-ID: <67BFA875989E5748A862DFF55409F2A24466E56F@IRSMSX104.ger.corp.intel.com>

Hello both lists, Jiming,

There are 5 basic features, provided by CSM SeaBIOS payload, and I am looking to list of these features.

Could you, please, provide to me list of these features, and some description, and/or pointer to these descriptions?

Thank you in advance,
Zoran Stojsavljevic
_______
Most of The Time you should be "intel inside" to be capable to think "out of the box".

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151218/560746b1/attachment.html>

From gappy1502 at gmx.net  Fri Dec 18 12:05:33 2015
From: gappy1502 at gmx.net (Gerhard Gappmeier)
Date: Fri, 18 Dec 2015 12:05:33 +0100
Subject: [coreboot] Wiki Link is dead
Message-ID: <5998499.01jaUOOSJZ@ws-gergap>

On the coreboot main page
https://www.coreboot.org/
when you click on Wiki the link is dead:
https://www.coreboot.org/Welcome_to_coreboot

502 Bad Gateway

regards,
Gerhard



From tpearson at raptorengineeringinc.com  Fri Dec 18 17:50:51 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Fri, 18 Dec 2015 10:50:51 -0600
Subject: [coreboot] setting up a bug tracker
In-Reply-To: <20151110053036.4bfbc753@lazus.yip>
References: <CAE-gjdVLBmgs9G8vuY=X6dx6L+Lsaqe+cUWBwJ78dJXHZaBd7w@mail.gmail.com>
 <CAE-gjdWAFThaN0EKrwh0wH3MJ=03f_m4eRPbDdi3sqE0emGCsg@mail.gmail.com>
 <563B8EBD.8020208@gmail.com> <20151110053036.4bfbc753@lazus.yip>
Message-ID: <5674396B.807@raptorengineeringinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/09/2015 10:30 PM, Alexander Couzens wrote:
> Hi,
> 
> I've started to setup a redmine. 
> The openid integration seems to need more improvements,
> but it should work as soon ssl works (and a another patch applied).
> 
> @Stefan/Patrick Can you create a CName for ticket.coreboot.org -> coreboot.dtn10.de
> 
> Next question is, how we handle the ssl stuff. Should we try let's encrypt?
> 
> Best
> lynxis
> 
> On Thu, 5 Nov 2015 09:15:41 -0800
> "Alex G." <mr.nuke.me at gmail.com> wrote:
>> Let's try it.
> 

The OpenID login is still not working; additionally I appear to have
somehow been locked out of my account and there is no password reset
feature (having to handle yet another authentication system with its own
bugs is one reason why OpenID was preferred).

https://ticket.coreboot.org/issues/15 is still a problem; see latest
uploads here:
https://review.coreboot.org/gitweb?p=board-status.git;a=commit;h=046dbe64930c44a6ff06ec85b852751a1152e4cf

Can someone with tracker access please set that bug to reopened?

Thanks!

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

iQEcBAEBAgAGBQJWdDllAAoJEK+E3vEXDOFbUtcIALUC8Q3nRtkJuBoy0ttH6oC9
A5Mn9dHsed6RkvmpmQaP0XRtXg2dQGgTB9FwhIGwImsjY5xwlXfDwbSv4/l8k66Z
tDRs4QeKvgr8sAJFn8SHtHyVxv8HU+huJA7s0b+bPTL0CFpkKjCs5vzAheA4G25u
TRU0yTXbncLLKLSjs9rO5zyJf1F9YZ44b9oYlKaqr97r4Qw/3NerWJjyhP68WX8S
unXVFYUh75RyI8Q/TiCEVNxOH+JmN2KIUV8+BImaZvSEAOvng3uDqOuOqg6plLAb
2KJUqY9CYTUhJi0kzyQZCMGq+rqLCwBTxIuN9dZihvdh4PhLcGCVVjbWtCq4n6w=
=pIzG
-----END PGP SIGNATURE-----


From kevin at koconnor.net  Sat Dec 19 02:38:53 2015
From: kevin at koconnor.net (Kevin O'Connor)
Date: Fri, 18 Dec 2015 20:38:53 -0500
Subject: [coreboot] [SeaBIOS] 5 basic features provided by CSM,
 which SeaBIOS does provide?
In-Reply-To: <67BFA875989E5748A862DFF55409F2A24466E56F@IRSMSX104.ger.corp.intel.com>
References: <67BFA875989E5748A862DFF55409F2A24466E56F@IRSMSX104.ger.corp.intel.com>
Message-ID: <20151219013853.GA13334@morn.lan>

On Fri, Dec 18, 2015 at 08:43:37AM +0000, Stojsavljevic, Zoran wrote:
> Hello both lists, Jiming,
> 
> There are 5 basic features, provided by CSM SeaBIOS payload, and I
> am looking to list of these features.
> 
> Could you, please, provide to me list of these features, and some
> description, and/or pointer to these descriptions?

I don't fully understand your question.  One can build SeaBIOS as a
Compatibility Support Module (CSM) for UEFI, and this has been tested
with OVMF on virtual machines.  It's theoretically also possible to
use it as a CSM on real hardware with a UEFI payload on coreboot, but
to the best of my knowledge that has never been tested.  When SeaBIOS
is used as a CSM module, it provides legacy 16bit BIOS support on UEFI
machines to bootloaders and option roms that require that support.

The only link I have for SeaBIOS CSM is:

  http://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support_Module_.28CSM.29

Cheers,
-Kevin


From paulepanter at users.sourceforge.net  Sat Dec 19 13:15:24 2015
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Sat, 19 Dec 2015 13:15:24 +0100
Subject: [coreboot] coreboot.org redirect to tracker.coreboot.org
Message-ID: <1450527324.13110.20.camel@users.sourceforge.net>

Dear coreboot administrators,


www.coreboot.org?and coreboot.org redirect to tracker.coreboot.org.


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151219/710e50be/attachment.asc>

From mytbk920423 at gmail.com  Mon Dec 21 03:18:01 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Mon, 21 Dec 2015 10:18:01 +0800
Subject: [coreboot] hyper_threading in CMOS/NVRAM seems useless in many CPU
	models
Message-ID: <CALWv5jR04ChAbp50yHJCiAZTUSU2QVhDsG+LLLhBmkpZu3tSzA@mail.gmail.com>

Hi,

I just tried to disable hyper-threading in my machine, and I found the
hyper_threading setting in NVRAM is useless. I searched in the code and
found only a few number of CPU code has in its Makefile.inc `subdirs-y +=
../hyperthreading', which can read the hyper_threading NVRAM option and
enable/disable hyper-threading.

Iru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151221/385f47ca/attachment.html>

From zoran.stojsavljevic at intel.com  Mon Dec 21 13:57:33 2015
From: zoran.stojsavljevic at intel.com (Stojsavljevic, Zoran)
Date: Mon, 21 Dec 2015 12:57:33 +0000
Subject: [coreboot] [SeaBIOS] 5 basic features provided by CSM,
 which SeaBIOS does provide?
In-Reply-To: <20151219013853.GA13334@morn.lan>
References: <67BFA875989E5748A862DFF55409F2A24466E56F@IRSMSX104.ger.corp.intel.com>
 <20151219013853.GA13334@morn.lan>
Message-ID: <67BFA875989E5748A862DFF55409F2A24466F71F@IRSMSX104.ger.corp.intel.com>

Hello Kevin,

All Good with setting CSM ON for legacy support. You need it for 16 bit BIOSes, and for legacy OSes, such as WIN XP or WIN 7 and derivatives.

Here is the question I am wondering: What if I decide to bring FSP -> Coreboot -> SeaBIOS -> WIN 8.1 32. Do I really need SeaBIOS with option set to: CSM ON (I brought WIN 8.1 32  on CC2 with SeaBIOS and feature CSM ON)? In other words, can I bring WIN 8.1 32 on FSP -> Coreboot -> SeaBIOS with CSM OFF?

The same question for: FSP -> Coreboot -> SeaBIOS -> WIN 8.1 64? I guess, here is CSM ON mandatory. Am I correct?

Could I have a true 32 or 64 UEFI compliant OS on BSP: FSP -> Coreboot -> SeaBIOS -> UEFI OS sans/without CSM feature ON? The same one I have after bringing on UEFI 32/64 BIOS UEFI 32/64 OS (CSM is OFF always)?  

Thank you,
Zoran

-----Original Message-----
From: Kevin O'Connor [mailto:kevin at koconnor.net] 
Sent: Saturday, December 19, 2015 2:39 AM
To: Stojsavljevic, Zoran
Cc: coreboot; seabios at seabios.org; Sun, Jiming
Subject: Re: [SeaBIOS] 5 basic features provided by CSM, which SeaBIOS does provide?

On Fri, Dec 18, 2015 at 08:43:37AM +0000, Stojsavljevic, Zoran wrote:
> Hello both lists, Jiming,
> 
> There are 5 basic features, provided by CSM SeaBIOS payload, and I am 
> looking to list of these features.
> 
> Could you, please, provide to me list of these features, and some 
> description, and/or pointer to these descriptions?

I don't fully understand your question.  One can build SeaBIOS as a Compatibility Support Module (CSM) for UEFI, and this has been tested with OVMF on virtual machines.  It's theoretically also possible to use it as a CSM on real hardware with a UEFI payload on coreboot, but to the best of my knowledge that has never been tested.  When SeaBIOS is used as a CSM module, it provides legacy 16bit BIOS support on UEFI machines to bootloaders and option roms that require that support.

The only link I have for SeaBIOS CSM is:

  http://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support_Module_.28CSM.29

Cheers,
-Kevin
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928



From kevin at koconnor.net  Mon Dec 21 19:30:52 2015
From: kevin at koconnor.net (Kevin O'Connor)
Date: Mon, 21 Dec 2015 13:30:52 -0500
Subject: [coreboot] [SeaBIOS] 5 basic features provided by CSM,
 which SeaBIOS does provide?
In-Reply-To: <67BFA875989E5748A862DFF55409F2A24466F71F@IRSMSX104.ger.corp.intel.com>
References: <67BFA875989E5748A862DFF55409F2A24466E56F@IRSMSX104.ger.corp.intel.com>
 <20151219013853.GA13334@morn.lan>
 <67BFA875989E5748A862DFF55409F2A24466F71F@IRSMSX104.ger.corp.intel.com>
Message-ID: <20151221183051.GA27329@morn.lan>

On Mon, Dec 21, 2015 at 12:57:33PM +0000, Stojsavljevic, Zoran wrote:
> Hello Kevin,
> 
> All Good with setting CSM ON for legacy support. You need it for 16 bit BIOSes, and for legacy OSes, such as WIN XP or WIN 7 and derivatives.
> 
> Here is the question I am wondering: What if I decide to bring FSP -> Coreboot -> SeaBIOS -> WIN 8.1 32. Do I really need SeaBIOS with option set to: CSM ON (I brought WIN 8.1 32  on CC2 with SeaBIOS and feature CSM ON)? In other words, can I bring WIN 8.1 32 on FSP -> Coreboot -> SeaBIOS with CSM OFF?
> 
> The same question for: FSP -> Coreboot -> SeaBIOS -> WIN 8.1 64? I guess, here is CSM ON mandatory. Am I correct?
> 
> Could I have a true 32 or 64 UEFI compliant OS on BSP: FSP -> Coreboot -> SeaBIOS -> UEFI OS sans/without CSM feature ON? The same one I have after bringing on UEFI 32/64 BIOS UEFI 32/64 OS (CSM is OFF always)?  
> 

In all of the above situations you must compile SeaBIOS with
CONFIG_COREBOOT=y and CONFIG_CSM=n.  CONFIG_CSM is mutually exclusive
with CONFIG_COREBOOT, and if one is planning to run SeaBIOS directly
from coreboot then one must use CONFIG_COREBOOT=y.

-Kevin


From hatim at hatimak.me  Mon Dec 21 19:45:52 2015
From: hatim at hatimak.me (Hatim Kanchwala)
Date: Tue, 22 Dec 2015 00:15:52 +0530
Subject: [coreboot] Getting started with coreboot and GSoC
Message-ID: <567848E0.1020109@hatimak.me>

Hello!

I am Hatim Kanchwala from India. I am a sophomore pursuing Bachelor's in
Electrical Engineering at the Indian Institute of Technology Patna. I
came across coreboot through the Google Summer of Code page. I am
aspiring to work with coreboot for GSoC 2016.

To get an introduction to coreboot, to its history and its philosophy, I
read the wiki and also watched videos on YouTube, including the Google
Tech Talk by Ron Minnich, Stefan Reinauer and Peter Stuge. I have
downloaded coreboot, built the cross compiler and then built coreboot
for emulation with QEMU x86, with SeaBIOS as payload. I managed to do
this with the help of documentation from the wiki and a bit of searching
through the web and through the mailing list archives. I couldn't try
coreboot on my machine as my mainboard isn't supported (yet). Currently,
I am trying to build and test coreboot for emulation with QEMU ARM.
Unfortunately, I haven't had much progress there, but I will remain at it!

I have taken an introductory course in the C language at my University
and a basic Digital Circuits course. I have a fair experience with Linux
and git. Please tell me how I can get started to contribute to coreboot.
I am certain that the skills and knowledge required to contribute is way
more than I currently possess, but I am a keen learner.

Academically, I am interested in Embedded Systems and Computer
Architecture, in which I hope to pursue higher studies. I consider being
part of coreboot and contributing to it as an opportunity to learn more
about these fields and to learn about open-source development as well.
Also, I am looking forward to getting to know people and learning from them!

You can find me on IRC (Freenode) under the nick hatim. I am already a
member of the #coreboot channel.

Thank you for your time and help.

Hatim

--

http://hatimak.me


From gappy1502 at gmx.net  Mon Dec 21 21:52:33 2015
From: gappy1502 at gmx.net (Gerhard Gappmeier)
Date: Mon, 21 Dec 2015 21:52:33 +0100
Subject: [coreboot] Getting started with coreboot and GSoC
In-Reply-To: <567848E0.1020109@hatimak.me>
References: <567848E0.1020109@hatimak.me>
Message-ID: <56786691.1040507@gmx.net>

I Hatim,

I also just started to dig into coreboot code in my spare time.

Beside the wiki I found this here to be in excelent article to get a
basic understanding:
http://lennartb.home.xs4all.nl/coreboot/coreboot.html

On 12/21/2015 07:45 PM, Hatim Kanchwala wrote:
> Hello!
>
> I am Hatim Kanchwala from India. I am a sophomore pursuing Bachelor's in
> Electrical Engineering at the Indian Institute of Technology Patna. I
> came across coreboot through the Google Summer of Code page. I am
> aspiring to work with coreboot for GSoC 2016.
>
> To get an introduction to coreboot, to its history and its philosophy, I
> read the wiki and also watched videos on YouTube, including the Google
> Tech Talk by Ron Minnich, Stefan Reinauer and Peter Stuge. I have
> downloaded coreboot, built the cross compiler and then built coreboot
> for emulation with QEMU x86, with SeaBIOS as payload. I managed to do
> this with the help of documentation from the wiki and a bit of searching
> through the web and through the mailing list archives. I couldn't try
> coreboot on my machine as my mainboard isn't supported (yet). Currently,
> I am trying to build and test coreboot for emulation with QEMU ARM.
> Unfortunately, I haven't had much progress there, but I will remain at it!
>
> I have taken an introductory course in the C language at my University
> and a basic Digital Circuits course. I have a fair experience with Linux
> and git. Please tell me how I can get started to contribute to coreboot.
> I am certain that the skills and knowledge required to contribute is way
> more than I currently possess, but I am a keen learner.
>
> Academically, I am interested in Embedded Systems and Computer
> Architecture, in which I hope to pursue higher studies. I consider being
> part of coreboot and contributing to it as an opportunity to learn more
> about these fields and to learn about open-source development as well.
> Also, I am looking forward to getting to know people and learning from them!
>
> You can find me on IRC (Freenode) under the nick hatim. I am already a
> member of the #coreboot channel.
>
> Thank you for your time and help.
>
> Hatim
>
> --
>
> http://hatimak.me
>



From marcj303 at gmail.com  Tue Dec 22 00:51:01 2015
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 21 Dec 2015 23:51:01 +0000
Subject: [coreboot] Getting started with coreboot and GSoC
In-Reply-To: <567848E0.1020109@hatimak.me>
References: <567848E0.1020109@hatimak.me>
Message-ID: <CALrs_3jL3Ldwt7WCaikdJ=R-GR2T-hknqXJWguNVF2t5pdoPwA@mail.gmail.com>

Hi Hatim,
Welcome, Thanks for joining the coreboot community. The best way to
understand coreboot is to get involved. I recommend reviewing patches in
gerrit. The project moved quickly and we are always working on
documentation. You are welcome to ask specific questions in IRC and meet
other developers that might be interested in the systems and architecture
you want to work on.

http://review.coreboot.org/


GSoC is  several months away, but you can look at project ideas and
previous projects:

https://www.coreboot.org/Project_Ideas
http://blogs.coreboot.org/blog/2015/04/27/coreboot-gsoc-2015-projects/

Regards,
Marc

On Mon, Dec 21, 2015, 11:52 AM Hatim Kanchwala <hatim at hatimak.me> wrote:

> Hello!
>
> I am Hatim Kanchwala from India. I am a sophomore pursuing Bachelor's in
> Electrical Engineering at the Indian Institute of Technology Patna. I
> came across coreboot through the Google Summer of Code page. I am
> aspiring to work with coreboot for GSoC 2016.
>
> To get an introduction to coreboot, to its history and its philosophy, I
> read the wiki and also watched videos on YouTube, including the Google
> Tech Talk by Ron Minnich, Stefan Reinauer and Peter Stuge. I have
> downloaded coreboot, built the cross compiler and then built coreboot
> for emulation with QEMU x86, with SeaBIOS as payload. I managed to do
> this with the help of documentation from the wiki and a bit of searching
> through the web and through the mailing list archives. I couldn't try
> coreboot on my machine as my mainboard isn't supported (yet). Currently,
> I am trying to build and test coreboot for emulation with QEMU ARM.
> Unfortunately, I haven't had much progress there, but I will remain at it!
>
> I have taken an introductory course in the C language at my University
> and a basic Digital Circuits course. I have a fair experience with Linux
> and git. Please tell me how I can get started to contribute to coreboot.
> I am certain that the skills and knowledge required to contribute is way
> more than I currently possess, but I am a keen learner.
>
> Academically, I am interested in Embedded Systems and Computer
> Architecture, in which I hope to pursue higher studies. I consider being
> part of coreboot and contributing to it as an opportunity to learn more
> about these fields and to learn about open-source development as well.
> Also, I am looking forward to getting to know people and learning from
> them!
>
> You can find me on IRC (Freenode) under the nick hatim. I am already a
> member of the #coreboot channel.
>
> Thank you for your time and help.
>
> Hatim
>
> --
>
> http://hatimak.me
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
http://marcjonesconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151221/2a2abcde/attachment.html>

From mark at edt.com  Tue Dec 22 23:43:25 2015
From: mark at edt.com (Mark C. Mason)
Date: Tue, 22 Dec 2015 14:43:25 -0800
Subject: [coreboot] Coreboot contract work in Beaverton, OR
Message-ID: <CAKQSR1yE6i-f3VvrDwjzroKheJb=uhZCfy7hFF3AztkOn-FipA@mail.gmail.com>

We need to hire someone on a contract basis to help us fine-tune the
current coreboot
to our new design based on the ASROCK IMB-A180 motherboard (AMD G-Series
SOC).

Please contact me directly if you are qualified and interested.  Part of
the work would occur
in our Beaverton, OR offices.


-- 
Mark C. Mason
SW Engineer
Direct line: 503-748-7877
Email: mark at edt.com

Engineering Design Team (EDT), Inc. - a HEICO company
1400 NW Compton Drive, Suite 315
Beaverton, Oregon 97006 (U.S.A.)
Phone: 503-690-1234 / 800-435-4320
Fax: 503-690-1243
Web: www.edt.com

Confidentiality Notice: The information contained in this email and any
accompanying attachment(s) is intended only for the use of the intended
recipient and may be confidential and/or privileged.  If any reader of this
communication is not the intended recipient, unauthorized use, disclosure or
copying is strictly prohibited, and may be unlawful.  If you have received
this communication in error, please immediately notify the sender by return
email, and delete the original message and all copies from your system.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151222/da18ead7/attachment.html>

From mr.nuke.me at gmail.com  Wed Dec 23 04:12:49 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Tue, 22 Dec 2015 19:12:49 -0800
Subject: [coreboot] <vendor> commit messages and their suitability for
	coreboot.org
Message-ID: <567A1131.7000504@gmail.com>

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 <board>". 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.


### <vendor>-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 that's why you should do it too (TM).

And my favorite "built and booted glados":
* You build glados? I didn't know you worked for Aperture, Inc.
* Oooh, you meant "built and booted google/glados". NVM then

### Tags in general ###

Tags are meant for machine-parsable content. coreboot commit message
body are inherently meant to be read by a human, and thus are by design,
human-readable. This fundamental contradiction means that tags will
always be second-class to clear sentences and well-structured
paragraphs. If you can avoid tags in the first place, please do so.

## Closing remarks ##

google "owns" most of the brand-name, respectable coreboot developers.
When those individuals make the mistakes I pointed here, it's very easy
for an observing new contributor to mistake those as the official policy
of the project. Because if all the respected names do it, it must be
right, right? People make mistakes.

I have the luck of doing coreboot for a company which does coreboot (and
is not google). I've shown people how to think about coreboot and write
upstreamable patches. Those very same people have corrected me on code
reviews. I make mistakes. If you're reading this, and are from planet
Earth, you make mistakes. If you're one of the very respected names I
mentioned earlier, you make mistakes... because nobody is perfect.

There's much more work going on in coreboot than the patches in google's
little world, or intel's little world, or raptor's little world, or
minifree's little world. When I write patches, I do my best to be
courteous to those outside my little world. I do my best to write short
patches that people not familiar with the hardware can review. I do my
best to properly namespace and describe the patch in the first line, so
that someone looking over 100+ patches can have a better idea of whether
or not that patch is relevant to him (or her).

I always think in terms of "would this be acceptable to coreboot.org" ?
Most developers think in those terms, and are held to that standard.
It's easy to do things like not properly prefix a title because you only
have 65 characters available, and it's inconvenient to spend time
thinking of a better title. It's easy to add nonsensical tags because
your employers tools will automootically check for such tags, what you
do when you submit your work to your employer for a paycheck is up to
you, but please make sure that work ending up on coreboot.org is free of
these easy to fix mistakes.

And if you're someone else observing this discussion, please keep in
mind that the people I mentioned earlier are well-intentioned. They try
to keep the chromium and coreboot.org branches in sync, and that's
neither an easy task, nor something they are asked to do.
Before someone decides to take my side, and start accusations, please
keep in mind these people are well-intentioned.

Alex


From adurbin at google.com  Wed Dec 23 17:06:17 2015
From: adurbin at google.com (Aaron Durbin)
Date: Wed, 23 Dec 2015 08:06:17 -0800
Subject: [coreboot] <vendor> commit messages and their suitability for
	coreboot.org
In-Reply-To: <567A1131.7000504@gmail.com>
References: <567A1131.7000504@gmail.com>
Message-ID: <CAE2855vX4QpASH8pdoUbC=fPiMdZkh_pLG2A2BKz7POGOmVDUA@mail.gmail.com>

On Tue, Dec 22, 2015 at 7:12 PM, Alex G. <mr.nuke.me at gmail.com> wrote:
> 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:

I'll bite since this is largely directed at me.

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

I didn't know summaries were complete sentences.

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

That's excellent code review feedback. Too bad it wasn't on gerrit.

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

Then why bring it up?

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

That creates more work on my part for juggling. I opted to create
patches against coreboot.org instead of just landing things in our
internal repository. If I stripped everything across that boundary I'd
be doing cumbersome clerical work. In the face of that it's actually
easier to not engage w/ coreboot.org first. That'd be an unfortunate
outcome in my opinion.

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

You may also optionally ignore the content. I don't see the issue. If
you are doing development against internal bug/feature databases that
tracking is very helpful. Demanding that such references not be put in
commit descriptions seems like a silly request when the developers
need that for their own work.

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

Again, this can be ignored but it also doesn't hurt anything.

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

Indeed good feedback on the code review, but it's not there. Actually,
it looks like I didn't backfill what I did. Thanks for the pointer.

> A very common TEST tag says "built and booted <board>". 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.

But it's not booted so in that sense it's actually a positive signal.
Jenkins building also doesn't cover all the combinations of options
that something could be impacted by.

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

If you juggle that many definitions of 'booted' in your head I can see
why the pedant comes out. It is my understanding that booted means
booting through the OS to userspace. Is there really other
definitions? And if there are wouldn't those be less progressing?

Again, feel free to ignore it as well. While it may not be beneficial
to you it may be beneficial to others.

>
> ### <vendor>-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.

That's a waste of line length which would impede on your full sentence
summary and --oneline.

>
> 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 that's why you should do it too (TM).

mcp509 lives in all those directories? Do we have subdirectories with
the same name under the higher level component directories?

>
> And my favorite "built and booted glados":
> * You build glados? I didn't know you worked for Aperture, Inc.
> * Oooh, you meant "built and booted google/glados". NVM then

There's only one glados directory in the tree.

>
> ### Tags in general ###
>
> Tags are meant for machine-parsable content. coreboot commit message
> body are inherently meant to be read by a human, and thus are by design,
> human-readable. This fundamental contradiction means that tags will
> always be second-class to clear sentences and well-structured
> paragraphs. If you can avoid tags in the first place, please do so.
>
> ## Closing remarks ##
>
> google "owns" most of the brand-name, respectable coreboot developers.
> When those individuals make the mistakes I pointed here, it's very easy
> for an observing new contributor to mistake those as the official policy
> of the project. Because if all the respected names do it, it must be
> right, right? People make mistakes.

Alex-deemed mistakes?

>
> I have the luck of doing coreboot for a company which does coreboot (and
> is not google). I've shown people how to think about coreboot and write
> upstreamable patches. Those very same people have corrected me on code
> reviews. I make mistakes. If you're reading this, and are from planet
> Earth, you make mistakes. If you're one of the very respected names I
> mentioned earlier, you make mistakes... because nobody is perfect.
>
> There's much more work going on in coreboot than the patches in google's
> little world, or intel's little world, or raptor's little world, or
> minifree's little world. When I write patches, I do my best to be
> courteous to those outside my little world. I do my best to write short
> patches that people not familiar with the hardware can review. I do my
> best to properly namespace and describe the patch in the first line, so
> that someone looking over 100+ patches can have a better idea of whether
> or not that patch is relevant to him (or her).

I'm curious how you can't determine if something is relevant to you or
not. Either you are familiar with a board, subsystem, etc or not. If
you aren't why wouldn't you just ignore it?

>
> I always think in terms of "would this be acceptable to coreboot.org" ?
> Most developers think in those terms, and are held to that standard.
> It's easy to do things like not properly prefix a title because you only
> have 65 characters available, and it's inconvenient to spend time
> thinking of a better title. It's easy to add nonsensical tags because
> your employers tools will automootically check for such tags, what you
> do when you submit your work to your employer for a paycheck is up to
> you, but please make sure that work ending up on coreboot.org is free of
> these easy to fix mistakes.

You keep using the term 'mistake', but I don't think that's the right
term. You have an opinion on things and are expressing it. Did I miss
somewhere on https://www.coreboot.org/Development_Guidelines where
your rules are stated? Many of things I see you commenting on here
aren't mentioned. Much of the requests seem like "make me happy
because I don't like this". When, in fact, you could easily ignore the
extraneous-to-you info while not putting upon others who are trying to
contribute back.

Taking the 65 characters available limit I actually think prefixing
the higher level component to be a net-loss when attempting to form a
clear summary.

$ find . -maxdepth 3 -type d | sort | grep -v include | sed -e
's#\.\/##' -e 's#$#:#' | while read l; do echo $(echo $l | wc -c)
"'$l'"; done | sort -n -r | less

Look at the distribution there. That's a lot of wasted characters.
Ignoring anything w/ mainboard in it still yields 20 characters or
more that disappear. That would suggest to me that the request is for
terse summaries and duplicating the directory structure in the summary
line.

>
> And if you're someone else observing this discussion, please keep in
> mind that the people I mentioned earlier are well-intentioned. They try
> to keep the chromium and coreboot.org branches in sync, and that's
> neither an easy task, nor something they are asked to do.
> Before someone decides to take my side, and start accusations, please
> keep in mind these people are well-intentioned.

That's the crux of the issue. You are requesting changes that make
that harder. To some it may seem all patches are standalone w/o any
other dependencies. That's definitely not the case when creating a
product that utilizes coreboot. As such, that metadata is needed for
tracking the dependencies across repositories. In the face of
stripping that metadata away to appease people that are annoyed by
some minor content in the description then the path of least
resistance is to not participate early.

>
> Alex
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From c-d.hailfinger.devel.2006 at gmx.net  Wed Dec 23 18:48:59 2015
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 23 Dec 2015 18:48:59 +0100
Subject: [coreboot] <vendor> commit messages and their suitability for
 coreboot.org
In-Reply-To: <CAE2855vX4QpASH8pdoUbC=fPiMdZkh_pLG2A2BKz7POGOmVDUA@mail.gmail.com>
References: <567A1131.7000504@gmail.com>
 <CAE2855vX4QpASH8pdoUbC=fPiMdZkh_pLG2A2BKz7POGOmVDUA@mail.gmail.com>
Message-ID: <567ADE8B.6050302@gmx.net>

Hi,

given that testing is something I value a lot, I'd like to chip in.


On 23.12.2015 17:06, Aaron Durbin via coreboot wrote:
> On Tue, Dec 22, 2015 at 7:12 PM, Alex G. <mr.nuke.me at gmail.com> wrote:
>> [...]For the
>> sake of example, I will pick on a RABDOM commit message which follows
>> the format:
>>
>> BUG=chrome-os-partner:48412
>> BUG=chromium:445938
>> BRANCH=None
>> TEST=TBD
>> [...]
>> ### 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.
>>
> Indeed good feedback on the code review, but it's not there. Actually,
> it looks like I didn't backfill what I did. Thanks for the pointer.
>
>> A very common TEST tag says "built and booted <board>". 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.
> But it's not booted so in that sense it's actually a positive signal.
> Jenkins building also doesn't cover all the combinations of options
> that something could be impacted by.

One of the problems of jenkins is that it didn't detect that qemu normal
image (instead of simple fallback-only) didn't compile for half a year.
With the expected combinatorial explosion, this is expected, but it
still doesn't make me happy.
Maybe it would make sense to say "build-tested in a non-jenkins config"
if that was tested.

 
>> 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.
> If you juggle that many definitions of 'booted' in your head I can see
> why the pedant comes out. It is my understanding that booted means
> booting through the OS to userspace. Is there really other
> definitions? And if there are wouldn't those be less progressing?
>
> Again, feel free to ignore it as well. While it may not be beneficial
> to you it may be beneficial to others.

Would flags help? E.g. payload+linux+net+usb?

Would it make sense to include a link to the boot log (that is, coreboot
console and dmesg)? Photo of the screen (to confirm gfx)?

>From my perspective, it would be great to use REACTS output in a way
that helps people check/confirm the awesomeness of a patch.

Regards,
Carl-Daniel


From hatim at hatimak.me  Sun Dec 27 18:51:04 2015
From: hatim at hatimak.me (Hatim Kanchwala)
Date: Sun, 27 Dec 2015 23:21:04 +0530
Subject: [coreboot] Getting started with coreboot and GSoC
In-Reply-To: <56786691.1040507@gmx.net>
References: <567848E0.1020109@hatimak.me> <56786691.1040507@gmx.net>
Message-ID: <56802508.50605@hatimak.me>

Hello Gerhard,

Thanks for the articles. I have read through them and it is a nice
introductory resource.

On Tuesday 22 December 2015 02:22 AM, Gerhard Gappmeier wrote:
> I Hatim,
> 
> I also just started to dig into coreboot code in my spare time.
> 
> Beside the wiki I found this here to be in excelent article to get a
> basic understanding:
> http://lennartb.home.xs4all.nl/coreboot/coreboot.html
> 
> On 12/21/2015 07:45 PM, Hatim Kanchwala wrote:
>> Hello!
>>
>> I am Hatim Kanchwala from India. I am a sophomore pursuing Bachelor's in
>> Electrical Engineering at the Indian Institute of Technology Patna. I
>> came across coreboot through the Google Summer of Code page. I am
>> aspiring to work with coreboot for GSoC 2016.
>>
>> To get an introduction to coreboot, to its history and its philosophy, I
>> read the wiki and also watched videos on YouTube, including the Google
>> Tech Talk by Ron Minnich, Stefan Reinauer and Peter Stuge. I have
>> downloaded coreboot, built the cross compiler and then built coreboot
>> for emulation with QEMU x86, with SeaBIOS as payload. I managed to do
>> this with the help of documentation from the wiki and a bit of searching
>> through the web and through the mailing list archives. I couldn't try
>> coreboot on my machine as my mainboard isn't supported (yet). Currently,
>> I am trying to build and test coreboot for emulation with QEMU ARM.
>> Unfortunately, I haven't had much progress there, but I will remain at it!
>>
>> I have taken an introductory course in the C language at my University
>> and a basic Digital Circuits course. I have a fair experience with Linux
>> and git. Please tell me how I can get started to contribute to coreboot.
>> I am certain that the skills and knowledge required to contribute is way
>> more than I currently possess, but I am a keen learner.
>>
>> Academically, I am interested in Embedded Systems and Computer
>> Architecture, in which I hope to pursue higher studies. I consider being
>> part of coreboot and contributing to it as an opportunity to learn more
>> about these fields and to learn about open-source development as well.
>> Also, I am looking forward to getting to know people and learning from them!
>>
>> You can find me on IRC (Freenode) under the nick hatim. I am already a
>> member of the #coreboot channel.
>>
>> Thank you for your time and help.
>>
>> Hatim
>>
>> --
>>
>> http://hatimak.me
>>
> 
> 


From ercanersoy at outlook.com  Sun Dec 27 20:37:12 2015
From: ercanersoy at outlook.com (Ercan Ersoy)
Date: Sun, 27 Dec 2015 21:37:12 +0200
Subject: [coreboot] Coreboot With Linux Payload Error
Message-ID: <DUB127-W333C0C8466E5DE1132A1A2D5FA0@phx.gbl>

Hi, I'm deals compling Coreboot. I compile Coreboot with Linux payload. This run on QEMU. Coreboot works, but kernel panic error I had. How I solve my problem?

Coreboot version: 4.1
Coreboot image size: 2 MB
GNU/Linux version in Coreboot: 4.1
QEMU version: 2.0.0
QEMU has been emulated processor type: x86 32 bit - Default
QEMU has been emulated RAM amount: 64 MB (If I set 1024 MB of RAM, even so I have this error.)

Thanks for replying.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151227/ae2b1600/attachment.html>

From ercanersoy at outlook.com  Sun Dec 27 20:40:13 2015
From: ercanersoy at outlook.com (Ercan Ersoy)
Date: Sun, 27 Dec 2015 21:40:13 +0200
Subject: [coreboot] Coreboot Linux Payload Error
Message-ID: <DUB127-W690794A063222283C1C856D5FA0@phx.gbl>

                                                                              Hi, I'm deals compling Coreboot. I compile Coreboot with 
Linux payload. This run on QEMU. Coreboot works, but kernel panic error I
 had. How I solve my problem?

Coreboot version: 4.1
Coreboot image size: 2 MB
GNU/Linux version in Coreboot: 4.1
QEMU version: 2.0.0
QEMU has been emulated processor type: x86 32 bit - Default
QEMU has been emulated RAM amount: 64 MB (If I set 1024 MB of RAM, even so I have this error.)
This error: Kernel panic - not syncing: Out of memory and no killable processes...

Thanks for replying. 		 	   		  

From contact at paulk.fr  Wed Dec 30 12:36:27 2015
From: contact at paulk.fr (Paul Kocialkowski)
Date: Wed, 30 Dec 2015 12:36:27 +0100
Subject: [coreboot] FOSDEM deadlines now!
In-Reply-To: <1446284488.2576.7.camel@collins>
References: <5626B038.80901@gmx.net> <1446284488.2576.7.camel@collins>
Message-ID: <1451475387.2531.14.camel@collins>

Hi,

Le samedi 31 octobre 2015 ? 10:41 +0100, Paul Kocialkowski a ?crit :
> Le mardi 20 octobre 2015 ? 23:20 +0200, Carl-Daniel Hailfinger a ?crit :
> > we obviously want to participate in FOSDEM.
> > https://fosdem.org/2016/news/2015-09-24-call-for-participation/
> > 
> > ACT NOW!
> > 
> > Some deadlines already expired. Some can still be managed.
> > 
> > Main track talks: Deadline 2015-10-30 (10 days left)
> > One hour of entertainment, huge audience.
> > Anyone up for the challenge?
> 
> I have submitted a talk proposal about liberating modern computers, and
> will of course be talking about Coreboot there.

Sadly, the talk was rejected and it's too late to apply for one in a
developer room. I'm a bit unsure whether I'll come to FOSDEM at all, but
if I do, I'll be sure to come by and hang around the Coreboot booth!

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151230/b3d4d08c/attachment.asc>

From paulepanter at users.sourceforge.net  Thu Dec 31 17:53:25 2015
From: paulepanter at users.sourceforge.net (Paul Menzel)
Date: Thu, 31 Dec 2015 17:53:25 +0100
Subject: [coreboot] [RFC] Prepending *Original* to tags from other
	repositories
Message-ID: <1451580805.3526.70.camel@users.sourceforge.net>

Dear coreboot folks,


change set #12804 [1] proposes the following addition to the file
`Documentation/gerrit_guidelines.md`.

239	+* When bringing in a patch from another git repo, update the original
240	+git/gerrit tags by prepending the lines with 'Original-'.??Marking
241	+the original text this way makes it much easier to tell what changes
242	+happened in which repository. This applies to these lines, not the actual
243	+commit message itself:
244	+????????Commit-Id:
245	+????????Change-Id:
246	+????????Signed-off-by:
247	+????????Reviewed-on:
248	+????????Tested-by:
249	+????????Reviewed-by:
250	+The script 'util/gitconfig/rebase.sh' can be used to help automate this.
251	+Other tags such as 'Commit-Queue' can simply be removed.

Unfortunately, I do not fully understand the reasoning yet. Why is it
important, to (easily) know what tags were added in what repository.

*Commit-Id* is good to know, to easily find the commit in the other
repository, but the *Change-Id* can be used for that too.

Signed-off-by is also not changed in the Linux kernel when it is pulled
in. The new Signed-off-by line is just appended after the tags so it?s
clear what way the commit or change set took.

The same is true for the other tags.

So I would actually propose, to leave the tags unchanged when moving
them over.

What am I missing?


Thanks,

Paul


[1]?https://review.coreboot.org/12804
[2] https://review.coreboot.org/#/c/12804/2/Documentation/gerrit_guidelines.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151231/4733ee4f/attachment.asc>

From mr.nuke.me at gmail.com  Thu Dec 31 23:54:09 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Thu, 31 Dec 2015 14:54:09 -0800
Subject: [coreboot] [RFC] Prepending *Original* to tags from other
 repositories
In-Reply-To: <1451580805.3526.70.camel@users.sourceforge.net>
References: <1451580805.3526.70.camel@users.sourceforge.net>
Message-ID: <5685B211.6070108@gmail.com>

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


From kr at openmailbox.org  Sat Dec 19 05:11:15 2015
From: kr at openmailbox.org (KR Tejeda)
Date: Fri, 18 Dec 2015 21:11:15 -0700
Subject: [coreboot] HP M6-1035dx vga bios option rom
Message-ID: <20151219041146.247247C135D@mail2.openmailbox.org>

Hello,

   I have just started playing with coreboot and BIOS flashing, so
please forgive the noobness.  I recently acquired an HP Pavilion
M6-1035dx to install coreboot as mentioned in the wiki.  I made a few
noob mistakes along the way.  First, I wiped the hard drive entirely
and installed Linux to try running flashrom from the native OS (hence
any factory recovery partition has been wiped). Second, I built a
coreboot.rom image without using the supplied .config file from the
wiki.  I just used a vanilla configuration, which didn't work at all,
not surprisingly.  

Once I found the right config settings, I realized that I never backed
up the stock BIOS ROM or extracted any option ROMs.  This is where I
gave my forehead a good slap.  Now, I'm able to build a semi-working
coreboot ROM that I can flash via ISP and a R-Pi.  I can tell that it
almost works because the system seems to boot fine, and I can see the
hostname in the router.  I would probably even be able to SSH in if I
had enabled sshd before the goof-up. The only (fatal) problem is that
the screen is completely blank.  No VGA support, obviously.

So, I'm convinced that if I had the right VGA BIOS option ROM, I could
probably get it to work as desired. I've tried to restore a stock
vendor bios rom to extract the vga bios from, but since I wiped the
hard drive and since I no longer have DVD support via coreboot, 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.

Does anyone here have any pointers or ideas that I could try? Or
perhaps someone has the right rom file laying around they could
kindly share? I've scoured all over the net, and the best I could
find was a mention in the config file of including
"1035_dxvgabios.bin", which seems to have been extracted locally.  I'm
stumped at this point. Any advice would be greatly appreciated.

much thanks,

-kr


From rms at gnu.org  Thu Dec 24 06:47:46 2015
From: rms at gnu.org (Richard Stallman)
Date: Thu, 24 Dec 2015 00:47:46 -0500
Subject: [coreboot] Porting Libreboot to the C201 Chromebook
	(veyron_speedy)
In-Reply-To: <1438593696.2283.29.camel@aldrin> (message from Paul Kocialkowski
 on Mon, 03 Aug 2015 11:21:36 +0200)
References: <1438593696.2283.29.camel@aldrin>
Message-ID: <E1aBykc-0004rB-L6@fencepost.gnu.org>

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The GPU is a Mali T764, on which Luc has been doing some early work to
  > have free software support for it. It is uncertain[0] how long it will
  > take to have an usable free replacement for it, but now that there is
  > that hardware available, free graphics for Mali T GPUs would mean having
  > a recent laptop running fully free software, down to the firmware level,
  > without losing any major hardware feature, something that has hardly
  > ever been achieved yet. Thus, I believe it is of the utmost importance
  > to back Luc up on this,

What support does he need?

  >  even if big players like ARM are trying hard to
  > make Lima not happen and to make it difficult for Luc to keep going.

What is ARM doing to Lima?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.