Lenovo T410 Coreboot
by A. Veek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
5 months, 1 week
ASUS KCMA-D8 workstation board port offer
by Timothy Pearson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
After reviewing some of the comments on the ASUS KGPE-D16 being
essentially too large of a system and too expensive for many people, and
the fact that modern, blob-free systems are not really available in the
mid-range arena, Raptor Engineering would like to offer to create a
native initalization blob-free port for the ASUS KCMA-D8, which is
essentially the KGPE-D16's ATX-compatible "little brother".
We would be asking $15,000 for the port, including upstreaming to the
master coreboot tree. We already have extensive experience with these
Family 10h/15h boards, and would be able to create a port of similar
quality to the existing KGPE-D16 source in terms of both code quality
and overall functionality.
If this is something you might be interested in please let me know. We
are able to accept multiple payments from various sources for the same
project (within limits), so if this is something your local Linux groups
or similar might be interested in we should be able to keep the cost on
any one individual or organization to a reasonable level.
Thank you for your consideration,
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJWQROpAAoJEK+E3vEXDOFbR2cH/3FTqGFH+cU/HVrBUPcoKjii
h9OC7SGeXdyoLZvob/YayG+g47Yppkg2um4pAC7dmGl/OXtkGh13hlsrQ8BNiYcz
g0kQUdNKYh9dmBC3YnlxU6a7psh473TdyuLILrl7/8WgI8DZnRtjy62Oo5k6XAKW
jfYb/bGC8I3tArYrgQDmFxz2dOejuTZit56I+mbWNtvbuQov2BDmrPPMLRuEvG3M
QHCAo/Pjaajzl4rmtrgu0GHcxHsgAnJcnrcPkFYeSDKt7QxSTNOB6NqhcnYdh1SY
RiA5Z/3enuDs+XNhS+6qMeKOcrEuf+Ccs7sGsgq5tWm20JA+bBoByvrXhHqVUxU=
=DKfR
-----END PGP SIGNATURE-----
2 years, 4 months
Re: [coreboot] Where is the first instrucion?
by Alex G.
On 01/10/2016 10:23 AM, ron minnich wrote:
> One thing I think you'd enjoy doing is building the qemu target, setting
> up qemu with gdb, and just watching what happens, instruction by
> instruction, as the system boots.
One exercise I liked doing was to rewrite the entire boot flow, from
reset vector to protected mode entry. Tested on qemu, put it on
hardware, nothing burned.
Alex
> ron
>
> On Sun, Jan 10, 2016 at 3:28 AM Rafael Machado
> <rafaelrodrigues.machado(a)gmail.com
> <mailto:rafaelrodrigues.machado@gmail.com>> wrote:
>
> Hi Peter and Rudolf.
> Thanks for the answers and tips. They are realy helpfull !
> I'll take a look.
>
> Rafael R. Machado
>
>
> Em Sáb, 9 de jan de 2016 17:19, Rudolf Marek <r.marek(a)assembler.cz
> <mailto:r.marek@assembler.cz>> escreveu:
>
> Hi,
>
> I guess your question is more general than the coreboot related
> right?
>
> If you have a firmware image dump of the flash (not the file you
> download from
> board vendor) then yes, first location to be executed is the
> instruction located
> 16 bytes before end of the image.
>
> In coreboot see in build/ bootblock_inc.S which also has
> reset16.inc and
> entry16.inc which is a real start. Consult the Intel or AMD
> manual to see the
> CPU state after reset. The CPU starts in real mode, but CS base
> is shifted to
> last 64KB before end of 4GB address space. In general your CPU
> starts in
> compatible mode with 8086 manufactured in 1978.
>
> Thanks
> Rudolf
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> <mailto:coreboot@coreboot.org>
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
2 years, 10 months
Re: [coreboot] On Intel Boot Guard
by Alexander Couzens
Hi Iru,
we aren't still sure which boards use Intel Boot Guard and which doesn't use it. But we expect most board use it,
because it's "recommended" by intel - as we dont recommend it.
Also there isn't yet a test script for Intel Boot Guard.
Can you post a link to that forum post?
I would like to look into a x240 flash image. If you have such board it would be nice
if you can send me a copy of the flash image via private mail.
Cheers,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)jabber.ccc.de
mobile: +4915123277221
3 years, 1 month
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
by Alex G.
On 01/30/2016 11:30 AM, ron minnich wrote:
> The change to the guidelines is hence a codification of a practice that
> goes back to the project's beginnings.
I find that statement inaccurate. This practice had not been an issue in
the past, on patches that you yourself approved. Mixed syntaxes have
been present in the codebase for a while. See EXHIBIT A.
EXHIBIT B shows a patch, mid last year, when a new intel_syntax code was
introduced. There was only one comment (following) about the syntax. The
patch was approved by you, Ron, without mentioning what you claim has
been a practice.
> Patrick Georgi, Jul 13, 2015
> follow up patch: we don't really want two _syntaxes in one file_, right?
(emphasis added)
The comment clearly addresses the issue of mixing two syntaxes within a
file. It does not mention "a practice that goes back to the project's
beginnings", nor does it mention that either "AT&T syntax is to be used
through-out the project", or "No new Intel syntax code is allowed into
the project."
EXHIBIT C, shows another such patch that, you, have also approved, Ron.
The comment got no replies.
> Ronald G. Minnich, Oct 30 10:43 AM
> why intel syntax _in a file that is att syntax_? it's a real
oportunity for a buggy time.+2'ing because you promised me you're
rewrite it.
(emphasis added)
Notice how the issue here is strictly the mixing of syntaxes within the
same file.
EXHIBIT D shows another such patch, this time approved by me. I have
made a comment about the issue of mixed syntax.
> Alexandru Gagniuc, Jul 17, 2015
> Really? Mixed syntax in the same file?
This also addresses strictly the issue of mixing of syntaxes within the
same file.
EXHIBIT E shows another patch, that you yourself approved. This time,
there was not even a mention of mixed syntaxes.
I conclude from these, that your assertion that this has been an
unspoken rule, is not true. Furthermore, I believe that this arbitrary
change was done as an act of spite towards a set of engineers. Also,
since you, and the rest of the coreboot leadership have shown a pattern
of first discussing changes to the project publicly, on the mailing
list, I conclude that a discussion about this issue was deliberately
avoided in order to prevent those engineers, as well as other coreboot
community members, from presenting their arguments.
Alex
### EXHIBIT A: Presence of .intel_syntax ###
* 4a30ab9 cpu/amd: remove .intel_syntax
* 0302b06 arch/x86: remove .intel_syntax
* c7b2b7c cbfstool: Fix potential error when using hash attribute
$ git reset --hard c7b2b7c67dc8afb52c3dc8e9297e5ed81fa22674
$ git grep intel_syntax
src/arch/x86/boot.c: ".intel_syntax noprefix\n\t"
src/arch/x86/c_start.S:.intel_syntax noprefix
src/arch/x86/wakeup.S: .intel_syntax noprefix
src/cpu/amd/agesa/cache_as_ram.inc: .intel_syntax noprefix
src/cpu/amd/pi/cache_as_ram.inc: .intel_syntax noprefix
### EXHIBIT B: src/arch/x86/[boot.c, c_start.S] ###
$ git blame src/arch/x86/boot.c |grep intel_syntax
9693885a src/arch/x86/boot/boot.c (Stefan Reinauer 2015-06-18 01:23:48
-0700 63) ".intel_syntax noprefix\n\t"
$ git blame src/arch/x86/c_start.S |grep intel_syntax
9693885a src/arch/x86/lib/c_start.S (Stefan Reinauer
2015-06-18 01:23:48 -0700 403) .intel_syntax noprefix
$ git show 9693885a
commit 9693885ad88d21ead7bd9ebc32f3e4901841b18b
Author: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Date: Thu Jun 18 01:23:48 2015 -0700
x86: Port x86 over to compile cleanly with x86-64
Change-Id: I26f1bbf027435be593f11bce4780111dcaf7cb86
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Signed-off-by: Scott Duplichan <scott(a)notabs.org>
Reviewed-on: http://review.coreboot.org/10586
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand
<noreply(a)raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com>
### EXHIBIT C: src/arch/x86/wakeup.S ###
$ git blame src/arch/x86/wakeup.S |grep intel_syntax
ac901e6b src/arch/x86/wakeup.S (Stefan Reinauer 2015-07-31
16:46:28 -0700 32) .intel_syntax noprefix
$ git show ac901e6b
commit ac901e6bedc98d115ebb8089afd8f67aef39c000
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Fri Jul 31 16:46:28 2015 -0700
wakeup: Switch back to 32bit mode first
On x86_64 we need to leave long mode before we can switch to 16bit
mode. Oh joy! When's my 64bit resume pointer coming?
Why didn't this get caught earlier? Seems the Asrock E350M2 didn't
do Suspend/Resume?
Yes, I know it's Intel syntax. Will be converted to AT&T syntax
as soon as the whole thing actually works.. 8)
Change-Id: Ic51869cf67d842041f8842cd9964d72a024c335f
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Reviewed-on: http://review.coreboot.org/11106
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com>
### EXHIBIT D: src/cpu/amd/agesa/cache_as_ram.inc ###
$ git blame src/cpu/amd/agesa/cache_as_ram.inc |grep intel_syntax
67b9430b src/cpu/amd/agesa/cache_as_ram.inc (Stefan Reinauer
2015-06-18 01:14:01 -0700 66) .intel_syntax noprefix
$ git show 67b9430b
commit 67b9430b367a9f9a884043f14365a55b7ef3c45c
Author: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Date: Thu Jun 18 01:14:01 2015 -0700
cpu: port amd/agesa to 64bit
Change-Id: I8644b04f4b57db5fc95ec155d3f78d53c63c9831
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Signed-off-by: Scott Duplichan <scott(a)notabs.org>
Reviewed-on: http://review.coreboot.org/10579
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com>
Tested-by: Raptor Engineering Automated Test Stand
<noreply(a)raptorengineeringinc.com>
### EXHIBIT E: src/cpu/amd/pi/cache_as_ram.inc ###
$ git blame src/cpu/amd/pi/cache_as_ram.inc |grep intel_syntax
f7613eca (Stefan Reinauer 2015-07-21 13:34:01 -0700 67) .intel_syntax
noprefix
$ git show f7613eca
commit f7613ecacc02d486caa868a1f494dc46983aeb3d
Author: Stefan Reinauer <reinauer(a)chromium.org>
Date: Tue Jul 21 13:34:01 2015 -0700
cpu: port amd/pi to 64bit
Change-Id: I66ef081fa1a520f0199366587800783ea1ef8719
Signed-off-by: Stefan Reinauer <stefan.reinauer(a)coreboot.org>
Reviewed-on: http://review.coreboot.org/11023
Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com>
Tested-by: build bot (Jenkins)
3 years, 3 months
berlin coreboot user group meeting 17.02.2016 18:00
by Alexander Couzens
hey,
the next coreboot user group meeting is on 17.02. at 1800 as usual at
club discordia / cccb.
everybody is welcome. I'll take some flasher with me, but it's still a
good idea to send me an email so everything is prepared for your
coreboot installation ;)
best,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
3 years, 3 months
[regression] Increased romstage boot time on ASRock E350M1 (AMD Family 14h)
by Paul Menzel
Dear coreboot folks,
on the ASRock E350M1, I lately noticed that the SeaBIOS banner takes
longer to appear. And looking at the logs board status [1], the time
stamps stored in CBMEM confirm this.
```
$ grep 1st asrock/e350m1/4.2-*/*/coreboot_timestamps.txt
asrock/e350m1/4.2-33-g42444f6/2015-10-30T17:54:28Z/coreboot_timestamps.txt: 0:1st timestamp 368,199
asrock/e350m1/4.2-36-g0ace013/2015-10-31T13:22:12Z/coreboot_timestamps.txt: 0:1st timestamp 368,416
asrock/e350m1/4.2-37-gab35575/2015-10-31T18:23:47Z/coreboot_timestamps.txt: 0:1st timestamp 367,904
asrock/e350m1/4.2-41-g3c47e8a/2015-10-31T20:39:02Z/coreboot_timestamps.txt: 0:1st timestamp 367,829
asrock/e350m1/4.2-42-g0746452/2015-10-31T21:11:04Z/coreboot_timestamps.txt: 0:1st timestamp 368,081
asrock/e350m1/4.2-43-g160ad6a/2015-10-31T21:12:09Z/coreboot_timestamps.txt: 0:1st timestamp 368,290
asrock/e350m1/4.2-44-gbabb2e6/2015-10-31T21:14:48Z/coreboot_timestamps.txt: 0:1st timestamp 368,023
asrock/e350m1/4.2-53-gf6dc544/2015-11-01T13:27:02Z/coreboot_timestamps.txt: 0:1st timestamp 368,470
asrock/e350m1/4.2-58-g65eec4d/2015-11-02T15:41:33Z/coreboot_timestamps.txt: 0:1st timestamp 679,462
asrock/e350m1/4.2-628-g62c0276/2015-12-29T17:17:01Z/coreboot_timestamps.txt: 0:1st timestamp 1,528,198
asrock/e350m1/4.2-701-gb95a074/2016-01-08T01:44:15Z/coreboot_timestamps.txt: 0:1st timestamp 1,298,841
asrock/e350m1/4.2-702-gfecc24a/2016-01-08T16:21:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,489
asrock/e350m1/4.2-703-g8846382/2016-01-09T21:18:59Z/coreboot_timestamps.txt: 0:1st timestamp 1,289,756
```
Unfortunately, there was a time, where I had forgotten to select this
option, so I am still bisecting this.
I thought, it might have been fixed with the commit 4.2-630-g65e33c0
below [1], but it’s not.
```
commit 65e33c08a9a88c52baaadaf515b9591856115a77
Author: Nico Huber <nico.huber(a)secunet.com>
Date: Mon Dec 28 20:17:13 2015 +0100
x86: Align CBFS on top of ROM
Since the introduction of the new (interim?) master header, coreboot
searches the whole ROM for CBFS entries. Fix that by aligning it on top
of the ROM.
Change-Id: I080cd4b746169a36462a49baff5e114b1f6f224a
[…]
```
Do you know, which commit the commit message referred to?
Looking more into it, Nico’s commit was reverted in commit 4.2-673-
g12c55ed [3] and the logic reworked.
```
commit 12c55eda11453ed1e7a24e218338831f67cd5de6
Author: Aaron Durbin <adurbin(a)chromium.org>
Date: Mon Jan 4 13:57:07 2016 -0600
Revert "x86: Align CBFS on top of ROM"
This reverts commit 65e33c08a9a88c52baaadaf515b9591856115a77.
This was the wrong logic to fix the master header.
Change-Id: I4688034831f09ac69abfd0660c76112deabd62ec
[…]
```
If you have any suggestions, please tell me. Otherwise, I’d continue
trying to bisect this.
And unfortunately, I am unable to provide romstage messages, as I still
haven’t got the serial header for the board.
So if somebody else, Stefan, Martin, Kevin, could provide that, that
would be awesome.
Thanks,
Paul
PS: I’ll try to create a ticket for this issue in the bug tracker [4]
this evening.
[1] https://review.coreboot.org/gitweb?p=board-status.git;a=summary
[2] https://review.coreboot.org/12810
[3] https://review.coreboot.org/12824
[4] https://ticket.coreboot.org/
3 years, 3 months
Re: [coreboot] [RFC] Proposal for policy for changing the development guidelines
by Martin Roth
Alex,
Please stop already. We know you don't agree with the decision.
Stefan has agreed privately that he shouldn't have submitted those,
and that it set a bad precedent. As you say in your email, *YOU* even
questioned it when he did it, and he agreed that he would change them
from Intel syntax to AT&T syntax.
The "change" WAS to formalize an unwritten rule that had been broken a
few times in the past. There was significant discussion in several
meetings about the reasons for and against standardizing on AT&T
syntax. Many of us, including myself, learned x86 assembly using
Intel syntax, and find it easier to read. Mixing Intel syntax with
AT&T syntax is just confusing and seems like bad practice. Because of
this, the decision was made to go with AT&T syntax only. It was NOT
done to spite you, whatever you might believe.
If you have a reason for using Intel syntax that is really more
persuasive than keeping the asm code in the project consistent, feel
free to state it. Otherwise, PLEASE let's move on.
Martin
On Sat, Jan 30, 2016 at 5:44 PM, ron minnich <rminnich(a)gmail.com> wrote:
>
>
> On Sat, Jan 30, 2016 at 3:06 PM Alex G. <mr.nuke.me(a)gmail.com> wrote:
>>
>> Furthermore, I believe that this arbitrary
>> change was done as an act of spite towards a set of engineers.
>
>
> Well, wow. This just got weird. I think I'm done with this discussion.
>
> ron
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
3 years, 3 months
[RFC] Proposal for policy for changing the development guidelines
by Paul Menzel
Dear coreboot folks,
I’d like to request for a policy on how the coreboot development
guidelines are changed.
### Background ###
The discussion in patch set #11784 [1] confused me quite a bit.
Especially, seeing Aaron’s quote of the development guidelines I
thought, why is this even discussed.
> https://www.coreboot.org/Development_Guidelines#Assembly_Language states:
> "To keep the code consistent across the different supported
> platforms, AT&T syntax is to be used through-out the project. We are
> working actively on replacing the existing Intel syntax code with
> AT&T syntax. No new Intel syntax code is allowed into the project."
But then, I wondered why I was not aware of that section in the
development guidelines [2], and wanted to read up on it. While at it, I
also looked through the history, and there I see, that it was only
added [3] on the same day.
I thought that editing rights for that page were blocked, because
changes without discussion shouldn’t be made.
Further on, I’d like changes to the development guidelines be announced
in the official forum, which is this mailing list, so that developers,
normally not reading the guidelines every day, are made aware of that.
### Proposal ###
Changes to the development guidelines can only be made, when the
following criteria are met.
1. A proposal of the change was sent to the list tagged with [RFC].
2. The proposal was up for discussion for at least two weeks.
3. If there is no objection, the change can be made.
4. If there is objection, and no agreement can be reached, the
proposal(s) should go up for a vote. The vote period should be at
least one week.
5. Changes have to be announced to the list.
### Past changes ###
No idea, but I’d think it’d be only fair to revert the changes made
this months, and discuss them first.
Thanks,
Paul
[1] https://review.coreboot.org/11784
[2] https://www.coreboot.org/Development_Guidelines#Assembly_Language
[3] https://www.coreboot.org/index.php?title=Development_Guidelines&type=revi...
3 years, 3 months
