From mytbk920423 at gmail.com  Thu Oct  1 05:05:07 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Thu, 1 Oct 2015 13:05:07 +0800
Subject: [coreboot]  Has anyone ported coreboot to ThinkPad T420?
Message-ID: <CALWv5jT3tJn_bX9=sG75DE_-dB4shoiBORB_G9_1ob2M+c0XCQ@mail.gmail.com>

Hi, community

I found Lenovo X220, T420s and T520 have coreboot support, but T420 is not
in the support list. I used the autoport tool in coreboot, and found some
differences(e.g. GPIO) between T420 and the supported models. I think it
should be easy to port it.

I've just disassembled a Lenovo ThinkPad T420, and found a Winbond 25Q64CV
flash after I moved the mainboard out. However, I couldn't read it with my
flash programmer. I don't know if the flash can be read if I try another
programmer or SOIC-8 clip.

Iru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151001/08ffacad/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Oct  1 22:20:41 2015
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 2 Oct 2015 00:20:41 +0200
Subject: [coreboot] Emergency: Talks needed for coreboot conference in Bonn
Message-ID: <560DB1B9.1050004@gmx.net>

Hey everyone,

due to various reasons, a few speakers can't make it to the conference
and thus I have a severe lack of talks and the agenda is starting to
look like swiss cheese (holes everywhere). Admittedly I do love swiss
cheese (so many delicious kinds of cheese), but for a conference agenda
I'd rather like to have less holes.

PLEASE PLEASE if you attend the conference PLEASE consider doing a talk
about something - anything really - even if it's just three slides and
five minutes of talking, followed by lots of discussion from/with the
audience.

Any proposals (title, duration (talk/discussion), name of speaker,
preferred time (morning, noon, afternoon)) are highly appreciated.
PLEASE send them to
<coreboot-conference at bsi.bund.de> ASAP so I can allocate a slot for you.

If you can't come but would be willing to donate slides for someone else
to do a talk on your behalf, PLEASE tell me at
<coreboot-conference at bsi.bund.de> or hit me up on IRC.

Doing talks remotely via a video conference system of your choice is
also an option.

THANK YOU!

Regards,
Carl-Daniel


From no-reply at raptorengineeringinc.com  Thu Oct  1 23:44:46 2015
From: no-reply at raptorengineeringinc.com (Raptor Engineering Automated Coreboot Test Stand)
Date: Thu, 1 Oct 2015 18:44:46 -0500
Subject: [coreboot] ASUS KFSN4-DRE Automated Test Failure
Message-ID: <20151001234445.GA4636@cb-test-ctl>

The ASUS KFSN4-DRE fails verification as of commit 77051f108a88532c13792492d904599c1e453e32

The following tests failed:
BOOT_FAILURE

Commits since last successful test:
77051f1 tegra132/tegra210: remove verstage.c

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: 1443743068-0-automaster.log.bz2
Type: application/octet-stream
Size: 26711 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151001/787cf7e6/attachment-0001.obj>

From tpearson at raptorengineeringinc.com  Fri Oct  2 02:52:16 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Thu, 01 Oct 2015 21:52:16 -0500
Subject: [coreboot] ASUS KFSN4-DRE Automated Test Failure
In-Reply-To: <20151001234445.GA4636@cb-test-ctl>
References: <20151001234445.GA4636@cb-test-ctl>
Message-ID: <560DF160.3070604@raptorengineeringinc.com>

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

On 10/01/2015 06:44 PM, Raptor Engineering Automated Coreboot Test Stand
wrote:
> The ASUS KFSN4-DRE fails verification as of commit 77051f108a88532c13792492d904599c1e453e32
>
> The following tests failed:
> BOOT_FAILURE
>
> Commits since last successful test:
> 77051f1 tegra132/tegra210: remove verstage.c
>
> 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
>

I'm seeing more of these spurious messages, likely due to the DUT
hardware (RAM) beginning to fail.  Diagnostics are under way.

Sorry for the noise!

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

iQEcBAEBAgAGBQJWDfFgAAoJEK+E3vEXDOFbNtQH/iJE+hj+lFiO8jQoGXvu23kA
ngAxvBMY8Ge7wHKWxGIfuKKJYHbU7WFdZ75ZDLr8NBleKQBJwO3RWfZSrDenqKrS
g6BIKBhMRHJlkR+hJmydxDr9GRX2W9aqtfzcCvzpHyQGs93sX9h5gTehvTFX/0Dm
3y4nv/Nsnr+LCXJh1hU7NIjxXJHs5d1Sya2lj2voplgDqb8arwMHBKzLd4TXb05q
KgwRUAP4uh73JvI9ZqZHLC7oW0pyQvPe/GVQnEOD6rlMu9D5QKGjOyvd1T1kJBmF
Ca4Y3dfufQV1Nlg++ZwBN5jgN6sZ74LqjUOJAwDSnCttewo/Qb5NFpEMhiM54zg=
=rd9r
-----END PGP SIGNATURE-----


From dhendrix at google.com  Sat Oct  3 03:43:16 2015
From: dhendrix at google.com (David Hendricks)
Date: Fri, 2 Oct 2015 20:43:16 -0700
Subject: [coreboot] coreboot conference 2015 invitation
In-Reply-To: <201509050312.38145.coreboot-conference@bsi.bund.de>
References: <201509050155.01612.coreboot-conference@bsi.bund.de>
 <201509050312.38145.coreboot-conference@bsi.bund.de>
Message-ID: <CAKOoyUdL5BYnh_hGCVe21eO96MB67Xrf+GEkm-zpsyrFyBxYMA@mail.gmail.com>

Hello Silicon Valley folks,
Since I am not going to Germany this year, I plan to VC in so that I can
participate in the presentations. I figure that if others are interested in
viewing or giving presentations then this might be a good opportunity for a
little get-together.

Germany is 9 hours ahead of us so scheduling will be a bit awkward for
some. I was thinking of booking a conference room somewhere at Google in
Mountain View (likely somewhere close to the Sports Page ;-)). My tentative
plan is to start a Hangout at around 1:00am PDT on Saturday the 10th to
fill in some morning presentation slots in Germany.

Others around the world who wish to participate will be welcome to use our
Hangout, though # of connections is limited. You do not need an account
with Google, I will send the meeting link and accept requests to join.

E-mail me if you're interested in either joining in person or over
Hangouts. I'll add some info on the conference wiki page at
http://coreboot.org/coreboot_conference_Bonn_2015, too.


On Fri, Sep 4, 2015 at 6:12 PM, coreboot conference <
coreboot-conference at bsi.bund.de> wrote:

> Dear vendors, developers, users and interested parties,
>
> my apologies. I accidentally left out users as addressees.
>
> On behalf of the Federal Office for Information Security (BSI) Germany I
> would
> like to invite you to the coreboot conference and developer meeting on
> October 9-11 2015 in Bonn, Germany.
>
> This conference and developer meeting is geared towards manufacturers of
> hardware (processors, chipsets, mainboards and servers/ laptops/ tablets/
> desktops/ appliances) as well as developers of firmware with an interest in
> coreboot and the possibilities it offers as well as (potential) coreboot
> users. Both professionals and hobbyists are invited.
>
> Please see the full text of the invitation at
> http://coreboot.org/coreboot_conference_Bonn_2015
>
> Sincerely,
> Carl-Daniel Hailfinger
> --
> Hailfinger, Carl-Daniel
> _________________________________________
> Section C 13 - Operating System and Application Security
> Federal Office for Information Security (BSI)
>
> Godesberger Allee 185-189
> 53175 Bonn, Germany
> phone:    +49 (0)228 9582-5939
> fax:      +49 (0)228 9582-5400
> e-mail:   coreboot-conference at bsi.bund.de
> internet: www.bsi.bund.de
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151002/8a84a3fc/attachment.html>

From mytbk920423 at gmail.com  Sat Oct  3 12:33:06 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Sat, 3 Oct 2015 20:33:06 +0800
Subject: [coreboot]  coreboot on Lenovo T420
Message-ID: <CALWv5jTiW9xFkJuY3rQ_s9V5gUSjdHFh4O3yidzTXNtc6YmzzQ@mail.gmail.com>

Hi,

I installed coreboot on my Lenovo ThinkPad T420 laptop today, and I'd like
to share some experience and hope some one can solve some issues on it.

First, I built the T420s port and flashed it to the T420 laptop.
Fortunately, the laptop could be brought up and boot to Linux. However,
several USB ports didn't function properly(except the one for EHCI debug)
because of the difference between T420s and T420 model. Now I've checked
and used the code from the result generated from autoport, and all the USB
ports work fine.

However, the devicetree.cb file generated from autoport does not work
properly. I use GRUB payload with native graphic init. When I use the T420s
devicetree.cb, it works fine, but with the autoport devicetree.cb, only the
backlight is on and nothing displays. At last I built a kernel for GRUB
payload, and the kernel handled the display properly, then I reflashed
another ROM with flashrom to unbrick my laptop.

So can some one give me some instruction on devicetree.cb file? And another
thing, how can I submit the code to the coreboot repository? Is symlinks to
another source files allowed in the source tree?

Iru Cai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151003/6643160b/attachment.html>

From zaolin at das-labor.org  Sat Oct  3 12:50:10 2015
From: zaolin at das-labor.org (Zaolin)
Date: Sat, 03 Oct 2015 15:50:10 +0300
Subject: [coreboot] coreboot on Lenovo T420
In-Reply-To: <CALWv5jTiW9xFkJuY3rQ_s9V5gUSjdHFh4O3yidzTXNtc6YmzzQ@das-labor.org>
References: <CALWv5jTiW9xFkJuY3rQ_s9V5gUSjdHFh4O3yidzTXNtc6YmzzQ@das-labor.org>
Message-ID: <1443876610.5454.2.camel@das-labor.org>

Hi Iru Cai,

take a look at this http://review.coreboot.org/#/c/11765/ change.
But beware there can be issues with that port.

Regards Zaolin

> Hi,
> 
> I installed coreboot on my Lenovo ThinkPad T420 laptop today, and I'd
> like to share some experience and hope some one can solve some issues
> on it.
> 
> First, I built the T420s port and flashed it to the T420 laptop.
> Fortunately, the laptop could be brought up and boot to Linux.
> However, several USB ports didn't function properly(except the one
> for EHCI debug) because of the difference between T420s and T420
> model. Now I've checked and used the code from the result generated
> from autoport, and all the USB ports work fine.
> 
> However, the devicetree.cb file generated from autoport does not work
> properly. I use GRUB payload with native graphic init. When I use the
> T420s devicetree.cb, it works fine, but with the autoport
> devicetree.cb, only the backlight is on and nothing displays. At last
> I built a kernel for GRUB payload, and the kernel handled the display
> properly, then I reflashed another ROM with flashrom to unbrick my
> laptop.
> 
> So can some one give me some instruction on devicetree.cb file? And
> another thing, how can I submit the code to the coreboot repository?
> Is symlinks to another source files allowed in the source tree?
> 
> Iru Cai
> 
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-------------- 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/20151003/f6d7e949/attachment.asc>

From peter at stuge.se  Sat Oct  3 13:44:21 2015
From: peter at stuge.se (Peter Stuge)
Date: Sat, 3 Oct 2015 15:44:21 +0200
Subject: [coreboot] coreboot on Lenovo T420
In-Reply-To: <CALWv5jTiW9xFkJuY3rQ_s9V5gUSjdHFh4O3yidzTXNtc6YmzzQ@mail.gmail.com>
References: <CALWv5jTiW9xFkJuY3rQ_s9V5gUSjdHFh4O3yidzTXNtc6YmzzQ@mail.gmail.com>
Message-ID: <20151003134421.32652.qmail@stuge.se>

Hi,

Iru Cai wrote:
> So can some one give me some instruction on devicetree.cb file?

It sounds like it has to be hand-crafted in your case.


> And another thing, how can I submit the code to the coreboot repository?

By creating an account at http://review.coreboot.org/ and pushing
commits there for review by the community.


> Is symlinks to another source files allowed in the source tree?

Not really, no. Is it possible to refactor the code in the reused
files so that it can be used by multiple mainboards more easily?


//Peter


From dhendrix at google.com  Sat Oct  3 19:46:23 2015
From: dhendrix at google.com (David Hendricks)
Date: Sat, 3 Oct 2015 12:46:23 -0700
Subject: [coreboot] coreboot conference 2015 invitation
In-Reply-To: <CAKOoyUdL5BYnh_hGCVe21eO96MB67Xrf+GEkm-zpsyrFyBxYMA@mail.gmail.com>
References: <201509050155.01612.coreboot-conference@bsi.bund.de>
 <201509050312.38145.coreboot-conference@bsi.bund.de>
 <CAKOoyUdL5BYnh_hGCVe21eO96MB67Xrf+GEkm-zpsyrFyBxYMA@mail.gmail.com>
Message-ID: <CAKOoyUdWqoCRG4WzOg_q+sUTX_=A0n8_vzNtCiVFEqjjqB+c5w@mail.gmail.com>

On Fri, Oct 2, 2015 at 8:43 PM, David Hendricks <dhendrix at google.com> wrote:

> Hello Silicon Valley folks,
> Since I am not going to Germany this year, I plan to VC in so that I can
> participate in the presentations. I figure that if others are interested in
> viewing or giving presentations then this might be a good opportunity for a
> little get-together.
>
> Germany is 9 hours ahead of us so scheduling will be a bit awkward for
> some. I was thinking of booking a conference room somewhere at Google in
> Mountain View (likely somewhere close to the Sports Page ;-)). My tentative
> plan is to start a Hangout at around 1:00am PDT on Saturday the 10th to
> fill in some morning presentation slots in Germany.
>
> Others around the world who wish to participate will be welcome to use our
> Hangout, though # of connections is limited. You do not need an account
> with Google, I will send the meeting link and accept requests to join.
>
> E-mail me if you're interested in either joining in person or over
> Hangouts. I'll add some info on the conference wiki page at
> http://coreboot.org/coreboot_conference_Bonn_2015, too.
>

I have updated the wiki page to include notes about videoconferencing and
presentations that are planned for Saturday morning:
http://coreboot.org/Coreboot_conference_Bonn_2015#Saturday

Check there for details and updates.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151003/f5d573fa/attachment-0001.html>

From lynxis at fe80.eu  Sun Oct  4 13:00:37 2015
From: lynxis at fe80.eu (Alexander Couzens)
Date: Sun, 4 Oct 2015 15:00:37 +0200
Subject: [coreboot] Emergency: Talks needed for coreboot conference in
 Bonn
In-Reply-To: <560DB1B9.1050004@gmx.net>
References: <560DB1B9.1050004@gmx.net>
Message-ID: <20151004150037.1d6cceee@lazus.yip>

Hi,

I would like to give a talk about my embedded controller programming.

And beside that, I would like to have a talk/workshop something, to
think about the future/roadmap/vision/roadmap name how you like it.
how coreboot should be in the next year.

Best,
lynxis

On Fri, 2 Oct 2015 00:20:41 +0200
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at jabber.ccc.de
mobile: +4915123277221
-------------- 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/20151004/f239ce9f/attachment.sig>

From rminnich at gmail.com  Sun Oct  4 17:55:28 2015
From: rminnich at gmail.com (ron minnich)
Date: Sun, 04 Oct 2015 17:55:28 +0000
Subject: [coreboot] Emergency: Talks needed for coreboot conference in
	Bonn
In-Reply-To: <20151004150037.1d6cceee@lazus.yip>
References: <560DB1B9.1050004@gmx.net> <20151004150037.1d6cceee@lazus.yip>
Message-ID: <CAP6exYJRqWhw9yt7hn9CtoGvd9JEpy7cSXn2m12TiV=oqYENhg@mail.gmail.com>

BTW, will you be recording. That's something we've lacked in the past.

ron

On Sun, Oct 4, 2015 at 6:02 AM Alexander Couzens <lynxis at fe80.eu> wrote:

> Hi,
>
> I would like to give a talk about my embedded controller programming.
>
> And beside that, I would like to have a talk/workshop something, to
> think about the future/roadmap/vision/roadmap name how you like it.
> how coreboot should be in the next year.
>
> Best,
> lynxis
>
> On Fri, 2 Oct 2015 00:20:41 +0200
> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> --
> Alexander Couzens
>
> mail: lynxis at fe80.eu
> jabber: lynxis at jabber.ccc.de
> mobile: +4915123277221
> --
> 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/20151004/2ddb279e/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Sun Oct  4 20:47:03 2015
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 4 Oct 2015 22:47:03 +0200
Subject: [coreboot] Emergency: Talks needed for coreboot conference in
 Bonn
In-Reply-To: <CAP6exYJRqWhw9yt7hn9CtoGvd9JEpy7cSXn2m12TiV=oqYENhg@mail.gmail.com>
References: <560DB1B9.1050004@gmx.net> <20151004150037.1d6cceee@lazus.yip>
 <CAP6exYJRqWhw9yt7hn9CtoGvd9JEpy7cSXn2m12TiV=oqYENhg@mail.gmail.com>
Message-ID: <56119047.9@gmx.net>

On 04.10.2015 19:55, ron minnich wrote:
> BTW, will you be recording. That's something we've lacked in the past.

Um. I didn't think of that, but I like the idea. Not sure where to get
some good recording equipment this quickly.
Apart from that, it seems like a nice idea, but
- each speaker would have to opt in individually
- public discussions won't be recorded in any case.

regards,
Carl-Daniel


> ron
>
> On Sun, Oct 4, 2015 at 6:02 AM Alexander Couzens <lynxis at fe80.eu> wrote:
>
>> Hi,
>>
>> I would like to give a talk about my embedded controller programming.
>>
>> And beside that, I would like to have a talk/workshop something, to
>> think about the future/roadmap/vision/roadmap name how you like it.
>> how coreboot should be in the next year.
>>
>> Best,
>> lynxis
>>
>> On Fri, 2 Oct 2015 00:20:41 +0200
>> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> --
>> Alexander Couzens
>>
>> mail: lynxis at fe80.eu
>> jabber: lynxis at jabber.ccc.de
>> mobile: +4915123277221
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot



From wangsiyuanbuaa at gmail.com  Mon Oct  5 08:12:45 2015
From: wangsiyuanbuaa at gmail.com (WANG Siyuan)
Date: Mon, 5 Oct 2015 16:12:45 +0800
Subject: [coreboot] We provide stable Bettong code in github
Message-ID: <CAKhuMPmtL9N=YWb4d4wk2kj9rvUvEW0SG8T_BtbWVc4eS_Eyfg@mail.gmail.com>

Hi, all
coreboot is changing all the time and the patches are reabsed when pushed to
community, so it is a little difficult to provide stable Bettong code.
>From now on, AMD provides source code which is validated by QA team.
The code is pushed to github https://github.com/BTDC/coreboot
The version is identified by a tag. All the changes will be pushed to
coreboot
community.

=====
Version: TCMEF1F0        Release Date: 09/29/2015

Changes from last version:
1. Fix external graphics issue.
2. Add board ID support.
3. Support DDR4.
4. Support SD 2.0.
5. Fix Windows 7 S4 issue.
6. Add GPIO, I2C and UART support.
7. Fix the interrupt routine.
8. Restruct PCI interrupt table (C00/C01).
9. Fix DSDT issue.
10. Fix the PCIe lane map.
11. Lower the TOM to give more MMIO space.
12. Add USB device.
13. Set the USB3 port as unremoveable.
14. Update AGESA to CarrizoPI 1.1.0.1.

Yours sincerely,
WANG Siyuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151005/0672e211/attachment.html>

From mytbk920423 at gmail.com  Mon Oct  5 13:49:49 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Mon, 5 Oct 2015 21:49:49 +0800
Subject: [coreboot]  About the USB issue on the Lenovo T420 port
Message-ID: <CALWv5jTxYh+1t8HyoQFXyhQWwEHUiKadUTMss7j9_3tc0vW55Q@mail.gmail.com>

Hi,

I'm using the new Lenovo T420 port on gerrit[1] and found a bug about
USB(in my post on the gerrit page). And just now I found a work around on
this issue.

First I tested a USB disk on the buggy USB port before suspending the
system, it works fine. Then I unplugged the USB disk, suspended my system,
resume, and replugged the disk, the bug occurred. Then I unplugged the
disk, reload the ehci_pci module as follows:

rmmod ehci_pci
modprobe ehci-pci

The I plugged in the USB disk, it worked fine again.

I think the kernel message[2] gives some information about it, because it
gives two different port number on the USB device. But I know almost
nothing about USB, so I'm not sure what's happening.

[1] http://review.coreboot.org/#/c/11765/
[2] see the attached dmesg.log

Iru Cai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151005/1822079c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.log
Type: text/x-log
Size: 10656 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151005/1822079c/attachment-0001.log>

From webmaster at noq2.net  Mon Oct  5 14:38:19 2015
From: webmaster at noq2.net (NOQ2 Webmaster)
Date: Mon, 5 Oct 2015 16:38:19 +0200
Subject: [coreboot] Compiling HowTo?
Message-ID: <56128B5B.2040300@noq2.net>

Hello,

Are there any more detailed descriptions on how to create a coreboot 
image for let?s say Thinkpad x61 or x230? Most of the online guides out 
there just describe the coreboot flashing procedure itself, not how the 
image was compiled before (especially which settings are of importance, 
how to cope with two eeprom chips in x230 - does it suffice to compile / 
flash a 4M image?). Any help appreciated :-)

noq2


From adurbin at google.com  Mon Oct  5 19:25:50 2015
From: adurbin at google.com (Aaron Durbin)
Date: Mon, 5 Oct 2015 14:25:50 -0500
Subject: [coreboot] cbmem fails with `Failed to mmap /dev/mem: Resource
 temporarily unavailable`
In-Reply-To: <CAE2855uj0kvEV3raUCFsizhppU6dsHhXB3K8tO7tfunb0YUTqg@mail.gmail.com>
References: <1443383663.2876.5.camel@users.sourceforge.net>
 <CAE2855u-d7RO080KNz7=3b5OfZ=HJpruho6RcMCUn6KEZC5Jrw@mail.gmail.com>
 <1443598143.2687.107.camel@users.sourceforge.net>
 <CAE2855uj0kvEV3raUCFsizhppU6dsHhXB3K8tO7tfunb0YUTqg@mail.gmail.com>
Message-ID: <CAE2855sE4dwa6seSW9mLqz8MX53tecjz1gAAqx7VBGZnHHHWLw@mail.gmail.com>

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f

That patch added dmi_init() which maintains a persistent dmi mapping.
However, that code used ioremap() as it's mapping. Thus, we have an
uncached-minus PAT entry covering the DMI tables. I'm actually not
sure why they don't just maintain a copy of the tables -- maybe for
eventlog purposes? So that PAT entry will always cause issues w/ cbmem
trying to do brute force 1MiB mappings of /dev/mem.

On Wed, Sep 30, 2015 at 8:50 AM, Aaron Durbin <adurbin at google.com> wrote:
> On Wed, Sep 30, 2015 at 2:29 AM, Paul Menzel
> <paulepanter at users.sourceforge.net> wrote:
>> Dear Aaron,
>>
>>
>> thank you for the quick reply.
>>
>>
>> Am Montag, den 28.09.2015, 09:38 -0500 schrieb Aaron Durbin:
>>> On Sun, Sep 27, 2015 at 2:54 PM, Paul Menzel wrote:
>>
>>> > building a coreboot image for the ASRock E350M1 with the attached
>>> > config, having code coverage enabled, I am unable to run the
>>> > utility `cbmem`.
>>> >
>>> > ```
>>> > $ sudo util/cbmem/cbmem -V -l
>>> > Looking for coreboot table at 0 1048576 bytes.
>>> > Mapping 1MB of physical memory at 0x0 (requested 0x0).
>>> > Found!
>>> >   coreboot table entry 0x11
>>> >     Found forwarding entry.
>>> > Unmapping 1MB of virtual memory at 0xb74b6000.
>>> > Looking for coreboot table at c7f9f000 1048576 bytes.
>>> > Mapping 1MB of physical memory at 0xffffffffc7f9f000 (requested 0xc7f9f000).
>>> >   ... failed.  Mapping 1052671B of physical memory at 0xffffffffc7f9e000.
>>> > Failed to mmap /dev/mem: Resource temporarily unavailable
>>> > ```
>>> >
>>> > Linux complains with the messages below.
>>> >
>>> > ```
>>> > $ dmesg
>>> > [?]
>>> > [  916.233910] x86/PAT: cbmem:2647 conflicting memory types c7f9f000-c809f000 uncached-minus<->write-back
>>> > [  916.233927] x86/PAT: reserve_memtype failed [mem 0xc7f9f000-0xc809efff], track uncached-minus, req write-back
>>> > [?]
>>> > ```
>>> >
>>>
>>> You are going to need to open the /dev/mem file w/ O_SYNC flags
>>> because the kernel is marking that range of memory as uncacheable.
>>> More info can be found here:
>>> https://www.kernel.org/doc/Documentation/x86/pat.txt
>>
>> I totally missed, that besides selecting code coverage, the Linux
>> kernel was updated to version 4.2 in between. Probably they changed
>> some default.
>>
>>     $ uname -a
>>     Linux my-asrocke350m1 4.2.0-1-686-pae #1 SMP Debian 4.2.1-1 (2015-09-25) i686 GNU/Linux
>>
>>> # cat /sys/kernel/debug/x86/pat_memtype_list
>>>
>>> would be helpful
>>
>>     $ sudo more /sys/kernel/debug/x86/pat_memtype_list
>>     PAT memtype list:
>> uncached-minus @ 0xc7fa7000-0xc7fa8000
>> write-back @ 0xc7fb8000-0xc7fbb000
>> write-back @ 0xc7fba000-0xc7fbd000
>
> Interesting. The range you requested isn't listed in here. However,
> the above 3 are which are smack in the middle of region you are
> requesting. I suspect that's where things are falling over. Do you
> know what these are? Are they listed in /proc/iomem ? The best
> visibility we have currently is the e820 below which just has the
> range starting at 0xc7f9d000 through 0xe0000000. There's some weird
> fudging the kernel does around the usable memory boundaries so those
> may not be we coreboot exported. Presumably you have coreboot logs
> from a previous boot not on this kernel? That might provide some
> insight as well.
>
> I should also note I didn't go trolling through the kernel to figure
> out its logic just yet. Just noting what you're finding.
>
>
>> write-combining @ 0xe0040000-0xe0274000
>> write-combining @ 0xe0274000-0xe0474000
>> write-combining @ 0xe0474000-0xe0475000
>> write-combining @ 0xe0478000-0xe0978000
>> uncached-minus @ 0xf0004000-0xf0005000
>> uncached-minus @ 0xf0100000-0xf0140000
>> uncached-minus @ 0xf0140000-0xf0144000
>> uncached-minus @ 0xf0144000-0xf0148000
>> uncached-minus @ 0xf0148000-0xf0149000
>> uncached-minus @ 0xf0149000-0xf014a000
>> uncached-minus @ 0xf014a000-0xf014b000
>> uncached-minus @ 0xf014b000-0xf014c000
>> uncached-minus @ 0xf014b000-0xf014c000
>> uncached-minus @ 0xf014b000-0xf014c000
>> uncached-minus @ 0xf014b000-0xf014c000
>> uncached-minus @ 0xf8088000-0xf8089000
>> uncached-minus @ 0xfed00000-0xfed01000
>> uncached-minus @ 0xfed80000-0xfed81000
>>
>>> along with this:
>>>
>>> $ for i in /sys/firmware/memmap/*; do echo $(cat $i/type $i/start $i/end); done
>>
>>     $ for i in /sys/firmware/memmap/*; do echo $(sudo cat $i/type $i/start $i/end); done
>>     System RAM 0x0 0x9fbff
>>     reserved 0x9fc00 0x9ffff
>>     reserved 0xf0000 0xfffff
>>     System RAM 0x100000 0xc7f9cfff
>>     reserved 0xc7f9d000 0xdfffffff
>>     reserved 0xf8000000 0xfbffffff
>>     System RAM 0x100000000 0x21effffff
>>
>>
>> Thanks,
>>
>> Paul
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot


From maxime.deroucy at gmail.com  Mon Oct  5 22:12:02 2015
From: maxime.deroucy at gmail.com (maxime de Roucy)
Date: Tue, 6 Oct 2015 00:12:02 +0200
Subject: [coreboot] Compiling HowTo?
In-Reply-To: <56128B5B.2040300@noq2.net>
References: <56128B5B.2040300@noq2.net>
Message-ID: <CAJqCpzj31XXtkiKWuL6GGx85L+84qOfduUVyQ8A3Guy04JKmfw@mail.gmail.com>

I made a blog article describing how I built a ROM for my Pcengines APU1.
It's not even near related to the Thinkpad x61 or x230 but it's a start.

http://pelican.craoc.fr/coreboot.html

Regards
Le 5 oct. 2015 4:45 PM, "NOQ2 Webmaster" <webmaster at noq2.net> a ?crit :

> Hello,
>
> Are there any more detailed descriptions on how to create a coreboot image
> for let?s say Thinkpad x61 or x230? Most of the online guides out there
> just describe the coreboot flashing procedure itself, not how the image was
> compiled before (especially which settings are of importance, how to cope
> with two eeprom chips in x230 - does it suffice to compile / flash a 4M
> image?). Any help appreciated :-)
>
> noq2
>
> --
> 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/20151006/d291cf56/attachment.html>

From phcoder at gmail.com  Tue Oct  6 20:36:22 2015
From: phcoder at gmail.com (Vladimir 'phcoder' Serbinenko)
Date: Tue, 06 Oct 2015 20:36:22 +0000
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <55EFDFC6.3080603@gmail.com>
References: <55EFDFC6.3080603@gmail.com>
Message-ID: <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>

Reminder, please write me if you want any of this. Right now only Ron
Minnich and echelon have ordered. I've added pictures at
http://coreboot.org/Coreboot_conference_Bonn_2015

Le Wed, Sep 9, 2015 ? 9:29 AM, Vladimir '?-coder/phcoder' Serbinenko <
phcoder at gmail.com> a ?crit :

> Hello, all. My girlfriend Maria (CC'ed) would like to organize some
> goodies for coreboot meeting. Already available are black T-shirts:
> 2 x M, 8 x L, 1 x XL according to my notes, it's no guarantee, I can't
> double-check now as I'm travelling.
> Expected price is under ?20 for any of items.
> Capacity is limited, first come first serve, respond to this e-mail to
> order.
> What else we can do:
> - White t-shirt
> - white cups
> - colour cups
> - Fridge magnets
> - case for iPhone (indicate which one), not sure which ones are available
> - Beer coaster
> - mouse pad
> - baseball cap
>
> In addition, if you're ok with waiting about a month + delivery time we
> can order:
> - Black t-shirt (other than the sizes mentioned above, or once the stock
> is out)
> - Colour t-shirt over ?20
>
> We're doing it just for fun and to serve the community, the price is
> only to cover our costs.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151006/69de49bd/attachment.html>

From peter at stuge.se  Tue Oct  6 20:54:33 2015
From: peter at stuge.se (Peter Stuge)
Date: Tue, 6 Oct 2015 22:54:33 +0200
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>
References: <55EFDFC6.3080603@gmail.com>
 <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>
Message-ID: <20151006205433.26070.qmail@stuge.se>

Vladimir 'phcoder' Serbinenko wrote:
> Reminder, please write me if you want any of this. Right now only
> Ron Minnich and echelon have ordered. I've added pictures at
> http://coreboot.org/Coreboot_conference_Bonn_2015

The goodies look really great! :) How many cups, plates and magnets
are there?

What's the square thing that isn't a magnet? Coaster or mouse pad?


Thanks

//Peter


From phcoder at gmail.com  Tue Oct  6 21:24:20 2015
From: phcoder at gmail.com (Vladimir 'phcoder' Serbinenko)
Date: Tue, 06 Oct 2015 21:24:20 +0000
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <20151006205433.26070.qmail@stuge.se>
References: <55EFDFC6.3080603@gmail.com>
 <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>
 <20151006205433.26070.qmail@stuge.se>
Message-ID: <CAEaD8JPfUxFc3jbiqD5gKMBFZx5Ae7tt0hn4V5mwrXJms8zFcQ@mail.gmail.com>

Le Tue, Oct 6, 2015 ? 10:55 PM, Peter Stuge <peter at stuge.se> a ?crit :

> Vladimir 'phcoder' Serbinenko wrote:
> > Reminder, please write me if you want any of this. Right now only
> > Ron Minnich and echelon have ordered. I've added pictures at
> > http://coreboot.org/Coreboot_conference_Bonn_2015
>
> The goodies look really great! :) How many cups, plates and magnets
> are there?
>
> Other than the ones already spoken for, I have:
8 L T-shirts
1 XL
3 white cups
1 x Black, yellow, orange and pink cup
6 x plates
3 x baseball cap
9 x magnets
5 x coasters

More is possible to order if I get replies quickly but I will not be able
to get them to the meeting, so we will have to arrange mail delivery.
If I get a reply before Friday we can order hoodies but again, they will
not be available for the conference

> What's the square thing that isn't a magnet? Coaster or mouse pad?
>
> It's coaster


>
> Thanks
>
> //Peter
>
> --
> 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/20151006/30d94c1b/attachment.html>

From peter at stuge.se  Tue Oct  6 21:34:26 2015
From: peter at stuge.se (Peter Stuge)
Date: Tue, 6 Oct 2015 23:34:26 +0200
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <CAEaD8JPfUxFc3jbiqD5gKMBFZx5Ae7tt0hn4V5mwrXJms8zFcQ@mail.gmail.com>
References: <55EFDFC6.3080603@gmail.com>
 <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>
 <20151006205433.26070.qmail@stuge.se>
 <CAEaD8JPfUxFc3jbiqD5gKMBFZx5Ae7tt0hn4V5mwrXJms8zFcQ@mail.gmail.com>
Message-ID: <20151006213426.29462.qmail@stuge.se>

Vladimir 'phcoder' Serbinenko wrote:
> > The goodies look really great! :) How many cups, plates and magnets
> > are there?
> 
> Other than the ones already spoken for, I have:
> 8 L T-shirts
> 1 XL
> 3 white cups
> 1 x Black, yellow, orange and pink cup
> 6 x plates
> 3 x baseball cap
> 9 x magnets
> 5 x coasters

I would like to order 3 plates, 1 white, 1 black, 1 pink cup and 1 magnet.
If you have extra white cups I'll buy those too.

If I don't make it in person I'll ask if someone might courier cash
and goodies on my behalf. Let me know the amount.


Thanks a lot! (Images sell. :)

//Peter


From phcoder at gmail.com  Tue Oct  6 21:44:22 2015
From: phcoder at gmail.com (Vladimir 'phcoder' Serbinenko)
Date: Tue, 06 Oct 2015 21:44:22 +0000
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <20151006213426.29462.qmail@stuge.se>
References: <55EFDFC6.3080603@gmail.com>
 <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>
 <20151006205433.26070.qmail@stuge.se>
 <CAEaD8JPfUxFc3jbiqD5gKMBFZx5Ae7tt0hn4V5mwrXJms8zFcQ@mail.gmail.com>
 <20151006213426.29462.qmail@stuge.se>
Message-ID: <CAEaD8JOtnW9J5ZY1q9KJAWHXUvBhoXUFZBbFf2bhrXni4rHcyA@mail.gmail.com>

>
>
> I would like to order 3 plates, 1 white, 1 black, 1 pink cup and 1 magnet.
>
All reserved for you.

> If you have extra white cups I'll buy those too.
>
> Sorry, only 1 was left before this e-mail.

> If I don't make it in person I'll ask if someone might courier cash
> and goodies on my behalf. Let me know the amount.
>
> I'll send out the final prices on Thursday or Friday.

>
> Thanks a lot! (Images sell. :)
>
> You're welcome.

> //Peter
>
> --
> 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/20151006/79593d6a/attachment.html>

From phcoder at gmail.com  Tue Oct  6 21:53:03 2015
From: phcoder at gmail.com (Vladimir 'phcoder' Serbinenko)
Date: Tue, 06 Oct 2015 21:53:03 +0000
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <CAEaD8JPfUxFc3jbiqD5gKMBFZx5Ae7tt0hn4V5mwrXJms8zFcQ@mail.gmail.com>
References: <55EFDFC6.3080603@gmail.com>
 <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>
 <20151006205433.26070.qmail@stuge.se>
 <CAEaD8JPfUxFc3jbiqD5gKMBFZx5Ae7tt0hn4V5mwrXJms8zFcQ@mail.gmail.com>
Message-ID: <CAEaD8JN2Ofnh656ZcqQ5vM0e2w8ud7k2w-TftHstB8jjEC85qQ@mail.gmail.com>

Currently remaining are:
8 x L T-shirts
1 x XL T-shirts
1 x yellow cup
3 x plates
3 x baseball cap
8 x magnets
5 x coasters
Every item under 20?
Images:
 http://coreboot.org/Coreboot_conference_Bonn_2015
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151006/c4724e56/attachment.html>

From marcj303 at gmail.com  Wed Oct  7 06:20:49 2015
From: marcj303 at gmail.com (Marc Jones)
Date: Wed, 07 Oct 2015 06:20:49 +0000
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <CAEaD8JN2Ofnh656ZcqQ5vM0e2w8ud7k2w-TftHstB8jjEC85qQ@mail.gmail.com>
References: <55EFDFC6.3080603@gmail.com>
 <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>
 <20151006205433.26070.qmail@stuge.se>
 <CAEaD8JPfUxFc3jbiqD5gKMBFZx5Ae7tt0hn4V5mwrXJms8zFcQ@mail.gmail.com>
 <CAEaD8JN2Ofnh656ZcqQ5vM0e2w8ud7k2w-TftHstB8jjEC85qQ@mail.gmail.com>
Message-ID: <CALrs_3hfh60khvigRUS9-y2=Mc4diDTHJyfs-gqiE0mFu88emg@mail.gmail.com>

Hi Vladimir,

I'd love a shirt. See you in a few days.

Marc

On Tue, Oct 6, 2015, 11:53 PM Vladimir 'phcoder' Serbinenko <
phcoder at gmail.com> wrote:

> Currently remaining are:
> 8 x L T-shirts
> 1 x XL T-shirts
> 1 x yellow cup
> 3 x plates
> 3 x baseball cap
> 8 x magnets
> 5 x coasters
> Every item under 20?
> Images:
>  http://coreboot.org/Coreboot_conference_Bonn_2015
> --
> 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/20151007/168b03aa/attachment.html>

From phcoder at gmail.com  Wed Oct  7 08:27:32 2015
From: phcoder at gmail.com (Vladimir 'phcoder' Serbinenko)
Date: Wed, 07 Oct 2015 08:27:32 +0000
Subject: [coreboot] Goodies for Bonn meeting
In-Reply-To: <CALrs_3hfh60khvigRUS9-y2=Mc4diDTHJyfs-gqiE0mFu88emg@mail.gmail.com>
References: <55EFDFC6.3080603@gmail.com>
 <CAEaD8JM=Kb7_aBG0XC6UgNuWKk8ZTVMEDB6Mar5FzExBg8wvQQ@mail.gmail.com>
 <20151006205433.26070.qmail@stuge.se>
 <CAEaD8JPfUxFc3jbiqD5gKMBFZx5Ae7tt0hn4V5mwrXJms8zFcQ@mail.gmail.com>
 <CAEaD8JN2Ofnh656ZcqQ5vM0e2w8ud7k2w-TftHstB8jjEC85qQ@mail.gmail.com>
 <CALrs_3hfh60khvigRUS9-y2=Mc4diDTHJyfs-gqiE0mFu88emg@mail.gmail.com>
Message-ID: <CAEaD8JMyns+S6vkZ8qxL5+odpqJbPq8b-Thg-0Q-eu9e1YA=wg@mail.gmail.com>

Is size L ok for you?

Le Wed, Oct 7, 2015 ? 8:20 AM, Marc Jones <marcj303 at gmail.com> a ?crit :

> Hi Vladimir,
>
> I'd love a shirt. See you in a few days.
>
> Marc
>
> On Tue, Oct 6, 2015, 11:53 PM Vladimir 'phcoder' Serbinenko <
> phcoder at gmail.com> wrote:
>
>> Currently remaining are:
>> 8 x L T-shirts
>> 1 x XL T-shirts
>> 1 x yellow cup
>> 3 x plates
>> 3 x baseball cap
>> 8 x magnets
>> 5 x coasters
>> Every item under 20?
>> Images:
>>  http://coreboot.org/Coreboot_conference_Bonn_2015
>>
> --
>> 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/20151007/1b172a21/attachment.html>

From scan-admin at coverity.com  Fri Oct  9 17:13:40 2015
From: scan-admin at coverity.com (scan-admin at coverity.com)
Date: Fri, 09 Oct 2015 10:13:40 -0700
Subject: [coreboot] New Defects reported by Coverity Scan for coreboot
Message-ID: <5617f5c46e09b_8c05ef330313cc@scan.mail>


Hi,

Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan.

250 new defect(s) introduced to coreboot found with Coverity Scan.
42 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 20 of 250 defect(s)


** CID 1325829:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 148 in htif_interrupt()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 151 in htif_interrupt()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 166 in htif_interrupt()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 167 in htif_interrupt()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 171 in htif_interrupt()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 173 in htif_interrupt()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 177 in htif_interrupt()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 179 in htif_interrupt()
/src/mainboard/emulation/spike-riscv/spike_util.c: 148 in htif_interrupt()
/src/mainboard/emulation/spike-riscv/spike_util.c: 151 in htif_interrupt()
/src/mainboard/emulation/spike-riscv/spike_util.c: 166 in htif_interrupt()
/src/mainboard/emulation/spike-riscv/spike_util.c: 167 in htif_interrupt()
/src/mainboard/emulation/spike-riscv/spike_util.c: 171 in htif_interrupt()
/src/mainboard/emulation/spike-riscv/spike_util.c: 173 in htif_interrupt()
/src/mainboard/emulation/spike-riscv/spike_util.c: 177 in htif_interrupt()
/src/mainboard/emulation/spike-riscv/spike_util.c: 179 in htif_interrupt()


________________________________________________________________________________________________________
*** CID 1325829:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 148 in htif_interrupt()
142     	return 0;
143     
144     	uintptr_t dev = FROMHOST_DEV(fromhost);
145     	uintptr_t cmd = FROMHOST_CMD(fromhost);
146     	uintptr_t data = FROMHOST_DATA(fromhost);
147     
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
148     	sbi_device_message* m = HLS()->device_request_queue_head;
149     	sbi_device_message* prev = 0x0;
150     	unsigned long i, n;
151     	for (i = 0, n = HLS()->device_request_queue_size; i < n; i++) {
152     		/*
153     		if (!supervisor_paddr_valid(m, sizeof(*m))
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 151 in htif_interrupt()
145     	uintptr_t cmd = FROMHOST_CMD(fromhost);
146     	uintptr_t data = FROMHOST_DATA(fromhost);
147     
148     	sbi_device_message* m = HLS()->device_request_queue_head;
149     	sbi_device_message* prev = 0x0;
150     	unsigned long i, n;
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
151     	for (i = 0, n = HLS()->device_request_queue_size; i < n; i++) {
152     		/*
153     		if (!supervisor_paddr_valid(m, sizeof(*m))
154     		&& EXTRACT_FIELD(read_csr(mstatus), MSTATUS_PRV1) != PRV_M)
155     		panic("htif: page fault");
156     		*/
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 166 in htif_interrupt()
160     			m->data = data;
161     
162     			// dequeue from request queue
163     			if (prev)
164     			prev->sbi_private_data = (uintptr_t)next;
165     			else
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
166     			HLS()->device_request_queue_head = next;
167     			HLS()->device_request_queue_size = n-1;
168     			m->sbi_private_data = 0;
169     
170     			// enqueue to response queue
171     			if (HLS()->device_response_queue_tail)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 167 in htif_interrupt()
161     
162     			// dequeue from request queue
163     			if (prev)
164     			prev->sbi_private_data = (uintptr_t)next;
165     			else
166     			HLS()->device_request_queue_head = next;
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
167     			HLS()->device_request_queue_size = n-1;
168     			m->sbi_private_data = 0;
169     
170     			// enqueue to response queue
171     			if (HLS()->device_response_queue_tail)
172     			{
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 171 in htif_interrupt()
165     			else
166     			HLS()->device_request_queue_head = next;
167     			HLS()->device_request_queue_size = n-1;
168     			m->sbi_private_data = 0;
169     
170     			// enqueue to response queue
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
171     			if (HLS()->device_response_queue_tail)
172     			{
173     				HLS()->device_response_queue_tail->sbi_private_data = (uintptr_t)m;
174     			}
175     			else
176     			{
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 173 in htif_interrupt()
167     			HLS()->device_request_queue_size = n-1;
168     			m->sbi_private_data = 0;
169     
170     			// enqueue to response queue
171     			if (HLS()->device_response_queue_tail)
172     			{
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
173     				HLS()->device_response_queue_tail->sbi_private_data = (uintptr_t)m;
174     			}
175     			else
176     			{
177     				HLS()->device_response_queue_head = m;
178     			}
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 177 in htif_interrupt()
171     			if (HLS()->device_response_queue_tail)
172     			{
173     				HLS()->device_response_queue_tail->sbi_private_data = (uintptr_t)m;
174     			}
175     			else
176     			{
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
177     				HLS()->device_response_queue_head = m;
178     			}
179     			HLS()->device_response_queue_tail = m;
180     
181     			// signal software interrupt
182     			set_csr(mip, MIP_SSIP);
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 179 in htif_interrupt()
173     				HLS()->device_response_queue_tail->sbi_private_data = (uintptr_t)m;
174     			}
175     			else
176     			{
177     				HLS()->device_response_queue_head = m;
178     			}
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
179     			HLS()->device_response_queue_tail = m;
180     
181     			// signal software interrupt
182     			set_csr(mip, MIP_SSIP);
183     			return 0;
184     		}
/src/mainboard/emulation/spike-riscv/spike_util.c: 148 in htif_interrupt()
142     	return 0;
143     
144     	uintptr_t dev = FROMHOST_DEV(fromhost);
145     	uintptr_t cmd = FROMHOST_CMD(fromhost);
146     	uintptr_t data = FROMHOST_DATA(fromhost);
147     
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
148     	sbi_device_message* m = HLS()->device_request_queue_head;
149     	sbi_device_message* prev = 0x0;
150     	unsigned long i, n;
151     	for (i = 0, n = HLS()->device_request_queue_size; i < n; i++) {
152     		/*
153     		if (!supervisor_paddr_valid(m, sizeof(*m))
/src/mainboard/emulation/spike-riscv/spike_util.c: 151 in htif_interrupt()
145     	uintptr_t cmd = FROMHOST_CMD(fromhost);
146     	uintptr_t data = FROMHOST_DATA(fromhost);
147     
148     	sbi_device_message* m = HLS()->device_request_queue_head;
149     	sbi_device_message* prev = 0x0;
150     	unsigned long i, n;
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
151     	for (i = 0, n = HLS()->device_request_queue_size; i < n; i++) {
152     		/*
153     		if (!supervisor_paddr_valid(m, sizeof(*m))
154     		&& EXTRACT_FIELD(read_csr(mstatus), MSTATUS_PRV1) != PRV_M)
155     		panic("htif: page fault");
156     		*/
/src/mainboard/emulation/spike-riscv/spike_util.c: 166 in htif_interrupt()
160     			m->data = data;
161     
162     			// dequeue from request queue
163     			if (prev)
164     			prev->sbi_private_data = (uintptr_t)next;
165     			else
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
166     			HLS()->device_request_queue_head = next;
167     			HLS()->device_request_queue_size = n-1;
168     			m->sbi_private_data = 0;
169     
170     			// enqueue to response queue
171     			if (HLS()->device_response_queue_tail)
/src/mainboard/emulation/spike-riscv/spike_util.c: 167 in htif_interrupt()
161     
162     			// dequeue from request queue
163     			if (prev)
164     			prev->sbi_private_data = (uintptr_t)next;
165     			else
166     			HLS()->device_request_queue_head = next;
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
167     			HLS()->device_request_queue_size = n-1;
168     			m->sbi_private_data = 0;
169     
170     			// enqueue to response queue
171     			if (HLS()->device_response_queue_tail)
172     			{
/src/mainboard/emulation/spike-riscv/spike_util.c: 171 in htif_interrupt()
165     			else
166     			HLS()->device_request_queue_head = next;
167     			HLS()->device_request_queue_size = n-1;
168     			m->sbi_private_data = 0;
169     
170     			// enqueue to response queue
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
171     			if (HLS()->device_response_queue_tail)
172     			{
173     				HLS()->device_response_queue_tail->sbi_private_data = (uintptr_t)m;
174     			}
175     			else
176     			{
/src/mainboard/emulation/spike-riscv/spike_util.c: 173 in htif_interrupt()
167     			HLS()->device_request_queue_size = n-1;
168     			m->sbi_private_data = 0;
169     
170     			// enqueue to response queue
171     			if (HLS()->device_response_queue_tail)
172     			{
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
173     				HLS()->device_response_queue_tail->sbi_private_data = (uintptr_t)m;
174     			}
175     			else
176     			{
177     				HLS()->device_response_queue_head = m;
178     			}
/src/mainboard/emulation/spike-riscv/spike_util.c: 177 in htif_interrupt()
171     			if (HLS()->device_response_queue_tail)
172     			{
173     				HLS()->device_response_queue_tail->sbi_private_data = (uintptr_t)m;
174     			}
175     			else
176     			{
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
177     				HLS()->device_response_queue_head = m;
178     			}
179     			HLS()->device_response_queue_tail = m;
180     
181     			// signal software interrupt
182     			set_csr(mip, MIP_SSIP);
/src/mainboard/emulation/spike-riscv/spike_util.c: 179 in htif_interrupt()
173     				HLS()->device_response_queue_tail->sbi_private_data = (uintptr_t)m;
174     			}
175     			else
176     			{
177     				HLS()->device_response_queue_head = m;
178     			}
>>>     CID 1325829:    (UNINIT)
>>>     Using uninitialized value "sp".
179     			HLS()->device_response_queue_tail = m;
180     
181     			// signal software interrupt
182     			set_csr(mip, MIP_SSIP);
183     			return 0;
184     		}

** CID 1325828:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 111 in mcall_dev_resp()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 115 in mcall_dev_resp()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 117 in mcall_dev_resp()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 122 in mcall_dev_resp()
/src/mainboard/emulation/spike-riscv/spike_util.c: 111 in mcall_dev_resp()
/src/mainboard/emulation/spike-riscv/spike_util.c: 115 in mcall_dev_resp()
/src/mainboard/emulation/spike-riscv/spike_util.c: 117 in mcall_dev_resp()
/src/mainboard/emulation/spike-riscv/spike_util.c: 122 in mcall_dev_resp()


________________________________________________________________________________________________________
*** CID 1325828:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 111 in mcall_dev_resp()
105     }
106     
107     uintptr_t mcall_dev_resp(void)
108     {
109     	htif_interrupt(0, 0);
110     
>>>     CID 1325828:    (UNINIT)
>>>     Using uninitialized value "sp".
111     	sbi_device_message* m = HLS()->device_response_queue_head;
112     	if (m) {
113     		//printm("resp %p\n", m);
114     		sbi_device_message* next = (void*)atomic_read(&m->sbi_private_data);
115     		HLS()->device_response_queue_head = next;
116     		if (!next) {
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 115 in mcall_dev_resp()
109     	htif_interrupt(0, 0);
110     
111     	sbi_device_message* m = HLS()->device_response_queue_head;
112     	if (m) {
113     		//printm("resp %p\n", m);
114     		sbi_device_message* next = (void*)atomic_read(&m->sbi_private_data);
>>>     CID 1325828:    (UNINIT)
>>>     Using uninitialized value "sp".
115     		HLS()->device_response_queue_head = next;
116     		if (!next) {
117     			HLS()->device_response_queue_tail = 0;
118     
119     			// only clear SSIP if no other events are pending
120     			clear_csr(mip, MIP_SSIP);
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 117 in mcall_dev_resp()
111     	sbi_device_message* m = HLS()->device_response_queue_head;
112     	if (m) {
113     		//printm("resp %p\n", m);
114     		sbi_device_message* next = (void*)atomic_read(&m->sbi_private_data);
115     		HLS()->device_response_queue_head = next;
116     		if (!next) {
>>>     CID 1325828:    (UNINIT)
>>>     Using uninitialized value "sp".
117     			HLS()->device_response_queue_tail = 0;
118     
119     			// only clear SSIP if no other events are pending
120     			clear_csr(mip, MIP_SSIP);
121     			mb();
122     			if (HLS()->ipi_pending) set_csr(mip, MIP_SSIP);
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 122 in mcall_dev_resp()
116     		if (!next) {
117     			HLS()->device_response_queue_tail = 0;
118     
119     			// only clear SSIP if no other events are pending
120     			clear_csr(mip, MIP_SSIP);
121     			mb();
>>>     CID 1325828:    (UNINIT)
>>>     Using uninitialized value "sp".
122     			if (HLS()->ipi_pending) set_csr(mip, MIP_SSIP);
123     		}
124     	}
125     	return (uintptr_t)m;
126     }
127     
/src/mainboard/emulation/spike-riscv/spike_util.c: 111 in mcall_dev_resp()
105     }
106     
107     uintptr_t mcall_dev_resp(void)
108     {
109     	htif_interrupt(0, 0);
110     
>>>     CID 1325828:    (UNINIT)
>>>     Using uninitialized value "sp".
111     	sbi_device_message* m = HLS()->device_response_queue_head;
112     	if (m) {
113     		//printm("resp %p\n", m);
114     		sbi_device_message* next = (void*)atomic_read(&m->sbi_private_data);
115     		HLS()->device_response_queue_head = next;
116     		if (!next) {
/src/mainboard/emulation/spike-riscv/spike_util.c: 115 in mcall_dev_resp()
109     	htif_interrupt(0, 0);
110     
111     	sbi_device_message* m = HLS()->device_response_queue_head;
112     	if (m) {
113     		//printm("resp %p\n", m);
114     		sbi_device_message* next = (void*)atomic_read(&m->sbi_private_data);
>>>     CID 1325828:    (UNINIT)
>>>     Using uninitialized value "sp".
115     		HLS()->device_response_queue_head = next;
116     		if (!next) {
117     			HLS()->device_response_queue_tail = 0;
118     
119     			// only clear SSIP if no other events are pending
120     			clear_csr(mip, MIP_SSIP);
/src/mainboard/emulation/spike-riscv/spike_util.c: 117 in mcall_dev_resp()
111     	sbi_device_message* m = HLS()->device_response_queue_head;
112     	if (m) {
113     		//printm("resp %p\n", m);
114     		sbi_device_message* next = (void*)atomic_read(&m->sbi_private_data);
115     		HLS()->device_response_queue_head = next;
116     		if (!next) {
>>>     CID 1325828:    (UNINIT)
>>>     Using uninitialized value "sp".
117     			HLS()->device_response_queue_tail = 0;
118     
119     			// only clear SSIP if no other events are pending
120     			clear_csr(mip, MIP_SSIP);
121     			mb();
122     			if (HLS()->ipi_pending) set_csr(mip, MIP_SSIP);
/src/mainboard/emulation/spike-riscv/spike_util.c: 122 in mcall_dev_resp()
116     		if (!next) {
117     			HLS()->device_response_queue_tail = 0;
118     
119     			// only clear SSIP if no other events are pending
120     			clear_csr(mip, MIP_SSIP);
121     			mb();
>>>     CID 1325828:    (UNINIT)
>>>     Using uninitialized value "sp".
122     			if (HLS()->ipi_pending) set_csr(mip, MIP_SSIP);
123     		}
124     	}
125     	return (uintptr_t)m;
126     }
127     

** CID 1325827:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 130 in mcall_hart_id()
/src/mainboard/emulation/spike-riscv/spike_util.c: 130 in mcall_hart_id()


________________________________________________________________________________________________________
*** CID 1325827:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 130 in mcall_hart_id()
124     	}
125     	return (uintptr_t)m;
126     }
127     
128     uintptr_t mcall_hart_id(void)
129     {
>>>     CID 1325827:    (UNINIT)
>>>     Using uninitialized value "sp".
130     	return HLS()->hart_id;
131     }
132     
133     void hls_init(uint32_t hart_id)
134     {
135     	memset(HLS(), 0, sizeof(*HLS()));
/src/mainboard/emulation/spike-riscv/spike_util.c: 130 in mcall_hart_id()
124     	}
125     	return (uintptr_t)m;
126     }
127     
128     uintptr_t mcall_hart_id(void)
129     {
>>>     CID 1325827:    (UNINIT)
>>>     Using uninitialized value "sp".
130     	return HLS()->hart_id;
131     }
132     
133     void hls_init(uint32_t hart_id)
134     {
135     	memset(HLS(), 0, sizeof(*HLS()));

** CID 1325826:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 61 in mcall_send_ipi()
/src/mainboard/emulation/spike-riscv/spike_util.c: 61 in mcall_send_ipi()


________________________________________________________________________________________________________
*** CID 1325826:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 61 in mcall_send_ipi()
55     
56     uintptr_t mcall_send_ipi(uintptr_t recipient)
57     {
58     	//if (recipient >= num_harts)
59     	//return -1;
60     
>>>     CID 1325826:    (UNINIT)
>>>     Using uninitialized value "sp".
61     	if (atomic_swap(&OTHER_HLS(recipient)->ipi_pending, 1) == 0) {
62     		mb();
63     		write_csr(send_ipi, recipient);
64     	}
65     
66     	return 0;
/src/mainboard/emulation/spike-riscv/spike_util.c: 61 in mcall_send_ipi()
55     
56     uintptr_t mcall_send_ipi(uintptr_t recipient)
57     {
58     	//if (recipient >= num_harts)
59     	//return -1;
60     
>>>     CID 1325826:    (UNINIT)
>>>     Using uninitialized value "sp".
61     	if (atomic_swap(&OTHER_HLS(recipient)->ipi_pending, 1) == 0) {
62     		mb();
63     		write_csr(send_ipi, recipient);
64     	}
65     
66     	return 0;

** CID 1325825:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 135 in hls_init()
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 136 in hls_init()
/src/mainboard/emulation/spike-riscv/spike_util.c: 135 in hls_init()
/src/mainboard/emulation/spike-riscv/spike_util.c: 136 in hls_init()


________________________________________________________________________________________________________
*** CID 1325825:    (UNINIT)
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 135 in hls_init()
129     {
130     	return HLS()->hart_id;
131     }
132     
133     void hls_init(uint32_t hart_id)
134     {
>>>     CID 1325825:    (UNINIT)
>>>     Using uninitialized value "sp".
135     	memset(HLS(), 0, sizeof(*HLS()));
136     	HLS()->hart_id = hart_id;
137     }
138     
139     uintptr_t htif_interrupt(uintptr_t mcause, uintptr_t* regs) {
140     	uintptr_t fromhost = swap_csr(mfromhost, 0);
/src/mainboard/emulation/qemu-riscv/qemu_util.c: 136 in hls_init()
130     	return HLS()->hart_id;
131     }
132     
133     void hls_init(uint32_t hart_id)
134     {
135     	memset(HLS(), 0, sizeof(*HLS()));
>>>     CID 1325825:    (UNINIT)
>>>     Using uninitialized value "sp".
136     	HLS()->hart_id = hart_id;
137     }
138     
139     uintptr_t htif_interrupt(uintptr_t mcause, uintptr_t* regs) {
140     	uintptr_t fromhost = swap_csr(mfromhost, 0);
141     	if (!fromhost)
/src/mainboard/emulation/spike-riscv/spike_util.c: 135 in hls_init()
129     {
130     	return HLS()->hart_id;
131     }
132     
133     void hls_init(uint32_t hart_id)
134     {
>>>     CID 1325825:    (UNINIT)
>>>     Using uninitialized value "sp".
135     	memset(HLS(), 0, sizeof(*HLS()));
136     	HLS()->hart_id = hart_id;
137     }
138     
139     uintptr_t htif_interrupt(uintptr_t mcause, uintptr_t* regs) {
140     	uintptr_t fromhost = swap_csr(mfromhost, 0);
/src/mainboard/emulation/spike-riscv/spike_util.c: 136 in hls_init()
130     	return HLS()->hart_id;
131     }
132     
133     void hls_init(uint32_t hart_id)
134     {
135     	memset(HLS(), 0, sizeof(*HLS()));
>>>     CID 1325825:    (UNINIT)
>>>     Using uninitialized value "sp".
136     	HLS()->hart_id = hart_id;
137     }
138     
139     uintptr_t htif_interrupt(uintptr_t mcause, uintptr_t* regs) {
140     	uintptr_t fromhost = swap_csr(mfromhost, 0);
141     	if (!fromhost)

** CID 1302458:  Control flow issues  (DEADCODE)
/src/cpu/amd/model_10xxx/powernow_acpi.c: 75 in write_pstates_for_core()


________________________________________________________________________________________________________
*** CID 1302458:  Control flow issues  (DEADCODE)
/src/cpu/amd/model_10xxx/powernow_acpi.c: 75 in write_pstates_for_core()
69     	/* Write PPC object */
70     	acpigen_write_PPC(pstate_num);
71     
72     	/* Write PSD indicating coordination type */
73     	if ((single_link) && (mctGetLogicalCPUID(0) & AMD_DR_GT_Bx)) {
74     		/* Revision C or greater single-link processor */
>>>     CID 1302458:  Control flow issues  (DEADCODE)
>>>     Execution cannot reach this statement: "cpuid1 = cpuid(-2147483640);".
75     		cpuid1 = cpuid(0x80000008);
76     		acpigen_write_PSD_package(0, (cpuid1.ecx & 0xff) + 1, SW_ALL);
77     	}
78     	else {
79     		/* Find the local APIC ID for the specified core ID */
80     		struct device* cpu;

** CID 1302450:  Security best practices violations  (STRING_OVERFLOW)
/src/drivers/intel/gma/acpi.c: 50 in drivers_intel_gma_displays_ssdt_generate()


________________________________________________________________________________________________________
*** CID 1302450:  Security best practices violations  (STRING_OVERFLOW)
/src/drivers/intel/gma/acpi.c: 50 in drivers_intel_gma_displays_ssdt_generate()
44     		char *ptr;
45     		int kind;
46     		kind = (conf->did[i] >> 8) & 0xf;
47     		if (kind >= ARRAY_SIZE(names)) {
48     			kind = 0;
49     		}
>>>     CID 1302450:  Security best practices violations  (STRING_OVERFLOW)
>>>     You might overrun the 10 byte fixed-size string "name" by copying "names[kind]" without checking the length.
50     		strcpy(name, names[kind]);
51     		for (ptr = name; *ptr; ptr++);
52     		*ptr++ = counters[kind] + '0';
53     		*ptr++ = '\0';
54     		counters[kind]++;
55     		acpigen_write_device(name);

** CID 1300288:  Incorrect expression  (IDENTICAL_BRANCHES)
/src/drivers/xgi/common/vb_setmode.c: 2608 in XGI_GetCRT2Data()


________________________________________________________________________________________________________
*** CID 1300288:  Incorrect expression  (IDENTICAL_BRANCHES)
/src/drivers/xgi/common/vb_setmode.c: 2608 in XGI_GetCRT2Data()
2602     		} else if (pVBInfo->LCDResInfo == Panel_1280x960) {
2603     			tempax = 1280;
2604     			if (pVBInfo->VGAVDE == 350)
2605     				tempbx = 700;
2606     			else if (pVBInfo->VGAVDE == 400)
2607     				tempbx = 800;
>>>     CID 1300288:  Incorrect expression  (IDENTICAL_BRANCHES)
>>>     The same code is executed regardless of whether "pVBInfo->VGAVDE == 1024" is true, because the 'then' and 'else' branches are identical. Should one of the branches be modified, or the entire 'if' statement replaced?
2608     			else if (pVBInfo->VGAVDE == 1024)
2609     				tempbx = 960;
2610     			else
2611     				tempbx = 960;
2612     		} else if (pVBInfo->LCDResInfo == Panel_1400x1050) {
2613     			tempax = 1400;

** CID 1295501:  Null pointer dereferences  (FORWARD_NULL)
/src/soc/broadcom/cygnus/gpio.c: 464 in gpio_get()


________________________________________________________________________________________________________
*** CID 1295501:  Null pointer dereferences  (FORWARD_NULL)
/src/soc/broadcom/cygnus/gpio.c: 464 in gpio_get()
458     {
459     	struct cygnus_gpio *chip;
460     	unsigned gpio_num;
461     
462     	chip = cygnus_get_gpio_core(gpio, &gpio_num);
463     	if (chip == NULL) {
>>>     CID 1295501:  Null pointer dereferences  (FORWARD_NULL)
>>>     Dereferencing null pointer "chip".
464     		dev_dbg(chip, "unable to find chip for gpio %d", gpio);
465     		return -1;
466     	}
467     
468     	return cygnus_gpio_get(chip, gpio_num);
469     }

** CID 1295500:  Control flow issues  (DEADCODE)
/src/soc/broadcom/cygnus/shmoo_and28.c: 4278 in soc_and28_shmoo_ctl()


________________________________________________________________________________________________________
*** CID 1295500:  Control flow issues  (DEADCODE)
/src/soc/broadcom/cygnus/shmoo_and28.c: 4278 in soc_and28_shmoo_ctl()
4272     
4273         if(!stat)
4274         {
4275             scPtr = &shmoo_container;
4276             if(scPtr == NULL)
4277             {
>>>     CID 1295500:  Control flow issues  (DEADCODE)
>>>     Execution cannot reach this statement: "return 4;".
4278                 return SOC_E_MEMORY;
4279             }
4280             sal_memset(scPtr, 0, sizeof(and28_shmoo_container_t));
4281     
4282             if(phy_ndx != SHMOO_AND28_INTERFACE_RSVP)
4283             {

** CID 1295499:  Control flow issues  (DEADCODE)
/src/soc/intel/common/nvm.c: 113 in nvm_is_write_protected()


________________________________________________________________________________________________________
*** CID 1295499:  Control flow issues  (DEADCODE)
/src/soc/intel/common/nvm.c: 113 in nvm_is_write_protected()
107     	}
108     	wp_spi = !!(sr1 & 0x80);
109     
110     	printk(BIOS_DEBUG, "SPI flash protection: WPSW=%d SRP0=%d\n",
111     	       wp_gpio, wp_spi);
112     
>>>     CID 1295499:  Control flow issues  (DEADCODE)
>>>     Execution cannot reach the expression "wp_spi" inside this statement: "return wp_gpio && wp_spi;".
113     	return wp_gpio && wp_spi;
114     }
115     
116     /* Apply protection to a range of flash */
117     int nvm_protect(void *start, size_t size)
118     {

** CID 1295498:  Null pointer dereferences  (FORWARD_NULL)
/src/soc/broadcom/cygnus/gpio.c: 404 in gpio_free()


________________________________________________________________________________________________________
*** CID 1295498:  Null pointer dereferences  (FORWARD_NULL)
/src/soc/broadcom/cygnus/gpio.c: 404 in gpio_free()
398     {
399     	struct cygnus_gpio *chip;
400     	unsigned gpio_num;
401     
402     	chip = cygnus_get_gpio_core(gpio, &gpio_num);
403     	if (chip == NULL) {
>>>     CID 1295498:  Null pointer dereferences  (FORWARD_NULL)
>>>     Dereferencing null pointer "chip".
404     		dev_dbg(chip, "unable to find chip for gpio %d", gpio);
405     		return;
406     	}
407     
408     	cygnus_gpio_free(chip, gpio_num);
409     }

** CID 1295497:  Integer handling issues  (NO_EFFECT)
/src/soc/broadcom/cygnus/i2c.c: 240 in i2c_init()


________________________________________________________________________________________________________
*** CID 1295497:  Integer handling issues  (NO_EFFECT)
/src/soc/broadcom/cygnus/i2c.c: 240 in i2c_init()
234     }
235     
236     void i2c_init(unsigned int bus, unsigned int hz)
237     {
238     	struct cygnus_i2c_regs *regs = i2c_bus[bus];
239     
>>>     CID 1295497:  Integer handling issues  (NO_EFFECT)
>>>     This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "bus >= 0U".
240     	assert(bus >= 0 && bus <= 1);
241     
242     	setbits_le32(&regs->i2c_con, I2C_SMB_RESET);
243     	udelay(100); /* wait 100 usec per spec */
244     	clrbits_le32(&regs->i2c_con, I2C_SMB_RESET);
245     

** CID 1295496:  Null pointer dereferences  (FORWARD_NULL)
/src/soc/broadcom/cygnus/gpio.c: 436 in gpio_input_pulldown()


________________________________________________________________________________________________________
*** CID 1295496:  Null pointer dereferences  (FORWARD_NULL)
/src/soc/broadcom/cygnus/gpio.c: 436 in gpio_input_pulldown()
430     {
431     	struct cygnus_gpio *chip;
432     	unsigned gpio_num;
433     
434     	chip = cygnus_get_gpio_core(gpio, &gpio_num);
435     	if (chip == NULL) {
>>>     CID 1295496:  Null pointer dereferences  (FORWARD_NULL)
>>>     Dereferencing null pointer "chip".
436     		dev_dbg(chip, "unable to find chip for gpio %d", gpio);
437     		return;
438     	}
439     
440     	cygnus_gpio_set_pull(chip, gpio_num, 0, 0);
441     }

** CID 1241910:    (OVERRUN)
/src/vendorcode/amd/agesa/f12/Proc/GNB/Nb/Family/LN/F12NbServices.c: 223 in NbFmFuseAdjustFuseTablePatch()
/src/vendorcode/amd/agesa/f14/Proc/GNB/Nb/Family/0x14/F14NbServices.c: 218 in NbFmFuseAdjustFuseTablePatch()


________________________________________________________________________________________________________
*** CID 1241910:    (OVERRUN)
/src/vendorcode/amd/agesa/f12/Proc/GNB/Nb/Family/LN/F12NbServices.c: 223 in NbFmFuseAdjustFuseTablePatch()
217             if (PpFuseArray->PolicyLabel[SwSatateIndex] == POLICY_LABEL_PERFORMANCE) {
218               break;
219             }
220           }
221           MaxSclkIndex = 0;
222           CurrentSclkDpmDid = 0xff;
>>>     CID 1241910:    (OVERRUN)
>>>     Overrunning array "PpFuseArray->SclkDpmValid" of 6 bytes at byte offset 6 using index "SwSatateIndex" (which evaluates to 6).
223           ASSERT (PpFuseArray->SclkDpmValid[SwSatateIndex] != 0);
224           for (DpmStateIndex = 0; DpmStateIndex < PP_FUSE_MAX_NUM_DPM_STATE; DpmStateIndex++) {
225             if ((PpFuseArray->SclkDpmValid[SwSatateIndex] & (1 << DpmStateIndex)) != 0) {
226               if (PpFuseArray->SclkDpmDid[DpmStateIndex] < CurrentSclkDpmDid) {
227                 CurrentSclkDpmDid = PpFuseArray->SclkDpmDid[DpmStateIndex];
228                 MaxSclkIndex = DpmStateIndex;
/src/vendorcode/amd/agesa/f14/Proc/GNB/Nb/Family/0x14/F14NbServices.c: 218 in NbFmFuseAdjustFuseTablePatch()
212             if (PpFuseArray->PolicyLabel[SwSatateIndex] == POLICY_LABEL_PERFORMANCE) {
213               break;
214             }
215           }
216           MaxSclkIndex = 0;
217           CurrentSclkDpmDid = 0xff;
>>>     CID 1241910:    (OVERRUN)
>>>     Overrunning array "PpFuseArray->SclkDpmValid" of 6 bytes at byte offset 6 using index "SwSatateIndex" (which evaluates to 6).
218           ASSERT (PpFuseArray->SclkDpmValid[SwSatateIndex] != 0);
219           for (DpmStateIndex = 0; DpmStateIndex < PP_FUSE_MAX_NUM_DPM_STATE; DpmStateIndex++) {
220             if ((PpFuseArray->SclkDpmValid[SwSatateIndex] & (1 << DpmStateIndex)) != 0) {
221               if (PpFuseArray->SclkDpmDid[DpmStateIndex] < CurrentSclkDpmDid) {
222                 CurrentSclkDpmDid = PpFuseArray->SclkDpmDid[DpmStateIndex];
223                 MaxSclkIndex = DpmStateIndex;

** CID 1241909:  Null pointer dereferences  (FORWARD_NULL)
/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxIntegratedInfoTableTN.c: 812 in GfxIntInfoTableInitTN()


________________________________________________________________________________________________________
*** CID 1241909:  Null pointer dereferences  (FORWARD_NULL)
/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxIntegratedInfoTableTN.c: 812 in GfxIntInfoTableInitTN()
806       AGESA_STATUS_UPDATE (Status, AgesaStatus);
807       // Assign usFormatID to 0x000B to represent Trinity
808       PpTable->usFormatID = 0xB;
809       // Build info from fuses
810       PpFuseArray = GnbLocateHeapBuffer (AMD_PP_FUSE_TABLE_HANDLE, GnbLibGetHeader (Gfx));
811       ASSERT (PpFuseArray != NULL);
>>>     CID 1241909:  Null pointer dereferences  (FORWARD_NULL)
>>>     Comparing "PpFuseArray" to null implies that "PpFuseArray" might be null.
812       if (PpFuseArray != NULL) {
813         // Build Display clock info
814         GfxIntInfoTableInitDispclkTable (PpFuseArray, &SystemInfoTableV2.sIntegratedSysInfo, Gfx);
815         // Build Sclk info table
816         GfxIntInfoTableInitSclkTable (PpFuseArray, &SystemInfoTableV2.sIntegratedSysInfo, Gfx);
817       } else {

** CID 1241908:    (DEADCODE)
/src/vendorcode/amd/agesa/f16kb/Proc/CPU/cpuMicrocodePatch.c: 151 in LoadMicrocodePatch()
/src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuMicrocodePatch.c: 150 in LoadMicrocodePatch()


________________________________________________________________________________________________________
*** CID 1241908:    (DEADCODE)
/src/vendorcode/amd/agesa/f16kb/Proc/CPU/cpuMicrocodePatch.c: 151 in LoadMicrocodePatch()
145                   }
146                   break; // Once we find a microcode patch that matches the processor, exit the for loop
147                 }
148               }
149             }
150           } else {
>>>     CID 1241908:    (DEADCODE)
>>>     Execution cannot reach the expression "1" inside this statement: "1 ? (VOID)0 : AmdIdsDebugPr...".
151             IDS_HDT_CONSOLE (CPU_TRACE, "  Force Ucode loaded from offset %x\n", ForceLoadMicrocodePatchPtr);
152             if (LoadMicrocode (ForceLoadMicrocodePatchPtr, StdHeader)) {
153               Status = TRUE;
154             } else {
155               PutEventLog (AGESA_ERROR,
156                            CPU_ERROR_MICRO_CODE_PATCH_IS_NOT_LOADED,
/src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuMicrocodePatch.c: 150 in LoadMicrocodePatch()
144                   }
145                   break; // Once we find a microcode patch that matches the processor, exit the for loop
146                 }
147               }
148             }
149           } else {
>>>     CID 1241908:    (DEADCODE)
>>>     Execution cannot reach this statement: "if (LoadMicrocode(ForceLoad...".
150             if (LoadMicrocode (ForceLoadMicrocodePatchPtr, StdHeader)) {
151               Status = TRUE;
152             } else {
153               PutEventLog (AGESA_ERROR,
154                            CPU_ERROR_MICRO_CODE_PATCH_IS_NOT_LOADED,
155                            0, 0, 0, 0, StdHeader);

** CID 1241907:  Memory - corruptions  (ARRAY_VS_SINGLETON)
/src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbSmuLibV7/GnbSmuInitLibV7.c: 258 in GnbSmuFirmwareLoadV7()


________________________________________________________________________________________________________
*** CID 1241907:  Memory - corruptions  (ARRAY_VS_SINGLETON)
/src/vendorcode/amd/agesa/f16kb/Proc/GNB/Modules/GnbSmuLibV7/GnbSmuInitLibV7.c: 258 in GnbSmuFirmwareLoadV7()
252     
253       // Step5, 12, Load firmware
254       IDS_HDT_CONSOLE (GNB_TRACE, "Step5, 12, Load firmware\n");
255       // 4 means byte length of next address during firmware download
256       UraTuple.StepLength = 4;
257       UraTuple.Value = (UINT32) ((UINTN) (Firmware));
>>>     CID 1241907:  Memory - corruptions  (ARRAY_VS_SINGLETON)
>>>     Taking address with "&UraTuple" yields a singleton pointer.
258       GnbUraCombinedSet (&DevObject, TRxSmuRamStartAddr | GNB_URA_STREAM_SET, &UraTuple, (Firmware->ImageSize >> 2));
259     
260       if (BfxSmuProtectedMode == 0) {
261         IDS_HDT_CONSOLE (GNB_TRACE, "Step6, write jmp to RAM firmware\n");
262         //Step 6, Write jmp to RAM firmware
263         RxSmuRamStartAddr = 0xE0000000 + ((SMC_RAM_START_ADDR + Firmware->HeaderSize) >> 2);

** CID 1241906:    (ARRAY_VS_SINGLETON)
/src/vendorcode/amd/agesa/f14/Proc/CPU/cpuApicUtilities.c: 1010 in ApUtilTransmitBuffer()
/src/vendorcode/amd/agesa/f12/Proc/CPU/cpuApicUtilities.c: 961 in ApUtilTransmitBuffer()
/src/vendorcode/amd/agesa/f16kb/Proc/CPU/cpuApicUtilities.c: 966 in ApUtilTransmitBuffer()
/src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuApicUtilities.c: 966 in ApUtilTransmitBuffer()
/src/vendorcode/amd/agesa/f15/Proc/CPU/cpuApicUtilities.c: 967 in ApUtilTransmitBuffer()


________________________________________________________________________________________________________
*** CID 1241906:    (ARRAY_VS_SINGLETON)
/src/vendorcode/amd/agesa/f14/Proc/CPU/cpuApicUtilities.c: 1010 in ApUtilTransmitBuffer()
1004       ApUtilWriteDataDword (BufferInfo->DataTransferFlags, StdHeader);
1005     
1006       ApUtilWriteControlByte (CORE_DATA_FLAGS_READY, StdHeader);
1007       WaitForStatus.WaitForStatusFlags = 0;
1008       ApUtilWaitForCoreStatus (Socket, Core, &WaitForStatus, StdHeader);
1009       if ((BufferInfo->DataTransferFlags & DATA_IN_MEMORY) != 0) {
>>>     CID 1241906:    (ARRAY_VS_SINGLETON)
>>>     Taking address with "&BufferInfo->DataPtr" yields a singleton pointer.
1010         ApUtilTransmitPointer (Socket, Core, (VOID **) &BufferInfo->DataPtr, StdHeader);
1011       } else {
1012         ApUtilWriteControlByte (CORE_STS_DATA_READY_1, StdHeader);
1013         CurrentStatus = CORE_STS_DATA_READY_0;
1014         WaitForStatus.Status = &CurrentStatus;
1015         WaitForStatus.WaitForStatusFlags = WAIT_STATUS_EQUALITY;
/src/vendorcode/amd/agesa/f12/Proc/CPU/cpuApicUtilities.c: 961 in ApUtilTransmitBuffer()
955       ApUtilWriteDataDword (BufferInfo->DataTransferFlags, StdHeader);
956     
957       ApUtilWriteControlByte (CORE_DATA_FLAGS_READY, StdHeader);
958       WaitForStatus.WaitForStatusFlags = 0;
959       ApUtilWaitForCoreStatus (TargetApicId, &WaitForStatus, StdHeader);
960       if ((BufferInfo->DataTransferFlags & DATA_IN_MEMORY) != 0) {
>>>     CID 1241906:    (ARRAY_VS_SINGLETON)
>>>     Taking address with "&BufferInfo->DataPtr" yields a singleton pointer.
961         ApUtilTransmitPointer (TargetApicId, (VOID **) &BufferInfo->DataPtr, StdHeader);
962       } else {
963         ApUtilWriteControlByte (CORE_STS_DATA_READY_1, StdHeader);
964         CurrentStatus = CORE_STS_DATA_READY_0;
965         WaitForStatus.Status = &CurrentStatus;
966         WaitForStatus.WaitForStatusFlags = WAIT_STATUS_EQUALITY;
/src/vendorcode/amd/agesa/f16kb/Proc/CPU/cpuApicUtilities.c: 966 in ApUtilTransmitBuffer()
960       ApUtilWriteDataDword (BufferInfo->DataTransferFlags, StdHeader);
961     
962       ApUtilWriteControlByte (CORE_DATA_FLAGS_READY, StdHeader);
963       WaitForStatus.WaitForStatusFlags = 0;
964       ApUtilWaitForCoreStatus (TargetApicId, &WaitForStatus, StdHeader);
965       if ((BufferInfo->DataTransferFlags & DATA_IN_MEMORY) != 0) {
>>>     CID 1241906:    (ARRAY_VS_SINGLETON)
>>>     Taking address with "&BufferInfo->DataPtr" yields a singleton pointer.
966         ApUtilTransmitPointer (TargetApicId, (VOID **) &BufferInfo->DataPtr, StdHeader);
967       } else {
968         ApUtilWriteControlByte (CORE_STS_DATA_READY_1, StdHeader);
969         CurrentStatus = CORE_STS_DATA_READY_0;
970         WaitForStatus.Status = &CurrentStatus;
971         WaitForStatus.WaitForStatusFlags = WAIT_STATUS_EQUALITY;
/src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuApicUtilities.c: 966 in ApUtilTransmitBuffer()
960       ApUtilWriteDataDword (BufferInfo->DataTransferFlags, StdHeader);
961     
962       ApUtilWriteControlByte (CORE_DATA_FLAGS_READY, StdHeader);
963       WaitForStatus.WaitForStatusFlags = 0;
964       ApUtilWaitForCoreStatus (TargetApicId, &WaitForStatus, StdHeader);
965       if ((BufferInfo->DataTransferFlags & DATA_IN_MEMORY) != 0) {
>>>     CID 1241906:    (ARRAY_VS_SINGLETON)
>>>     Taking address with "&BufferInfo->DataPtr" yields a singleton pointer.
966         ApUtilTransmitPointer (TargetApicId, (VOID **) &BufferInfo->DataPtr, StdHeader);
967       } else {
968         ApUtilWriteControlByte (CORE_STS_DATA_READY_1, StdHeader);
969         CurrentStatus = CORE_STS_DATA_READY_0;
970         WaitForStatus.Status = &CurrentStatus;
971         WaitForStatus.WaitForStatusFlags = WAIT_STATUS_EQUALITY;
/src/vendorcode/amd/agesa/f15/Proc/CPU/cpuApicUtilities.c: 967 in ApUtilTransmitBuffer()
961       ApUtilWriteDataDword (BufferInfo->DataTransferFlags, StdHeader);
962     
963       ApUtilWriteControlByte (CORE_DATA_FLAGS_READY, StdHeader);
964       WaitForStatus.WaitForStatusFlags = 0;
965       ApUtilWaitForCoreStatus (TargetApicId, &WaitForStatus, StdHeader);
966       if ((BufferInfo->DataTransferFlags & DATA_IN_MEMORY) != 0) {
>>>     CID 1241906:    (ARRAY_VS_SINGLETON)
>>>     Taking address with "&BufferInfo->DataPtr" yields a singleton pointer.
967         ApUtilTransmitPointer (TargetApicId, (VOID **) &BufferInfo->DataPtr, StdHeader);
968       } else {
969         ApUtilWriteControlByte (CORE_STS_DATA_READY_1, StdHeader);
970         CurrentStatus = CORE_STS_DATA_READY_0;
971         WaitForStatus.Status = &CurrentStatus;
972         WaitForStatus.WaitForStatusFlags = WAIT_STATUS_EQUALITY;

** CID 1241905:    (BAD_SHIFT)
/src/vendorcode/amd/agesa/f15/Proc/Mem/Ps/mp.c: 1149 in MemPCheckTblDrvOverrideConfig()
/src/vendorcode/amd/agesa/f15tn/Proc/Mem/Ps/mp.c: 1143 in MemPCheckTblDrvOverrideConfig()
/src/vendorcode/amd/agesa/f16kb/Proc/Mem/Ps/mp.c: 1154 in MemPCheckTblDrvOverrideConfig()


________________________________________________________________________________________________________
*** CID 1241905:    (BAD_SHIFT)
/src/vendorcode/amd/agesa/f15/Proc/Mem/Ps/mp.c: 1149 in MemPCheckTblDrvOverrideConfig()
1143     
1144       CurrentChannel = NBPtr->ChannelPtr;
1145     
1146       // Get platform configuration.
1147       MaxDimmPerCh = GetMaxDimmsPerChannel (NBPtr->RefPtr->PlatformMemoryConfiguration, NBPtr->MCTPtr->SocketId, CurrentChannel->ChannelID);
1148       CurDDRrate = (UINT32) (1 << (CurrentChannel->DCTPtr->Timings.Speed / 66));
>>>     CID 1241905:    (BAD_SHIFT)
>>>     In expression "1 << ((NBPtr->RefPtr->DDR3Voltage == VOLT1_5) ? 0 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_35) ? 1 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_25) ? 2 : 255)))", left shifting by more than 31 bits has undefined behavior.  The shift amount, "(NBPtr->RefPtr->DDR3Voltage == VOLT1_5) ? 0 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_35) ? 1 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_25) ? 2 : 255))", is 255.
1149       DDR3Voltage = (UINT8) (1 << CONVERT_VDDIO_TO_ENCODED (NBPtr->RefPtr->DDR3Voltage));
1150       RankTypeOfPopulatedDimm = MemAGetPsRankType (CurrentChannel);
1151     
1152       if ((MaxDimmPerCh == Buffer[0]) && ((DDR3Voltage & Buffer[1]) != 0) &&
1153         ((CurDDRrate & *(UINT32 *)&Buffer[2]) != 0) && ((RankTypeOfPopulatedDimm & *(UINT16 *)&Buffer[6]) != 0)) {
1154         return TRUE;
/src/vendorcode/amd/agesa/f15tn/Proc/Mem/Ps/mp.c: 1143 in MemPCheckTblDrvOverrideConfig()
1137     
1138       CurrentChannel = NBPtr->ChannelPtr;
1139     
1140       // Get platform configuration.
1141       MaxDimmPerCh = GetMaxDimmsPerChannel (NBPtr->RefPtr->PlatformMemoryConfiguration, NBPtr->MCTPtr->SocketId, CurrentChannel->ChannelID);
1142       CurDDRrate = (UINT32) (1 << (CurrentChannel->DCTPtr->Timings.Speed / 66));
>>>     CID 1241905:    (BAD_SHIFT)
>>>     In expression "1 << ((NBPtr->RefPtr->DDR3Voltage == VOLT1_5) ? 0 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_35) ? 1 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_25) ? 2 : 255)))", left shifting by more than 31 bits has undefined behavior.  The shift amount, "(NBPtr->RefPtr->DDR3Voltage == VOLT1_5) ? 0 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_35) ? 1 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_25) ? 2 : 255))", is 255.
1143       DDR3Voltage = (UINT8) (1 << CONVERT_VDDIO_TO_ENCODED (NBPtr->RefPtr->DDR3Voltage));
1144       RankTypeOfPopulatedDimm = MemAGetPsRankType (CurrentChannel);
1145     
1146       if ((MaxDimmPerCh == Buffer[0]) && ((DDR3Voltage & Buffer[1]) != 0) &&
1147         ((CurDDRrate & *(UINT32 *)&Buffer[2]) != 0) && ((RankTypeOfPopulatedDimm & *(UINT16 *)&Buffer[6]) != 0)) {
1148         return TRUE;
/src/vendorcode/amd/agesa/f16kb/Proc/Mem/Ps/mp.c: 1154 in MemPCheckTblDrvOverrideConfig()
1148     
1149       CurrentChannel = NBPtr->ChannelPtr;
1150     
1151       // Get platform configuration.
1152       MaxDimmPerCh = GetMaxDimmsPerChannel (NBPtr->RefPtr->PlatformMemoryConfiguration, NBPtr->MCTPtr->SocketId, CurrentChannel->ChannelID);
1153       CurDDRrate = (UINT32) (1 << (CurrentChannel->DCTPtr->Timings.Speed / 66));
>>>     CID 1241905:    (BAD_SHIFT)
>>>     In expression "1 << ((NBPtr->RefPtr->DDR3Voltage == VOLT1_5) ? 0 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_35) ? 1 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_25) ? 2 : 255)))", left shifting by more than 31 bits has undefined behavior.  The shift amount, "(NBPtr->RefPtr->DDR3Voltage == VOLT1_5) ? 0 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_35) ? 1 : ((NBPtr->RefPtr->DDR3Voltage == VOLT1_25) ? 2 : 255))", is 255.
1154       DDR3Voltage = (UINT8) (1 << CONVERT_VDDIO_TO_ENCODED (NBPtr->RefPtr->DDR3Voltage));
1155       RankTypeOfPopulatedDimm = MemAGetPsRankType (CurrentChannel);
1156     
1157       if ((MaxDimmPerCh == Buffer[0]) && ((DDR3Voltage & Buffer[1]) != 0) &&
1158         ((CurDDRrate & *(UINT32 *)&Buffer[2]) != 0) && ((RankTypeOfPopulatedDimm & *(UINT16 *)&Buffer[6]) != 0)) {
1159         return TRUE;


________________________________________________________________________________________________________
To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/coreboot?tab=overview

To manage Coverity Scan email notifications for "coreboot at coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&token=49533df725f93b78361afb7b89ccde93



From pgeorgi at google.com  Sun Oct 11 15:35:50 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Sun, 11 Oct 2015 17:35:50 +0200
Subject: [coreboot] RFC: draft policy for accepting blob contributions to
	3rdparty/blobs
Message-ID: <CAE-gjdXZsFG3bJ4JqWVdgfJov8vYU7LN0L4qrhvME3Ui5RiKhQ@mail.gmail.com>

Hi all,

on the coreboot conference, we discussed a draft of a policy for
inclusion of binaries into the 3rdparty/blobs repository.

If binaries are required, we want them redistributable in
3rdparty/blobs to make users' lives easier, and make it possible to
deal with them as good as it is possible with binaries.
Having clear rules should also make it easier for the developers at
vendors who try to maintain these binaries - no more back-and-forth on
gerrit that some more documentation is necessary and so on.
Other rules are simply necessary (eg. a license allowing
redistribution) for practical reasons.

This doesn't mean we encourage the use of binaries, and to use them,
because they still need to be integrated through code in the coreboot
repository.

The current draft can be found at
https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTCrOwU/edit,
and is open for comments.

The idea is to instate this policy (or something like this) once we
found agreement. We can still revise the policy over time.


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


From mr.nuke.me at gmail.com  Sun Oct 11 18:27:29 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Sun, 11 Oct 2015 11:27:29 -0700
Subject: [coreboot] RFC: draft policy for accepting blob contributions
 to 3rdparty/blobs
In-Reply-To: <CAE-gjdXZsFG3bJ4JqWVdgfJov8vYU7LN0L4qrhvME3Ui5RiKhQ@mail.gmail.com>
References: <CAE-gjdXZsFG3bJ4JqWVdgfJov8vYU7LN0L4qrhvME3Ui5RiKhQ@mail.gmail.com>
Message-ID: <561AAA11.1000807@gmail.com>

Hi all,

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

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

Alex

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


From echelon at free.fr  Mon Oct 12 08:43:37 2015
From: echelon at free.fr (echelon at free.fr)
Date: Mon, 12 Oct 2015 10:43:37 +0200 (CEST)
Subject: [coreboot] Item lost during coreboot conference in Bonn
Message-ID: <1680952437.83109210.1444639417669.JavaMail.root@zimbra6-e1.priv.proxad.net>

Hello,
During the coreboot meeting I lent a AMD CPU with socket AM2 to someone in the hacking room to do some tests. It seems to me that this item is missing in my packs. I think that the person which borrowed this CPU from me was sitting in front of me in the hacking room close to Vladimir (maybe Patrick or Nicholas?..), that is at the range of tables which were placed on the left side of the hacking room when looking from the conference room.
I'm sorry to annoy you with this thing, but this item is quite important for me. Can you check if you still have it and contact me?
Thanks a lot beforehand!
 Florentin Demetrescu


From marcj303 at gmail.com  Mon Oct 12 09:08:28 2015
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 12 Oct 2015 09:08:28 +0000
Subject: [coreboot] RFC: draft policy for accepting blob contributions
	to 3rdparty/blobs
In-Reply-To: <561AAA11.1000807@gmail.com>
References: <CAE-gjdXZsFG3bJ4JqWVdgfJov8vYU7LN0L4qrhvME3Ui5RiKhQ@mail.gmail.com>
 <561AAA11.1000807@gmail.com>
Message-ID: <CALrs_3gzBc8BDmLfpoOuYmM0KSLS=aYJtoo0fTxdzm6UgxQe7A@mail.gmail.com>

Hi all,

Thanks for the comments. The conference discussion was very helpful. We'll
work on this  when I land in Denver and vet it posted asap. This should
make it clear to vendors and easier on the community to review.

Thanks Patrick, Stefan, Carl-Daniel, and everyone else at the conference
for the feedback.

Regards,
Marc

On Sun, Oct 11, 2015, 8:28 PM Alex G. <mr.nuke.me at gmail.com> wrote:

> Hi all,
>
> I like that we're talking about a policy, but I really feel the policy,
> as written right now, is specific to ISA blobs, and some of the points
> do not map very well to non-ISA blobs. I've made some inline comments om
> that.
>
> A point about ISA blobs and their licensing, is that whatever legalese
> they come with should not have restrictive clauses. E.g:
>     - no-reverse-engineering/decompilation clause(s)
>     - no-modification clause(s)
>     - only-use-on-<vendorname>-hardware clause(s)
> Abstracting the lack of source code, any clause which is incompatible
> with the freedoms afforded by the GPL should be rejected. I realize this
> sets a high bar, but I think protecting our contributors who do exactly
> the things I've exemplified should take priority.
>
> Alex
>
> On 10/11/2015 08:35 AM, Patrick Georgi wrote:
> > Hi all,
> >
> > on the coreboot conference, we discussed a draft of a policy for
> > inclusion of binaries into the 3rdparty/blobs repository.
> >
> > If binaries are required, we want them redistributable in
> > 3rdparty/blobs to make users' lives easier, and make it possible to
> > deal with them as good as it is possible with binaries.
> > Having clear rules should also make it easier for the developers at
> > vendors who try to maintain these binaries - no more back-and-forth on
> > gerrit that some more documentation is necessary and so on.
> > Other rules are simply necessary (eg. a license allowing
> > redistribution) for practical reasons.
> >
> > This doesn't mean we encourage the use of binaries, and to use them,
> > because they still need to be integrated through code in the coreboot
> > repository.
> >
> > The current draft can be found at
> >
> https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTCrOwU/edit
> ,
> > and is open for comments.
> >
> > The idea is to instate this policy (or something like this) once we
> > found agreement. We can still revise the policy over time.
> >
> >
> > Patrick
> >
>
> --
> coreboot mailing list: coreboot 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/20151012/e26a5597/attachment.html>

From echelon at free.fr  Mon Oct 12 17:06:55 2015
From: echelon at free.fr (echelon at free.fr)
Date: Mon, 12 Oct 2015 19:06:55 +0200 (CEST)
Subject: [coreboot] =?utf-8?q?Re=C2=A0=3A__Item_lost_during_coreboot_confe?=
 =?utf-8?q?rence_in_Bonn?=
In-Reply-To: <1680952437.83109210.1444639417669.JavaMail.root@zimbra6-e1.priv.proxad.net>
Message-ID: <1530093221.84252955.1444669615396.JavaMail.root@zimbra6-e1.priv.proxad.net>

My bad! the cpu was inside his socket right onto the board!.. Please forget my request (I really need to have some sleep now!..)
By the way, if you have old amd cpus (or apus) for sale, please let me know, i'm intersted.
 Florentin

----- Mail d'origine -----
De: echelon at free.fr
?: Coreboot <coreboot at coreboot.org>
Envoy?: Mon, 12 Oct 2015 10:43:37 +0200 (CEST)
Objet: [coreboot] Item lost during coreboot conference in Bonn

Hello,
During the coreboot meeting I lent a AMD CPU with socket AM2 to someone in the hacking room to do some tests. It seems to me that this item is missing in my packs. I think that the person which borrowed this CPU from me was sitting in front of me in the hacking room close to Vladimir (maybe Patrick or Nicholas?..), that is at the range of tables which were placed on the left side of the hacking room when looking from the conference room.
I'm sorry to annoy you with this thing, but this item is quite important for me. Can you check if you still have it and contact me?
Thanks a lot beforehand!
 Florentin Demetrescu

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



From david.guckian at intel.com  Mon Oct 12 17:55:58 2015
From: david.guckian at intel.com (Guckian, David)
Date: Mon, 12 Oct 2015 17:55:58 +0000
Subject: [coreboot] Rangeley SoC FSP and Mohon Peak board support
Message-ID: <EBFDAB01CECF7F49957DBFF067E4F797435E038B@IRSMSX108.ger.corp.intel.com>

Hi,

I saw recently that Rangeley SoC FSP and Mohon Peak board support has been removed from Coreboot.
One of the reasons for the removal is that this is not used by anyone.
That is not the case as there are users of this SoC and board.
I have tested out a patch on Mohon Peak that will enable us to easily integrate with the latest microcode infrastructure.
Going forward I can be the maintainer for Rangeley / Mohon Peak.
I would like to work with the community to get this code added back in to Coreboot.
A patch will be forthcoming in gerrit for your review.
Thanks.

Regards,
David


--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

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

From mr.nuke.me at gmail.com  Tue Oct 13 04:13:40 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Mon, 12 Oct 2015 21:13:40 -0700
Subject: [coreboot] Rangeley SoC FSP and Mohon Peak board support
In-Reply-To: <EBFDAB01CECF7F49957DBFF067E4F797435E038B@IRSMSX108.ger.corp.intel.com>
References: <EBFDAB01CECF7F49957DBFF067E4F797435E038B@IRSMSX108.ger.corp.intel.com>
Message-ID: <561C84F4.7030901@gmail.com>

Hi David,

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

Alex

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

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


From lynxis at fe80.eu  Tue Oct 13 10:08:29 2015
From: lynxis at fe80.eu (Alexander Couzens)
Date: Tue, 13 Oct 2015 12:08:29 +0200
Subject: [coreboot] Rangeley SoC FSP and Mohon Peak board support
In-Reply-To: <EBFDAB01CECF7F49957DBFF067E4F797435E038B@IRSMSX108.ger.corp.intel.com>
References: <EBFDAB01CECF7F49957DBFF067E4F797435E038B@IRSMSX108.ger.corp.intel.com>
Message-ID: <20151013120829.2f722b0e@lazus.yip>

Hi David,

that's great!

Welcome to the coreboot.

Best,
Alex

-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at jabber.ccc.de
mobile: +4915123277221
-------------- 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/20151013/1195fb22/attachment.sig>

From david.guckian at intel.com  Tue Oct 13 10:04:43 2015
From: david.guckian at intel.com (Guckian, David)
Date: Tue, 13 Oct 2015 10:04:43 +0000
Subject: [coreboot] Rangeley SoC FSP and Mohon Peak board support
In-Reply-To: <561C84F4.7030901@gmail.com>
References: <EBFDAB01CECF7F49957DBFF067E4F797435E038B@IRSMSX108.ger.corp.intel.com>
 <561C84F4.7030901@gmail.com>
Message-ID: <EBFDAB01CECF7F49957DBFF067E4F797435E068C@IRSMSX108.ger.corp.intel.com>

Hi Alex,

As per our chat yesterday with CSIG and IOTG:
Fei Wang (Wang, Fei Z <fei.z.wang at intel.com>) and myself will be maintainers for Rangeley/Mohon Peak.
Jin Huang and York Yang will be maintainers for FSP1.0 & FSP1.1.
Andrey Petrov will also be maintainer for FSP1.1.

Thanks.
David.

-----Original Message-----
From: Alex G. [mailto:mr.nuke.me at gmail.com] 
Sent: Tuesday, October 13, 2015 5:14 AM
To: Guckian, David; coreboot at coreboot.org; gaumless at gmail.com
Subject: Re: Rangeley SoC FSP and Mohon Peak board support

Hi David,

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

Alex

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

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

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.




From mr.nuke.me at gmail.com  Wed Oct 14 02:17:38 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Tue, 13 Oct 2015 19:17:38 -0700
Subject: [coreboot] Rangeley SoC FSP and Mohon Peak board support
In-Reply-To: <EBFDAB01CECF7F49957DBFF067E4F797435E068C@IRSMSX108.ger.corp.intel.com>
References: <EBFDAB01CECF7F49957DBFF067E4F797435E038B@IRSMSX108.ger.corp.intel.com>
 <561C84F4.7030901@gmail.com>
 <EBFDAB01CECF7F49957DBFF067E4F797435E068C@IRSMSX108.ger.corp.intel.com>
Message-ID: <561DBB42.6090500@gmail.com>

Hi David,

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

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

Alex

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


From mr.nuke.me at gmail.com  Wed Oct 14 16:13:15 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Wed, 14 Oct 2015 09:13:15 -0700
Subject: [coreboot] Possible work from home coreboot developer position
Message-ID: <561E7F1B.2040508@gmail.com>

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

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

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

Alex


From david.guckian at intel.com  Wed Oct 14 18:58:51 2015
From: david.guckian at intel.com (Guckian, David)
Date: Wed, 14 Oct 2015 18:58:51 +0000
Subject: [coreboot] Rangeley SoC FSP and Mohon Peak board support
In-Reply-To: <561DBB42.6090500@gmail.com>
References: <EBFDAB01CECF7F49957DBFF067E4F797435E038B@IRSMSX108.ger.corp.intel.com>
 <561C84F4.7030901@gmail.com>
 <EBFDAB01CECF7F49957DBFF067E4F797435E068C@IRSMSX108.ger.corp.intel.com>
 <561DBB42.6090500@gmail.com>
Message-ID: <EBFDAB01CECF7F49957DBFF067E4F797435E207E@IRSMSX108.ger.corp.intel.com>

Thanks for the update Alex.

York Yang has submitted the patch for microcode handling in FSP1.0:
http://review.coreboot.org/11895

Regards,
David

-----Original Message-----
From: Alex G. [mailto:mr.nuke.me at gmail.com] 
Sent: Wednesday, October 14, 2015 3:18 AM
To: Guckian, David; coreboot at coreboot.org; gaumless at gmail.com
Subject: Re: Rangeley SoC FSP and Mohon Peak board support

Hi David,

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

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

Alex

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

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.




From no-reply at raptorengineeringinc.com  Thu Oct 15 02:09:42 2015
From: no-reply at raptorengineeringinc.com (Raptor Engineering Automated Coreboot Test Stand)
Date: Wed, 14 Oct 2015 21:09:42 -0500
Subject: [coreboot] ASUS KFSN4-DRE Automated Test Failure
Message-ID: <20151015020941.GA30872@cb-test-ctl>

The ASUS KFSN4-DRE fails verification as of commit 58562405c8c416a415652516b8af31b204b4ff0d

The following tests failed:
VIDEO_FAILURE

Commits since last successful test:
5856240 Revert "Remove FSP Rangeley SOC and mohonpeak board support"

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: 1444874965-0-automaster.log.bz2
Type: application/octet-stream
Size: 51911 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151014/647568aa/attachment-0001.obj>

From contact at paulk.fr  Thu Oct 15 20:02:45 2015
From: contact at paulk.fr (Paul Kocialkowski)
Date: Thu, 15 Oct 2015 22:02:45 +0200
Subject: [coreboot] Moving forward with armv7: Word-sized/half-word-sized
 memory operations for 32/16 bit read/write
Message-ID: <1444939365.2740.9.camel@collins>

For nearly a month, a few people (includign myself) have been arguing
over http://review.coreboot.org/#/c/11698/

So far, we've investigated two solutions:
* inline assembly
* __builtin_assume_aligned builtin

Each solution has its pros and cons, I'm not going to move that
discussion here.

However, I would like to suggest another solution: reverting the
toolchain built by crossgcc-arm to GCC 4.9.0, where everything works
fine. That would only be for ARM, since GCC 4.9.0 apparently breaks
RISC-V support and wasn't reported to misbehave on other architectures.

I wish to use the toolchain for rebuilding the cros EC firmware
(especially important for libreboot) and GCC 5.2.0 is causing run-time
errors that are apparently not even of the same nature as the problem
discussed in code review.

Would this be an agreeable solution until everything is sorted out in
gcc upstream?

-- 
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/20151015/5b0b24da/attachment.asc>

From nr at das-labor.org  Tue Oct  6 16:00:33 2015
From: nr at das-labor.org (Nicolas Reinecke)
Date: Tue, 06 Oct 2015 16:00:33 +0200
Subject: [coreboot] About the USB issue on the Lenovo T420 port
In-Reply-To: <CALWv5jTxYh+1t8HyoQFXyhQWwEHUiKadUTMss7j9_3tc0vW55Q@das-labor.org>
References: <CALWv5jTxYh+1t8HyoQFXyhQWwEHUiKadUTMss7j9_3tc0vW55Q@das-labor.org>
Message-ID: <1444140033.6674.5.camel@das-labor.org>

Hi,
can you send me a RCBA dump with vendor bios, coreboot after boot and
suspend?
util/inteltool/inteltool -r
Nicolas Reinecke
Am Montag, den 05.10.2015, 21:49 +0800 schrieb Iru Cai:
> Hi,
> 
> I'm using the new Lenovo T420 port on gerrit[1] and found a bug about
> USB(in my post on the gerrit page). And just now I found a work
> around on this issue.
> 
> First I tested a USB disk on the buggy USB port before suspending the
> system, it works fine. Then I unplugged the USB disk, suspended my
> system, resume, and replugged the disk, the bug occurred. Then I
> unplugged the disk, reload the ehci_pci module as follows:
> 
> rmmod ehci_pci
> modprobe ehci-pci
> 
> The I plugged in the USB disk, it worked fine again.
> 
> I think the kernel message[2] gives some information about it,
> because it gives two different port number on the USB device. But I
> know almost nothing about USB, so I'm not sure what's happening.
> 
> [1] http://review.coreboot.org/#/c/11765/
> [2] see the attached dmesg.log
> 
> Iru Cai
> 
> -- 
> 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/20151006/671f317d/attachment.html>

From john at iwavesystems.com  Mon Oct 12 13:58:12 2015
From: john at iwavesystems.com (John)
Date: Mon, 12 Oct 2015 17:28:12 +0530
Subject: [coreboot] intel atom e3815
Message-ID: <008501d104e5$46992ac0$d3cb8040$@com>

Hi,

 

   Is the coreboot for intel atom E3815 available?

 

Best regards,

John OT

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

From tpearson at raptorengineeringinc.com  Fri Oct 16 19:54:54 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Fri, 16 Oct 2015 12:54:54 -0500
Subject: [coreboot] Patchset up for review to remove external microcode file
 Kconfig option
Message-ID: <562139EE.6040807@raptorengineeringinc.com>

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

All,

I just wanted to alert you to this patchset up for review that removes
the built-in Kconfig option to add an external microcode file.  As
mentioned in the commit message, this option appears to be of decreasing
utility due to the recent microcode update streamlining efforts, however
as it is a user visible change it was decided that the general community
should be involved in the final decision:

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

I expect this to impact only a small number of users.  In any case the
desired microcode files(s) can still be added after build via cbfstool
(this has been tested here and works well).

Thank you!

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

iQEcBAEBAgAGBQJWITnsAAoJEK+E3vEXDOFbh4YIAKNrtJuo/NXPnjI4ZfXciAE7
z+OhO1cwDip+/Ta/NbxTfc3xxCuGn38aOu3cWXCmOtWn2wXAsiGMQNdt+yFn6KOK
a+hvy1IU4yuE5ULk1zCZ1SmkGuANzRQJIX2u09Q56h0xez8Sl/2Rt2M8TXvUYulk
wIoxglPi6mIZ0VveAA28m4xKZ+KUvgJ8RS6mjmy7tKVe40ZZHvS/YczyYJL/j3ql
dSs2XWBNsjKulLJqomryRv5OMyQUifpFaW1EuqMFfwfzTk3rzsukin/h3XPkuXwD
L8jQhzj9O6Fcut5js5SqEIVIEwZN/Dy/agTFRD+Opn1Q6xwLZ1aBQ/jGciln3Kk=
=OigL
-----END PGP SIGNATURE-----


From gaumless at gmail.com  Fri Oct 16 22:08:08 2015
From: gaumless at gmail.com (Martin Roth)
Date: Fri, 16 Oct 2015 14:08:08 -0600
Subject: [coreboot] intel atom e3815
In-Reply-To: <008501d104e5$46992ac0$d3cb8040$@com>
References: <008501d104e5$46992ac0$d3cb8040$@com>
Message-ID: <CA+e+Ov7_1+O1D9Ya2dhRiqgu8pd=8FM7-BygjF0DH+7UKf9_+A@mail.gmail.com>

Hi John,
  coreboot does support the E3815 (Bay Trail I)  with the Intel FSP.
The tree is a little broken for it right now, but we're working to get
it fixed.  The primary example for that chip is the Minnowboard Max.

A couple of resources to get you started:
 - http://intel.com/fsp - There are a number of cocuments in the
"Intel Atom processor E3800 product family" section that would apply
here.
 - http://www.apress.com/9781484200711?gtmf=s - The Embedded Firmware
Solutions book talks specifically about this family of chips

If you have any questions about how to get started, the best place to
get support might be the coreboot irc channel - #coreboot on
freenode.net.
https://webchat.freenode.net/?channels=#coreboot

Martin

On Mon, Oct 12, 2015 at 5:58 AM, John <john at iwavesystems.com> wrote:
> Hi,
>
>
>
>    Is the coreboot for intel atom E3815 available?
>
>
>
> Best regards,
>
> John OT
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From tpearson at raptorengineeringinc.com  Fri Oct 16 22:11:13 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Fri, 16 Oct 2015 15:11:13 -0500
Subject: [coreboot] coreboot ported to the ASUS KGPE-D16 (Libreboot:
 blobless, fully functional!)
In-Reply-To: <556C92CE.7020701@raptorengineeringinc.com>
References: <55414D58.7080306@raptorengineeringinc.com>
 <556C92CE.7020701@raptorengineeringinc.com>
Message-ID: <562159E1.7010704@raptorengineeringinc.com>

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

All,

Raptor Engineering is pleased to announce the public release of the ASUS
KGPE-D16 support code, including support for Family 15h processors!

The current feature status matrix and link to the patchsets on Gerrit is
available here:
https://raptorengineeringinc.com/coreboot/kgpe-d16-status.php

Raptor Engineering would also like to thank Minifree Ltd. for sponsoring
this release.  I know earlier it looked like the crowdfunding push had
died away, but we were working hard on a deal to get this code to the
general public as quickly as possible.  As such I couldn't say too much
on the topic until now.

To get the funding requirements down to a manageable level, Raptor
Engineering has split off several items that would normally have been
included with this upstreaming push.  Specifically, there is no blanket
warranty provided with the patchset as was originally intended --
instead, if an functionality issue is found, you are encouraged to
contract directly with Raptor Engineering to create a fix.  Also, some
of the features not directly related to our production operations here
are incomplete; for example, we are currently looking for sponsors to
sponsore the work needed to resolve certain RAM initialisation issues
and to port the OpenBMC firmware to these boards.

Thank you all for your interest in this port; I hope to hear from you
again in the future!

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

iQEcBAEBAgAGBQJWIVnfAAoJEK+E3vEXDOFbt+oH/jBq8ZBpVWPjMUPXxg7Q4Yl6
QG0TiNK3fOg3uspx3/z7YCKHcRt9Gz33zzDWWiiKNQemXReJqf/ST3HcWLfvSVl4
S4gWoUHoik2lgpI0LdaZNKdsA9mF53E840y1JQnQroE0HWB+FAN95X+FESbezC1z
Xrj6Dk8GagXFEAO5kNclzq/4bcbrw1xjjFcgeiToIYSsx+ZaNDURxNmdlz4h663b
oOL4Qf8ar5BWmgWF3rh0sKNI50qtCArrqjEDDCXwpGveiNOIukVorxZBFMMA3Eid
f1v9cf3i90dqonXcV5hTwjdGsehg/FetTkAO/HIcZnzg/OT+ZROo/u0qT4r+jI4=
=CrJV
-----END PGP SIGNATURE-----


From Brett.Testerman at cobham.com  Fri Oct 16 23:55:32 2015
From: Brett.Testerman at cobham.com (Testerman, Brett (US COM))
Date: Fri, 16 Oct 2015 21:55:32 +0000
Subject: [coreboot] intel atom e3815
In-Reply-To: <CA+e+Ov7_1+O1D9Ya2dhRiqgu8pd=8FM7-BygjF0DH+7UKf9_+A@mail.gmail.com>
References: <008501d104e5$46992ac0$d3cb8040$@com>
 <CA+e+Ov7_1+O1D9Ya2dhRiqgu8pd=8FM7-BygjF0DH+7UKf9_+A@mail.gmail.com>
Message-ID: <1142408A68D00D4F9162A8F3AFF1970A823A2F20@NHC2-WHT-MBX02.white.cobham.local>

John,

One 'gotcha' of  the Minnowboard Max to look out for is based on a GPIO (jumper setting) it will override some of the DRAM settings that you put into your FSP. You probably do not want that. I found it better to use the Baker Sport for ECC designs or the Bayley Bay for non-ECC designs as a starting point with custom hardware.

There are a lot of things to consider when trying to boot this chip. One thing I learned the hard way is you do not have to cover the images on the E3800 family (Baytrail-I) and it will boot without the TXE image in the boot flash. But if you leave the TXE out the XDP port is disabled.

Brett

Long time reader - 1st time posting to this mailing list. Thanks everyone for the support you give so many.


From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Martin Roth
Sent: Friday, October 16, 2015 1:08 PM
To: John
Cc: coreboot
Subject: Re: [coreboot] intel atom e3815


** Please note that the Sender of this email is from outside the Cobham NA IT Hub **
Hi John,
coreboot does support the E3815 (Bay Trail I) with the Intel FSP.
The tree is a little broken for it right now, but we're working to get
it fixed. The primary example for that chip is the Minnowboard Max.

A couple of resources to get you started:
- http://intel.com/fsp<http://intel.com/fsp> - There are a number of cocuments in the
"Intel Atom processor E3800 product family" section that would apply
here.
- http://www.apress.com/9781484200711?gtmf=s<http://www.apress.com/9781484200711?gtmf=s> - The Embedded Firmware
Solutions book talks specifically about this family of chips

If you have any questions about how to get started, the best place to
get support might be the coreboot irc channel - #coreboot on
freenode.net<http://freenode.net>.
https://webchat.freenode.net/?channels=#coreboot<https://webchat.freenode.net/?channels=#coreboot>

Martin

On Mon, Oct 12, 2015 at 5:58 AM, John <john at iwavesystems.com<mailto:john at iwavesystems.com>> wrote:
> Hi,
>
>
>
> Is the coreboot for intel atom E3815 available?
>
>
>
> Best regards,
>
> John OT
>
>
> --
> 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>

--
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/20151016/1046d3ed/attachment.html>

From peter at stuge.se  Sat Oct 17 01:41:47 2015
From: peter at stuge.se (Peter Stuge)
Date: Sat, 17 Oct 2015 01:41:47 +0200
Subject: [coreboot] coreboot ported to the ASUS KGPE-D16
	(Libreboot:	blobless, fully functional!)
In-Reply-To: <562159E1.7010704@raptorengineeringinc.com>
References: <55414D58.7080306@raptorengineeringinc.com>
 <556C92CE.7020701@raptorengineeringinc.com>
 <562159E1.7010704@raptorengineeringinc.com>
Message-ID: <20151016234147.15816.qmail@stuge.se>

Hi all,

Timothy Pearson wrote:
> Raptor Engineering is pleased to announce the public release of the ASUS
> KGPE-D16 support code, including support for Family 15h processors!
..
> Raptor Engineering would also like to thank Minifree Ltd. for sponsoring
> this release.

I would like to take this opportunity to also express my gratitude
and appreciation to Minifree Ltd. and Francis Rowe for enabling this
most excellent contribution to coreboot possible!

Thank you very much.

I have been quite critical of the Libreboot project, but I do
recognize that this contribution to coreboot would never have been
possible if it were not for Francis starting out on the Libreboot
adventure.

Well done! Keep them coming. :) Francis, now I owe you two beverages.


Have a great weekend

//Peter


From mytbk920423 at gmail.com  Sun Oct 18 18:06:25 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Mon, 19 Oct 2015 00:06:25 +0800
Subject: [coreboot]  about Ivy Bridge CPU with QM67 PCH
Message-ID: <20151018160625.GA3768@mytbk-laptop.lan>

Hi,

I've been testing the Lenovo T420 port recently, and now I can install an Ivy Bridge processor and run fine on Linux(except some thermal issues). However, the native graphics initialization doesn't work properly before Linux kernel boots. I can see the GRUB interface but it displays bad as if it's on a panel larger than the laptop panel. Then, Linux kernel boots and the graphics become good again. I read some of the i915 driver code of Linux, and saw some code about PCH, so I think this issue has something to do about the southbridge. I don't know if someone has tried using mixed generation of CPU and chipset combination with coreboot before, and I hope this issue can be resolved.

I have pushed the patch that makes coreboot support both SNB and IVB processor for review:
http://review.coreboot.org/#/c/12087/

Iru Cai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151019/d0fdd6ab/attachment.asc>

From peter at stuge.se  Sun Oct 18 18:44:09 2015
From: peter at stuge.se (Peter Stuge)
Date: Sun, 18 Oct 2015 18:44:09 +0200
Subject: [coreboot] about Ivy Bridge CPU with QM67 PCH
In-Reply-To: <20151018160625.GA3768@mytbk-laptop.lan>
References: <20151018160625.GA3768@mytbk-laptop.lan>
Message-ID: <20151018164409.9670.qmail@stuge.se>

Hi,

Iru Cai wrote:
> I've been testing the Lenovo T420 port recently, and now I can
> install an Ivy Bridge processor and run fine on Linux(except some
> thermal issues).

That's pretty nice I think.


> However, the native graphics initialization doesn't work properly
..
> I don't know if someone has tried using mixed generation of CPU and
> chipset combination with coreboot before,

Probably not.


> I have pushed the patch that makes coreboot support both SNB and
> IVB processor for review:
> http://review.coreboot.org/#/c/12087/

Thanks! There is a source code style issue - you used two spaces
instead of one tab to indent - please fix that, but other than that
the patch looks fine to me.

But the two files gma_{sandy,ivy}bridge_lvds.c are a bit of a mess -
they need to be cleaned up and can quite easily be unified into a
single file, without having it become the mess that the i915 kernel
code is. The key is to have a good data model, and the data model
seems clear to me from the existing code.

For fun (or pain), take a look at: git diff 758a41 7137c5
(sandy..ivy)


//Peter


From gw at oxff.net  Mon Oct 19 17:39:09 2015
From: gw at oxff.net (Georg Wicherski)
Date: Mon, 19 Oct 2015 17:39:09 +0200
Subject: [coreboot] Broadwell IGD (on Auron_Paine)
Message-ID: <56250E9D.80706@oxff.net>

Hi,

thanks to Marc Jones' SGD patch for the Auron board
(f3214d02482a4104d7276f06d6b326b2a54c4262), I was able to get my
Auron_Paine up to ramstage.

Unfortunately, the IGD code in soc/intel/broadwell/ appears to be
somewhat broken. Based off Aaron's guidance on IRC, I've pin-pointed the
issue to be within igd_setup_panel . The first gtt_read there seems to
hang already (BIOS_SPEW log attached). Find my current code with those
debug prints at <http://review.coreboot.org/#/c/11907/2>. FWIW, I've
tested with some commenting-out, etc. that it's any gtt_read that
immediately causes a hang there. Also dumped the gtt_res, small excerpt
from the log:

--8<--
igd's gtt_res = { base=e0000000, size=1000000, limit=e0ffffff,
flags=60000201 }
igd_init: waited for pre-graphics delay to pass
igd_init: went through early init
igd_init: RP1 graphics frequency is set
gtt_read(PCH_PORT_HOTPLUG)
--8<--

People on IRC mentioned that this is an issue that people may have run
into before on Broadwell, any suggestions on how to fix the hang there?


Thanks,
G
-------------- next part --------------
?USB


coreboot-4.1-757-g354d2c3-dirty Thu Oct 15 17:53:02 UTC 2015 romstage starting...
PM1_STS:   0110
PM1_EN:    0000
PM1_CNT:   00000000
TCO_STS:   0000 0000
GPE0_STS:  1ef86df0 147dcfdf 0005f240 00000000
GPE0_EN:   00000000 00000000 00000000 00000000
GEN_PMCON: 0200 2024 4206
Previous Sleep State: S5
CPU: Intel(R) Celeron(R) 3205U @ 1.50GHz
CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001f
CPU: AES NOT supported, TXT NOT supported, VT supported
MCH: device id 1604 (rev 08) is Broadwell E0
PCH: device id 9cc5 (rev 03) is Broadwell U Base
IGD: device id 1606 (rev 08) is Broadwell U GT1
CPU: frequency set to 1500 MHz
SPD: index 5 (GPIO47=1 GPIO9=0 GPIO13=1)
CBFS @ 400000 size 3ff8c0
CBFS: Locating 'spd.bin'
CBFS: Found @ offset 25d00 size 1000
SPD: module type is DDR3
SPD: module part is HMT425S6AFR6A-PB  
SPD: banks 8, ranks 1, rows 15, columns 10, density 4096 Mb
SPD: device width 16 bits, bus width 64 bits
SPD: module size is 2048 MB (per channel)
ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Pseudo-global reset
ME: Progress Phase State    : Waiting for DID BIOS message
ME: HSIO Version            : 8705 (CRC 0xfbc2)
No MRC cache found.
CBFS @ 400000 size 3ff8c0
CBFS: Locating 'mrc.bin'
CBFS: Found @ offset 39ffc0 size 3669c
Starting Memory Reference Code
Initializing Policy
Installing common PPI
MRC: Starting...
Initializing Memory
MRC: Done.
MRC Version 2.4.0 Build 1
memcfg DDR3 clock 1600 MHz
memcfg channel assignment: A: 0, B  1, C  2
memcfg channel[0] config (00780008):
   enhanced interleave mode on
   rank interleave on
   DIMMA 2048 MB width x16 single rank, selected
   DIMMB 0 MB width x16 single rank
memcfg channel[1] config (00600000):
   enhanced interleave mode on
   rank interleave on
   DIMMA 0 MB width x8 or x32 single rank, selected
   DIMMB 0 MB width x8 or x32 single rank
CBMEM:
IMD: root @ 7bfff000 254 entries.
IMD: root @ 7bffec00 62 entries.
External stage cache:
IMD: root @ 7c3ff000 254 entries.
IMD: root @ 7c3fec00 62 entries.
MRC data at ff7d0d9c 6246 bytes
Relocate MRC DATA from ff7d0d9c to 7bf7b000 (6246 bytes)
create cbmem for dimm information
TPM initialization.
TPM: Init
Found TPM SLB9635 TT 1.2 by Infineon
TPM: Open
TPM: Startup
TPM: command 0x99 returned 0x0
TPM: OK.
CBFS provider active.
CBFS @ 400000 size 3ff8c0
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 3b200 size 1364a
'fallback/ramstage' located at offset: 43b238 size: 1364a
Decompressing stage fallback/ramstage @ 0x7bf3afc0 (241232 bytes)
Loading module at 7bf3b000 with entry 7bf3b000. filesize: 0x29e98 memsize: 0x3ae10
Processing 2712 relocs. Offset value of 0x7be3b000
USB


coreboot-4.1-757-g354d2c3-dirty Thu Oct 15 17:53:02 UTC 2015 ramstage starting...
Moving GDT to 7bf39000...ok
Normal boot.
BS: BS_PRE_DEVICE times (us): entry 5 run 5 exit 4
BS: BS_DEV_INIT_CHIPS times (us): entry 5 run 8 exit 5
Enumerating buses...
Show all devs... Before device enumeration.
Root Device: enabled 1
CPU_CLUSTER: 0: enabled 1
APIC: 00: enabled 1
DOMAIN: 0000: enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:02.0: enabled 1
PCI: 00:03.0: enabled 1
PCI: 00:13.0: enabled 0
PCI: 00:14.0: enabled 1
PCI: 00:15.0: enabled 1
PCI: 00:15.1: enabled 1
PCI: 00:15.2: enabled 1
PCI: 00:15.3: enabled 0
PCI: 00:15.4: enabled 0
PCI: 00:15.5: enabled 0
PCI: 00:15.6: enabled 0
PCI: 00:16.0: enabled 1
PCI: 00:16.1: enabled 0
PCI: 00:16.2: enabled 0
PCI: 00:16.3: enabled 0
PCI: 00:17.0: enabled 0
PCI: 00:19.0: enabled 0
PCI: 00:1b.0: enabled 1
PCI: 00:1c.0: enabled 1
PCI: 00:1c.1: enabled 0
PCI: 00:1c.2: enabled 0
PCI: 00:1c.3: enabled 0
PCI: 00:1c.4: enabled 0
PCI: 00:1c.5: enabled 0
PCI: 00:1d.0: enabled 1
PCI: 00:1e.0: enabled 0
PCI: 00:1f.0: enabled 1
PNP: 0c31.0: enabled 1
PNP: 0c09.0: enabled 1
PCI: 00:1f.2: enabled 1
PCI: 00:1f.3: enabled 0
PCI: 00:1f.6: enabled 1
Compare with tree...
Root Device: enabled 1
 CPU_CLUSTER: 0: enabled 1
  APIC: 00: enabled 1
 DOMAIN: 0000: enabled 1
  PCI: 00:00.0: enabled 1
  PCI: 00:02.0: enabled 1
  PCI: 00:03.0: enabled 1
  PCI: 00:13.0: enabled 0
  PCI: 00:14.0: enabled 1
  PCI: 00:15.0: enabled 1
  PCI: 00:15.1: enabled 1
  PCI: 00:15.2: enabled 1
  PCI: 00:15.3: enabled 0
  PCI: 00:15.4: enabled 0
  PCI: 00:15.5: enabled 0
  PCI: 00:15.6: enabled 0
  PCI: 00:16.0: enabled 1
  PCI: 00:16.1: enabled 0
  PCI: 00:16.2: enabled 0
  PCI: 00:16.3: enabled 0
  PCI: 00:17.0: enabled 0
  PCI: 00:19.0: enabled 0
  PCI: 00:1b.0: enabled 1
  PCI: 00:1c.0: enabled 1
  PCI: 00:1c.1: enabled 0
  PCI: 00:1c.2: enabled 0
  PCI: 00:1c.3: enabled 0
  PCI: 00:1c.4: enabled 0
  PCI: 00:1c.5: enabled 0
  PCI: 00:1d.0: enabled 1
  PCI: 00:1e.0: enabled 0
  PCI: 00:1f.0: enabled 1
   PNP: 0c31.0: enabled 1
   PNP: 0c09.0: enabled 1
  PCI: 00:1f.2: enabled 1
  PCI: 00:1f.3: enabled 0
  PCI: 00:1f.6: enabled 1
Root Device scanning...
root_dev_scan_bus for Root Device
CPU_CLUSTER: 0 enabled
DOMAIN: 0000 enabled
DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [8086/0000] ops
PCI: 00:00.0 [8086/1604] enabled
PCI: 00:02.0 [8086/0000] ops
PCI: 00:02.0 [8086/1606] enabled
PCI: 00:03.0 [8086/0000] ops
PCI: 00:03.0 [8086/160c] enabled
PCI: 00:13.0: Disabling device
PCI: 00:14.0 [8086/0000] ops
PCI: 00:14.0 [8086/9cb1] enabled
PCI: 00:15.0 [8086/0000] ops
PCI: 00:15.0 [8086/9ce0] enabled
PCI: 00:15.1 [8086/0000] ops
PCI: 00:15.1 [8086/9ce1] enabled
PCI: 00:15.2 [8086/0000] ops
PCI: 00:15.2 [8086/9ce2] enabled
PCI: 00:15.3: Disabling device
PCI: 00:15.4: Disabling device
PCI: 00:15.5: Disabling device
PCI: 00:15.6: Disabling device
PCI: 00:16.0 [8086/0000] ops
PCI: 00:16.0 [8086/9cba] enabled
PCI: 00:16.1: Disabling device
PCI: 00:16.2: Disabling device
PCI: 00:16.3: Disabling device
PCI: 00:17.0: Disabling device
PCI: 00:19.0: Disabling device
PCI: 00:1b.0 [8086/0000] ops
PCI: 00:1b.0 [8086/9ca0] enabled
PCI: 00:1c.0 [8086/0000] bus ops
PCIe Root Port 1 ASPM is enabled
PCI: 00:1c.0 [8086/9c90] enabled
PCI: 00:1c.1 [8086/0000] bus ops
PCI: 00:1c.1 [8086/9c92] disabled
PCI: 00:1c.2 [8086/0000] bus ops
PCI: 00:1c.2 [8086/9c94] disabled
PCI: 00:1c.3 [8086/0000] bus ops
PCI: 00:1c.3 [8086/9c96] disabled
PCI: 00:1c.4 [8086/0000] bus ops
PCI: 00:1c.4 [8086/9c98] disabled
PCI: 00:1c.5 [8086/0000] bus ops
PCI: 00:1c.1: Disabling device
PCI: 00:1c.2: Disabling device
PCI: 00:1c.3: Disabling device
PCI: 00:1c.4: Disabling device
PCI: 00:1c.5: Disabling device
PCH: RPFN 0x00543210 -> 0x00dcba90
PCI: 00:1c.5 [8086/9c9a] disabled
PCI: 00:1d.0 [8086/0000] ops
PCI: 00:1d.0 [8086/9ca6] enabled
PCI: 00:1e.0: Disabling device
PCI: 00:1f.0 [8086/0000] bus ops
PCI: 00:1f.0 [8086/9cc5] enabled
PCI: 00:1f.2 [8086/0000] ops
PCI: 00:1f.2 [8086/9c83] enabled
PCI: 00:1f.3: Disabling device
PCI: 00:1f.6 [8086/9ca4] enabled
PCI: 00:1c.0 scanning...
do_pci_scan_bridge for PCI: 00:1c.0
PCI: pci_scan_bus for bus 01
PCI: 01:00.0 [8086/08b1] enabled
Capability: type 0x01 @ 0xc8
Capability: type 0x05 @ 0xd0
Capability: type 0x10 @ 0x40
Capability: type 0x10 @ 0x40
Enabling Common Clock Configuration
L1 Sub-State supported from root port 28
L1 Sub-State Support = 0xf
CommonModeRestoreTime = 0x28
Power On Value = 0x1e, Power On Scale = 0x0
Capability: type 0x10 @ 0x40
Capability: type 0x01 @ 0xc8
Capability: type 0x05 @ 0xd0
Capability: type 0x10 @ 0x40
ASPM: Enabled L1
PCI: 00:1f.0 scanning...
scan_lpc_bus for PCI: 00:1f.0
PNP: 0c31.0 enabled
PNP: 0c09.0 enabled
scan_lpc_bus for PCI: 00:1f.0 done
root_dev_scan_bus for Root Device done
done
BS: BS_DEV_ENUMERATE times (us): entry 5 run 411244 exit 4
found VGA at PCI: 00:02.0
Setting up VGA for PCI: 00:02.0
Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Allocating resources...
Reading resources...
Root Device read_resources bus 0 link: 0
CPU_CLUSTER: 0 read_resources bus 0 link: 0
APIC: 00 missing read_resources
CPU_CLUSTER: 0 read_resources bus 0 link: 0 done
DOMAIN: 0000 read_resources bus 0 link: 0
mc_add_fixed_mmio_resources: Adding PCIEXBAR @ 60 0xf0000000-0xf3ffffff.
mc_add_fixed_mmio_resources: Adding MCHBAR @ 48 0xfed10000-0xfed17fff.
mc_add_fixed_mmio_resources: Adding DMIBAR @ 68 0xfed18000-0xfed18fff.
mc_add_fixed_mmio_resources: Adding EPBAR @ 40 0xfed19000-0xfed19fff.
mc_add_fixed_mmio_resources: Adding GDXCBAR @ 5420 0xfed84000-0xfed84fff.
mc_add_fixed_mmio_resources: Adding EDRAMBAR @ 5408 0xfed80000-0xfed83fff.
MC MAP: TOM: 0x80000000
MC MAP: TOUUD: 0x7f000000
MC MAP: MESEG_BASE: 0x7f000000
MC MAP: MESEG_LIMIT: 0x7fff0fffff
MC MAP: REMAP_BASE: 0x7ffff00000
MC MAP: REMAP_LIMIT: 0xfffff
MC MAP: TOLUD: 0x7f000000
MC MAP: BGSM: 0x7c800000
MC MAP: BDSM: 0x7d000000
MC MAP: TESGMB: 0x7c000000
MC MAP: GGC: 0x1c1
PCI: 00:1c.0 read_resources bus 1 link: 0
PCI: 00:1c.0 read_resources bus 1 link: 0 done
PCI: 00:1d.0 EHCI BAR hook registered
PCI: 00:1f.0 read_resources bus 0 link: 0
PCI: 00:1f.0 read_resources bus 0 link: 0 done
DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
Done reading resources.
Show resources in subtree (Root Device)...After reading.
 Root Device child on link 0 CPU_CLUSTER: 0
  CPU_CLUSTER: 0 child on link 0 APIC: 00
   APIC: 00
  DOMAIN: 0000 child on link 0 PCI: 00:00.0
  DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags 40040100 index 10000000
  DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags 40040200 index 10000100
   PCI: 00:00.0
   PCI: 00:00.0 resource base f0000000 size 4000000 align 0 gran 0 limit 0 flags f0000200 index 60
   PCI: 00:00.0 resource base fed10000 size 8000 align 0 gran 0 limit 0 flags f0000200 index 48
   PCI: 00:00.0 resource base fed18000 size 1000 align 0 gran 0 limit 0 flags f0000200 index 68
   PCI: 00:00.0 resource base fed19000 size 1000 align 0 gran 0 limit 0 flags f0000200 index 40
   PCI: 00:00.0 resource base fed84000 size 1000 align 0 gran 0 limit 0 flags f0000200 index 5420
   PCI: 00:00.0 resource base fed80000 size 4000 align 0 gran 0 limit 0 flags f0000200 index 5408
   PCI: 00:00.0 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index 0
   PCI: 00:00.0 resource base c0000 size 7bf40000 align 0 gran 0 limit 0 flags e0004200 index 1
   PCI: 00:00.0 resource base 7c000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 2
   PCI: 00:00.0 resource base 7c800000 size 2800000 align 0 gran 0 limit 0 flags f0000200 index 3
   PCI: 00:00.0 resource base a0000 size 20000 align 0 gran 0 limit 0 flags f0000200 index 4
   PCI: 00:00.0 resource base c0000 size 40000 align 0 gran 0 limit 0 flags f0004200 index 5
   PCI: 00:02.0
   PCI: 00:02.0 resource base 0 size 1000000 align 24 gran 24 limit ffffffffffffffff flags 201 index 10
   PCI: 00:02.0 resource base 0 size 10000000 align 28 gran 28 limit ffffffffffffffff flags 1201 index 18
   PCI: 00:02.0 resource base 0 size 40 align 6 gran 6 limit ffff flags 100 index 20
   PCI: 00:03.0
   PCI: 00:03.0 resource base 0 size 4000 align 14 gran 14 limit ffffffffffffffff flags 201 index 10
   PCI: 00:13.0
   PCI: 00:14.0
   PCI: 00:14.0 resource base 0 size 10000 align 16 gran 16 limit ffffffffffffffff flags 201 index 10
   PCI: 00:15.0
   PCI: 00:15.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 10
   PCI: 00:15.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 14
   PCI: 00:15.1
   PCI: 00:15.1 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 10
   PCI: 00:15.1 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 14
   PCI: 00:15.2
   PCI: 00:15.2 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 10
   PCI: 00:15.2 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 14
   PCI: 00:15.3
   PCI: 00:15.4
   PCI: 00:15.5
   PCI: 00:15.6
   PCI: 00:16.0
   PCI: 00:16.0 resource base 0 size 20 align 5 gran 5 limit ffffffffffffffff flags 201 index 10
   PCI: 00:16.1
   PCI: 00:16.2
   PCI: 00:16.3
   PCI: 00:17.0
   PCI: 00:19.0
   PCI: 00:1b.0
   PCI: 00:1b.0 resource base 0 size 4000 align 14 gran 14 limit ffffffffffffffff flags 201 index 10
   PCI: 00:1c.0 child on link 0 PCI: 01:00.0
   PCI: 00:1c.0 resource base 0 size 0 align 12 gran 12 limit ffff flags 80102 index 1c
   PCI: 00:1c.0 resource base 0 size 0 align 20 gran 20 limit ffffffffffffffff flags 81202 index 24
   PCI: 00:1c.0 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80202 index 20
    PCI: 01:00.0
    PCI: 01:00.0 resource base 0 size 2000 align 13 gran 13 limit ffffffffffffffff flags 201 index 10
   PCI: 00:1c.1
   PCI: 00:1c.2
   PCI: 00:1c.3
   PCI: 00:1c.4
   PCI: 00:1c.5
   PCI: 00:1d.0
   PCI: 00:1d.0 resource base 0 size 400 align 10 gran 10 limit ffffffff flags 200 index 10
   PCI: 00:1e.0
   PCI: 00:1f.0 child on link 0 PNP: 0c31.0
   PCI: 00:1f.0 resource base fec00000 size 1400000 align 0 gran 0 limit 0 flags c0000200 index 31fe
   PCI: 00:1f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0000100 index 0
   PCI: 00:1f.0 resource base 1400 size 400 align 0 gran 0 limit 0 flags c0000100 index 48
   PCI: 00:1f.0 resource base 1000 size 100 align 0 gran 0 limit 0 flags c0000100 index 40
    PNP: 0c31.0
    PNP: 0c31.0 resource base a size 1 align 0 gran 0 limit 0 flags c0000400 index 70
    PNP: 0c31.0 resource base fed40000 size 5000 align 0 gran 0 limit 0 flags f0000200 index 0
    PNP: 0c09.0
   PCI: 00:1f.2
   PCI: 00:1f.2 resource base 0 size 8 align 3 gran 3 limit ffff flags 100 index 10
   PCI: 00:1f.2 resource base 0 size 4 align 2 gran 2 limit ffff flags 100 index 14
   PCI: 00:1f.2 resource base 0 size 8 align 3 gran 3 limit ffff flags 100 index 18
   PCI: 00:1f.2 resource base 0 size 4 align 2 gran 2 limit ffff flags 100 index 1c
   PCI: 00:1f.2 resource base 0 size 20 align 5 gran 5 limit ffff flags 100 index 20
   PCI: 00:1f.2 resource base 0 size 8000 align 15 gran 15 limit ffffffff flags 200 index 24
   PCI: 00:1f.3
   PCI: 00:1f.6
   PCI: 00:1f.6 resource base 0 size 1000 align 12 gran 12 limit ffffffffffffffff flags 201 index 10
DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff
PCI: 00:1c.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff
PCI: 00:1c.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff done
PCI: 00:02.0 20 *  [0x0 - 0x3f] io
PCI: 00:1f.2 20 *  [0x40 - 0x5f] io
PCI: 00:1f.2 10 *  [0x60 - 0x67] io
PCI: 00:1f.2 18 *  [0x68 - 0x6f] io
PCI: 00:1f.2 14 *  [0x70 - 0x73] io
PCI: 00:1f.2 1c *  [0x74 - 0x77] io
DOMAIN: 0000 io: base: 78 size: 78 align: 6 gran: 0 limit: ffff done
DOMAIN: 0000 mem: base: 0 size: 0 align: 0 gran: 0 limit: ffffffff
PCI: 00:1c.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffffffffff
PCI: 00:1c.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffffffffff done
PCI: 00:1c.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 01:00.0 10 *  [0x0 - 0x1fff] mem
PCI: 00:1c.0 mem: base: 2000 size: 100000 align: 20 gran: 20 limit: ffffffff done
PCI: 00:02.0 18 *  [0x0 - 0xfffffff] prefmem
PCI: 00:02.0 10 *  [0x10000000 - 0x10ffffff] mem
PCI: 00:1c.0 20 *  [0x11000000 - 0x110fffff] mem
PCI: 00:14.0 10 *  [0x11100000 - 0x1110ffff] mem
PCI: 00:1f.2 24 *  [0x11110000 - 0x11117fff] mem
PCI: 00:03.0 10 *  [0x11118000 - 0x1111bfff] mem
PCI: 00:1b.0 10 *  [0x1111c000 - 0x1111ffff] mem
PCI: 00:15.0 10 *  [0x11120000 - 0x11120fff] mem
PCI: 00:15.0 14 *  [0x11121000 - 0x11121fff] mem
PCI: 00:15.1 10 *  [0x11122000 - 0x11122fff] mem
PCI: 00:15.1 14 *  [0x11123000 - 0x11123fff] mem
PCI: 00:15.2 10 *  [0x11124000 - 0x11124fff] mem
PCI: 00:15.2 14 *  [0x11125000 - 0x11125fff] mem
PCI: 00:1f.6 10 *  [0x11126000 - 0x11126fff] mem
PCI: 00:1d.0 10 *  [0x11127000 - 0x111273ff] mem
PCI: 00:16.0 10 *  [0x11127400 - 0x1112741f] mem
DOMAIN: 0000 mem: base: 11127420 size: 11127420 align: 28 gran: 0 limit: ffffffff done
avoid_fixed_resources: DOMAIN: 0000
avoid_fixed_resources:@DOMAIN: 0000 10000000 limit 0000ffff
avoid_fixed_resources:@DOMAIN: 0000 10000100 limit ffffffff
constrain_resources: PCI: 00:00.0 60 base f0000000 limit f3ffffff mem (fixed)
constrain_resources: PCI: 00:00.0 00 base 00000000 limit 0009ffff mem (fixed)
constrain_resources: PCI: 00:00.0 01 base 000c0000 limit 7bffffff mem (fixed)
constrain_resources: PCI: 00:00.0 02 base 7c000000 limit 7c7fffff mem (fixed)
constrain_resources: PCI: 00:00.0 03 base 7c800000 limit 7effffff mem (fixed)
constrain_resources: PCI: 00:1f.0 00 base 00000000 limit 00000fff io (fixed)
constrain_resources: PCI: 00:1f.0 48 base 00001400 limit 000017ff io (fixed)
avoid_fixed_resources:@DOMAIN: 0000 10000000 base 00001800 limit 0000ffff
avoid_fixed_resources:@DOMAIN: 0000 10000100 base d0000000 limit efffffff
Setting resources...
DOMAIN: 0000 io: base:1800 size:78 align:6 gran:0 limit:ffff
PCI: 00:02.0 20 *  [0x1800 - 0x183f] io
PCI: 00:1f.2 20 *  [0x1840 - 0x185f] io
PCI: 00:1f.2 10 *  [0x1860 - 0x1867] io
PCI: 00:1f.2 18 *  [0x1868 - 0x186f] io
PCI: 00:1f.2 14 *  [0x1870 - 0x1873] io
PCI: 00:1f.2 1c *  [0x1874 - 0x1877] io
DOMAIN: 0000 io: next_base: 1878 size: 78 align: 6 gran: 0 done
PCI: 00:1c.0 io: base:ffff size:0 align:12 gran:12 limit:ffff
PCI: 00:1c.0 io: next_base: ffff size: 0 align: 12 gran: 12 done
DOMAIN: 0000 mem: base:d0000000 size:11127420 align:28 gran:0 limit:efffffff
PCI: 00:02.0 18 *  [0xd0000000 - 0xdfffffff] prefmem
PCI: 00:02.0 10 *  [0xe0000000 - 0xe0ffffff] mem
PCI: 00:1c.0 20 *  [0xe1000000 - 0xe10fffff] mem
PCI: 00:14.0 10 *  [0xe1100000 - 0xe110ffff] mem
PCI: 00:1f.2 24 *  [0xe1110000 - 0xe1117fff] mem
PCI: 00:03.0 10 *  [0xe1118000 - 0xe111bfff] mem
PCI: 00:1b.0 10 *  [0xe111c000 - 0xe111ffff] mem
PCI: 00:15.0 10 *  [0xe1120000 - 0xe1120fff] mem
PCI: 00:15.0 14 *  [0xe1121000 - 0xe1121fff] mem
PCI: 00:15.1 10 *  [0xe1122000 - 0xe1122fff] mem
PCI: 00:15.1 14 *  [0xe1123000 - 0xe1123fff] mem
PCI: 00:15.2 10 *  [0xe1124000 - 0xe1124fff] mem
PCI: 00:15.2 14 *  [0xe1125000 - 0xe1125fff] mem
PCI: 00:1f.6 10 *  [0xe1126000 - 0xe1126fff] mem
PCI: 00:1d.0 10 *  [0xe1127000 - 0xe11273ff] mem
PCI: 00:16.0 10 *  [0xe1127400 - 0xe112741f] mem
DOMAIN: 0000 mem: next_base: e1127420 size: 11127420 align: 28 gran: 0 done
PCI: 00:1c.0 prefmem: base:efffffff size:0 align:20 gran:20 limit:efffffff
PCI: 00:1c.0 prefmem: next_base: efffffff size: 0 align: 20 gran: 20 done
PCI: 00:1c.0 mem: base:e1000000 size:100000 align:20 gran:20 limit:e10fffff
PCI: 01:00.0 10 *  [0xe1000000 - 0xe1001fff] mem
PCI: 00:1c.0 mem: next_base: e1002000 size: 100000 align: 20 gran: 20 done
Root Device assign_resources, bus 0 link: 0
DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:02.0 10 <- [0x00e0000000 - 0x00e0ffffff] size 0x01000000 gran 0x18 mem64
PCI: 00:02.0 18 <- [0x00d0000000 - 0x00dfffffff] size 0x10000000 gran 0x1c prefmem64
PCI: 00:02.0 20 <- [0x0000001800 - 0x000000183f] size 0x00000040 gran 0x06 io
PCI: 00:03.0 10 <- [0x00e1118000 - 0x00e111bfff] size 0x00004000 gran 0x0e mem64
PCI: 00:14.0 10 <- [0x00e1100000 - 0x00e110ffff] size 0x00010000 gran 0x10 mem64
PCI: 00:15.0 10 <- [0x00e1120000 - 0x00e1120fff] size 0x00001000 gran 0x0c mem
PCI: 00:15.0 14 <- [0x00e1121000 - 0x00e1121fff] size 0x00001000 gran 0x0c mem
PCI: 00:15.1 10 <- [0x00e1122000 - 0x00e1122fff] size 0x00001000 gran 0x0c mem
PCI: 00:15.1 14 <- [0x00e1123000 - 0x00e1123fff] size 0x00001000 gran 0x0c mem
PCI: 00:15.2 10 <- [0x00e1124000 - 0x00e1124fff] size 0x00001000 gran 0x0c mem
PCI: 00:15.2 14 <- [0x00e1125000 - 0x00e1125fff] size 0x00001000 gran 0x0c mem
PCI: 00:16.0 10 <- [0x00e1127400 - 0x00e112741f] size 0x00000020 gran 0x05 mem64
PCI: 00:1b.0 10 <- [0x00e111c000 - 0x00e111ffff] size 0x00004000 gran 0x0e mem64
PCI: 00:1c.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 01 io
PCI: 00:1c.0 24 <- [0x00efffffff - 0x00effffffe] size 0x00000000 gran 0x14 bus 01 prefmem
PCI: 00:1c.0 20 <- [0x00e1000000 - 0x00e10fffff] size 0x00100000 gran 0x14 bus 01 mem
PCI: 00:1c.0 assign_resources, bus 1 link: 0
PCI: 01:00.0 10 <- [0x00e1000000 - 0x00e1001fff] size 0x00002000 gran 0x0d mem64
PCI: 00:1c.0 assign_resources, bus 1 link: 0
PCI: 00:1d.0 EHCI Debug Port hook triggered
PCI: 00:1d.0 10 <- [0x00e1127000 - 0x00e11273ff] size 0x00000400 gran 0x0a mem
PCI: 00:1d.0 EHCI Debug Port relocated
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PNP: 0c31.0 70 <- [0x000000000a - 0x000000000a] size 0x00000001 gran 0x00 irq <tpm>
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PCI: 00:1f.2 10 <- [0x0000001860 - 0x0000001867] size 0x00000008 gran 0x03 io
PCI: 00:1f.2 14 <- [0x0000001870 - 0x0000001873] size 0x00000004 gran 0x02 io
PCI: 00:1f.2 18 <- [0x0000001868 - 0x000000186f] size 0x00000008 gran 0x03 io
PCI: 00:1f.2 1c <- [0x0000001874 - 0x0000001877] size 0x00000004 gran 0x02 io
PCI: 00:1f.2 20 <- [0x0000001840 - 0x000000185f] size 0x00000020 gran 0x05 io
PCI: 00:1f.2 24 <- [0x00e1110000 - 0x00e1117fff] size 0x00008000 gran 0x0f mem
PCI: 00:1f.6 10 <- [0x00e1126000 - 0x00e1126fff] size 0x00001000 gran 0x0c mem64
DOMAIN: 0000 assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Show resources in subtree (Root Device)...After assigning values.
 Root Device child on link 0 CPU_CLUSTER: 0
  CPU_CLUSTER: 0 child on link 0 APIC: 00
   APIC: 00
  DOMAIN: 0000 child on link 0 PCI: 00:00.0
  DOMAIN: 0000 resource base 1800 size 78 align 6 gran 0 limit ffff flags 40040100 index 10000000
  DOMAIN: 0000 resource base d0000000 size 11127420 align 28 gran 0 limit efffffff flags 40040200 index 10000100
   PCI: 00:00.0
   PCI: 00:00.0 resource base f0000000 size 4000000 align 0 gran 0 limit 0 flags f0000200 index 60
   PCI: 00:00.0 resource base fed10000 size 8000 align 0 gran 0 limit 0 flags f0000200 index 48
   PCI: 00:00.0 resource base fed18000 size 1000 align 0 gran 0 limit 0 flags f0000200 index 68
   PCI: 00:00.0 resource base fed19000 size 1000 align 0 gran 0 limit 0 flags f0000200 index 40
   PCI: 00:00.0 resource base fed84000 size 1000 align 0 gran 0 limit 0 flags f0000200 index 5420
   PCI: 00:00.0 resource base fed80000 size 4000 align 0 gran 0 limit 0 flags f0000200 index 5408
   PCI: 00:00.0 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index 0
   PCI: 00:00.0 resource base c0000 size 7bf40000 align 0 gran 0 limit 0 flags e0004200 index 1
   PCI: 00:00.0 resource base 7c000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 2
   PCI: 00:00.0 resource base 7c800000 size 2800000 align 0 gran 0 limit 0 flags f0000200 index 3
   PCI: 00:00.0 resource base a0000 size 20000 align 0 gran 0 limit 0 flags f0000200 index 4
   PCI: 00:00.0 resource base c0000 size 40000 align 0 gran 0 limit 0 flags f0004200 index 5
   PCI: 00:02.0
   PCI: 00:02.0 resource base e0000000 size 1000000 align 24 gran 24 limit e0ffffff flags 60000201 index 10
   PCI: 00:02.0 resource base d0000000 size 10000000 align 28 gran 28 limit dfffffff flags 60001201 index 18
   PCI: 00:02.0 resource base 1800 size 40 align 6 gran 6 limit 183f flags 60000100 index 20
   PCI: 00:03.0
   PCI: 00:03.0 resource base e1118000 size 4000 align 14 gran 14 limit e111bfff flags 60000201 index 10
   PCI: 00:13.0
   PCI: 00:14.0
   PCI: 00:14.0 resource base e1100000 size 10000 align 16 gran 16 limit e110ffff flags 60000201 index 10
   PCI: 00:15.0
   PCI: 00:15.0 resource base e1120000 size 1000 align 12 gran 12 limit e1120fff flags 60000200 index 10
   PCI: 00:15.0 resource base e1121000 size 1000 align 12 gran 12 limit e1121fff flags 60000200 index 14
   PCI: 00:15.1
   PCI: 00:15.1 resource base e1122000 size 1000 align 12 gran 12 limit e1122fff flags 60000200 index 10
   PCI: 00:15.1 resource base e1123000 size 1000 align 12 gran 12 limit e1123fff flags 60000200 index 14
   PCI: 00:15.2
   PCI: 00:15.2 resource base e1124000 size 1000 align 12 gran 12 limit e1124fff flags 60000200 index 10
   PCI: 00:15.2 resource base e1125000 size 1000 align 12 gran 12 limit e1125fff flags 60000200 index 14
   PCI: 00:15.3
   PCI: 00:15.4
   PCI: 00:15.5
   PCI: 00:15.6
   PCI: 00:16.0
   PCI: 00:16.0 resource base e1127400 size 20 align 5 gran 5 limit e112741f flags 60000201 index 10
   PCI: 00:16.1
   PCI: 00:16.2
   PCI: 00:16.3
   PCI: 00:17.0
   PCI: 00:19.0
   PCI: 00:1b.0
   PCI: 00:1b.0 resource base e111c000 size 4000 align 14 gran 14 limit e111ffff flags 60000201 index 10
   PCI: 00:1c.0 child on link 0 PCI: 01:00.0
   PCI: 00:1c.0 resource base ffff size 0 align 12 gran 12 limit ffff flags 60080102 index 1c
   PCI: 00:1c.0 resource base efffffff size 0 align 20 gran 20 limit efffffff flags 60081202 index 24
   PCI: 00:1c.0 resource base e1000000 size 100000 align 20 gran 20 limit e10fffff flags 60080202 index 20
    PCI: 01:00.0
    PCI: 01:00.0 resource base e1000000 size 2000 align 13 gran 13 limit e1001fff flags 60000201 index 10
   PCI: 00:1c.1
   PCI: 00:1c.2
   PCI: 00:1c.3
   PCI: 00:1c.4
   PCI: 00:1c.5
   PCI: 00:1d.0
   PCI: 00:1d.0 resource base e1127000 size 400 align 10 gran 10 limit e11273ff flags 60000200 index 10
   PCI: 00:1e.0
   PCI: 00:1f.0 child on link 0 PNP: 0c31.0
   PCI: 00:1f.0 resource base fec00000 size 1400000 align 0 gran 0 limit 0 flags c0000200 index 31fe
   PCI: 00:1f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0000100 index 0
   PCI: 00:1f.0 resource base 1400 size 400 align 0 gran 0 limit 0 flags c0000100 index 48
   PCI: 00:1f.0 resource base 1000 size 100 align 0 gran 0 limit 0 flags c0000100 index 40
    PNP: 0c31.0
    PNP: 0c31.0 resource base a size 1 align 0 gran 0 limit 0 flags e0000400 index 70
    PNP: 0c31.0 resource base fed40000 size 5000 align 0 gran 0 limit 0 flags f0000200 index 0
    PNP: 0c09.0
   PCI: 00:1f.2
   PCI: 00:1f.2 resource base 1860 size 8 align 3 gran 3 limit 1867 flags 60000100 index 10
   PCI: 00:1f.2 resource base 1870 size 4 align 2 gran 2 limit 1873 flags 60000100 index 14
   PCI: 00:1f.2 resource base 1868 size 8 align 3 gran 3 limit 186f flags 60000100 index 18
   PCI: 00:1f.2 resource base 1874 size 4 align 2 gran 2 limit 1877 flags 60000100 index 1c
   PCI: 00:1f.2 resource base 1840 size 20 align 5 gran 5 limit 185f flags 60000100 index 20
   PCI: 00:1f.2 resource base e1110000 size 8000 align 15 gran 15 limit e1117fff flags 60000200 index 24
   PCI: 00:1f.3
   PCI: 00:1f.6
   PCI: 00:1f.6 resource base e1126000 size 1000 align 12 gran 12 limit e1126fff flags 60000201 index 10
Done allocating resources.
BS: BS_DEV_RESOURCES times (us): entry 4 run 1655869 exit 5
Enabling resources...
PCI: 00:00.0 subsystem <- 0000/0000
PCI: 00:00.0 cmd <- 06
PCI: 00:02.0 subsystem <- 0000/0000
PCI: 00:02.0 cmd <- 03
PCI: 00:03.0 subsystem <- 0000/0000
PCI: 00:03.0 cmd <- 02
PCI: 00:14.0 subsystem <- 0000/0000
PCI: 00:14.0 cmd <- 102
PCI: 00:15.0 subsystem <- 0000/0000
PCI: 00:15.0 cmd <- 106
PCI: 00:15.1 subsystem <- 0000/0000
PCI: 00:15.1 cmd <- 102
PCI: 00:15.2 subsystem <- 0000/0000
PCI: 00:15.2 cmd <- 102
PCI: 00:16.0 subsystem <- 0000/0000
PCI: 00:16.0 cmd <- 02
PCI: 00:1b.0 subsystem <- 0000/0000
PCI: 00:1b.0 cmd <- 02
PCI: 00:1c.0 bridge ctrl <- 0003
PCI: 00:1c.0 subsystem <- 0000/0000
PCI: 00:1c.0 cmd <- 06
PCI: 00:1d.0 subsystem <- 0000/0000
PCI: 00:1d.0 cmd <- 02
PCI: 00:1f.0 subsystem <- 0000/0000
PCI: 00:1f.0 cmd <- 107
PCI: 00:1f.2 subsystem <- 0000/0000
PCI: 00:1f.2 cmd <- 103
PCI: 00:1f.6 subsystem <- 0000/0000
PCI: 00:1f.6 cmd <- 102
PCI: 01:00.0 cmd <- 02
done.
BS: BS_DEV_ENABLE times (us): entry 5 run 81994 exit 5
Initializing devices...
Root Device init ...
mainboard_ec_init
Chrome EC: Set WAKE mask to 0x00000000
Root Device init finished in 6959 usecs
CPU_CLUSTER: 0 init ...
CPU has 2 cores, 2 threads enabled.
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x000000007c800000 size 0x7c740000 type 6
0x000000007c800000 - 0x00000000d0000000 size 0x53800000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
MTRR: Fixed MSR 0x250 0x0606060606060606
MTRR: Fixed MSR 0x258 0x0606060606060606
MTRR: Fixed MSR 0x259 0x0000000000000000
MTRR: Fixed MSR 0x268 0x0606060606060606
MTRR: Fixed MSR 0x269 0x0606060606060606
MTRR: Fixed MSR 0x26a 0x0606060606060606
MTRR: Fixed MSR 0x26b 0x0606060606060606
MTRR: Fixed MSR 0x26c 0x0606060606060606
MTRR: Fixed MSR 0x26d 0x0606060606060606
MTRR: Fixed MSR 0x26e 0x0606060606060606
MTRR: Fixed MSR 0x26f 0x0606060606060606
call enable_fixed_mtrr()
MTRR: default type WB/UC MTRR counts: 7/5.
MTRR: UC selected as default type.
MTRR: 0 base 0x0000000000000000 mask 0x0000007f80000000 type 6
MTRR: 1 base 0x000000007c800000 mask 0x0000007fff800000 type 0
MTRR: 2 base 0x000000007d000000 mask 0x0000007fff000000 type 0
MTRR: 3 base 0x000000007e000000 mask 0x0000007ffe000000 type 0
MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Initializing VR config.
PCODE: 24MHz BLCK calibration response: 0
PCODE: 24MHz BLCK calibration value: 0x8506879e
PCH Power: PCODE Levels 0x3f1c50c2 0x004cd2c9
CBFS @ 400000 size 3ff8c0
CBFS: Locating 'cpu_microcode_blob.bin'
CBFS: Found @ offset 0 size 11440
microcode: sig=0x306d4 pf=0x40 revision=0x1f
Setting up SMI for CPU
Loading module at 00038000 with entry 00038000. filesize: 0x160 memsize: 0x160
Processing 10 relocs. Offset value of 0x00038000
SMM Module: stub loaded at 00038000. Will call 7bf434c1(7bf6d080)
Installing SMM handler to 0x7c000000
Loading module at 7c010000 with entry 7c010070. filesize: 0xf48 memsize: 0x4f68
Processing 35 relocs. Offset value of 0x7c010000
Loading module at 7c008000 with entry 7c008000. filesize: 0x160 memsize: 0x160
Processing 10 relocs. Offset value of 0x7c008000
SMM Module: placing jmp sequence at 7c007c00 rel16 0x03fd
SMM Module: stub loaded at 7c008000. Will call 7c010070(00000000)
Initializing Southbridge SMI... ... pmbase = 0x1000

SMI_STS: TCO PM1 
PM1_STS: PWRBTN BM TMROF 
In relocation handler: cpu 0
New SMBASE=0x7c000000 IEDBASE=0x7c400000
Writing SMRR. base = 0x7c000006, mask=0xff800800
Relocation complete.
CPU: Intel(R) Celeron(R) 3205U @ 1.50GHz.
Loading module at 00030000 with entry 00030000. filesize: 0x130 memsize: 0x130
Processing 16 relocs. Offset value of 0x00030000
Attempting to start 1 APs
Waiting for 10ms after sending INIT.
Waiting for 1st SIPI to complete...done.
AP: slot 1 apic_id 2.
Waiting for 2nd SIPI to complete...done.
In relocation handler: cpu 1
New SMBASE=0x7bfffc00 IEDBASE=0x7c400000
Writing SMRR. base = 0x7c000006, mask=0xff800800
Relocation complete.
Initializing CPU #0
CPU: vendor Intel device 306d4
CPU: family 06, model 3d, stepping 04
Setting up local apic... apic_id: 0x00 done.
cpu: energy policy set to 6
Turbo is available but hidden
Turbo has been enabled
CPU #0 initialized
Initializing CPU #1
CPU: vendor Intel device 306d4
CPU: family 06, model 3d, stepping 04
Setting up local apic... apic_id: 0x02 done.
cpu: energy policy set to 6
CPU #1 initialized
Enabling SMIs.
Locking SMM.
cpu: frequency set to 1500
CPU_CLUSTER: 0 init finished in 323000 usecs
PCI: 00:00.0 init ...
Set BIOS_RESET_CPL
CPU TDP: 15 Watts
PCI: 00:00.0 init finished in 5751 usecs
PCI: 00:02.0 init ...
igd's gtt_res = { base=e0000000, size=1000000, limit=e0ffffff, flags=60000201 }
igd_init: waited for pre-graphics delay to pass
igd_init: went through early init
igd_init: RP1 graphics frequency is set
gtt_read(PCH_PORT_HOTPLUG)

From stefan.reinauer at coreboot.org  Mon Oct 19 20:30:40 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Mon, 19 Oct 2015 20:30:40 +0200
Subject: [coreboot] steps before screen mods
In-Reply-To: <CAJYonf2Y8ZcOYg7ALfmGG6qY66FoOY4N0DGx-o1cP+_wdgSSnA@mail.gmail.com>
References: <CAJYonf2Y8ZcOYg7ALfmGG6qY66FoOY4N0DGx-o1cP+_wdgSSnA@mail.gmail.com>
Message-ID: <20151019183040.GA13747@coreboot.org>

* Mario Goljak <goljak at gmail.com> [150925 16:06]:
> Hi guys,
> 
> I just came across thinkpad forum thread where people are discuss about
> hardware mods for getting FHD screen on lenovo x220/x230 laptops.
> http://forum.thinkpads.com/viewtopic.php?f=43&t=106919&start=90
> ?
> What do you guys think, will this affect coreboot at all? Are there any
> necessary steps before playing with the screen?


You probably want to force your display to digital 2, as well, like in
the example pictures on http://letsitbe.jugem.jp/?eid=62

In coreboot you can do that in the int15 handler code, part of the
mainboard ramstage code.

Stefan


From pgeorgi at google.com  Mon Oct 19 20:44:54 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Mon, 19 Oct 2015 20:44:54 +0200
Subject: [coreboot] GPL license headers
Message-ID: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>

Hi all,

we recently removed the FSF addresses from license headers in our
files to avoid the maintenance of updating them every time the FSF
decides to move their office.

Now we also added checkpatch.pl that comes from Linux to automatically
ensure some consistency across the tree, and it looks for removal of
the entire paragraph.
Now, that may just make sense and I'm willing to update the scripts to
do that and update the tree.

The paragraph in question is:
----
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc.
----

Since the GPL is fairly well-known (incl where to find it), and our
tree already contains the license in the toplevel directory, that
paragraph shouldn't be necessary.


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


From peter at stuge.se  Mon Oct 19 20:52:27 2015
From: peter at stuge.se (Peter Stuge)
Date: Mon, 19 Oct 2015 20:52:27 +0200
Subject: [coreboot] GPL license headers
In-Reply-To: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
Message-ID: <20151019185227.11985.qmail@stuge.se>

Patrick Georgi wrote:
> The paragraph in question is:
> ----
> You should have received a copy of the GNU General Public License
> along with this program; if not, write to the Free Software
> Foundation, Inc.
> ----
> 
> Since the GPL is fairly well-known (incl where to find it), and our
> tree already contains the license in the toplevel directory, that
> paragraph shouldn't be necessary.
> 
> Opinions?

I agree with removing it.


//Peter


From stefan.reinauer at coreboot.org  Mon Oct 19 21:15:14 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Mon, 19 Oct 2015 21:15:14 +0200
Subject: [coreboot] Broadwell IGD (on Auron_Paine)
In-Reply-To: <56250E9D.80706@oxff.net>
References: <56250E9D.80706@oxff.net>
Message-ID: <20151019191514.GB13747@coreboot.org>

* Georg Wicherski <gw at oxff.net> [151019 17:39]:
> Hi,
> 
> thanks to Marc Jones' SGD patch for the Auron board
> (f3214d02482a4104d7276f06d6b326b2a54c4262), I was able to get my
> Auron_Paine up to ramstage.
> 
> Unfortunately, the IGD code in soc/intel/broadwell/ appears to be
> somewhat broken. Based off Aaron's guidance on IRC, I've pin-pointed the
> issue to be within igd_setup_panel . The first gtt_read there seems to
> hang already (BIOS_SPEW log attached). Find my current code with those
> debug prints at <http://review.coreboot.org/#/c/11907/2>. FWIW, I've
> tested with some commenting-out, etc. that it's any gtt_read that
> immediately causes a hang there. Also dumped the gtt_res, small excerpt
> from the log:
> 
> --8<--
> igd's gtt_res = { base=e0000000, size=1000000, limit=e0ffffff,
> flags=60000201 }
> igd_init: waited for pre-graphics delay to pass
> igd_init: went through early init
> igd_init: RP1 graphics frequency is set
> gtt_read(PCH_PORT_HOTPLUG)
> --8<--
> 
> People on IRC mentioned that this is an issue that people may have run
> into before on Broadwell, any suggestions on how to fix the hang there?
> 
> 
> Thanks,
> G

Hi Georg,

it seems that the refcode binary was not running. Can you verify that
it was part of the image and gets executed?

Stefan




From rminnich at gmail.com  Mon Oct 19 22:05:04 2015
From: rminnich at gmail.com (ron minnich)
Date: Mon, 19 Oct 2015 20:05:04 +0000
Subject: [coreboot] GPL license headers
In-Reply-To: <20151019185227.11985.qmail@stuge.se>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <20151019185227.11985.qmail@stuge.se>
Message-ID: <CAP6exY+3O-KB6_TZRUPq+b2bbb-0EnZwpC96+rr1+WaZJrf0wg@mail.gmail.com>

I won't say +1, that's so 2014.

Plus Two!

ron

On Mon, Oct 19, 2015 at 11:53 AM Peter Stuge <peter at stuge.se> wrote:

> Patrick Georgi wrote:
> > The paragraph in question is:
> > ----
> > You should have received a copy of the GNU General Public License
> > along with this program; if not, write to the Free Software
> > Foundation, Inc.
> > ----
> >
> > Since the GPL is fairly well-known (incl where to find it), and our
> > tree already contains the license in the toplevel directory, that
> > paragraph shouldn't be necessary.
> >
> > Opinions?
>
> I agree with removing it.
>
>
> //Peter
>
> --
> 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/20151019/5586e3bf/attachment.html>

From vbendeb at chromium.org  Mon Oct 19 22:29:31 2015
From: vbendeb at chromium.org (Vadim Bendebury)
Date: Mon, 19 Oct 2015 13:29:31 -0700
Subject: [coreboot] GPL license headers
In-Reply-To: <CAP6exY+3O-KB6_TZRUPq+b2bbb-0EnZwpC96+rr1+WaZJrf0wg@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <20151019185227.11985.qmail@stuge.se>
 <CAP6exY+3O-KB6_TZRUPq+b2bbb-0EnZwpC96+rr1+WaZJrf0wg@mail.gmail.com>
Message-ID: <CAC3GErHrRfWXHVZrRczF4u6tkK8gtdvDYGSih2W-=oxyY2iB+A@mail.gmail.com>

oh, I thought you'd say +1^2 :)

--vb

On Mon, Oct 19, 2015 at 1:05 PM, ron minnich <rminnich at gmail.com> wrote:
> I won't say +1, that's so 2014.
>
> Plus Two!
>
> ron
>
> On Mon, Oct 19, 2015 at 11:53 AM Peter Stuge <peter at stuge.se> wrote:
>>
>> Patrick Georgi wrote:
>> > The paragraph in question is:
>> > ----
>> > You should have received a copy of the GNU General Public License
>> > along with this program; if not, write to the Free Software
>> > Foundation, Inc.
>> > ----
>> >
>> > Since the GPL is fairly well-known (incl where to find it), and our
>> > tree already contains the license in the toplevel directory, that
>> > paragraph shouldn't be necessary.
>> >
>> > Opinions?
>>
>> I agree with removing it.
>>
>>
>> //Peter
>>
>> --
>> 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


From jwerner at chromium.org  Tue Oct 20 00:57:54 2015
From: jwerner at chromium.org (Julius Werner)
Date: Mon, 19 Oct 2015 15:57:54 -0700
Subject: [coreboot] [help]build cbfstool fail with cygwin64
In-Reply-To: <CAALi9ZPjRwWmNUSetKUcmNaRqhb+urcBL-a3yK7AcEdCANKHFw@mail.gmail.com>
References: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
 <20150914180756.GA32636@coreboot.org>
 <CAALi9ZNqRmFFRe2LjaG_0ybm6P+_76_BUvWAmacNMdUY8qK8kw@mail.gmail.com>
 <CAALi9ZMAoffYtgSEzE6teEd33+HxdSjf5mLnwCNzSETmw+fWKw@mail.gmail.com>
 <CAALi9ZPjRwWmNUSetKUcmNaRqhb+urcBL-a3yK7AcEdCANKHFw@mail.gmail.com>
Message-ID: <CAODwPW8zkco-ay3HDRkCJhzTn+kZXqX9a2X1WW9Yhg8fuuMS7Q@mail.gmail.com>

> is there anyway to dynamic define std to gnu99 when detect build with cygwin?

cbfstool is already defining -std=c99. I don't see a strong reason why
we shouldn't just change that to gnu99 globally.

>>> 2. default build will error as below,
>>> HOSTCC     cbfstool/cbfstool.o
>>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c: In function 'main':
>>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1075:5: error: array
>>> subscript has type 'char' [-Werror=char-subscripts]
>>>      if (tolower(suffix[0])=='k') {
>>>      ^

This sounds like an bug in cygwin and you should file it with them.
They're probably implementing tolower() in their standard header as a
macro which directly indexes an array with an argument. They should at
least be casting the argument inside that macro or they are not
POSIX-compliant.


From mr.nuke.me at gmail.com  Tue Oct 20 03:42:39 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Mon, 19 Oct 2015 18:42:39 -0700
Subject: [coreboot] GPL license headers
In-Reply-To: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
Message-ID: <56259C0F.106@gmail.com>

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

+2

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

+2

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

+2

> Opinions?

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

> Patrick

Alex


From stefan.reinauer at coreboot.org  Tue Oct 20 04:06:29 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Mon, 19 Oct 2015 19:06:29 -0700
Subject: [coreboot] [help]build cbfstool fail with cygwin64
In-Reply-To: <CAODwPW8zkco-ay3HDRkCJhzTn+kZXqX9a2X1WW9Yhg8fuuMS7Q@mail.gmail.com>
References: <CAALi9ZO2iZ0VHsrY3_Zv6GqJa70HEwLiVLzr=iS+WYd4P97fnQ@mail.gmail.com>
 <20150914180756.GA32636@coreboot.org>
 <CAALi9ZNqRmFFRe2LjaG_0ybm6P+_76_BUvWAmacNMdUY8qK8kw@mail.gmail.com>
 <CAALi9ZMAoffYtgSEzE6teEd33+HxdSjf5mLnwCNzSETmw+fWKw@mail.gmail.com>
 <CAALi9ZPjRwWmNUSetKUcmNaRqhb+urcBL-a3yK7AcEdCANKHFw@mail.gmail.com>
 <CAODwPW8zkco-ay3HDRkCJhzTn+kZXqX9a2X1WW9Yhg8fuuMS7Q@mail.gmail.com>
Message-ID: <a4cded68-411d-424c-a4df-618a4e68c31a@coreboot.org>

I think switching to c99 per default is a great idea. The problem below should be fixed by http://review.coreboot.org/#/c/11666/ and the following patch.

Stefan

On Oct 19, 2015, Julius Werner <jwerner at chromium.org> wrote:
>> is there anyway to dynamic define std to gnu99 when detect build with
>cygwin?
>
>cbfstool is already defining -std=c99. I don't see a strong reason why
>we shouldn't just change that to gnu99 globally.
>
>>>> 2. default build will error as below,
>>>> HOSTCC     cbfstool/cbfstool.o
>>>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c: In function
>'main':
>>>> /cygdrive/d/FW/coreboot/util/cbfstool/cbfstool.c:1075:5: error:
>array
>>>> subscript has type 'char' [-Werror=char-subscripts]
>>>>      if (tolower(suffix[0])=='k') {
>>>>      ^
>
>This sounds like an bug in cygwin and you should file it with them.
>They're probably implementing tolower() in their standard header as a
>macro which directly indexes an array with an argument. They should at
>least be casting the argument inside that macro or they are not
>POSIX-compliant.

-- 
Sent with <a href="https://play.google.com/store/apps/details?id=com.onegravity.k10.pro2"><b>K-@ Mail</b></a> - the evolution of emailing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151019/009a083a/attachment-0001.html>

From lynxis at fe80.eu  Tue Oct 20 11:47:07 2015
From: lynxis at fe80.eu (Alexander Couzens)
Date: Tue, 20 Oct 2015 11:47:07 +0200
Subject: [coreboot] screwdriver 0.3.0 released
Message-ID: <20151020114707.26953a32@lazus.yip>

hi,

I'm happy to announce the release of screwdriver 0.3.0.

screwdriver is a small distribution for bbb (beagleboneblack) based on OpenWrt supporting
spi flashing and usbdebug.

Take a look on the wiki page [1] for more infomation.

Best
lynxis

PS. help or feedback is welcome!

[1] http://www.coreboot.org/BBB_screwdriver
[2] https://github.com/lynxis/bbb_screwdriver_builder
[3] http://repo.fe80.eu/screwdriver/0.3.0/omap/generic/default/openwrt-0.3.0-omap-beagleboneblack-sdcard-vfat-am335x_evm.img
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
-------------- 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/20151020/c704ba15/attachment.sig>

From gregg.drwho8 at gmail.com  Tue Oct 20 15:23:00 2015
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 20 Oct 2015 09:23:00 -0400
Subject: [coreboot] screwdriver 0.3.0 released
In-Reply-To: <20151020114707.26953a32@lazus.yip>
References: <20151020114707.26953a32@lazus.yip>
Message-ID: <CAC5iaNHC6qB1cHFn=5ArOgNxGxgo00knAc=Nj8wFGNeM+U2K5A@mail.gmail.com>

Hello!
I'm impressed. In fact the wiki page is easy to understand. How well
does the USB debug module perform? Also for setting up the board to do
that, you should include a write up as well. Although I believe there
was one earlier in the Wiki.

(Writing as someone who's extremely familiar with the board, but does
not own one.)
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Oct 20, 2015 at 5:47 AM, Alexander Couzens <lynxis at fe80.eu> wrote:
> hi,
>
> I'm happy to announce the release of screwdriver 0.3.0.
>
> screwdriver is a small distribution for bbb (beagleboneblack) based on OpenWrt supporting
> spi flashing and usbdebug.
>
> Take a look on the wiki page [1] for more infomation.
>
> Best
> lynxis
>
> PS. help or feedback is welcome!
>
> [1] http://www.coreboot.org/BBB_screwdriver
> [2] https://github.com/lynxis/bbb_screwdriver_builder
> [3] http://repo.fe80.eu/screwdriver/0.3.0/omap/generic/default/openwrt-0.3.0-omap-beagleboneblack-sdcard-vfat-am335x_evm.img
> --
> Alexander Couzens
>
> mail: lynxis at fe80.eu
> jabber: lynxis at fe80.eu
> mobile: +4915123277221
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From pgeorgi at google.com  Tue Oct 20 19:29:32 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Tue, 20 Oct 2015 19:29:32 +0200
Subject: [coreboot] GPL license headers
In-Reply-To: <56259C0F.106@gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
Message-ID: <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>

2015-10-20 3:42 GMT+02:00 Alex G. <mr.nuke.me at gmail.com>:
> I'd go as far as removing the last two paragraphs completely. The "this
> comes with no warranty" boilerplate is only binding because it is also
> included in the GPL proper, not because it's slapped in developers'
> faces all so often.
Get (the right set of) lawyers to sign off on that.
So far, there's clearance to get rid of the last paragraph, but
dropping actual legalese sounds scary.


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


From rminnich at gmail.com  Tue Oct 20 19:54:13 2015
From: rminnich at gmail.com (ron minnich)
Date: Tue, 20 Oct 2015 17:54:13 +0000
Subject: [coreboot] GPL license headers
In-Reply-To: <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
 <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
Message-ID: <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>

Eben Moglen, who ought to know, guided us on the release rules for the Plan
9 GPL release.

Here is what he told us could go in each file:
/*
 * This file is part of the UCB release of Plan 9. It is subject to the
license
 * terms in the LICENSE file found in the top-level directory of this
 * distribution and at http://akaros.cs.berkeley.edu/files/Plan9License. No
 * part of the UCB release of Plan 9, including this file, may be copied,
 * modified, propagated, or distributed except according to the terms
contained
 * in the LICENSE file.
 */

And, then, to see the file:
https://github.com/Harvey-OS/harvey/blob/master/LICENSE

You really don't need all the text in each file. You don't have to believe
me but you can definitely believe Eben :-)

ron

On Tue, Oct 20, 2015 at 10:30 AM Patrick Georgi <pgeorgi at google.com> wrote:

> 2015-10-20 3:42 GMT+02:00 Alex G. <mr.nuke.me at gmail.com>:
> > I'd go as far as removing the last two paragraphs completely. The "this
> > comes with no warranty" boilerplate is only binding because it is also
> > included in the GPL proper, not because it's slapped in developers'
> > faces all so often.
> Get (the right set of) lawyers to sign off on that.
> So far, there's clearance to get rid of the last paragraph, but
> dropping actual legalese sounds scary.
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot 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/20151020/7d53d194/attachment.html>

From arpita.biswas07 at gmail.com  Tue Oct 20 21:26:37 2015
From: arpita.biswas07 at gmail.com (Arpita Biswas)
Date: Tue, 20 Oct 2015 12:26:37 -0700
Subject: [coreboot] Trying to flash coreboot onto on-board SPI chip of HP
 Envy H87 haswell chipset.
Message-ID: <CAHoSYHVsm4PTZ-P_OGu8MwyZvMXnyyOxujuHD_neJZfmydRogA@mail.gmail.com>

Hi all,

I am trying to update BIOS with coreboot onto HP Envy H87 haswell chipset
(ipm87_mp)  <http://www.newegg.com/Product/Product.aspx?Item=9SIA6392VN4810>.
I am using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip
(W25Q64). However dediprog doesn't detect the chip when it's soldered
on-board. On removing the chip from board, I can detect/read/write onto it
without any issues.

I've tried (and failed) with the following configurations :
(1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP (IO2)
---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD (IO3) --->
3.3V, VCC ---> 3.3V with motherboard power ON.

(2) Same config as above but I tried to isolate the chip by removing CMOS
battery + removing jumper on SPI header + powering OFF the motherboard.

(3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float.

(4) I tried using flashrom on the box too as internal programmer, but it
did not recognize the SPI chip. Error log says "Found Programmer flash chip
"Opaque flash chip" (8192 kB, Programmer-specific)."

I've a feeling that something on the motherboard is interfering with the
SPI chip since an off-board chip is working fine. Does anybody have any
pointers on what could be going wrong ?

Thanks in advance,
- Arpita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151020/10ff8a19/attachment.html>

From dhendrix at google.com  Tue Oct 20 23:05:16 2015
From: dhendrix at google.com (David Hendricks)
Date: Tue, 20 Oct 2015 14:05:16 -0700
Subject: [coreboot] Trying to flash coreboot onto on-board SPI chip of
 HP Envy H87 haswell chipset.
In-Reply-To: <CAHoSYHVsm4PTZ-P_OGu8MwyZvMXnyyOxujuHD_neJZfmydRogA@mail.gmail.com>
References: <CAHoSYHVsm4PTZ-P_OGu8MwyZvMXnyyOxujuHD_neJZfmydRogA@mail.gmail.com>
Message-ID: <CAKOoyUeXmjBxJvameNh1beiiKQ1xEwozRUT9cSovfFOq6PTEbA@mail.gmail.com>

On Tue, Oct 20, 2015 at 12:26 PM, Arpita Biswas <arpita.biswas07 at gmail.com>
wrote:

> Hi all,
>
> I am trying to update BIOS with coreboot onto HP Envy H87 haswell chipset
> (ipm87_mp)
> <http://www.newegg.com/Product/Product.aspx?Item=9SIA6392VN4810>. I am
> using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64).
> However dediprog doesn't detect the chip when it's soldered on-board. On
> removing the chip from board, I can detect/read/write onto it without any
> issues.
>
> I've tried (and failed) with the following configurations :
> (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP (IO2)
> ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD (IO3) --->
> 3.3V, VCC ---> 3.3V with motherboard power ON.
>
> (2) Same config as above but I tried to isolate the chip by removing CMOS
> battery + removing jumper on SPI header + powering OFF the motherboard.
>
> (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float.
>
> (4) I tried using flashrom on the box too as internal programmer, but it
> did not recognize the SPI chip. Error log says "Found Programmer flash chip
> "Opaque flash chip" (8192 kB, Programmer-specific)."
>
> I've a feeling that something on the motherboard is interfering with the
> SPI chip since an off-board chip is working fine. Does anybody have any
> pointers on what could be going wrong ?
>

I suspect your motherboard does not isolate the SPI ROM's voltage supply
and thus your Dediprog is effectively powering other components on the
board.

If you can find a way to hold the PCH and ME in reset while the board is
powered on, that might work. Or, with the board off, you can try using an
external power supply (the usual warnings about possibly frying your board
apply).



>
> Thanks in advance,
> - Arpita
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151020/6de213f1/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Tue Oct 20 23:20:56 2015
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 20 Oct 2015 23:20:56 +0200
Subject: [coreboot] FOSDEM deadlines now!
Message-ID: <5626B038.80901@gmx.net>

Hi,

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?

Stands: Deadline 2015-11-13 (24 days left)
I can send in the proposal if I'm not going to be alone there.
How many tables do we want for our stand/booth(s)?
Who is coming?

Lightning talks: Deadline 2015-11-27 (38 days left)
Short and to the point. Your 15-minute elevator pitch.
Can you sell the project?

All deadlines are at 23.59 UTC

Developer room proposal: Deadline EXPIRED
Maybe some developer room will accept talks/demos from us.

Regards,
Carl-Daniel



From retorayen at hotmail.com  Wed Oct 21 00:15:49 2015
From: retorayen at hotmail.com (Reto Rayen)
Date: Wed, 21 Oct 2015 00:15:49 +0200
Subject: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13
Message-ID: <DUB402-EAS30328B4FA97B1131E12901CA2390@phx.gbl>

Hi guys i am writing to about compiling a coreboot 4.1 bios for the PC Engines Alix 2d13 with ipxe support.

I tried so many different ways and even with ?VSA image? with blob support, but the bios start always hangs after ?RAM initialization?. Can may anyone help me?

Thank you in advance.


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

From lynxis at fe80.eu  Wed Oct 21 00:30:16 2015
From: lynxis at fe80.eu (Alexander Couzens)
Date: Wed, 21 Oct 2015 00:30:16 +0200
Subject: [coreboot] screwdriver 0.3.0 released
In-Reply-To: <CAC5iaNHC6qB1cHFn=5ArOgNxGxgo00knAc=Nj8wFGNeM+U2K5A@mail.gmail.com>
References: <20151020114707.26953a32@lazus.yip>
 <CAC5iaNHC6qB1cHFn=5ArOgNxGxgo00knAc=Nj8wFGNeM+U2K5A@mail.gmail.com>
Message-ID: <20151021003016.2b90239c@lazus.yip>

On Tue, 20 Oct 2015 09:23:00 -0400
Gregg Levine <gregg.drwho8 at gmail.com> wrote:

> Hello!
> I'm impressed. In fact the wiki page is easy to understand. How well
> does the USB debug module perform? Also for setting up the board to do
> that, you should include a write up as well. Although I believe there
> was one earlier in the Wiki.

any thoughts how to do that? could you write a small draft on what you
exactly mean?

best,
lynxis

ps. a pull-request is also welcome ;)
-- 
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/20151021/ca4eea09/attachment.sig>

From arpita.biswas07 at gmail.com  Wed Oct 21 01:51:15 2015
From: arpita.biswas07 at gmail.com (Arpita Biswas)
Date: Tue, 20 Oct 2015 16:51:15 -0700
Subject: [coreboot] Trying to flash coreboot onto on-board SPI chip of
 HP Envy H87 haswell chipset.
In-Reply-To: <CAKOoyUeXmjBxJvameNh1beiiKQ1xEwozRUT9cSovfFOq6PTEbA@mail.gmail.com>
References: <CAHoSYHVsm4PTZ-P_OGu8MwyZvMXnyyOxujuHD_neJZfmydRogA@mail.gmail.com>
 <CAKOoyUeXmjBxJvameNh1beiiKQ1xEwozRUT9cSovfFOq6PTEbA@mail.gmail.com>
Message-ID: <CAHoSYHWMPzT8MHvPzev+TamF2aMxEDVyFxAiDHoGwU+WURg8Xw@mail.gmail.com>

Hi David,

That did the trick !!! Thanks a bunch ! For anyone else interested, here is
the combination of things I did :

SOIC config as (1) mentioned earlier + held down the power button for 30
sec to reset it + removed CMOS battery + removed jumper on SPI header (that
cuts off the processor signal to SPI chip) + plugged in the power cable
(that way enough power was there throughout the board for dediprog to
detect) + removed the DIM (dunno if that made any difference, but did it
since a post mentioned it anyways!).

Dediprog then detected it sweetly :) :)

Cheers,
- Arpita

On Tue, Oct 20, 2015 at 2:05 PM, David Hendricks <dhendrix at google.com>
wrote:

>
>
> On Tue, Oct 20, 2015 at 12:26 PM, Arpita Biswas <arpita.biswas07 at gmail.com
> > wrote:
>
>> Hi all,
>>
>> I am trying to update BIOS with coreboot onto HP Envy H87 haswell
>> chipset (ipm87_mp)
>> <http://www.newegg.com/Product/Product.aspx?Item=9SIA6392VN4810>. I am
>> using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64).
>> However dediprog doesn't detect the chip when it's soldered on-board. On
>> removing the chip from board, I can detect/read/write onto it without any
>> issues.
>>
>> I've tried (and failed) with the following configurations :
>> (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP (IO2)
>> ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD (IO3) --->
>> 3.3V, VCC ---> 3.3V with motherboard power ON.
>>
>> (2) Same config as above but I tried to isolate the chip by removing CMOS
>> battery + removing jumper on SPI header + powering OFF the motherboard.
>>
>> (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float.
>>
>> (4) I tried using flashrom on the box too as internal programmer, but it
>> did not recognize the SPI chip. Error log says "Found Programmer flash chip
>> "Opaque flash chip" (8192 kB, Programmer-specific)."
>>
>> I've a feeling that something on the motherboard is interfering with the
>> SPI chip since an off-board chip is working fine. Does anybody have any
>> pointers on what could be going wrong ?
>>
>
> I suspect your motherboard does not isolate the SPI ROM's voltage supply
> and thus your Dediprog is effectively powering other components on the
> board.
>
> If you can find a way to hold the PCH and ME in reset while the board is
> powered on, that might work. Or, with the board off, you can try using an
> external power supply (the usual warnings about possibly frying your board
> apply).
>
>
>
>>
>> Thanks in advance,
>> - Arpita
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151020/b06c9839/attachment.html>

From dhendrix at google.com  Wed Oct 21 01:58:58 2015
From: dhendrix at google.com (David Hendricks)
Date: Tue, 20 Oct 2015 16:58:58 -0700
Subject: [coreboot] Trying to flash coreboot onto on-board SPI chip of
 HP Envy H87 haswell chipset.
In-Reply-To: <CAHoSYHWMPzT8MHvPzev+TamF2aMxEDVyFxAiDHoGwU+WURg8Xw@mail.gmail.com>
References: <CAHoSYHVsm4PTZ-P_OGu8MwyZvMXnyyOxujuHD_neJZfmydRogA@mail.gmail.com>
 <CAKOoyUeXmjBxJvameNh1beiiKQ1xEwozRUT9cSovfFOq6PTEbA@mail.gmail.com>
 <CAHoSYHWMPzT8MHvPzev+TamF2aMxEDVyFxAiDHoGwU+WURg8Xw@mail.gmail.com>
Message-ID: <CAKOoyUfHSDf25JK2gSNz8MySxM1jqnmKsQXVg=kLW4iYmuGJyA@mail.gmail.com>

Cool, glad it worked!

To make things slightly easier, you should also try keeping the CMOS
battery and DIM (whatever that is) in.

On Tue, Oct 20, 2015 at 4:51 PM, Arpita Biswas <arpita.biswas07 at gmail.com>
wrote:

> Hi David,
>
> That did the trick !!! Thanks a bunch ! For anyone else interested, here
> is the combination of things I did :
>
> SOIC config as (1) mentioned earlier + held down the power button for 30
> sec to reset it + removed CMOS battery + removed jumper on SPI header (that
> cuts off the processor signal to SPI chip) + plugged in the power cable
> (that way enough power was there throughout the board for dediprog to
> detect) + removed the DIM (dunno if that made any difference, but did it
> since a post mentioned it anyways!).
>
> Dediprog then detected it sweetly :) :)
>
> Cheers,
> - Arpita
>
> On Tue, Oct 20, 2015 at 2:05 PM, David Hendricks <dhendrix at google.com>
> wrote:
>
>>
>>
>> On Tue, Oct 20, 2015 at 12:26 PM, Arpita Biswas <
>> arpita.biswas07 at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am trying to update BIOS with coreboot onto HP Envy H87 haswell
>>> chipset (ipm87_mp)
>>> <http://www.newegg.com/Product/Product.aspx?Item=9SIA6392VN4810>. I am
>>> using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64).
>>> However dediprog doesn't detect the chip when it's soldered on-board. On
>>> removing the chip from board, I can detect/read/write onto it without any
>>> issues.
>>>
>>> I've tried (and failed) with the following configurations :
>>> (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP
>>> (IO2) ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD
>>> (IO3) ---> 3.3V, VCC ---> 3.3V with motherboard power ON.
>>>
>>> (2) Same config as above but I tried to isolate the chip by removing
>>> CMOS battery + removing jumper on SPI header + powering OFF the motherboard.
>>>
>>> (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float.
>>>
>>> (4) I tried using flashrom on the box too as internal programmer, but it
>>> did not recognize the SPI chip. Error log says "Found Programmer flash chip
>>> "Opaque flash chip" (8192 kB, Programmer-specific)."
>>>
>>> I've a feeling that something on the motherboard is interfering with the
>>> SPI chip since an off-board chip is working fine. Does anybody have any
>>> pointers on what could be going wrong ?
>>>
>>
>> I suspect your motherboard does not isolate the SPI ROM's voltage supply
>> and thus your Dediprog is effectively powering other components on the
>> board.
>>
>> If you can find a way to hold the PCH and ME in reset while the board is
>> powered on, that might work. Or, with the board off, you can try using an
>> external power supply (the usual warnings about possibly frying your board
>> apply).
>>
>>
>>
>>>
>>> Thanks in advance,
>>> - Arpita
>>>
>>> --
>>> coreboot mailing list: coreboot at coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>>
>> --
>> David Hendricks (dhendrix)
>> Systems Software Engineer, Google Inc.
>>
>
>


-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151020/4ba81afc/attachment.html>

From mr.nuke.me at gmail.com  Wed Oct 21 02:47:23 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Tue, 20 Oct 2015 17:47:23 -0700
Subject: [coreboot] GPL license headers
In-Reply-To: <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
 <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
 <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>
Message-ID: <5626E09B.3040607@gmail.com>

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

+2

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

You were saying, Patrick?

Alex


From gaumless at gmail.com  Wed Oct 21 04:19:47 2015
From: gaumless at gmail.com (Martin Roth)
Date: Tue, 20 Oct 2015 20:19:47 -0600
Subject: [coreboot] GPL license headers
In-Reply-To: <5626E09B.3040607@gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
 <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
 <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>
 <5626E09B.3040607@gmail.com>
Message-ID: <CA+e+Ov5AhBNOjqZY14LFf_8Ut9E2JTMDnNshkuaGsa4WNAKmJQ@mail.gmail.com>

I haven't seen any disagreement that we get rid of the entire third paragraph.

Alex votes that we should get rid of the second paragraph of the
header as well, and what Ron posted SEEMS to support that we can,
although the wording in that license header might be different enough
that it doesn't apply to our case.

Personally, I'm in favor of keeping the second paragraph.  It looks to
me like the first paragraph just discusses distribution, not
liability.  I don't really see any NEED to get rid of the second
paragraph.

Are there any other thoughts either way on getting rid of the second paragraph?

Martin



On Tue, Oct 20, 2015 at 6:47 PM, Alex G. <mr.nuke.me at gmail.com> wrote:
> On 10/20/2015 10:54 AM, ron minnich wrote:
>> Eben Moglen, who ought to know, guided us on the release rules for the
>> Plan 9 GPL release.
>>
>> Here is what he told us could go in each file:
>> /*
>>  * This file is part of the UCB release of Plan 9. It is subject to the
>> license
>>  * terms in the LICENSE file found in the top-level directory of this
>>  * distribution and at http://akaros.cs.berkeley.edu/files/Plan9License. No
>>  * part of the UCB release of Plan 9, including this file, may be copied,
>>  * modified, propagated, or distributed except according to the terms
>> contained
>>  * in the LICENSE file.
>>  */
>
> +2
>
>> On Tue, Oct 20, 2015 at 10:30 AM Patrick Georgi <pgeorgi at google.com
>> <mailto:pgeorgi at google.com>> wrote:
>>     Get (the right set of) lawyers to sign off on that.
>
> You were saying, Patrick?
>
> Alex
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From rminnich at gmail.com  Wed Oct 21 05:41:43 2015
From: rminnich at gmail.com (ron minnich)
Date: Wed, 21 Oct 2015 03:41:43 +0000
Subject: [coreboot] GPL license headers
In-Reply-To: <CA+e+Ov5AhBNOjqZY14LFf_8Ut9E2JTMDnNshkuaGsa4WNAKmJQ@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
 <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
 <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>
 <5626E09B.3040607@gmail.com>
 <CA+e+Ov5AhBNOjqZY14LFf_8Ut9E2JTMDnNshkuaGsa4WNAKmJQ@mail.gmail.com>
Message-ID: <CAP6exY+p7tO93zYTAyW7utMoobXGYEPnqQdcWZgyP4QxzaNqWg@mail.gmail.com>

Let me ask around.

ron

On Tue, Oct 20, 2015 at 7:20 PM Martin Roth <gaumless at gmail.com> wrote:

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

From kyosti.malkki at gmail.com  Wed Oct 21 06:15:37 2015
From: kyosti.malkki at gmail.com (=?ISO-8859-1?Q?Ky=F6sti_M=E4lkki?=)
Date: Wed, 21 Oct 2015 07:15:37 +0300
Subject: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13
In-Reply-To: <DUB402-EAS30328B4FA97B1131E12901CA2390@phx.gbl>
References: <DUB402-EAS30328B4FA97B1131E12901CA2390@phx.gbl>
Message-ID: <1445400937.11202.6.camel@obelix>

On ke, 2015-10-21 at 00:15 +0200, Reto Rayen wrote:
> Hi guys i am writing to about compiling a coreboot 4.1 bios for the PC Engines Alix 2d13 with ipxe support.
> 
> I tried so many different ways and even with ?VSA image? with blob support, but the bios start always hangs after ?RAM initialization?. Can may anyone help me?
> 
> Thank you in advance.
> 
> 

Hi

We have last record of PC Engines Alix 2d booting from August 2014 in
our board-status repository. Can You try to replicate this tested build
from there:

http://www.coreboot.org/Supported_Motherboards#pcengines.2Falix2d

I don't see any line "RAM initialization" in the log there, better
attach the actual console output in your mail.

Regards,
Ky?sti



From pgeorgi at google.com  Wed Oct 21 09:11:02 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Wed, 21 Oct 2015 09:11:02 +0200
Subject: [coreboot] GPL license headers
In-Reply-To: <CAP6exY+p7tO93zYTAyW7utMoobXGYEPnqQdcWZgyP4QxzaNqWg@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
 <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
 <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>
 <5626E09B.3040607@gmail.com>
 <CA+e+Ov5AhBNOjqZY14LFf_8Ut9E2JTMDnNshkuaGsa4WNAKmJQ@mail.gmail.com>
 <CAP6exY+p7tO93zYTAyW7utMoobXGYEPnqQdcWZgyP4QxzaNqWg@mail.gmail.com>
Message-ID: <CAE-gjdUL6qja2+3hF=cz7BdUd4xDu8FCQPJRgfpLw8e-NS+sag@mail.gmail.com>

One issue brought up the last time we had this discussion was that
lawyers prefer to have their tools (eg. license scanners) continue to
work, which is why we shouldn't reduce the length too much (we had a
number of proposals with just two lines back then). Referring to an
external file is alright, as long as you assume that the code never
leaves the context of the repository.


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


From echelon at free.fr  Wed Oct 21 10:15:30 2015
From: echelon at free.fr (echelon at free.fr)
Date: Wed, 21 Oct 2015 10:15:30 +0200 (CEST)
Subject: [coreboot] =?utf-8?q?Re=C2=A0=3A__FOSDEM_deadlines_now!?=
In-Reply-To: <5626B038.80901@gmx.net>
Message-ID: <1648225735.107236173.1445415330101.JavaMail.root@zimbra6-e1.priv.proxad.net>

+1

* for the stands count me in : I can bring my AMD boards and if all is going well I will be able to do demos on my G505s laptop. (I will also bring various electronic stuff and tools..)
* for the main tracks I cannot help unfortunately
* for the lightining traks I have some (bold!) ideeas but they are not mature yet (and I must first discuss with you about this .. maybe on irc..)
Regards,
 Florentin

PS : an announcement about the next coreboot hackaton in Paris will arrive soon!.. :-)


----- Mail d'origine -----
De: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
?: coreboot <coreboot at coreboot.org>, flashrom <flashrom at flashrom.org>
Envoy?: Tue, 20 Oct 2015 23:20:56 +0200 (CEST)
Objet: [coreboot] FOSDEM deadlines now!

Hi,

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?

Stands: Deadline 2015-11-13 (24 days left)
I can send in the proposal if I'm not going to be alone there.
How many tables do we want for our stand/booth(s)?
Who is coming?

Lightning talks: Deadline 2015-11-27 (38 days left)
Short and to the point. Your 15-minute elevator pitch.
Can you sell the project?

All deadlines are at 23.59 UTC

Developer room proposal: Deadline EXPIRED
Maybe some developer room will accept talks/demos from us.

Regards,
Carl-Daniel


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



From mr.nuke.me at gmail.com  Wed Oct 21 11:00:42 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Wed, 21 Oct 2015 02:00:42 -0700
Subject: [coreboot] GPL license headers
In-Reply-To: <CAE-gjdUL6qja2+3hF=cz7BdUd4xDu8FCQPJRgfpLw8e-NS+sag@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
 <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
 <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>
 <5626E09B.3040607@gmail.com>
 <CA+e+Ov5AhBNOjqZY14LFf_8Ut9E2JTMDnNshkuaGsa4WNAKmJQ@mail.gmail.com>
 <CAP6exY+p7tO93zYTAyW7utMoobXGYEPnqQdcWZgyP4QxzaNqWg@mail.gmail.com>
 <CAE-gjdUL6qja2+3hF=cz7BdUd4xDu8FCQPJRgfpLw8e-NS+sag@mail.gmail.com>
Message-ID: <5627543A.9030005@gmail.com>

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

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

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

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

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

I might be partially guilty for that.

Alex


From retorayen at hotmail.com  Wed Oct 21 23:00:31 2015
From: retorayen at hotmail.com (Reto Rayen)
Date: Wed, 21 Oct 2015 23:00:31 +0200
Subject: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13
Message-ID: <DUB402-EAS296E4C123C2FCFC7D5E04F4A2380@phx.gbl>

Hi guys i get it working to boot up a coreboot bios with coreboot version 4.0. Thanks to PaulePanter

Here are the steps:

1.) Clone the coreboot git -> git clone http://review.coreboot.org/coreboot.git
2.) Revert back to the coreboot version -> git reset --hard a0a3727dbbd7f3ae9f9021e0797ce2fc61d1b79e
3.) Download the following .config file for compiling -> http://review.coreboot.org/gitweb?p=board-status.git;a=blob_plain;f=pcengines/alix2d/4.0-6723-ga0a3727-dirty/2014-08-15T23:01:34Z/config.txt;hb=HEAD
4.) Open the .config file with ?make menuconfig? and close it again
5.) As least you do the ?make? and write the coreboot bios on your ?Pc Engines Alix2d13?.

PaulePanter will help me now get coreboot bios working with the master code. So with the actual coreboot 4.1



Gesendet von Mail f?r Windows 10



Von: Reto Rayen
Gesendet: Mittwoch, 21. Oktober 2015 15:30
An: Martin Roth
Betreff: Re: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13


Thank you Martin

I will try it out and let you know.

Gesendet von Mail f?r Windows 10



Von: Martin Roth
Gesendet: Mittwoch, 21. Oktober 2015 00:48
An: Reto Rayen
Betreff: Re: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13


Hi!? We can absolutely help.

Generally the best way to get coreboot help is on the #coreboot IRC
channel on freenode.net.? If you plan to continue working with
coreboot, you probably want to set up an IRC client, but for now, you
can use a web interface:
https://webchat.freenode.net/?channels=#coreboot

The first things we're going to want are a console log, and to know
how the system is configured (Your .config)

These would generally get posted to your favorite text file site, then
just give us the URL ( pastebin.com )


In your case, I'd recommend that you look at the alix2d configuration
that was posted to the coreboot board-status repository.
http://review.coreboot.org/gitweb?p=board-status.git;a=tree;f=pcengines/alix2d/4.0-6723-ga0a3727/2014-08-15T01:44:46Z

I'd suggest that you check out the revision of the git repo listed in
the revision.txt file, copy the config.txt to your .config (save yours
first), and try to build a binary similar to what was used before.
You can then compare your console output to what was posted.


Hope this helps.
Martin

On Tue, Oct 20, 2015 at 4:15 PM, Reto Rayen <retorayen at hotmail.com> wrote:
> Hi guys i am writing to about compiling a coreboot 4.1 bios for the PC
> Engines Alix 2d13 with ipxe support.
>
>
>
> I tried so many different ways and even with ?VSA image? with blob support,
> but the bios start always hangs after ?RAM initialization?. Can may anyone
> help me?
>
>
>
> Thank you in advance.
>
>
>
>
>
>
> --
> 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/20151021/d9f2b222/attachment.html>

From retorayen at hotmail.com  Wed Oct 21 23:18:31 2015
From: retorayen at hotmail.com (Reto Rayen)
Date: Wed, 21 Oct 2015 23:18:31 +0200
Subject: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13
Message-ID: <DUB402-EAS3621AD04D2932EC4889D243A2380@phx.gbl>

Hi guys

When i try with a pxe image (ipxe rom image), then it gets not loaded. Can may anyone help to get this bios working with ipxe. Here are the logs of the startup:

http://pastebin.com/ASfZGsZD

Thank you in advance.

Gesendet von Mail f?r Windows 10



Von: Reto Rayen
Gesendet: Mittwoch, 21. Oktober 2015 22:59
An: Martin Roth;coreboot at coreboot.org
Betreff: Re: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13


Hi guys i get it working to boot up a coreboot bios with coreboot version 4.0. Thanks to PaulePanter

Here are the steps:

1.)??? Clone the coreboot git -> git clone http://review.coreboot.org/coreboot.git
2.)??? Revert back to the coreboot version -> git reset --hard a0a3727dbbd7f3ae9f9021e0797ce2fc61d1b79e
3.)??? Download the following .config file for compiling -> http://review.coreboot.org/gitweb?p=board-status.git;a=blob_plain;f=pcengines/alix2d/4.0-6723-ga0a3727-dirty/2014-08-15T23:01:34Z/config.txt;hb=HEAD
4.)??? Open the .config file with ?make menuconfig? and close it again
5.)??? As least you do the ?make? and write the coreboot bios on your ?Pc Engines Alix2d13?.

PaulePanter will help me now get coreboot bios working with the master code. So with the actual coreboot 4.1



Gesendet von Mail f?r Windows 10



Von: Reto Rayen
Gesendet: Mittwoch, 21. Oktober 2015 15:30
An: Martin Roth
Betreff: Re: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13


Thank you Martin

I will try it out and let you know.

Gesendet von Mail f?r Windows 10



Von: Martin Roth
Gesendet: Mittwoch, 21. Oktober 2015 00:48
An: Reto Rayen
Betreff: Re: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13


Hi!? We can absolutely help.

Generally the best way to get coreboot help is on the #coreboot IRC
channel on freenode.net.? If you plan to continue working with
coreboot, you probably want to set up an IRC client, but for now, you
can use a web interface:
https://webchat.freenode.net/?channels=#coreboot

The first things we're going to want are a console log, and to know
how the system is configured (Your .config)

These would generally get posted to your favorite text file site, then
just give us the URL ( pastebin.com )


In your case, I'd recommend that you look at the alix2d configuration
that was posted to the coreboot board-status repository.
http://review.coreboot.org/gitweb?p=board-status.git;a=tree;f=pcengines/alix2d/4.0-6723-ga0a3727/2014-08-15T01:44:46Z

I'd suggest that you check out the revision of the git repo listed in
the revision.txt file, copy the config.txt to your .config (save yours
first), and try to build a binary similar to what was used before.
You can then compare your console output to what was posted.


Hope this helps.
Martin

On Tue, Oct 20, 2015 at 4:15 PM, Reto Rayen <retorayen at hotmail.com> wrote:
> Hi guys i am writing to about compiling a coreboot 4.1 bios for the PC
> Engines Alix 2d13 with ipxe support.
>
>
>
> I tried so many different ways and even with ?VSA image? with blob support,
> but the bios start always hangs after ?RAM initialization?. Can may anyone
> help me?
>
>
>
> Thank you in advance.
>
>
>
>
>
>
> --
> 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/20151021/e45652f3/attachment.html>

From kyosti.malkki at gmail.com  Thu Oct 22 07:21:46 2015
From: kyosti.malkki at gmail.com (=?ISO-8859-1?Q?Ky=F6sti_M=E4lkki?=)
Date: Thu, 22 Oct 2015 08:21:46 +0300
Subject: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13
In-Reply-To: <DUB402-EAS3621AD04D2932EC4889D243A2380@phx.gbl>
References: <DUB402-EAS3621AD04D2932EC4889D243A2380@phx.gbl>
Message-ID: <1445491306.17851.23.camel@obelix>

On ke, 2015-10-21 at 23:18 +0200, Reto Rayen wrote:
> Hi guys
> 
> When i try with a pxe image (ipxe rom image), then it gets not loaded. Can may anyone help to get this bios working with ipxe. Here are the logs of the startup:
> 
> http://pastebin.com/ASfZGsZD
> 
> Thank you in advance.
> 

Hi

My first impression from the logs is that SeaBIOS did execute option
roms. Did you enable serial console for iPXE build?

Also note that the VIA NICs you have are listed as "expected to work but
not confirmed" for iPXE. Given that this is a very old controller,
driver may be more stable or tested in the Etherboot -repository.

Regards,
Ky?sti


> Gesendet von Mail f?r Windows 10
> 
> 
> 
> Von: Reto Rayen
> Gesendet: Mittwoch, 21. Oktober 2015 22:59
> An: Martin Roth;coreboot at coreboot.org
> Betreff: Re: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13
> 
> 
> Hi guys i get it working to boot up a coreboot bios with coreboot version 4.0. Thanks to PaulePanter
> 
> Here are the steps:
> 
> 1.)    Clone the coreboot git -> git clone http://review.coreboot.org/coreboot.git
> 2.)    Revert back to the coreboot version -> git reset --hard a0a3727dbbd7f3ae9f9021e0797ce2fc61d1b79e
> 3.)    Download the following .config file for compiling -> http://review.coreboot.org/gitweb?p=board-status.git;a=blob_plain;f=pcengines/alix2d/4.0-6723-ga0a3727-dirty/2014-08-15T23:01:34Z/config.txt;hb=HEAD
> 4.)    Open the .config file with ?make menuconfig? and close it again
> 5.)    As least you do the ?make? and write the coreboot bios on your ?Pc Engines Alix2d13?.
> 
> PaulePanter will help me now get coreboot bios working with the master code. So with the actual coreboot 4.1
> 
> 
> 
> Gesendet von Mail f?r Windows 10
> 
> 
> 
> Von: Reto Rayen
> Gesendet: Mittwoch, 21. Oktober 2015 15:30
> An: Martin Roth
> Betreff: Re: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13
> 
> 
> Thank you Martin
> 
> I will try it out and let you know.
> 
> Gesendet von Mail f?r Windows 10
> 
> 
> 
> Von: Martin Roth
> Gesendet: Mittwoch, 21. Oktober 2015 00:48
> An: Reto Rayen
> Betreff: Re: [coreboot] Coreboot 4.1 for PC Engines Alix 2d13
> 
> 
> Hi!  We can absolutely help.
> 
> Generally the best way to get coreboot help is on the #coreboot IRC
> channel on freenode.net.  If you plan to continue working with
> coreboot, you probably want to set up an IRC client, but for now, you
> can use a web interface:
> https://webchat.freenode.net/?channels=#coreboot
> 
> The first things we're going to want are a console log, and to know
> how the system is configured (Your .config)
> 
> These would generally get posted to your favorite text file site, then
> just give us the URL ( pastebin.com )
> 
> 
> In your case, I'd recommend that you look at the alix2d configuration
> that was posted to the coreboot board-status repository.
> http://review.coreboot.org/gitweb?p=board-status.git;a=tree;f=pcengines/alix2d/4.0-6723-ga0a3727/2014-08-15T01:44:46Z
> 
> I'd suggest that you check out the revision of the git repo listed in
> the revision.txt file, copy the config.txt to your .config (save yours
> first), and try to build a binary similar to what was used before.
> You can then compare your console output to what was posted.
> 
> 
> Hope this helps.
> Martin
> 
> On Tue, Oct 20, 2015 at 4:15 PM, Reto Rayen <retorayen at hotmail.com> wrote:
> > Hi guys i am writing to about compiling a coreboot 4.1 bios for the PC
> > Engines Alix 2d13 with ipxe support.
> >
> >
> >
> > I tried so many different ways and even with ?VSA image? with blob support,
> > but the bios start always hangs after ?RAM initialization?. Can may anyone
> > help me?
> >
> >
> >
> > Thank you in advance.
> >
> >
> >
> >
> >
> >
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
> 
> 
> 
> 
> 
> 





From stefan.reinauer at coreboot.org  Thu Oct 22 20:00:44 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Thu, 22 Oct 2015 20:00:44 +0200
Subject: [coreboot] GPL license headers
In-Reply-To: <CAP6exY+p7tO93zYTAyW7utMoobXGYEPnqQdcWZgyP4QxzaNqWg@mail.gmail.com>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
 <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
 <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>
 <5626E09B.3040607@gmail.com>
 <CA+e+Ov5AhBNOjqZY14LFf_8Ut9E2JTMDnNshkuaGsa4WNAKmJQ@mail.gmail.com>
 <CAP6exY+p7tO93zYTAyW7utMoobXGYEPnqQdcWZgyP4QxzaNqWg@mail.gmail.com>
Message-ID: <20151022180044.GA13053@coreboot.org>

>From my previous discussions with lawyers on the topic, the third
paragraph is unproblematic to remove. With resolutions of today's
monitors and keyboards often having a page down key, keeping the second
paragraph seems like a good compromise to stay friends with the legal
experts and err on the safe side.

Stefan

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



From vinibali1 at gmail.com  Thu Oct 22 16:59:29 2015
From: vinibali1 at gmail.com (=?UTF-8?Q?Bal=C3=A1zs_Vinarz?=)
Date: Thu, 22 Oct 2015 16:59:29 +0200
Subject: [coreboot] Asus M2N-E no boot, post codes A5 80 73
Message-ID: <CAO=iczHZG_fA4-T15TyiJHtV-XRZh_26hfdR+DKo=3CSDJsB3w@mail.gmail.com>

Hi.
I compiled from the source about 6 months and now. The mobo is still unable
to boot.
Serial debugs are attached, i tried with many memory-modules in all sockets.
There are two options, when the postcard jumps between codes A5 and 80:

#START
coreboot-4.1-781-g744729a Tue Oct 20 14:50:25 UTC 2015 romstage starting...

*sysinfo range: [000c8020,000c8750]

bsp_apicid=0x00

Enabling routing table for node 0 done.

Enabling UP settings

Disabling read/write/fill probes for UP... done.

coherent_ht_finalize

done

core0 started:

started ap apicid:

SBLink=00

NC node|link=00

entering optimize_link_incoherent_ht

sysinfo->link_pair_num=0x1

entering ht_optimize_link

pos=0x8a, unfiltered freq_cap=0x8075

pos=0x8a, filtered freq_cap=0x75

pos=0x52, unfiltered freq_cap=0x7f

pos=0x52, filtered freq_cap=0x7f

freq_cap1=0x75, freq_cap2=0x7f

dev1 old_freq=0x6, freq=0x6, needs_reset=0x0

dev2 old_freq=0x6, freq=0x6, needs_reset=0x0

width_cap1=0x11, width_cap2=0x11

dev1 input ln_width1=0x4, ln_width2=0x4

dev1 input width=0x1

dev1 output ln_width1=0x4, ln_width2=0x4

dev1 input|output width=0x11

old dev1 input|output width=0x11

dev2 input|output width=0x11

old dev2 input|output width=0x11

after ht_optimize_link for link pair 0, reset_needed=0x0

after optimize_link_read_pointers_chain, reset_needed=0x0

mcp55_num: 01

Ram1.00

setting up CPU 00 northbridge registers

done.

Ram2.00

sdram_set_spd_registers: paramx :000cff38

Unbuffered

333MHz

333MHz

Interleaving disabled

RAM end at 0x00100000 kB

Ram3

Initializing memory:  done

Setting variable MTRR 2, base:    0MB, range: 1024MB, type WB

set DQS timing:RcvrEn:Pass1: 00

 CTLRMaxDelay=ae

Total DQS Training : tsc [00]=0000000012a29d35

Total DQS Training : tsc [01]=4d33333300000002

Total DQS Training : tsc [02]=0000000000007a48

Total DQS Training : tsc [03]=fff85d4d00000064

Ram4

Prepare CAR migration and stack regions... Fill [001ff400-001fffff] ...
Done
Copying data from cache to RAM...  Copy [000c8000-000c877f] to [001ff880 -
001fe
Switching to use RAM as stack...





INIT detected from  --- { APICID = 00 NODEID = 00 COREID = 00} ---



Issuing SOFT_RESET...

coreboot-4.1-781-g744729a Tue Oct 20 14:50:25 UTC 2015 romstage starting...

*sysinfo range: [000c8020,000c8750]

bsp_apicid=0x00

Enabling routing table for node 0 done.

Enabling UP settings

Disabling read/write/fill probes for UP... done.

coherent_ht_finalize

done

core0 started:

started ap apicid:

SBLink=00

NC node|link=00

entering optimize_link_incoherent_ht

sysinfo->link_pair_num=0x1

entering ht_optimize_link

pos=0x8a, unfiltered freq_cap=0x8075

pos=0x8a, filtered freq_cap=0x75

pos=0x52, unfiltered freq_cap=0x7f

pos=0x52, filtered freq_cap=0x7f

freq_cap1=0x75, freq_cap2=0x7f

dev1 old_freq=0x6, freq=0x6, needs_reset=0x0

dev2 old_freq=0x6, freq=0x6, needs_reset=0x0

width_cap1=0x11, width_cap2=0x11

dev1 input ln_width1=0x4, ln_width2=0x4

dev1 input width=0x1

dev1 output ln_width1=0x4, ln_width2=0x4

dev1 input|output width=0x11

old dev1 input|output width=0x11

dev2 input|output width=0x11

old dev2 input|output width=0x11

after ht_optimize_link for link pair 0, reset_needed=0x0

after optimize_link_read_pointers_chain, reset_needed=0x0

mcp55_num: 01

Ram1.00

setting up CPU 00 northbridge registers

done.

Ram2.00

sdram_set_spd_registers: paramx :000cff38

Unbuffered

333MHz

333MHz

Interleaving disabled

RAM end at 0x00100000 kB

Ram3

Initializing memory:  done

Setting variable MTRR 2, base:    0MB, range: 1024MB, type WB

set DQS timing:RcvrEn:Pass1: 00

 CTLRMaxDelay=ae

Total DQS Training : tsc [00]=0000000012a29d35

Total DQS Training : tsc [01]=4d33333300000002

Total DQS Training : tsc [02]=0000000000007a48

Total DQS Training : tsc [03]=fff85d4d00000064

Ram4

Prepare CAR migration and stack regions... Fill [001ff400-001fffff] ...
Done
Copying data from cache to RAM...  Copy [000c8000-000c877f] to [001ff880 -
001fe
Switching to use RAM as stack...





INIT detected from  --- { APICID = 00 NODEID = 00 COREID = 00} ---



Issuing SOFT_RESET...

#END

And when it turn off and ends with postcode 73:

#START

ENDS WITH post 73

coreboot-4.1-781-g744729a Tue Oct 20 14:50:25 UTC 2015 romstage starting...
*sysinfo range: [000c8020,000c8750]
bsp_apicid=0x00
Enabling routing table for node 0 done.
Enabling UP settings
Disabling read/write/fill probes for UP... done.
coherent_ht_finalize
done
core0 started:
started ap apicid:
SBLink=00
NC node|link=00
entering optimize_link_incoherent_ht
sysinfo->link_pair_num=0x1
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x75
pos=0x52, unfiltered freq_cap=0x807f
pos=0x52, filtered freq_cap=0x7f
freq_cap1=0x75, freq_cap2=0x7f
dev1 old_freq=0x0, freq=0x6, needs_reset=0x1
dev2 old_freq=0x0, freq=0x6, needs_reset=0x1
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
after ht_optimize_link for link pair 0, reset_needed=0x1
after optimize_link_read_pointers_chain, reset_needed=0x1
mcp55_num: 01
ht reset -


coreboot-4.1-781-g744729a Tue Oct 20 14:50:25 UTC 2015 romstage starting...
*sysinfo range: [000c8020,000c8750]
bsp_apicid=0x00
Enabling routing table for node 0 done.
Enabling UP settings
Disabling read/write/fill probes for UP... done.
coherent_ht_finalize
done
core0 started:
started ap apicid:
SBLink=00
NC node|link=00
entering optimize_link_incoherent_ht
sysinfo->link_pair_num=0x1
entering ht_optimize_link
pos=0x8a, unfiltered freq_cap=0x8075
pos=0x8a, filtered freq_cap=0x75
pos=0x52, unfiltered freq_cap=0x7f
pos=0x52, filtered freq_cap=0x7f
freq_cap1=0x75, freq_cap2=0x7f
dev1 old_freq=0x6, freq=0x6, needs_reset=0x0
dev2 old_freq=0x6, freq=0x6, needs_reset=0x0
width_cap1=0x11, width_cap2=0x11
dev1 input ln_width1=0x4, ln_width2=0x4
dev1 input width=0x1
dev1 output ln_width1=0x4, ln_width2=0x4
dev1 input|output width=0x11
old dev1 input|output width=0x11
dev2 input|output width=0x11
old dev2 input|output width=0x11
after ht_optimize_link for link pair 0, reset_needed=0x0
after optimize_link_read_pointers_chain, reset_needed=0x0
mcp55_num: 01
Ram1.00
setting up CPU 00 northbridge registers
done.
Ram2.00
sdram_set_spd_registers: paramx :000cff38
Unbuffered
333MHz
333MHz
Interleaved
RAM end at 0x00100000 kB
Ram3
Initializing memory:  done
Setting variable MTRR 2, base:    0MB, range: 1024MB, type WB
set DQS timing:RcvrEn:Pass1: 00
 CTLRMaxDelay=12
 done
set DQS timing:DQSPos: 00
TrainDQSRdWrPos: buf_a:000cfa20
TrainDQSPos: MutualCSPassW[48] :000cf8f8
TrainDQSPos: MutualCSPassW[48] :000cf8f8
TrainDQSPos: MutualCSPassW[48] :000cf8f8
TrainDQSPos: MutualCSPassW[48] :000cf908
 done
set DQS timing:RcvrEn:Pass2: 00
 CTLRMaxDelay=57
 done
Total DQS Training : tsc [00]=0000000012945351
Total DQS Training : tsc [01]=0000000013137d9b
Total DQS Training : tsc [02]=000000001f9559cb
Total DQS Training : tsc [03]=00000000205fad07
Ram4
Prepare CAR migration and stack regions... Fill [001ff400-001fffff] ... Done
Copying data from cache to RAM...  Copy [000c8000-000c877f] to [001ff880 ?
001f
Switching to use RAM as stack... Top about 001ff86c ... Done
Disabling cache as ram now
Prepare ramstage memory region...  Fill [00000000-001ff3ff] ... Done
CBFS provider active.
CBFS @ 0 size 7fc00
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset c240 size b72d
'fallback/ramstage' located at offset: c278 size: b72d


coreboot-4.1-781-g744729a Tue Oct 20 14:50:25 UTC 2015 ramstage starting...
Enumerating buses...
Show all devs... Before device enumeration.
Root Device: enabled 1
CPU_CLUSTER: 0: enabled 1
APIC: 00: enabled 1
DOMAIN: 0000: enabled 1
PCI: 00:18.0: enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:01.0: enabled 1
PNP: 002e.0: enabled 1
PNP: 002e.1: enabled 1
PNP: 002e.2: enabled 0
PNP: 002e.3: enabled 1
PNP: 002e.4: enabled 1
PNP: 002e.5: enabled 1
PNP: 002e.6: enabled 1
PNP: 002e.7: enabled 0
PNP: 002e.8: enabled 0
PNP: 002e.9: enabled 0
PNP: 002e.a: enabled 0
PCI: 00:01.1: enabled 1
I2C: 00:50: enabled 1
I2C: 00:51: enabled 1
I2C: 00:52: enabled 1
I2C: 00:53: enabled 1
PCI: 00:02.0: enabled 1
PCI: 00:02.1: enabled 1
PCI: 00:04.0: enabled 1
PCI: 00:05.0: enabled 1
PCI: 00:05.1: enabled 1
PCI: 00:05.2: enabled 1
PCI: 00:06.0: enabled 1
PCI: 00:06.1: enabled 1
PCI: 00:08.0: enabled 1
PCI: 00:09.0: enabled 0
PCI: 00:0a.0: enabled 1
PCI: 00:0b.0: enabled 0
PCI: 00:0c.0: enabled 1
PCI: 00:0d.0: enabled 1
PCI: 00:0e.0: enabled 0
PCI: 00:0f.0: enabled 1
PCI: 00:18.1: enabled 1
PCI: 00:18.2: enabled 1
PCI: 00:18.3: enabled 1
Compare with tree...
Root Device: enabled 1
 CPU_CLUSTER: 0: enabled 1
  APIC: 00: enabled 1
 DOMAIN: 0000: enabled 1
  PCI: 00:18.0: enabled 1
   PCI: 00:00.0: enabled 1
   PCI: 00:01.0: enabled 1
    PNP: 002e.0: enabled 1
    PNP: 002e.1: enabled 1
    PNP: 002e.2: enabled 0
    PNP: 002e.3: enabled 1
    PNP: 002e.4: enabled 1
    PNP: 002e.5: enabled 1
    PNP: 002e.6: enabled 1
    PNP: 002e.7: enabled 0
    PNP: 002e.8: enabled 0
    PNP: 002e.9: enabled 0
    PNP: 002e.a: enabled 0
   PCI: 00:01.1: enabled 1
    I2C: 00:50: enabled 1
    I2C: 00:51: enabled 1
    I2C: 00:52: enabled 1
    I2C: 00:53: enabled 1
   PCI: 00:02.0: enabled 1
   PCI: 00:02.1: enabled 1
   PCI: 00:04.0: enabled 1
   PCI: 00:05.0: enabled 1
   PCI: 00:05.1: enabled 1
   PCI: 00:05.2: enabled 1
   PCI: 00:06.0: enabled 1
   PCI: 00:06.1: enabled 1
   PCI: 00:08.0: enabled 1
   PCI: 00:09.0: enabled 0
   PCI: 00:0a.0: enabled 1
   PCI: 00:0b.0: enabled 0
   PCI: 00:0c.0: enabled 1
   PCI: 00:0d.0: enabled 1
   PCI: 00:0e.0: enabled 0
   PCI: 00:0f.0: enabled 1
  PCI: 00:18.1: enabled 1
  PCI: 00:18.2: enabled 1
  PCI: 00:18.3: enabled 1
Root Device scanning...
root_dev_scan_bus for Root Device
setup_bsp_ramtop, TOP MEM: msr.lo = 0x40000000, msr.hi = 0x00000000
setup_bsp_ramtop, TOP MEM2: msr.lo = 0x00000000, msr.hi = 0x00000000
CPU_CLUSTER: 0 enabled
DOMAIN: 0000 enabled
CPU_CLUSTER: 0 scanning...
  PCI: 00:18.3 siblings=0
#[24;9HFound Rev E or Rev F later single core
CPU: APIC: 00 enabled
DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 00
PCI: 00:18.0 [1022/1100] bus ops
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:18.0 scanning...
PCI: 00:00.0 [10de/0369] ops
PCI: 00:00.0 [10de/0369] enabled
Capability: type 0x08 @ 0x44
flags: 0x01e0
PCI: 00:00.0 count: 000f static_count: 0010
PCI: 00:00.0 [10de/0369] enabled next_unitid: 0010
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [10de/0369] enabled
PCI: 00:01.0 [10de/0000] bus ops
PCI: 00:01.0 [10de/0360] enabled
PCI: 00:01.1 [10de/0368] bus ops
PCI: 00:01.1 [10de/0368] enabled
PCI: 00:01.2 [10de/036a] enabled
PCI: 00:01.3 [10de/036b] enabled
PCI: 00:02.0 [10de/036c] ops
PCI: 00:02.0 [10de/036c] enabled
PCI: 00:02.1 [10de/036d] ops
PCI: 00:02.1 [10de/036d] enabled
PCI: 00:04.0 [10de/036e] ops
PCI: 00:04.0 [10de/036e] enabled
PCI: 00:05.0 [10de/037f] ops
PCI: 00:05.0 [10de/037f] enabled
PCI: 00:05.1 [10de/037f] ops
PCI: 00:05.1 [10de/037f] enabled
PCI: 00:05.2 [10de/037f] ops
PCI: 00:05.2 [10de/037f] enabled
PCI: 00:06.0 [10de/0370] bus ops
PCI: 00:06.0 [10de/0370] enabled
PCI: 00:06.1 [10de/0371] ops
PCI: 00:06.1 [10de/0371] enabled
PCI: 00:08.0 [10de/0373] ops
PCI: 00:08.0 [10de/0373] enabled
PCI: 00:0a.0 [10de/0000] bus ops
PCI: 00:0a.0 [10de/0376] enabled
PCI: 00:0c.0 [10de/0000] bus ops
PCI: 00:0c.0 [10de/0374] enabled
PCI: 00:0d.0 [10de/0000] bus ops
PCI: 00:0d.0 [10de/0378] enabled
PCI: 00:0f.0 [10de/0000] bus ops
PCI: 00:0f.0 [10de/0377] enabled
PCI: 00:01.0 scanning...
scan_lpc_bus for PCI: 00:01.0
PNP: 002e.0 enabled
PNP: 002e.1 enabled
PNP: 002e.2 disabled
PNP: 002e.3 enabled
PNP: 002e.4 enabled
PNP: 002e.5 enabled
PNP: 002e.6 enabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
scan_lpc_bus for PCI: 00:01.0 done
PCI: 00:01.1 scanning...
scan_smbus for PCI: 00:01.1
smbus: PCI: 00:01.1[0]->I2C: 01:50 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:51 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:52 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:53 enabled
scan_smbus for PCI: 00:01.1 done
PCI: 00:06.0 scanning...
do_pci_scan_bridge for PCI: 00:06.0
PCI: pci_scan_bus for bus 01
PCI: 00:0a.0 scanning...
do_pci_scan_bridge for PCI: 00:0a.0
PCI: pci_scan_bus for bus 02
PCI: 00:0c.0 scanning...
do_pci_scan_bridge for PCI: 00:0c.0
PCI: pci_scan_bus for bus 03
PCI: 00:0d.0 scanning...
do_pci_scan_bridge for PCI: 00:0d.0
PCI: pci_scan_bus for bus 04
PCI: 00:0f.0 scanning...
do_pci_scan_bridge for PCI: 00:0f.0
PCI: pci_scan_bus for bus 05
PCI: 05:00.0 [1002/5b63] enabled
PCI: 05:00.1 [1002/5b73] enabled
DOMAIN: 0000 passpw: enabled
root_dev_scan_bus for Root Device done
done
found VGA at PCI: 05:00.0
Setting up VGA for PCI: 05:00.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:0f.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Allocating resources...
Reading resources...
Root Device read_resources bus 0 link: 0
CPU_CLUSTER: 0 read_resources bus 0 link: 0
APIC: 00 missing read_resources
CPU_CLUSTER: 0 read_resources bus 0 link: 0 done
DOMAIN: 0000 read_resources bus 0 link: 0
VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device
PCI: 00:18.0 read_resources bus 0 link: 0
PCI: 00:01.0 read_resources bus 0 link: 0
PCI: 00:01.0 read_resources bus 0 link: 0 done
PCI: 00:01.1 read_resources bus 1 link: 0
I2C: 01:50 missing read_resources
I2C: 01:51 missing read_resources
I2C: 01:52 missing read_resources
I2C: 01:53 missing read_resources
PCI: 00:01.1 read_resources bus 1 link: 0 done
PCI: 00:06.0 read_resources bus 1 link: 0
PCI: 00:06.0 read_resources bus 1 link: 0 done
PCI: 00:0a.0 read_resources bus 2 link: 0
PCI: 00:0a.0 read_resources bus 2 link: 0 done
PCI: 00:0c.0 read_resources bus 3 link: 0
PCI: 00:0c.0 read_resources bus 3 link: 0 done
PCI: 00:0d.0 read_resources bus 4 link: 0
PCI: 00:0d.0 read_resources bus 4 link: 0 done
PCI: 00:0f.0 read_resources bus 5 link: 0
PCI: 00:0f.0 read_resources bus 5 link: 0 done
PCI: 00:18.0 read_resources bus 0 link: 0 done
PCI: 00:18.0 read_resources bus 0 link: 1
PCI: 00:18.0 read_resources bus 0 link: 1 done
PCI: 00:18.0 read_resources bus 0 link: 2
PCI: 00:18.0 read_resources bus 0 link: 2 done
DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
Done reading resources.
Show resources in subtree (Root Device)...After reading.
 Root Device child on link 0 CPU_CLUSTER: 0
  CPU_CLUSTER: 0 child on link 0 APIC: 00
   APIC: 00
  DOMAIN: 0000 child on link 0 PCI: 00:18.0
  DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags
40040100
  DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags
40040
   PCI: 00:18.0 child on link 0 PCI: 00:00.0
   PCI: 00:18.0 resource base 33 size 0 align 0 gran 0 limit 3000 flags 1
index
   PCI: 00:18.0 resource base 0 size 0 align 12 gran 12 limit ffff flags
80100
   PCI: 00:18.0 resource base 0 size 0 align 20 gran 20 limit ffffffffff
flags
   PCI: 00:18.0 resource base 0 size 0 align 20 gran 20 limit ffffffff
flags 80
   PCI: 00:18.0 resource base a0000 size 20000 align 0 gran 0 limit
ffffffff fl
    PCI: 00:00.0
    PCI: 00:01.0 child on link 0 PNP: 002e.0
    PCI: 00:01.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff
flag
    PCI: 00:01.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags
c004010
    PCI: 00:01.0 resource base ff800000 size 800000 align 0 gran 0 limit 0
flag
    PCI: 00:01.0 resource base fec00000 size 1000 align 0 gran 0 limit 0
flags
     PNP: 002e.0
     PNP: 002e.0 resource base 3f0 size 8 align 3 gran 3 limit 7ff flags
c00001
     PNP: 002e.0 resource base 6 size 1 align 0 gran 0 limit 0 flags
c0000400 i
     PNP: 002e.0 resource base 2 size 1 align 0 gran 0 limit 0 flags
c0000800 i
     PNP: 002e.1
     PNP: 002e.1 resource base 3f8 size 8 align 3 gran 3 limit 7ff flags
c00001
     PNP: 002e.1 resource base 4 size 1 align 0 gran 0 limit 0 flags
c0000400 i
     PNP: 002e.2
     PNP: 002e.2 resource base 0 size 8 align 3 gran 3 limit 7ff flags 100
inde
     PNP: 002e.2 resource base 0 size 1 align 0 gran 0 limit 0 flags 400
index
     PNP: 002e.3
     PNP: 002e.3 resource base 378 size 8 align 3 gran 3 limit 7ff flags
c00001
     PNP: 002e.3 resource base 0 size 0 align 0 gran 0 limit 0 flags
c0000100 i
     PNP: 002e.3 resource base 7 size 1 align 0 gran 0 limit 0 flags
c0000400 i
     PNP: 002e.3 resource base 4 size 1 align 0 gran 0 limit 0 flags
c0000800 i
     PNP: 002e.4
     PNP: 002e.4 resource base 290 size 8 align 3 gran 3 limit 7ff flags
c00001
     PNP: 002e.4 resource base 0 size 8 align 3 gran 3 limit 7ff flags
c0000100
     PNP: 002e.4 resource base 0 size 1 align 0 gran 0 limit 0 flags
c0000400 i
     PNP: 002e.5
     PNP: 002e.5 resource base 60 size 1 align 0 gran 0 limit ffffffff
flags c0
     PNP: 002e.5 resource base 64 size 1 align 0 gran 0 limit ffffffff
flags c0
     PNP: 002e.5 resource base 1 size 1 align 0 gran 0 limit 0 flags
c0000400 i
     PNP: 002e.6
     PNP: 002e.6 resource base c size 1 align 0 gran 0 limit 0 flags
c0000400 i
     PNP: 002e.7
     PNP: 002e.7 resource base 0 size 0 align 0 gran 0 limit 0 flags
c0000100 i
     PNP: 002e.7 resource base 800 size 8 align 3 gran 3 limit 7ff flags
c00001
     PNP: 002e.7 resource base 0 size 8 align 3 gran 3 limit 7ff flags
c0000100
     PNP: 002e.8
     PNP: 002e.8 resource base 0 size 2 align 1 gran 1 limit 7ff flags 100
inde
     PNP: 002e.8 resource base 0 size 1 align 0 gran 0 limit 0 flags 400
index
     PNP: 002e.9
     PNP: 002e.9 resource base 0 size 1 align 0 gran 0 limit ffffffff flags
100
     PNP: 002e.a
    PCI: 00:01.1 child on link 0 I2C: 01:50
    PCI: 00:01.1 resource base 0 size 40 align 6 gran 6 limit ffff flags
100 in
    PCI: 00:01.1 resource base 0 size 40 align 6 gran 6 limit ffff flags
100 in
    PCI: 00:01.1 resource base 0 size 40 align 6 gran 6 limit ffff flags
100 in
    PCI: 00:01.1 resource base 0 size 100 align 8 gran 8 limit ffff flags
100 i
    PCI: 00:01.1 resource base 0 size 100 align 8 gran 8 limit ffff flags
100 i
    PCI: 00:01.1 resource base 0 size 100 align 8 gran 8 limit ffff flags
100 i
     I2C: 01:50
     I2C: 01:51
     I2C: 01:52
     I2C: 01:53
    PCI: 00:01.2
    PCI: 00:01.3
    PCI: 00:01.3 resource base 0 size 40000 align 18 gran 18 limit ffffffff
fla
    PCI: 00:02.0
    PCI: 00:02.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff
flag
    PCI: 00:02.1
    PCI: 00:02.1 resource base 0 size 100 align 8 gran 8 limit ffffffff
flags 2
    PCI: 00:04.0
    PCI: 00:04.0 resource base 0 size 10 align 4 gran 4 limit ffff flags
100 in
    PCI: 00:05.0
    PCI: 00:05.0 resource base 0 size 8 align 3 gran 3 limit ffff flags 100
ind
    PCI: 00:05.0 resource base 0 size 4 align 2 gran 2 limit ffff flags 100
ind
    PCI: 00:05.0 resource base 0 size 8 align 3 gran 3 limit ffff flags 100
ind
    PCI: 00:05.0 resource base 0 size 4 align 2 gran 2 limit ffff flags 100
ind
    PCI: 00:05.0 resource base 0 size 10 align 4 gran 4 limit ffff flags
100 in
    PCI: 00:05.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff
flag
    PCI: 00:05.1
    PCI: 00:05.1 resource base 0 size 8 align 3 gran 3 limit ffff flags 100
ind
    PCI: 00:05.1 resource base 0 size 4 align 2 gran 2 limit ffff flags 100
ind
    PCI: 00:05.1 resource base 0 size 8 align 3 gran 3 limit ffff flags 100
ind
    PCI: 00:05.1 resource base 0 size 4 align 2 gran 2 limit ffff flags 100
ind
    PCI: 00:05.1 resource base 0 size 10 align 4 gran 4 limit ffff flags
100 in
    PCI: 00:05.1 resource base 0 size 1000 align 12 gran 12 limit ffffffff
flag
    PCI: 00:05.2
    PCI: 00:05.2 resource base 0 size 8 align 3 gran 3 limit ffff flags 100
ind
    PCI: 00:05.2 resource base 0 size 4 align 2 gran 2 limit ffff flags 100
ind
    PCI: 00:05.2 resource base 0 size 8 align 3 gran 3 limit ffff flags 100
ind
    PCI: 00:05.2 resource base 0 size 4 align 2 gran 2 limit ffff flags 100
ind
    PCI: 00:05.2 resource base 0 size 10 align 4 gran 4 limit ffff flags
100 in
    PCI: 00:05.2 resource base 0 size 1000 align 12 gran 12 limit ffffffff
flag
    PCI: 00:06.0
    PCI: 00:06.0 resource base 0 size 0 align 12 gran 12 limit ffff flags
80102
    PCI: 00:06.0 resource base 0 size 0 align 20 gran 20 limit ffffffff
flags 8
    PCI: 00:06.0 resource base 0 size 0 align 20 gran 20 limit ffffffff
flags 8
    PCI: 00:06.1
    PCI: 00:06.1 resource base 0 size 4000 align 14 gran 14 limit ffffffff
flag
    PCI: 00:08.0
    PCI: 00:08.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff
flag
    PCI: 00:08.0 resource base 0 size 8 align 3 gran 3 limit ffff flags 100
ind
    PCI: 00:08.0 resource base 0 size 100 align 8 gran 8 limit ffffffff
flags 2
    PCI: 00:08.0 resource base 0 size 10 align 4 gran 4 limit ffffffff
flags 20
    PCI: 00:09.0
    PCI: 00:0a.0
    PCI: 00:0a.0 resource base 0 size 0 align 12 gran 12 limit ffffffff
flags 8
    PCI: 00:0a.0 resource base 0 size 0 align 20 gran 20 limit
ffffffffffffffff
    PCI: 00:0a.0 resource base 0 size 0 align 20 gran 20 limit ffffffff
flags 8
    PCI: 00:0b.0
    PCI: 00:0c.0
    PCI: 00:0c.0 resource base 0 size 0 align 12 gran 12 limit ffffffff
flags 8
    PCI: 00:0c.0 resource base 0 size 0 align 20 gran 20 limit
ffffffffffffffff
    PCI: 00:0c.0 resource base 0 size 0 align 20 gran 20 limit ffffffff
flags 8
    PCI: 00:0d.0
    PCI: 00:0d.0 resource base 0 size 0 align 12 gran 12 limit ffffffff
flags 8
    PCI: 00:0d.0 resource base 0 size 0 align 20 gran 20 limit
ffffffffffffffff
    PCI: 00:0d.0 resource base 0 size 0 align 20 gran 20 limit ffffffff
flags 8
    PCI: 00:0e.0
    PCI: 00:0f.0 child on link 0 PCI: 05:00.0
    PCI: 00:0f.0 resource base 0 size 0 align 12 gran 12 limit ffffffff
flags 8
    PCI: 00:0f.0 resource base 0 size 0 align 20 gran 20 limit
ffffffffffffffff
    PCI: 00:0f.0 resource base 0 size 0 align 20 gran 20 limit ffffffff
flags 8
     PCI: 05:00.0
     PCI: 05:00.0 resource base 0 size 8000000 align 27 gran 27 limit
ffffffff
     PCI: 05:00.0 resource base 0 size 100 align 8 gran 8 limit ffff flags
100
     PCI: 05:00.0 resource base 0 size 10000 align 16 gran 16 limit
ffffffff fl
     PCI: 05:00.0 resource base 0 size 20000 align 17 gran 17 limit
ffffffff fl
     PCI: 05:00.1
     PCI: 05:00.1 resource base 0 size 10000 align 16 gran 16 limit
ffffffff fl
   PCI: 00:18.1
   PCI: 00:18.2
   PCI: 00:18.3
   PCI: 00:18.3 resource base 0 size 4000000 align 26 gran 26 limit
ffffffff fl
DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff
PCI: 00:18.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff
PCI: 00:06.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff
PCI: 00:06.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff done
PCI: 00:0a.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffffffff
PCI: 00:0a.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffffffff done
PCI: 00:0c.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffffffff
PCI: 00:0c.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffffffff done
PCI: 00:0d.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffffffff
PCI: 00:0d.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffffffff done
PCI: 00:0f.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffffffff
PCI: 05:00.0 14 *  [0x0 - 0xff] io
PCI: 00:0f.0 io: base: 100 size: 1000 align: 12 gran: 12 limit: ffff done
PCI: 00:0f.0 1c *  [0x0 - 0xfff] io
PCI: 00:01.1 60 *  [0x1000 - 0x10ff] io
PCI: 00:01.1 64 *  [0x1400 - 0x14ff] io
PCI: 00:01.1 68 *  [0x1800 - 0x18ff] io
PCI: 00:01.1 10 *  [0x1c00 - 0x1c3f] io
PCI: 00:01.1 20 *  [0x1c40 - 0x1c7f] io
PCI: 00:01.1 24 *  [0x1c80 - 0x1cbf] io
PCI: 00:04.0 20 *  [0x1cc0 - 0x1ccf] io
PCI: 00:05.0 20 *  [0x1cd0 - 0x1cdf] io
PCI: 00:05.1 20 *  [0x1ce0 - 0x1cef] io
PCI: 00:05.2 20 *  [0x1cf0 - 0x1cff] io
PCI: 00:05.0 10 *  [0x2000 - 0x2007] io
PCI: 00:05.0 18 *  [0x2008 - 0x200f] io
PCI: 00:05.1 10 *  [0x2010 - 0x2017] io
PCI: 00:05.1 18 *  [0x2018 - 0x201f] io
PCI: 00:05.2 10 *  [0x2020 - 0x2027] io
PCI: 00:05.2 18 *  [0x2028 - 0x202f] io
PCI: 00:08.0 14 *  [0x2030 - 0x2037] io
PCI: 00:05.0 14 *  [0x2038 - 0x203b] io
PCI: 00:05.0 1c *  [0x203c - 0x203f] io
PCI: 00:05.1 14 *  [0x2040 - 0x2043] io
PCI: 00:05.1 1c *  [0x2044 - 0x2047] io
PCI: 00:05.2 14 *  [0x2048 - 0x204b] io
PCI: 00:05.2 1c *  [0x204c - 0x204f] io
PCI: 00:18.0 io: base: 2050 size: 3000 align: 12 gran: 12 limit: ffff done
PCI: 00:18.0 00 *  [0x0 - 0x2fff] io
DOMAIN: 0000 io: base: 3000 size: 3000 align: 12 gran: 0 limit: ffff done
DOMAIN: 0000 mem: base: 0 size: 0 align: 0 gran: 0 limit: ffffffff
PCI: 00:18.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffff
PCI: 00:06.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 00:06.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
done
PCI: 00:0a.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit:
fffffffffffffff
PCI: 00:0a.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit:
fffffffffffffff
PCI: 00:0c.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit:
fffffffffffffff
PCI: 00:0c.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit:
fffffffffffffff
PCI: 00:0d.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit:
fffffffffffffff
PCI: 00:0d.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit:
fffffffffffffff
PCI: 00:0f.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit:
fffffffffffffff
PCI: 05:00.0 10 *  [0x0 - 0x7ffffff] prefmem
PCI: 00:0f.0 prefmem: base: 8000000 size: 8000000 align: 27 gran: 20 limit:
fff
PCI: 00:0f.0 24 *  [0x0 - 0x7ffffff] prefmem
PCI: 00:18.0 prefmem: base: 8000000 size: 8000000 align: 27 gran: 20 limit:
fff
PCI: 00:18.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 00:06.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 00:06.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff done
PCI: 00:0a.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 00:0a.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff done
PCI: 00:0c.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 00:0c.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff done
PCI: 00:0d.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 00:0d.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff done
PCI: 00:0f.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 05:00.0 30 *  [0x0 - 0x1ffff] mem
PCI: 05:00.0 18 *  [0x20000 - 0x2ffff] mem
PCI: 05:00.1 10 *  [0x30000 - 0x3ffff] mem
PCI: 00:0f.0 mem: base: 40000 size: 100000 align: 20 gran: 20 limit:
ffffffff d
PCI: 00:0f.0 20 *  [0x0 - 0xfffff] mem
PCI: 00:01.3 10 *  [0x100000 - 0x13ffff] mem
PCI: 00:06.1 10 *  [0x140000 - 0x143fff] mem
PCI: 00:01.0 14 *  [0x144000 - 0x144fff] mem
PCI: 00:02.0 10 *  [0x145000 - 0x145fff] mem
PCI: 00:05.0 24 *  [0x146000 - 0x146fff] mem
PCI: 00:05.1 24 *  [0x147000 - 0x147fff] mem
PCI: 00:05.2 24 *  [0x148000 - 0x148fff] mem
PCI: 00:08.0 10 *  [0x149000 - 0x149fff] mem
PCI: 00:02.1 10 *  [0x14a000 - 0x14a0ff] mem
PCI: 00:08.0 18 *  [0x14a100 - 0x14a1ff] mem
PCI: 00:08.0 1c *  [0x14a200 - 0x14a20f] mem
PCI: 00:18.0 mem: base: 14a210 size: 200000 align: 20 gran: 20 limit:
ffffffff
PCI: 00:18.0 02 *  [0x0 - 0x7ffffff] prefmem
PCI: 00:18.3 94 *  [0x8000000 - 0xbffffff] mem
PCI: 00:18.0 01 *  [0xc000000 - 0xc1fffff] mem
DOMAIN: 0000 mem: base: c200000 size: c200000 align: 27 gran: 0 limit:
ffffffff
avoid_fixed_resources: DOMAIN: 0000
avoid_fixed_resources:@DOMAIN: 0000 10000000 limit 0000ffff
avoid_fixed_resources:@DOMAIN: 0000 10000100 limit ffffffff
constrain_resources: PCI: 00:18.0 04 base 000a0000 limit 000bffff mem
(fixed)
constrain_resources: PCI: 00:01.0 10000000 base 00000000 limit 00000fff io
(fix
constrain_resources: PCI: 00:01.0 10000100 base ff800000 limit ffffffff mem
(fi
constrain_resources: PCI: 00:01.0 03 base fec00000 limit fec00fff mem
(fixed)
skipping PNP: 002e.3 at 62 fixed resource, size=0!
avoid_fixed_resources:@DOMAIN: 0000 10000000 base 00001000 limit 0000ffff
avoid_fixed_resources:@DOMAIN: 0000 10000100 base f0000000 limit febfffff
Setting resources...
DOMAIN: 0000 io: base:1000 size:3000 align:12 gran:0 limit:ffff
PCI: 00:18.0 00 *  [0x1000 - 0x3fff] io
DOMAIN: 0000 io: next_base: 4000 size: 3000 align: 12 gran: 0 done
PCI: 00:18.0 io: base:1000 size:3000 align:12 gran:12 limit:3fff
PCI: 00:0f.0 1c *  [0x1000 - 0x1fff] io
PCI: 00:01.1 60 *  [0x2000 - 0x20ff] io
PCI: 00:01.1 64 *  [0x2400 - 0x24ff] io
PCI: 00:01.1 68 *  [0x2800 - 0x28ff] io
PCI: 00:01.1 10 *  [0x2c00 - 0x2c3f] io
PCI: 00:01.1 20 *  [0x2c40 - 0x2c7f] io
PCI: 00:01.1 24 *  [0x2c80 - 0x2cbf] io
PCI: 00:04.0 20 *  [0x2cc0 - 0x2ccf] io
PCI: 00:05.0 20 *  [0x2cd0 - 0x2cdf] io
PCI: 00:05.1 20 *  [0x2ce0 - 0x2cef] io
PCI: 00:05.2 20 *  [0x2cf0 - 0x2cff] io
PCI: 00:05.0 10 *  [0x3000 - 0x3007] io
PCI: 00:05.0 18 *  [0x3008 - 0x300f] io
PCI: 00:05.1 10 *  [0x3010 - 0x3017] io
PCI: 00:05.1 18 *  [0x3018 - 0x301f] io
PCI: 00:05.2 10 *  [0x3020 - 0x3027] io
PCI: 00:05.2 18 *  [0x3028 - 0x302f] io
PCI: 00:08.0 14 *  [0x3030 - 0x3037] io
PCI: 00:05.0 14 *  [0x3038 - 0x303b] io
PCI: 00:05.0 1c *  [0x303c - 0x303f] io
PCI: 00:05.1 14 *  [0x3040 - 0x3043] io
PCI: 00:05.1 1c *  [0x3044 - 0x3047] io
PCI: 00:05.2 14 *  [0x3048 - 0x304b] io
PCI: 00:05.2 1c *  [0x304c - 0x304f] io
PCI: 00:18.0 io: next_base: 3050 size: 3000 align: 12 gran: 12 done
PCI: 00:06.0 io: base:3fff size:0 align:12 gran:12 limit:3fff
PCI: 00:06.0 io: next_base: 3fff size: 0 align: 12 gran: 12 done
PCI: 00:0a.0 io: base:3fff size:0 align:12 gran:12 limit:3fff
PCI: 00:0a.0 io: next_base: 3fff size: 0 align: 12 gran: 12 done
PCI: 00:0c.0 io: base:3fff size:0 align:12 gran:12 limit:3fff
PCI: 00:0c.0 io: next_base: 3fff size: 0 align: 12 gran: 12 done
PCI: 00:0d.0 io: base:3fff size:0 align:12 gran:12 limit:3fff
PCI: 00:0d.0 io: next_base: 3fff size: 0 align: 12 gran: 12 done
PCI: 00:0f.0 io: base:1000 size:1000 align:12 gran:12 limit:1fff
PCI: 05:00.0 14 *  [0x1000 - 0x10ff] io
PCI: 00:0f.0 io: next_base: 1100 size: 1000 align: 12 gran: 12 done
DOMAIN: 0000 mem: base:f0000000 size:c200000 align:27 gran:0 limit:febfffff
PCI: 00:18.0 02 *  [0xf0000000 - 0xf7ffffff] prefmem
PCI: 00:18.3 94 *  [0xf8000000 - 0xfbffffff] mem
PCI: 00:18.0 01 *  [0xfc000000 - 0xfc1fffff] mem
DOMAIN: 0000 mem: next_base: fc200000 size: c200000 align: 27 gran: 0 done
PCI: 00:18.0 prefmem: base:f0000000 size:8000000 align:27 gran:20
limit:f7fffff
PCI: 00:0f.0 24 *  [0xf0000000 - 0xf7ffffff] prefmem
PCI: 00:18.0 prefmem: next_base: f8000000 size: 8000000 align: 27 gran: 20
done
PCI: 00:06.0 prefmem: base:f7ffffff size:0 align:20 gran:20 limit:f7ffffff
PCI: 00:06.0 prefmem: next_base: f7ffffff size: 0 align: 20 gran: 20 done
PCI: 00:0a.0 prefmem: base:f7ffffff size:0 align:20 gran:20 limit:f7ffffff
PCI: 00:0a.0 prefmem: next_base: f7ffffff size: 0 align: 20 gran: 20 done
PCI: 00:0c.0 prefmem: base:f7ffffff size:0 align:20 gran:20 limit:f7ffffff
PCI: 00:0c.0 prefmem: next_base: f7ffffff size: 0 align: 20 gran: 20 done
PCI: 00:0d.0 prefmem: base:f7ffffff size:0 align:20 gran:20 limit:f7ffffff
PCI: 00:0d.0 prefmem: next_base: f7ffffff size: 0 align: 20 gran: 20 done
PCI: 00:0f.0 prefmem: base:f0000000 size:8000000 align:27 gran:20
limit:f7fffff
PCI: 05:00.0 10 *  [0xf0000000 - 0xf7ffffff] prefmem
PCI: 00:0f.0 prefmem: next_base: f8000000 size: 8000000 align: 27 gran: 20
done
PCI: 00:18.0 mem: base:fc000000 size:200000 align:20 gran:20 limit:fc1fffff
PCI: 00:0f.0 20 *  [0xfc000000 - 0xfc0fffff] mem
PCI: 00:01.3 10 *  [0xfc100000 - 0xfc13ffff] mem
PCI: 00:06.1 10 *  [0xfc140000 - 0xfc143fff] mem
PCI: 00:01.0 14 *  [0xfc144000 - 0xfc144fff] mem
PCI: 00:02.0 10 *  [0xfc145000 - 0xfc145fff] mem
PCI: 00:05.0 24 *  [0xfc146000 - 0xfc146fff] mem
PCI: 00:05.1 24 *  [0xfc147000 - 0xfc147fff] mem
PCI: 00:05.2 24 *  [0xfc148000 - 0xfc148fff] mem
PCI: 00:08.0 10 *  [0xfc149000 - 0xfc149fff] mem
PCI: 00:02.1 10 *  [0xfc14a000 - 0xfc14a0ff] mem
PCI: 00:08.0 18 *  [0xfc14a100 - 0xfc14a1ff] mem
PCI: 00:08.0 1c *  [0xfc14a200 - 0xfc14a20f] mem
PCI: 00:18.0 mem: next_base: fc14a210 size: 200000 align: 20 gran: 20 done
PCI: 00:06.0 mem: base:fc1fffff size:0 align:20 gran:20 limit:fc1fffff
PCI: 00:06.0 mem: next_base: fc1fffff size: 0 align: 20 gran: 20 done
PCI: 00:0a.0 mem: base:fc1fffff size:0 align:20 gran:20 limit:fc1fffff
PCI: 00:0a.0 mem: next_base: fc1fffff size: 0 align: 20 gran: 20 done
PCI: 00:0c.0 mem: base:fc1fffff size:0 align:20 gran:20 limit:fc1fffff
PCI: 00:0c.0 mem: next_base: fc1fffff size: 0 align: 20 gran: 20 done
PCI: 00:0d.0 mem: base:fc1fffff size:0 align:20 gran:20 limit:fc1fffff
PCI: 00:0d.0 mem: next_base: fc1fffff size: 0 align: 20 gran: 20 done
PCI: 00:0f.0 mem: base:fc000000 size:100000 align:20 gran:20 limit:fc0fffff
PCI: 05:00.0 30 *  [0xfc000000 - 0xfc01ffff] mem
PCI: 05:00.0 18 *  [0xfc020000 - 0xfc02ffff] mem
PCI: 05:00.1 10 *  [0xfc030000 - 0xfc03ffff] mem
PCI: 00:0f.0 mem: next_base: fc040000 size: 100000 align: 20 gran: 20 done
Root Device assign_resources, bus 0 link: 0
0: mmio_basek=003c0000, basek=00000300, limitk=00100000
DOMAIN: 0000 assign_resources, bus 0 link: 0
amdk8_set_resource, enabling legacy VGA IO forwarding for PCI: 00:18.0 link
0x0
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] size 0x00003000 gran 0x0c
io
PCI: 00:18.0 1b8 <- [0x00f0000000 - 0x00f7ffffff] size 0x08000000 gran 0x14
pre
PCI: 00:18.0 1b0 <- [0x00fc000000 - 0x00fc1fffff] size 0x00200000 gran 0x14
mem
PCI: 00:18.0 1a8 <- [0x00000a0000 - 0x00000bffff] size 0x00020000 gran 0x00
mem
PCI: 00:18.0 assign_resources, bus 0 link: 0
PCI: 00:01.0 14 <- [0x00fc144000 - 0x00fc144fff] size 0x00001000 gran 0x0c
mem
PCI: 00:01.0 assign_resources, bus 0 link: 0
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] size 0x00000008 gran 0x03 io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] size 0x00000001 gran 0x00
irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] size 0x00000001 gran 0x00
drq
PNP: 002e.1 60 <- [0x00000003f8 - 0x00000003ff] size 0x00000008 gran 0x03 io
PNP: 002e.1 70 <- [0x0000000004 - 0x0000000004] size 0x00000001 gran 0x00
irq
PNP: 002e.3 60 <- [0x0000000378 - 0x000000037f] size 0x00000008 gran 0x03 io
PNP: 002e.3 62 <- [0x0000000000 - 0xffffffffffffffff] size 0x00000000 gran
0x00
PNP: 002e.3 70 <- [0x0000000007 - 0x0000000007] size 0x00000001 gran 0x00
irq
PNP: 002e.3 74 <- [0x0000000004 - 0x0000000004] size 0x00000001 gran 0x00
drq
PNP: 002e.4 60 <- [0x0000000290 - 0x0000000297] size 0x00000008 gran 0x03 io
PNP: 002e.4 62 <- [0x0000000000 - 0x0000000007] size 0x00000008 gran 0x03 io
PNP: 002e.4 70 <- [0x0000000000 - 0x0000000000] size 0x00000001 gran 0x00
irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] size 0x00000001 gran 0x00 io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] size 0x00000001 gran 0x00 io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] size 0x00000001 gran 0x00
irq
PNP: 002e.6 70 <- [0x000000000c - 0x000000000c] size 0x00000001 gran 0x00
irq
PCI: 00:01.0 assign_resources, bus 0 link: 0
PCI: 00:01.1 10 <- [0x0000002c00 - 0x0000002c3f] size 0x00000040 gran 0x06
io
PCI: 00:01.1 20 <- [0x0000002c40 - 0x0000002c7f] size 0x00000040 gran 0x06
io
PCI: 00:01.1 24 <- [0x0000002c80 - 0x0000002cbf] size 0x00000040 gran 0x06
io
PCI: 00:01.1 60 <- [0x0000002000 - 0x00000020ff] size 0x00000100 gran 0x08
io
PCI: 00:01.1 64 <- [0x0000002400 - 0x00000024ff] size 0x00000100 gran 0x08
io
PCI: 00:01.1 68 <- [0x0000002800 - 0x00000028ff] size 0x00000100 gran 0x08
io
PCI: 00:01.1 assign_resources, bus 1 link: 0
PCI: 00:01.1 assign_resources, bus 1 link: 0
PCI: 00:01.3 10 <- [0x00fc100000 - 0x00fc13ffff] size 0x00040000 gran 0x12
mem
PCI: 00:02.0 10 <- [0x00fc145000 - 0x00fc145fff] size 0x00001000 gran 0x0c
mem
PCI: 00:02.1 10 <- [0x00fc14a000 - 0x00fc14a0ff] size 0x00000100 gran 0x08
mem
PCI: 00:04.0 20 <- [0x0000002cc0 - 0x0000002ccf] size 0x00000010 gran 0x04
io
PCI: 00:05.0 10 <- [0x0000003000 - 0x0000003007] size 0x00000008 gran 0x03
io
PCI: 00:05.0 14 <- [0x0000003038 - 0x000000303b] size 0x00000004 gran 0x02
io
PCI: 00:05.0 18 <- [0x0000003008 - 0x000000300f] size 0x00000008 gran 0x03
io
PCI: 00:05.0 1c <- [0x000000303c - 0x000000303f] size 0x00000004 gran 0x02
io
PCI: 00:05.0 20 <- [0x0000002cd0 - 0x0000002cdf] size 0x00000010 gran 0x04
io
PCI: 00:05.0 24 <- [0x00fc146000 - 0x00fc146fff] size 0x00001000 gran 0x0c
mem
PCI: 00:05.1 10 <- [0x0000003010 - 0x0000003017] size 0x00000008 gran 0x03
io
PCI: 00:05.1 14 <- [0x0000003040 - 0x0000003043] size 0x00000004 gran 0x02
io
PCI: 00:05.1 18 <- [0x0000003018 - 0x000000301f] size 0x00000008 gran 0x03
io
PCI: 00:05.1 1c <- [0x0000003044 - 0x0000003047] size 0x00000004 gran 0x02
io
PCI: 00:05.1 20 <- [0x0000002ce0 - 0x0000002cef] size 0x00000010 gran 0x04
io
PCI: 00:05.1 24 <- [0x00fc147000 - 0x00fc147fff] size 0x00001000 gran 0x0c
mem
PCI: 00:05.2 10 <- [0x0000003020 - 0x0000003027] size 0x00000008 gran 0x03
io
PCI: 00:05.2 14 <- [0x0000003048 - 0x000000304b] size 0x00000004 gran 0x02
io
PCI: 00:05.2 18 <- [0x0000003028 - 0x000000302f] size 0x00000008 gran 0x03
io
PCI: 00:05.2 1c <- [0x000000304c - 0x000000304f] size 0x00000004 gran 0x02
io
PCI: 00:05.2 20 <- [0x0000002cf0 - 0x0000002cff] size 0x00000010 gran 0x04
io
PCI: 00:05.2 24 <- [0x00fc148000 - 0x00fc148fff] size 0x00001000 gran 0x0c
mem
PCI: 00:06.0 1c <- [0x0000003fff - 0x0000003ffe] size 0x00000000 gran 0x0c
bus
PCI: 00:06.0 24 <- [0x00f7ffffff - 0x00f7fffffe] size 0x00000000 gran 0x14
bus
PCI: 00:06.0 20 <- [0x00fc1fffff - 0x00fc1ffffe] size 0x00000000 gran 0x14
bus
PCI: 00:06.1 10 <- [0x00fc140000 - 0x00fc143fff] size 0x00004000 gran 0x0e
mem
PCI: 00:08.0 10 <- [0x00fc149000 - 0x00fc149fff] size 0x00001000 gran 0x0c
mem
PCI: 00:08.0 14 <- [0x0000003030 - 0x0000003037] size 0x00000008 gran 0x03
io
PCI: 00:08.0 18 <- [0x00fc14a100 - 0x00fc14a1ff] size 0x00000100 gran 0x08
mem
PCI: 00:08.0 1c <- [0x00fc14a200 - 0x00fc14a20f] size 0x00000010 gran 0x04
mem
PCI: 00:0a.0 1c <- [0x0000003fff - 0x0000003ffe] size 0x00000000 gran 0x0c
bus
PCI: 00:0a.0 24 <- [0x00f7ffffff - 0x00f7fffffe] size 0x00000000 gran 0x14
bus
PCI: 00:0a.0 20 <- [0x00fc1fffff - 0x00fc1ffffe] size 0x00000000 gran 0x14
bus
PCI: 00:0c.0 1c <- [0x0000003fff - 0x0000003ffe] size 0x00000000 gran 0x0c
bus
PCI: 00:0c.0 24 <- [0x00f7ffffff - 0x00f7fffffe] size 0x00000000 gran 0x14
bus
PCI: 00:0c.0 20 <- [0x00fc1fffff - 0x00fc1ffffe] size 0x00000000 gran 0x14
bus
PCI: 00:0d.0 1c <- [0x0000003fff - 0x0000003ffe] size 0x00000000 gran 0x0c
bus
PCI: 00:0d.0 24 <- [0x00f7ffffff - 0x00f7fffffe] size 0x00000000 gran 0x14
bus
PCI: 00:0d.0 20 <- [0x00fc1fffff - 0x00fc1ffffe] size 0x00000000 gran 0x14
bus
PCI: 00:0f.0 1c <- [0x0000001000 - 0x0000001fff] size 0x00001000 gran 0x0c
bus
PCI: 00:0f.0 24 <- [0x00f0000000 - 0x00f7ffffff] size 0x08000000 gran 0x14
bus
PCI: 00:0f.0 20 <- [0x00fc000000 - 0x00fc0fffff] size 0x00100000 gran 0x14
bus
PCI: 00:0f.0 assign_resources, bus 5 link: 0
PCI: 05:00.0 10 <- [0x00f0000000 - 0x00f7ffffff] size 0x08000000 gran 0x1b
pref
PCI: 05:00.0 14 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08
io
PCI: 05:00.0 18 <- [0x00fc020000 - 0x00fc02ffff] size 0x00010000 gran 0x10
mem
PCI: 05:00.0 30 <- [0x00fc000000 - 0x00fc01ffff] size 0x00020000 gran 0x11
rome
PCI: 05:00.1 10 <- [0x00fc030000 - 0x00fc03ffff] size 0x00010000 gran 0x10
mem
PCI: 00:0f.0 assign_resources, bus 5 link: 0
PCI: 00:18.0 assign_resources, bus 0 link: 0
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] size 0x04000000 g#?

#END

I've marked the logs, i hope it helps.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151022/3ef3579e/attachment-0001.html>

From wordpress at blogs.coreboot.org  Thu Oct 22 22:46:26 2015
From: wordpress at blogs.coreboot.org (WordPress)
Date: Thu, 22 Oct 2015 20:46:26 +0000
Subject: [coreboot] New on blogs.coreboot.org: coreboot changelog
Message-ID: <c59ba907b3c1c7ac3971c35b63419fd6@blogs.coreboot.org>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151022/f7d61489/attachment.html>

From mr.nuke.me at gmail.com  Fri Oct 23 05:20:38 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Thu, 22 Oct 2015 20:20:38 -0700
Subject: [coreboot] GPL license headers
In-Reply-To: <20151022180044.GA13053@coreboot.org>
References: <CAE-gjdVc38Vg6omF2rG6=oY4529Xi5DROXNY=a+tFidX41KmFQ@mail.gmail.com>
 <56259C0F.106@gmail.com>
 <CAE-gjdXdLeVqVhPHeKQFrwJjLsbkK3bj-Rp3t0VBQO_SiKm6kg@mail.gmail.com>
 <CAP6exYKhL2tB8EakHkvJWM4ZQ2M=X5RBP7dg1W4tvoCdVKG02g@mail.gmail.com>
 <5626E09B.3040607@gmail.com>
 <CA+e+Ov5AhBNOjqZY14LFf_8Ut9E2JTMDnNshkuaGsa4WNAKmJQ@mail.gmail.com>
 <CAP6exY+p7tO93zYTAyW7utMoobXGYEPnqQdcWZgyP4QxzaNqWg@mail.gmail.com>
 <20151022180044.GA13053@coreboot.org>
Message-ID: <5629A786.20506@gmail.com>

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

> With resolutions of today's monitors 

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

> and keyboards often having a page down key,

My macbookpro doesn't have a PgDn key.

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

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

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

Alex

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


From mytbk920423 at gmail.com  Fri Oct 23 13:31:59 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Fri, 23 Oct 2015 19:31:59 +0800
Subject: [coreboot] about Ivy Bridge CPU with QM67 PCH
In-Reply-To: <20151018164409.9670.qmail@stuge.se>
References: <20151018160625.GA3768@mytbk-laptop.lan>
 <20151018164409.9670.qmail@stuge.se>
Message-ID: <20151023113159.GA4135@mytbk-laptop>

Hi,

On Sun, Oct 18, 2015 at 06:44:09PM +0200, Peter Stuge wrote:
> Hi,
> 
> Iru Cai wrote:
> > I've been testing the Lenovo T420 port recently, and now I can
> > install an Ivy Bridge processor and run fine on Linux(except some
> > thermal issues).
> 
> That's pretty nice I think.
> 
> 
> > However, the native graphics initialization doesn't work properly
> ..
> > I don't know if someone has tried using mixed generation of CPU and
> > chipset combination with coreboot before,
> 
> Probably not.
I finally found it's lvds_num_lanes in devicetree.cb that breaks
native graphics initilization, because SNB and IVB use different values.
And it has been solved in this upstream commit:

commit c48f5ef3cc623a4b1bccdbc9cb3e1d15505b7ad4
Author: Vladimir Serbinenko <phcoder at gmail.com>
Date:   Sun Oct 11 02:05:55 2015 +0200

    Kill lvds_num_lanes

    Only one value would work with corresponding gma code currently (which one
    depends on board). Going forward, it's possible to compute which number can
    be used, so there is no need to keep this info around.

Thank you Vladimir Serbinenko.

> 
> 
> > I have pushed the patch that makes coreboot support both SNB and
> > IVB processor for review:
> > http://review.coreboot.org/#/c/12087/
> 
> Thanks! There is a source code style issue - you used two spaces
> instead of one tab to indent - please fix that, but other than that
> the patch looks fine to me.
> 
> But the two files gma_{sandy,ivy}bridge_lvds.c are a bit of a mess -
> they need to be cleaned up and can quite easily be unified into a
> single file, without having it become the mess that the i915 kernel
> code is. The key is to have a good data model, and the data model
> seems clear to me from the existing code.
> 
> For fun (or pain), take a look at: git diff 758a41 7137c5
> (sandy..ivy)
> 
> 
> //Peter
> 
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot

Iru Cai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151023/d17c8f0c/attachment.asc>

From gw at oxff.net  Fri Oct 23 14:44:18 2015
From: gw at oxff.net (Georg Wicherski)
Date: Fri, 23 Oct 2015 14:44:18 +0200
Subject: [coreboot] Broadwell IGD (on Auron_Paine)
In-Reply-To: <20151019191514.GB13747@coreboot.org>
References: <56250E9D.80706@oxff.net> <20151019191514.GB13747@coreboot.org>
Message-ID: <562A2BA2.2010801@oxff.net>

On 10/19/2015 09:15 PM, Stefan Reinauer wrote:
> it seems that the refcode binary was not running. Can you verify that
> it was part of the image and gets executed?

Of course, good find.

The reference code blob was actually in the CBFS but unfortunately the
code to run it was disabled if no such blob was directly provided to
KConfig.

<http://review.coreboot.org/#/c/11907/4> now actually works on my
Auron_Paine and correctly boots with framebuffer into a payload.


There is one remaining issue, when using GRUB2 as payload and using the
at_keyboard terminal_input, the machine resets. The last debug print I
can see from GRUB2 is from term/at_keyboard.c:367 with current_set=0, so
I suppose the crasher is the write_mode(1) a few lines down.

Is this a GRUB2 issue or Coreboot issue (the at_keyboard is related to
the EC, maybe not properly initialized)?


Thanks for all involved so far!
G


From gw at oxff.net  Fri Oct 23 14:46:50 2015
From: gw at oxff.net (Georg Wicherski)
Date: Fri, 23 Oct 2015 14:46:50 +0200
Subject: [coreboot] Broadwell IGD (on Auron_Paine)
In-Reply-To: <562A2BA2.2010801@oxff.net>
References: <56250E9D.80706@oxff.net> <20151019191514.GB13747@coreboot.org>
 <562A2BA2.2010801@oxff.net>
Message-ID: <562A2C3A.3080906@oxff.net>

On 10/23/2015 02:44 PM, Georg Wicherski wrote:
> There is one remaining issue, when using GRUB2 as payload and using the
> at_keyboard terminal_input, the machine resets. The last debug print I
> can see from GRUB2 is from term/at_keyboard.c:367 with current_set=0, so
> I suppose the crasher is the write_mode(1) a few lines down.
> 
> Is this a GRUB2 issue or Coreboot issue (the at_keyboard is related to
> the EC, maybe not properly initialized)?

I should mention, I observed exactly the same bug/behavior on a Peppy
board (which is pretty close to the Auron_Paine).

Using a USB keyboard, I can happily edit stuff in GRUB2 and boot into
Linux 4.x (which then crashes in gpio_lynxpoint, but I can simply
blacklist that module for now).


From pgeorgi at google.com  Fri Oct 23 17:23:43 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 23 Oct 2015 17:23:43 +0200
Subject: [coreboot] SPD binaries in coreboot
Message-ID: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>

Hi,

Some mainboards come with soldered-on memory without SPD ROM. For
these, we carry the SPD data in coreboot.

Currently, they're stored in a hexdump format that is then converted
to binary at build time. The various mechanisms of doing so fail on
some platform or another:
 - "echo -e -n $stuff" isn't well-liked by some shells (emits "e -n $stuff")
 - "printf '\x42'" isn't well-liked by some shells (or /usr/bin/printf
tools) that don't support hexadecimal formats
 - "printf '\0377'" isn't well-liked by some non-conforming, but existing shells
 - xxd -rg1 $file > $file.bin requires xxd, which comes with vim and
may just not exist

I see essentially two ways out of this, before we can start reducing
duplication across the tree in that area:
We could build our own tool to parse hex files and dump binary, or we
could ship SPD data as binary from the start (and only have to
concatenate them).

The second option has the appeal of being much simpler (and there
isn't really a "preferred form" for editing SPD data that I'm aware of
- is there?), but looks icky at a glance because it's binary (but it's
really just as impenetrable as the equivalent hexdump).

So what do these files contain? Parameters (as in: facts) about the
hardware's size, layout, and timing, and a bunch of vendor/model
identifier strings.


So, is there a third option that I'm missing? Other opinions?
Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle


From rminnich at gmail.com  Fri Oct 23 17:32:47 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 23 Oct 2015 15:32:47 +0000
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
Message-ID: <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>

Build the tool in go. It's trivial. If you have an idea how it ought to
work I can set it up in the playground in a few minutes.

ron

On Fri, Oct 23, 2015 at 8:24 AM Patrick Georgi <pgeorgi at google.com> wrote:

> Hi,
>
> Some mainboards come with soldered-on memory without SPD ROM. For
> these, we carry the SPD data in coreboot.
>
> Currently, they're stored in a hexdump format that is then converted
> to binary at build time. The various mechanisms of doing so fail on
> some platform or another:
>  - "echo -e -n $stuff" isn't well-liked by some shells (emits "e -n
> $stuff")
>  - "printf '\x42'" isn't well-liked by some shells (or /usr/bin/printf
> tools) that don't support hexadecimal formats
>  - "printf '\0377'" isn't well-liked by some non-conforming, but existing
> shells
>  - xxd -rg1 $file > $file.bin requires xxd, which comes with vim and
> may just not exist
>
> I see essentially two ways out of this, before we can start reducing
> duplication across the tree in that area:
> We could build our own tool to parse hex files and dump binary, or we
> could ship SPD data as binary from the start (and only have to
> concatenate them).
>
> The second option has the appeal of being much simpler (and there
> isn't really a "preferred form" for editing SPD data that I'm aware of
> - is there?), but looks icky at a glance because it's binary (but it's
> really just as impenetrable as the equivalent hexdump).
>
> So what do these files contain? Parameters (as in: facts) about the
> hardware's size, layout, and timing, and a bunch of vendor/model
> identifier strings.
>
>
> So, is there a third option that I'm missing? Other opinions?
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot 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/20151023/aa07aa71/attachment.html>

From peter at stuge.se  Fri Oct 23 17:33:21 2015
From: peter at stuge.se (Peter Stuge)
Date: Fri, 23 Oct 2015 17:33:21 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
Message-ID: <20151023153321.6326.qmail@stuge.se>

Patrick Georgi wrote:
> we carry the SPD data in coreboot.
..
> Currently, they're stored in a hexdump format
..
> I see essentially two ways out of this
..
> We could build our own tool to parse hex files and dump binary,

If we create a tool for this process I think we can find a better
"source" format than hex files. Someone needs to take a look at the
JEDEC standard and think of what might be suitable.


> or we could ship SPD data as binary from the start

I am actually strongly in favor of this approach. Converting SPD data
from human readable to machine readable is an orthogonal problem to
fixing the structure of our codebase, and there is no reason not to
solve the structural problem without first having to invent a new
data format.


> The second option has the appeal of being much simpler (and there
> isn't really a "preferred form" for editing SPD data that I'm aware of
> - is there?)

I guess JEDEC does have a structured format. Maybe it's XML or JSON. :)


> So, is there a third option that I'm missing? Other opinions?

The third option would be a plain text format which is easy to parse
but still covers the spec well.


Unblobing SPD files is an excellent entry-level project which we
could keep on shelf. Maybe for next GSoC..

Fixing structure is more important IMO and shouldn't need to block on that.


//Peter


From adurbin at google.com  Fri Oct 23 17:39:32 2015
From: adurbin at google.com (Aaron Durbin)
Date: Fri, 23 Oct 2015 10:39:32 -0500
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <20151023153321.6326.qmail@stuge.se>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
Message-ID: <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>

On Fri, Oct 23, 2015 at 10:33 AM, Peter Stuge <peter at stuge.se> wrote:
> Patrick Georgi wrote:
>> we carry the SPD data in coreboot.
> ..
>> Currently, they're stored in a hexdump format
> ..
>> I see essentially two ways out of this
> ..
>> We could build our own tool to parse hex files and dump binary,
>
> If we create a tool for this process I think we can find a better
> "source" format than hex files. Someone needs to take a look at the
> JEDEC standard and think of what might be suitable.
>
>
>> or we could ship SPD data as binary from the start
>
> I am actually strongly in favor of this approach. Converting SPD data
> from human readable to machine readable is an orthogonal problem to
> fixing the structure of our codebase, and there is no reason not to
> solve the structural problem without first having to invent a new
> data format.
>
>
>> The second option has the appeal of being much simpler (and there
>> isn't really a "preferred form" for editing SPD data that I'm aware of
>> - is there?)
>
> I guess JEDEC does have a structured format. Maybe it's XML or JSON. :)
>

I don't believe JEDEC has a format. And the one thing missing here is
that there is no standard way of distributing these files. In fact,
I've mainly seen spreadsheets as a form of distribution from the
memory manufacturers.

>
>> So, is there a third option that I'm missing? Other opinions?
>
> The third option would be a plain text format which is easy to parse
> but still covers the spec well.

The issue is that spds are for dimms while soldered down dram aren't
dimms. The spds provide the illusion of an actual dimm to the memory
training code which needs specific values. And because of this those
files need to be edited at times because of errors.

FWIW, LPDDR has the ability to be queried on the command bus so these
constructs should go away over time.

>
>
> Unblobing SPD files is an excellent entry-level project which we
> could keep on shelf. Maybe for next GSoC..
>
> Fixing structure is more important IMO and shouldn't need to block on that.

What's the specific structural gripe you have? The snippet of
duplicated Makefile code?


From pgeorgi at google.com  Fri Oct 23 17:39:47 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 23 Oct 2015 17:39:47 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
Message-ID: <CAE-gjdX-KY0RhW=ZVuQLC5Y05583DagLPN62-kMEMzA4KmJVqg@mail.gmail.com>

It's more trivial not to have a tool in the first place.
It's also more trivial not to add a new dependency to our build process.
Especially a dependency that is lacking in portability (ie. users
can't build coreboot anymore because they can't run go)

Sorry, but no.

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



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


From peter at stuge.se  Fri Oct 23 17:42:31 2015
From: peter at stuge.se (Peter Stuge)
Date: Fri, 23 Oct 2015 17:42:31 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
Message-ID: <20151023154231.7193.qmail@stuge.se>

ron minnich wrote:
> Build the tool in go.

I have to disagree with that. We want to keep dependencies few and small,
neither of which is really true for Go.

Hammer and nail..


> It's trivial.

I think that's true regardless of which tool we use.


//Peter


From peter at stuge.se  Fri Oct 23 17:48:05 2015
From: peter at stuge.se (Peter Stuge)
Date: Fri, 23 Oct 2015 17:48:05 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
Message-ID: <20151023154805.7741.qmail@stuge.se>

Aaron Durbin wrote:
> > I guess JEDEC does have a structured format. Maybe it's XML or JSON. :)
> 
> I don't believe JEDEC has a format. And the one thing missing here is
> that there is no standard way of distributing these files. In fact,
> I've mainly seen spreadsheets as a form of distribution from the
> memory manufacturers.

Nod, then we would be creating the format.


> The issue is that spds are for dimms while soldered down dram aren't
> dimms. The spds provide the illusion of an actual dimm to the memory
> training code which needs specific values. And because of this those
> files need to be edited at times because of errors.

Right, "accidental review" as these data sets pass by humans in the
review process is a good reason for a text-based format. Editing,
well, whether I edit a hex dump or use hexedit to edit a binary
really doesn't make a big difference - in which case I strongly
favor requiring developers who make edits to have more tooling,
over requiring new tooling at build time.


> FWIW, LPDDR has the ability to be queried on the command bus so
> these constructs should go away over time.

Old boards stay in the tree.


> > Fixing structure is more important IMO and shouldn't need to block on that.
> 
> What's the specific structural gripe you have? The snippet of
> duplicated Makefile code?

Code and data in mainboard directories for components which are not
the mainboard.


//Peter


From pgeorgi at google.com  Fri Oct 23 17:52:31 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 23 Oct 2015 17:52:31 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <20151023154805.7741.qmail@stuge.se>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
 <20151023154805.7741.qmail@stuge.se>
Message-ID: <CAE-gjdX65t=Jpj11mvmO92P9TqNyM09gUSwiTYqsoALxVXbCuw@mail.gmail.com>

2015-10-23 17:48 GMT+02:00 Peter Stuge <peter at stuge.se>:
> Code and data in mainboard directories for components which are not
> the mainboard.
In this case, they _are_ "the mainboard" just like magic numbers for
USB trace lengths are.
That stuff describes soldered-on components, it can't be more
"mainboard" than that.


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


From rminnich at gmail.com  Fri Oct 23 17:53:39 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 23 Oct 2015 15:53:39 +0000
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE-gjdX-KY0RhW=ZVuQLC5Y05583DagLPN62-kMEMzA4KmJVqg@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE-gjdX-KY0RhW=ZVuQLC5Y05583DagLPN62-kMEMzA4KmJVqg@mail.gmail.com>
Message-ID: <CAP6exY+bjfRDzX5CaFT-G6fpdN44Vbuad3gkhX7fAdU5z+g7BA@mail.gmail.com>

On Fri, Oct 23, 2015 at 8:39 AM Patrick Georgi <pgeorgi at google.com> wrote:

> It's more trivial not to have a tool in the first place.
> It's also more trivial not to add a new dependency to our build process.
> Especially a dependency that is lacking in portability (ie. users
> can't build coreboot anymore because they can't run go)
>
> Sorry, but no.
>
>
Actually the idea crossed my mind because I just saw a different tool hit
the tree yesterday that was written in ... guess what language?

I would have accepted the 'go is not supported' argument a year ago. Now?
It's everywhere.

But, ok, ship binaries. I guess we'll grow the blobs.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151023/3c1f34ba/attachment.html>

From pgeorgi at google.com  Fri Oct 23 17:55:14 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 23 Oct 2015 17:55:14 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAP6exY+bjfRDzX5CaFT-G6fpdN44Vbuad3gkhX7fAdU5z+g7BA@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE-gjdX-KY0RhW=ZVuQLC5Y05583DagLPN62-kMEMzA4KmJVqg@mail.gmail.com>
 <CAP6exY+bjfRDzX5CaFT-G6fpdN44Vbuad3gkhX7fAdU5z+g7BA@mail.gmail.com>
Message-ID: <CAE-gjdXxunV54YvDnGH_ouXhHBAt9H1K+sKyq=DStFaJ3+coCQ@mail.gmail.com>

2015-10-23 17:53 GMT+02:00 ron minnich <rminnich at gmail.com>:
> Actually the idea crossed my mind because I just saw a different tool hit
> the tree yesterday that was written in ... guess what language?
That tool (just like autoport before it) isn't part of the build system.


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


From rminnich at gmail.com  Fri Oct 23 17:56:01 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 23 Oct 2015 15:56:01 +0000
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE-gjdXxunV54YvDnGH_ouXhHBAt9H1K+sKyq=DStFaJ3+coCQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE-gjdX-KY0RhW=ZVuQLC5Y05583DagLPN62-kMEMzA4KmJVqg@mail.gmail.com>
 <CAP6exY+bjfRDzX5CaFT-G6fpdN44Vbuad3gkhX7fAdU5z+g7BA@mail.gmail.com>
 <CAE-gjdXxunV54YvDnGH_ouXhHBAt9H1K+sKyq=DStFaJ3+coCQ@mail.gmail.com>
Message-ID: <CAP6exYJ9LHruXd5htDbXPqPGpM5XEdOoQLYWe45KWBWRNLEcJQ@mail.gmail.com>

We'll agree to disagree :-)

ron

On Fri, Oct 23, 2015 at 8:55 AM Patrick Georgi <pgeorgi at google.com> wrote:

> 2015-10-23 17:53 GMT+02:00 ron minnich <rminnich at gmail.com>:
> > Actually the idea crossed my mind because I just saw a different tool hit
> > the tree yesterday that was written in ... guess what language?
> That tool (just like autoport before it) isn't part of the build system.
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151023/65329e47/attachment.html>

From peter at stuge.se  Fri Oct 23 17:57:43 2015
From: peter at stuge.se (Peter Stuge)
Date: Fri, 23 Oct 2015 17:57:43 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE-gjdX65t=Jpj11mvmO92P9TqNyM09gUSwiTYqsoALxVXbCuw@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
 <20151023154805.7741.qmail@stuge.se>
 <CAE-gjdX65t=Jpj11mvmO92P9TqNyM09gUSwiTYqsoALxVXbCuw@mail.gmail.com>
Message-ID: <20151023155743.8609.qmail@stuge.se>

Patrick Georgi wrote:
> 2015-10-23 17:48 GMT+02:00 Peter Stuge <peter at stuge.se>:
> > Code and data in mainboard directories for components which are not
> > the mainboard.
> In this case, they _are_ "the mainboard" just like magic numbers for
> USB trace lengths are.
> That stuff describes soldered-on components, it can't be more
> "mainboard" than that.

RAM is just as much the mainboard as the CPU/SOC is. (Not at all.)
We have cpu and soc directories for good reason.


//Peter


From dlaurie at chromium.org  Fri Oct 23 18:08:54 2015
From: dlaurie at chromium.org (Duncan Laurie)
Date: Fri, 23 Oct 2015 09:08:54 -0700
Subject: [coreboot]  SPD binaries in coreboot
In-Reply-To: <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
Message-ID: <CADv6+04CmLtT31FtNp1pZfCigkdkipsC292y5uZWMi2QJP5gXQ@mail.gmail.com>

On Friday, October 23, 2015, Aaron Durbin <adurbin at google.com
<javascript:_e(%7B%7D,'cvml','adurbin at google.com');>> wrote:

> On Fri, Oct 23, 2015 at 10:33 AM, Peter Stuge <peter at stuge.se> wrote:
> > Patrick Georgi wrote:
> >> we carry the SPD data in coreboot.
> > ..
> >> Currently, they're stored in a hexdump format
> > ..
> >> I see essentially two ways out of this
> > ..
> >> We could build our own tool to parse hex files and dump binary,
> >
> > If we create a tool for this process I think we can find a better
> > "source" format than hex files. Someone needs to take a look at the
> > JEDEC standard and think of what might be suitable.
> >
> >
> >> or we could ship SPD data as binary from the start
> >
> > I am actually strongly in favor of this approach. Converting SPD data
> > from human readable to machine readable is an orthogonal problem to
> > fixing the structure of our codebase, and there is no reason not to
> > solve the structural problem without first having to invent a new
> > data format.
> >
> >
> >> The second option has the appeal of being much simpler (and there
> >> isn't really a "preferred form" for editing SPD data that I'm aware of
> >> - is there?)
> >
> > I guess JEDEC does have a structured format. Maybe it's XML or JSON. :)
> >
>
> I don't believe JEDEC has a format. And the one thing missing here is
> that there is no standard way of distributing these files. In fact,
> I've mainly seen spreadsheets as a form of distribution from the
> memory manufacturers.
>
>
There is a format but it's kind of a mess.  On the one hand it would be
nice to be able to define the memory by human readable geometry and timing
for when we only get a datasheet and have to craft the DPS, but this is
hopefully a rare case.



> >
> >> So, is there a third option that I'm missing? Other opinions?
> >
> > The third option would be a plain text format which is easy to parse
> > but still covers the spec well.
>
> The issue is that spds are for dimms while soldered down dram aren't
> dimms. The spds provide the illusion of an actual dimm to the memory
> training code which needs specific values. And because of this those
> files need to be edited at times because of errors.
>
>
This is why we went from binary firms to hex in the first place, it is
important to be able to easily edit and review changes.

-duncan



> FWIW, LPDDR has the ability to be queried on the command bus so these
> constructs should go away over time.
>
> >
> >
> > Unblobing SPD files is an excellent entry-level project which we
> > could keep on shelf. Maybe for next GSoC..
> >
> > Fixing structure is more important IMO and shouldn't need to block on
> that.
>
> What's the specific structural gripe you have? The snippet of
> duplicated Makefile code?
>
> --
> 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/20151023/3a2858d4/attachment-0001.html>

From adurbin at google.com  Fri Oct 23 18:25:45 2015
From: adurbin at google.com (Aaron Durbin)
Date: Fri, 23 Oct 2015 11:25:45 -0500
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <20151023155743.8609.qmail@stuge.se>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
 <20151023154805.7741.qmail@stuge.se>
 <CAE-gjdX65t=Jpj11mvmO92P9TqNyM09gUSwiTYqsoALxVXbCuw@mail.gmail.com>
 <20151023155743.8609.qmail@stuge.se>
Message-ID: <CAE2855uVBki28s9xOzxb6nvu5ePuP1rRPYDDvR5DyU9kGO4tGQ@mail.gmail.com>

On Fri, Oct 23, 2015 at 10:57 AM, Peter Stuge <peter at stuge.se> wrote:
> Patrick Georgi wrote:
>> 2015-10-23 17:48 GMT+02:00 Peter Stuge <peter at stuge.se>:
>> > Code and data in mainboard directories for components which are not
>> > the mainboard.
>> In this case, they _are_ "the mainboard" just like magic numbers for
>> USB trace lengths are.
>> That stuff describes soldered-on components, it can't be more
>> "mainboard" than that.
>
> RAM is just as much the mainboard as the CPU/SOC is. (Not at all.)
> We have cpu and soc directories for good reason.

The only reason cpu/soc are in separate directories is because there
is a many to one relationship w.r.t. mainboards and said components.
I'm guessing you are thinking these are the same as well? So it's
duplication of Makefile recipes and potential duplication of SPD data?

The ordering of how the spds are built is very much a property of the
mainboard because different stuffing options have memory config GPIOs
set differently in order to know what memory was actually stuffed on
the board.


From gaumless at gmail.com  Fri Oct 23 18:32:22 2015
From: gaumless at gmail.com (Martin Roth)
Date: Fri, 23 Oct 2015 10:32:22 -0600
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CADv6+04CmLtT31FtNp1pZfCigkdkipsC292y5uZWMi2QJP5gXQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
 <CADv6+04CmLtT31FtNp1pZfCigkdkipsC292y5uZWMi2QJP5gXQ@mail.gmail.com>
Message-ID: <CA+e+Ov69anz6kF1pxrQd6GPb73jj0XYFNBZi8Oe_+SK91UYJ-g@mail.gmail.com>

> So, is there a third option that I'm missing? Other opinions?
>> > The third option would be a plain text format which is easy to parse
>> > but still covers the spec well.

I'd say that we should store the SPDs as binaries - these are easy to
use at build time, and there's no reason to build them every time.
They change, but infrequently.  Then we need a better tool.

It would be really nice to have a tool to update the binaries in a
reasonable way.  Using a hex editor on the binary or updating hex
values in a table are just as bad as far as I'm concerned.  The hex
value text file is just easier to review, but you still have to go to
the JEDEC specs to know what the heck just changed.

 It would be really handy to have a tool that would read in a binary
SPD, and allow you to edit the JEDEC values.  It should understand all
of the different JEDEC SPD specs.  The easiest way would be to
interpret the binary SPD and output all the fields to a text file
where they can then be edited.  Then it could read the text file and
generate a new SPD.

At that point, it doesn't much matter what language it's written in -
it's not in the critical build path.  I think Ron volunteered to write
it if we use go.  :)



Alternatively, the text files could be stored as text and generated
every time, but this puts the tool back in the build path and forces
constraints on the language.  Back to writing it in c?
Or we could store both binary and text and just use the binary at
build time.  This allows for ease of review and ease of use.

Martin


From pgeorgi at google.com  Fri Oct 23 18:38:19 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 23 Oct 2015 18:38:19 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CA+e+Ov69anz6kF1pxrQd6GPb73jj0XYFNBZi8Oe_+SK91UYJ-g@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
 <CADv6+04CmLtT31FtNp1pZfCigkdkipsC292y5uZWMi2QJP5gXQ@mail.gmail.com>
 <CA+e+Ov69anz6kF1pxrQd6GPb73jj0XYFNBZi8Oe_+SK91UYJ-g@mail.gmail.com>
Message-ID: <CAE-gjdUstZwVK5mm9dm2FYBUtKbWTYMKBd6PeC-LU-cHqskZ-Q@mail.gmail.com>

2015-10-23 18:32 GMT+02:00 Martin Roth <gaumless at gmail.com>:
>  It would be really handy to have a tool that would read in a binary
> SPD, and allow you to edit the JEDEC values.  It should understand all
> of the different JEDEC SPD specs.  The easiest way would be to
> interpret the binary SPD and output all the fields to a text file
> where they can then be edited.  Then it could read the text file and
> generate a new SPD.
>
> At that point, it doesn't much matter what language it's written in -
> it's not in the critical build path.
Sounds good to me.

I wonder if a daring soul (with java experience) could extend the
gerrit diff viewer, too ;-)

> Or we could store both binary and text and just use the binary at
> build time.  This allows for ease of review and ease of use.
That's quickly misleading because people look at one file while the
code uses another.


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


From nico.h at gmx.de  Fri Oct 23 18:59:19 2015
From: nico.h at gmx.de (Nico Huber)
Date: Fri, 23 Oct 2015 18:59:19 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CA+e+Ov69anz6kF1pxrQd6GPb73jj0XYFNBZi8Oe_+SK91UYJ-g@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
 <CADv6+04CmLtT31FtNp1pZfCigkdkipsC292y5uZWMi2QJP5gXQ@mail.gmail.com>
 <CA+e+Ov69anz6kF1pxrQd6GPb73jj0XYFNBZi8Oe_+SK91UYJ-g@mail.gmail.com>
Message-ID: <562A6767.708@gmx.de>

On 23.10.2015 18:32, Martin Roth wrote:
>> So, is there a third option that I'm missing? Other opinions?
>>>> The third option would be a plain text format which is easy to parse
>>>> but still covers the spec well.
> 
> I'd say that we should store the SPDs as binaries - these are easy to
> use at build time, and there's no reason to build them every time.
> They change, but infrequently.  Then we need a better tool.
That would also apply to a bootblock that needs a specific assembler or
romcc. Would you distribute that as a binary too?

Nico


From pgeorgi at google.com  Fri Oct 23 19:08:22 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 23 Oct 2015 19:08:22 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <562A675A.7050107@gmx.de>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <562A675A.7050107@gmx.de>
Message-ID: <CAE-gjdXvUSQNd6SStFqyA8PyaSwPPhfCrOZ3n4ZGdHZvzh7v0A@mail.gmail.com>

2015-10-23 18:59 GMT+02:00 Nico Huber <nico.h at gmx.de>:
> Well, we have raminit code that we can not fix, i.e. the BLOBs. So, if
> anything we should write serialization that takes a struct and generates
> the binary during runtime. Yeah, more BLOB wrapping code!
Even source AGESA (SourcePI?) uses spd.bin, see
src/northbridge/amd/agesa/common/common.c

It's the go-to workaround when you have code that expects an SPD ROM
to be around and you don't have it.


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


From pgeorgi at google.com  Fri Oct 23 19:09:59 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 23 Oct 2015 19:09:59 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <562A6767.708@gmx.de>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
 <CADv6+04CmLtT31FtNp1pZfCigkdkipsC292y5uZWMi2QJP5gXQ@mail.gmail.com>
 <CA+e+Ov69anz6kF1pxrQd6GPb73jj0XYFNBZi8Oe_+SK91UYJ-g@mail.gmail.com>
 <562A6767.708@gmx.de>
Message-ID: <CAE-gjdUB8ThHT=jdTBscNo3xuZfJtx2yTk47ZEcnuvVT34m01A@mail.gmail.com>

2015-10-23 18:59 GMT+02:00 Nico Huber <nico.h at gmx.de>:
>> I'd say that we should store the SPDs as binaries - these are easy to
>> use at build time, and there's no reason to build them every time.
>> They change, but infrequently.  Then we need a better tool.
> That would also apply to a bootblock that needs a specific assembler or
> romcc. Would you distribute that as a binary too?
If there's exactly one translation between "preferred form" and
binary, that is bijective, why not?


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


From gaumless at gmail.com  Fri Oct 23 19:09:43 2015
From: gaumless at gmail.com (Martin Roth)
Date: Fri, 23 Oct 2015 11:09:43 -0600
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <562A6767.708@gmx.de>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <20151023153321.6326.qmail@stuge.se>
 <CAE2855tNjjFOH_NUdFmxTgvXmzBasFupO9=k3G=M1G6yPKjaYQ@mail.gmail.com>
 <CADv6+04CmLtT31FtNp1pZfCigkdkipsC292y5uZWMi2QJP5gXQ@mail.gmail.com>
 <CA+e+Ov69anz6kF1pxrQd6GPb73jj0XYFNBZi8Oe_+SK91UYJ-g@mail.gmail.com>
 <562A6767.708@gmx.de>
Message-ID: <CA+e+Ov4XWSRp-X=T4-wzt7tm8SsCeShkcrQa284ndfjAbzRZSw@mail.gmail.com>

I don't think it's really very similar at all.  The bootblock output
can change drastically based on Kconfig settings.  Am I missing
something?

On Fri, Oct 23, 2015 at 10:59 AM, Nico Huber <nico.h at gmx.de> wrote:
> On 23.10.2015 18:32, Martin Roth wrote:
>>> So, is there a third option that I'm missing? Other opinions?
>>>>> The third option would be a plain text format which is easy to parse
>>>>> but still covers the spec well.
>>
>> I'd say that we should store the SPDs as binaries - these are easy to
>> use at build time, and there's no reason to build them every time.
>> They change, but infrequently.  Then we need a better tool.
> That would also apply to a bootblock that needs a specific assembler or
> romcc. Would you distribute that as a binary too?
>
> Nico


From nico.h at gmx.de  Fri Oct 23 18:59:06 2015
From: nico.h at gmx.de (Nico Huber)
Date: Fri, 23 Oct 2015 18:59:06 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
Message-ID: <562A675A.7050107@gmx.de>

Hi all,

On 23.10.2015 17:23, Patrick Georgi wrote:
> I see essentially two ways out of this, before we can start reducing
> duplication across the tree in that area:
> [...]
Neither of your options tackles the real problem. That is: We have
interfaces that use binary SPD data. It's just stupid. We can just put
the data in a struct and never use binaries.

Well, we have raminit code that we can not fix, i.e. the BLOBs. So, if
anything we should write serialization that takes a struct and generates
the binary during runtime. Yeah, more BLOB wrapping code!

And if we're going to write a tool, it should work the other way around:
deserializing an SPD binary, generating the code to fill the struct.

Nico


From adurbin at google.com  Fri Oct 23 20:35:12 2015
From: adurbin at google.com (Aaron Durbin)
Date: Fri, 23 Oct 2015 13:35:12 -0500
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
Message-ID: <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>

This one's for Ron.

On Fri, Oct 23, 2015 at 10:32 AM, ron minnich <rminnich at gmail.com> wrote:
> Build the tool in go. It's trivial. If you have an idea how it ought to work
> I can set it up in the playground in a few minutes.
>
> ron
>
> On Fri, Oct 23, 2015 at 8:24 AM Patrick Georgi <pgeorgi at google.com> wrote:
>>
>> Hi,
>>
>> Some mainboards come with soldered-on memory without SPD ROM. For
>> these, we carry the SPD data in coreboot.
>>
>> Currently, they're stored in a hexdump format that is then converted
>> to binary at build time. The various mechanisms of doing so fail on
>> some platform or another:
>>  - "echo -e -n $stuff" isn't well-liked by some shells (emits "e -n
>> $stuff")
>>  - "printf '\x42'" isn't well-liked by some shells (or /usr/bin/printf
>> tools) that don't support hexadecimal formats
>>  - "printf '\0377'" isn't well-liked by some non-conforming, but existing
>> shells
>>  - xxd -rg1 $file > $file.bin requires xxd, which comes with vim and
>> may just not exist
>>
>> I see essentially two ways out of this, before we can start reducing
>> duplication across the tree in that area:
>> We could build our own tool to parse hex files and dump binary, or we
>> could ship SPD data as binary from the start (and only have to
>> concatenate them).
>>
>> The second option has the appeal of being much simpler (and there
>> isn't really a "preferred form" for editing SPD data that I'm aware of
>> - is there?), but looks icky at a glance because it's binary (but it's
>> really just as impenetrable as the equivalent hexdump).
>>
>> So what do these files contain? Parameters (as in: facts) about the
>> hardware's size, layout, and timing, and a bunch of vendor/model
>> identifier strings.
>>
>>
>> So, is there a third option that I'm missing? Other opinions?
>> Patrick
>> --
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>> Hamburg
>> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>>
>> --
>> coreboot mailing list: coreboot 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 --------------
A non-text attachment was scrubbed...
Name: spd.go
Type: text/x-go
Size: 1629 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151023/8432a468/attachment.bin>

From rminnich at gmail.com  Fri Oct 23 20:44:35 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 23 Oct 2015 18:44:35 +0000
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
Message-ID: <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>

Aaron is my hero :-)

ron

On Fri, Oct 23, 2015 at 11:35 AM Aaron Durbin <adurbin at google.com> wrote:

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

From gaumless at gmail.com  Fri Oct 23 21:15:38 2015
From: gaumless at gmail.com (Martin Roth)
Date: Fri, 23 Oct 2015 13:15:38 -0600
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
Message-ID: <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>

I like what I understand Nico's proposal to be: Store the SPD data as
a c struct with all of the different JEDEC fields broken out.  it
would relatively trivial to compile this into an SPD binary, or it can
be used in whatever other fashion is desired.  A tool to convert from
a binary SPD to the structure file would be desirable to help the
transition, but it's out of the build path.

I believe this satisfies all the requirements:
- It's easy to review differences.
- It can be be built with no new tools.
- The fields are broken out, so you can actually tell what you're doing.




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


From peter at stuge.se  Fri Oct 23 21:37:56 2015
From: peter at stuge.se (Peter Stuge)
Date: Fri, 23 Oct 2015 21:37:56 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
Message-ID: <20151023193756.25518.qmail@stuge.se>

Aaron Durbin wrote:
> This one's for Ron.

En guard!

$ wc -c -l spd.*
  81 1462 spd.c
 100 1629 spd.go
$ 


//Peter
-------------- next part --------------
#include <stdio.h>
#include <string.h>
#include <errno.h>

static unsigned char spd[256];

int readhex(const char *filename) {
	int pos = 0, i, end;
	unsigned int n;
	char buf[128], *hex;
	FILE *f = fopen(filename, "r");

	if (!f) {
		fprintf(stderr, "%s: fopen(%s): %s\n", __func__, filename, strerror(errno));
		return 0;
	}

	memset(spd, 0, sizeof spd);

	while (pos < sizeof spd && fgets(buf, sizeof buf, f)) {
		hex = strtok(buf, ":");
		hex = strtok(NULL, ":");

		for (i = 0; i < 16; i++) {
			if (sscanf(hex, " %02x%n", &n, &end) < 1)
				goto done;

			spd[pos++] = n;
			hex += end;
		}
	}

done:
	fclose(f);
	return pos;
}

int writebin(const char *filename) {
	FILE *f = fopen(filename, "wb");
	size_t n;

	if (!f) {
		fprintf(stderr, "%s: fopen(%s): %s\n", __func__, filename, strerror(errno));
		return 0;
	}

	n = fwrite(spd, 1, sizeof spd, f);

	fclose(f);

	if (n != sizeof spd) {
		if (ferror(f))
			fprintf(stderr, "%s: fwrite: %s\n", __func__, strerror(errno));
		else
			fprintf(stderr, "%s: Short write! Got %zd, want %zd.\n", __func__, n, sizeof spd);

		return 0;
	}

	return 1;
}

int main(int argc, char *argv[]) {

	if (argc < 3) {
		fprintf(stderr, "syntax: %s input output\n", argv[0]);
		return 1;
	}

	if (!readhex(argv[1])) {
		fprintf(stderr, "Unable to read hex data from %s\n", argv[1]);
		return 1;
	}

	if (!writebin(argv[2])) {
		fprintf(stderr, "Unable to write binary data to %s\n", argv[2]);
		return 1;
	}

	return 0;
}

From c-d.hailfinger.devel.2006 at gmx.net  Fri Oct 23 21:43:04 2015
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 23 Oct 2015 21:43:04 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
 <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
Message-ID: <562A8DC8.8070409@gmx.net>

On 23.10.2015 21:15, Martin Roth wrote:
> I like what I understand Nico's proposal to be: Store the SPD data as
> a c struct with all of the different JEDEC fields broken out.  it
> would relatively trivial to compile this into an SPD binary, or it can
> be used in whatever other fashion is desired.  A tool to convert from
> a binary SPD to the structure file would be desirable to help the
> transition, but it's out of the build path.
>
> I believe this satisfies all the requirements:
> - It's easy to review differences.
> - It can be be built with no new tools.
> - The fields are broken out, so you can actually tell what you're doing.

Now that would be a nice way to combine the benefits of diffable source
and no-tool builds.

Ron, is that solution is acceptable to you?

Side note: There is a tool called decode-dimms which can be fed with
binary SPD dumps. It decodes everything in the SPD and could serve as a
nice way to verify the output of Ron's magic SPD tool.


Regards,
Carl-Daniel

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



From peter at stuge.se  Fri Oct 23 21:46:32 2015
From: peter at stuge.se (Peter Stuge)
Date: Fri, 23 Oct 2015 21:46:32 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
 <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
Message-ID: <20151023194632.26244.qmail@stuge.se>

Martin Roth wrote:
> I like what I understand Nico's proposal to be: Store the SPD data as
> a c struct with all of the different JEDEC fields broken out.

Yes, fun and games aside, this is definitely the way to go.

Thanks Nico for showing us the forest behind all the trees.


//Peter


From adurbin at google.com  Fri Oct 23 21:54:15 2015
From: adurbin at google.com (Aaron Durbin)
Date: Fri, 23 Oct 2015 14:54:15 -0500
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <562A8DC8.8070409@gmx.net>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
 <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
 <562A8DC8.8070409@gmx.net>
Message-ID: <CAE2855vzA2GjmvxeRUvccYG17erZD4MYTCmSabOHSzw=9Vt2Jw@mail.gmail.com>

On Fri, Oct 23, 2015 at 2:43 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 23.10.2015 21:15, Martin Roth wrote:
>> I like what I understand Nico's proposal to be: Store the SPD data as
>> a c struct with all of the different JEDEC fields broken out.  it
>> would relatively trivial to compile this into an SPD binary, or it can
>> be used in whatever other fashion is desired.  A tool to convert from
>> a binary SPD to the structure file would be desirable to help the
>> transition, but it's out of the build path.
>>
>> I believe this satisfies all the requirements:
>> - It's easy to review differences.
>> - It can be be built with no new tools.
>> - The fields are broken out, so you can actually tell what you're doing.
>
> Now that would be a nice way to combine the benefits of diffable source
> and no-tool builds.
>
> Ron, is that solution is acceptable to you?
>
> Side note: There is a tool called decode-dimms which can be fed with
> binary SPD dumps. It decodes everything in the SPD and could serve as a
> nice way to verify the output of Ron's magic SPD tool.

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


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


From nico.h at gmx.de  Fri Oct 23 22:59:34 2015
From: nico.h at gmx.de (Nico Huber)
Date: Fri, 23 Oct 2015 22:59:34 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE2855vzA2GjmvxeRUvccYG17erZD4MYTCmSabOHSzw=9Vt2Jw@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
 <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
 <562A8DC8.8070409@gmx.net>
 <CAE2855vzA2GjmvxeRUvccYG17erZD4MYTCmSabOHSzw=9Vt2Jw@mail.gmail.com>
Message-ID: <562A9FB6.80206@gmx.de>

On 23.10.2015 21:54, Aaron Durbin wrote:
> On Fri, Oct 23, 2015 at 2:43 PM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> On 23.10.2015 21:15, Martin Roth wrote:
>>> I like what I understand Nico's proposal to be: Store the SPD data as
>>> a c struct with all of the different JEDEC fields broken out.  it
>>> would relatively trivial to compile this into an SPD binary, or it can
>>> be used in whatever other fashion is desired.  A tool to convert from
>>> a binary SPD to the structure file would be desirable to help the
>>> transition, but it's out of the build path.
Thanks for the support. One remark: I would really prefer serializing
during runtime over compiling a C struct to a binary. The latter could
cause much bit-field headache given the SPD format.

>>>
>>> I believe this satisfies all the requirements:
>>> - It's easy to review differences.
>>> - It can be be built with no new tools.
>>> - The fields are broken out, so you can actually tell what you're doing.
>>
>> Now that would be a nice way to combine the benefits of diffable source
>> and no-tool builds.
>>
>> Ron, is that solution is acceptable to you?
>>
>> Side note: There is a tool called decode-dimms which can be fed with
>> binary SPD dumps. It decodes everything in the SPD and could serve as a
>> nice way to verify the output of Ron's magic SPD tool.
> 
> Do people realize these binaries sit in cbfs?
Yes, they do _currently_. We don't have to keep it that way.

> Are we going to compile
> random c files into object files then objcopy them? Then add to cbfs?
I wouldn't like that either.

> Also, the SPD format is quite silly as it is w.r.t. values crossing
> multiple fields in a byte, etc. There's not really a good way to
> encode that in a C struct.
We don't have to encode the binary SPD format in the C struct. We can
just use a C struct to store the SPD information. Like we used C structs
before we knew bit fields (wasn't that a good time?). If we encounter a
not so beautiful, unchangeable interface that needs the information as
binary SPD, well, we could decide to be gracious and serialize the in-
formation.

Nico


From mr.nuke.me at gmail.com  Sat Oct 24 00:22:28 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Fri, 23 Oct 2015 15:22:28 -0700
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
Message-ID: <562AB324.2060008@gmail.com>

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

Not everybody knows or wants to learn go.

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


From mr.nuke.me at gmail.com  Sat Oct 24 00:35:38 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Fri, 23 Oct 2015 15:35:38 -0700
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE2855vzA2GjmvxeRUvccYG17erZD4MYTCmSabOHSzw=9Vt2Jw@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
 <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
 <562A8DC8.8070409@gmx.net>
 <CAE2855vzA2GjmvxeRUvccYG17erZD4MYTCmSabOHSzw=9Vt2Jw@mail.gmail.com>
Message-ID: <562AB63A.2020000@gmail.com>


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

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

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

Alex

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


From mr.nuke.me at gmail.com  Sat Oct 24 00:37:56 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Fri, 23 Oct 2015 15:37:56 -0700
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <562A9FB6.80206@gmx.de>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
 <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
 <562A8DC8.8070409@gmx.net>
 <CAE2855vzA2GjmvxeRUvccYG17erZD4MYTCmSabOHSzw=9Vt2Jw@mail.gmail.com>
 <562A9FB6.80206@gmx.de>
Message-ID: <562AB6C4.6000004@gmail.com>

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

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

> over compiling a C struct to a binary.

We're not doing that either.

Alex


From nico.h at gmx.de  Sat Oct 24 01:22:50 2015
From: nico.h at gmx.de (Nico Huber)
Date: Sat, 24 Oct 2015 01:22:50 +0200
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <562AB6C4.6000004@gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
 <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
 <562A8DC8.8070409@gmx.net>
 <CAE2855vzA2GjmvxeRUvccYG17erZD4MYTCmSabOHSzw=9Vt2Jw@mail.gmail.com>
 <562A9FB6.80206@gmx.de> <562AB6C4.6000004@gmail.com>
Message-ID: <562AC14A.7030907@gmx.de>

On 24.10.2015 00:37, Alex G. wrote:
> On 10/23/2015 01:59 PM, Nico Huber wrote:
>> Thanks for the support. One remark: I would really prefer serializing
>> during runtime
> 
> Why waste runtime cycles (and code space) doing something you can
> already do at build time?

I don't see a requirement for a binary other than feeding a blob.
And don't like the idea to add another blob to cbfs just to feed another
blob. But actually I don't care much about the blob case.

What I care about is that we shouldn't serialize in the first place if
we can avoid it. Even if we don't serialize at runtime but use a binary,
we'd still waste runtime cycles deserializing later.

Nico


From mr.nuke.me at gmail.com  Sat Oct 24 01:36:17 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Fri, 23 Oct 2015 16:36:17 -0700
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <562AC14A.7030907@gmx.de>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
 <CAP6exYLRrhtxQtsMPaTBq=febScNYo7u3Cu4954BgZdXQ2sM4A@mail.gmail.com>
 <CA+e+Ov6JPLs9xbCNWK7WW-3N_w8W25RAkqezRr6w-BczgsC9YQ@mail.gmail.com>
 <562A8DC8.8070409@gmx.net>
 <CAE2855vzA2GjmvxeRUvccYG17erZD4MYTCmSabOHSzw=9Vt2Jw@mail.gmail.com>
 <562A9FB6.80206@gmx.de> <562AB6C4.6000004@gmail.com>
 <562AC14A.7030907@gmx.de>
Message-ID: <562AC471.3070104@gmail.com>

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

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

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


Alex


From ssl at google.com  Fri Oct 23 21:06:03 2015
From: ssl at google.com (Sheng-Liang Song)
Date: Fri, 23 Oct 2015 12:06:03 -0700
Subject: [coreboot] SPD binaries in coreboot
In-Reply-To: <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
References: <CAE-gjdX=86+Ow7feftNs11yNgpNNA8gqH=W1ZQOy8S_J=33ECQ@mail.gmail.com>
 <CAP6exYK0Zr-_LoBKaryFN12afe56VXppDevr4HvWnWQboA65Fg@mail.gmail.com>
 <CAE2855t0q5TqqsFvmCQWqycNMYBQ5+m3TJ-gLQHGpAoQxY5pOw@mail.gmail.com>
Message-ID: <CABGK7UP+25wY3iL0UpZLFR0HMFHe21RSg=VEHxyhi-+A6QaEyA@mail.gmail.com>

FYI:
I used put spd data in a stand alone C source code so that I can edit with
vi directly.

unsigned char global_spd_data[256]  = __attribute__ ((section("spd_data")))
{
0x??, 0x??, ...
};

Note: I also put spd_data in the spd data section that is the end of my
binary xloader code.
I can easily edit with bvi editor too.

https://en.wikipedia.org/wiki/Serial_presence_detect


On Fri, Oct 23, 2015 at 11:35 AM, Aaron Durbin <adurbin at google.com> wrote:

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



-- 
Sheng-Liang Song | Software Engineer | ssl at google.com | 650-537-5017
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151023/6db56897/attachment.html>

From lynxis at fe80.eu  Sun Oct 25 23:23:18 2015
From: lynxis at fe80.eu (Alexander Couzens)
Date: Sun, 25 Oct 2015 23:23:18 +0100
Subject: [coreboot] Berlin Usergroup Meeting October 28.10.2015 20:30 cccb
Message-ID: <20151025232318.3460bd4c@lazus.yip>

tldr;
28.10.2015 20:30 cccb

Hi,

The Berlin Usergroup Meeting in October will taken
place on 28.10.2015 in the rooms of the chaos computer club berlin
(cccb).

Chaos Computer Club Berlin e.V.
Marienstra?e 11
10117 Berlin

https://berlin.ccc.de/wiki/Club_Discordia

best,
lynxis

PS. It looks like the date for the november is the 18.11.2015 20:30.
-- 
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/20151025/75583f13/attachment.sig>

From gaumless at gmail.com  Mon Oct 26 22:51:21 2015
From: gaumless at gmail.com (Martin Roth)
Date: Mon, 26 Oct 2015 15:51:21 -0600
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets
	for 4.2 release
Message-ID: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>

I'd like to start a discussion about boards, chipsets, drivers, or
other code that can be removed from the tree.

At the coreboot conference in Bonn, we discussed this some. I believe
that we decided to wait until the next release/branch of the coreboot
tree before removing anything.  By planning ahead and deleting the
components immediately after the release, we can list the things that
have been end-of-lifed in the branch release notes.

By discussing this on the mailing list instead of just pushing commits
to the tree, we can get better buy in from all interested parties.


I'd request that these be boards & chips that are no longer being
produced, and haven't been updated in a few years.

These seem like good candidates to start the discussion:
   mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
   northbridge/via/vx800 - http://review.coreboot.org/#/c/7471

As far as I can tell, the last real contributions to these came in
2009 - all the changes since then have been cleanup and modifications
for other changes across the coreboot tree.

What other directories should be removed from the tree after the next release?


Eventually it would be nice to be able to use submissions to
board-status repo to determine what's being used.  We're just not at
that point yet.


From mr.nuke.me at gmail.com  Tue Oct 27 04:36:20 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Mon, 26 Oct 2015 20:36:20 -0700
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
Message-ID: <562EF134.20204@gmail.com>

On 10/26/2015 02:51 PM, Martin Roth wrote:
> I'd like to start a discussion about boards, chipsets, drivers, or
> other code that can be removed from the tree.
>
> What other directories should be removed from the tree after the next release?
> 
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native
support, I don't think we want to haul around the AGESA implementations,
which have been troublesome in the past.

Actually, branch off those boards, keep them alive in their little
branch, but remove them from master. Gerrit is knows how to handle
branches, so we already have the infrastructure in place to support this.

Alex


From peter at stuge.se  Tue Oct 27 09:34:59 2015
From: peter at stuge.se (Peter Stuge)
Date: Tue, 27 Oct 2015 09:34:59 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards
	and	chipsets for 4.2 release
In-Reply-To: <562EF134.20204@gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com>
Message-ID: <20151027083459.7160.qmail@stuge.se>

Alex G. wrote:
> > I'd like to start a discussion about boards, chipsets, drivers, or
> > other code that can be removed from the tree.
> 
> All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native
> support, I don't think we want to haul around the AGESA implementations,
> which have been troublesome in the past.
> 
> Actually, branch off those boards, keep them alive in their little
> branch, but remove them from master.

Hm maybe. It's important that the boards which use AGESA are still
available somehow, so that they could be ported to coreboot init
if someone has interest in doing that. Maybe a branch is good enough.


//Peter


From wvervoorn at eltan.com  Tue Oct 27 16:01:38 2015
From: wvervoorn at eltan.com (Wim Vervoorn)
Date: Tue, 27 Oct 2015 15:01:38 +0000
Subject: [coreboot] Proposal: Removing obsolete & EOL boards
	and	chipsets for 4.2 release
In-Reply-To: <20151027083459.7160.qmail@stuge.se>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
Message-ID: <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>

Sounds like a good idea to create a branch of these but shouldn't that be done for other boards as well.

So when you intend to remove boards to create version 4.2 you create a 4.1 branch of the existing state with those boards included. Then remove all boards that need to be dropped.

When it's handled this way it's probably easier to drop boards that aren't used actively and thereby dropping unnecessary maintenance work.

BR Wim

-----Original Message-----
From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Peter Stuge
Sent: Tuesday, October 27, 2015 9:35 AM
To: coreboot at coreboot.org
Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

Alex G. wrote:
> > I'd like to start a discussion about boards, chipsets, drivers, or 
> > other code that can be removed from the tree.
> 
> All of AGESA fam10 and fam15. With Raptop Engineering upstreaming 
> native support, I don't think we want to haul around the AGESA 
> implementations, which have been troublesome in the past.
> 
> Actually, branch off those boards, keep them alive in their little 
> branch, but remove them from master.

Hm maybe. It's important that the boards which use AGESA are still available somehow, so that they could be ported to coreboot init if someone has interest in doing that. Maybe a branch is good enough.


//Peter

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






From mytbk920423 at gmail.com  Tue Oct 27 16:21:30 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Tue, 27 Oct 2015 23:21:30 +0800
Subject: [coreboot]  Linux kernel hangs
Message-ID: <20151027152130.GA8032@mytbk-laptop>

Hi,

I'm testing the Lenovo T420 port[1]. After I saw some commits on
Sandy/Ivy RAM init and native graphics init code, I asked Nicolas
Reinecke to rebase and update the code. After I flashed the new
firmware, coreboot runs fine and boot to GRUB payload. However, Linux
kernel hanged and could not boot. I think there must be something
wrong with some of the upstream commits.

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

Iru Cai
-------------- next part --------------
USB


coreboot-4.1-855-gc584a7c Mon Oct 26 20:01:31 UTC 2015 romstage starting...
Setting up static southbridge registers... done.
Disabling Watchdog reboot... done.
Setting up static northbridge registers... done.
Initializing Graphics...
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
Back from sandybridge_early_initialization()
SMBus controller enabled.
CPU id(206a7): Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
AES supported, TXT supported, VT supported
PCH type: QM67, device id: 1c4f, rev id 5
Intel ME early init
Intel ME firmware is ready
ME: Requested 32MB UMA
Starting native Platform init
  Row    addr bits  : 15
  Column addr bits  : 10
  Number of ranks   : 2
  DIMM Capacity     : 4096 MB
  CAS latencies     : 5 6 7 8 9
  tCKmin            :   1.500 ns
  tAAmin            :  13.125 ns
  tWRmin            :  15.000 ns
  tRCDmin           :  13.125 ns
  tRRDmin           :   6.000 ns
  tRPmin            :  13.125 ns
  tRASmin           :  36.000 ns
  tRCmin            :  49.125 ns
  tRFCmin           : 160.000 ns
  tWTRmin           :   7.500 ns
  tRTPmin           :   7.500 ns
  tFAWmin           :  30.000 ns
rankmap[0] = 0x3
 PLL busy...done
MCU frequency is set at : 666 MHz
Selected DRAM frequency: 666 MHz
Minimum  CAS latency   : 9T
Selected CAS latency   : 9T
Selected CWL latency   : 7T
Selected tRCD          : 9T
Selected tRP           : 9T
Selected tRAS          : 24T
Selected tWR           : 10T
Selected tFAW          : 20T
Selected tRRD          : 4T
Selected tRTP          : 5T
Selected tWTR          : 5T
Selected tRFC          : 107T
[c14] = 3000000
[320c] = 4024000
[d14] = 0
[330c] = 4000
[4000] = 187999
[4004] = ca145454
[400c] = a0690
[4298] = 5a6b1450
[42a4] = 41f97200
[4400] = 187999
[4404] = ca145454
[440c] = a0690
[4698] = 5a6b1450
[46a4] = 41f97200
Done dimm mapping
PCI:[a0] = 0
PCI:[a4] = 1
PCI:[bc] = c2a00000
PCI:[a8] = 3b600000
PCI:[ac] = 1
PCI:[b8] = c0000000
PCI:[b0] = c0a00000
PCI:[b4] = c0800000
PCI:[7c] = 7f
PCI:[70] = fe000000
PCI:[74] = 0
PCI:[78] = fe000c00
Done memory map
RCOMP...done
COMP2 done
COMP1 done
FORCE RCOMP and wait 20us...done
Done io registers
Done jedec reset
Done MRS commands
High adjust 0:0000ffffffffffff
High adjust 1:0000ffffffffffff
High adjust 2:0000ffffffffffff
High adjust 3:0000ffffffffffff
High adjust 4:00000000ffffffff
High adjust 5:0000ffffffffffff
High adjust 6:00000000ffffffff
High adjust 7:00000000ffffffff
High adjust 0:0000ffffffffffff
High adjust 1:0000ffffffffffff
High adjust 2:0000ffffffffffff
High adjust 3:0000ffffffffffff
High adjust 4:00000000ffffffff
High adjust 5:0000ffffffffffff
High adjust 6:00000000ffffffff
High adjust 7:00000000ffffffff
t123: 1912, 9120, 500
ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State    : 0x4e
ME: FWS2: 0x104e0006
ME:  Bist in progress: 0x0
ME:  ICC Status      : 0x3
ME:  Invoke MEBx     : 0x0
ME:  CPU replaced    : 0x0
ME:  MBP ready       : 0x0
ME:  MFS failure     : 0x0
ME:  Warm reset req  : 0x0
ME:  CPU repl valid  : 0x0
ME:  (Reserved)      : 0x0
ME:  FW update req   : 0x0
ME:  (Reserved)      : 0x0
ME:  Current state   : 0x4e
ME:  Current PM event: 0x0
ME:  Progress code   : 0x1
Waited long enough, or CPU was not replaced, continue...
PASSED! Tell ME that DRAM is ready
ME: FWS2: 0x10500006
ME:  Bist in progress: 0x0
ME:  ICC Status      : 0x3
ME:  Invoke MEBx     : 0x0
ME:  CPU replaced    : 0x0
ME:  MBP ready       : 0x0
ME:  MFS failure     : 0x0
ME:  Warm reset req  : 0x0
ME:  CPU repl valid  : 0x0
ME:  (Reserved)      : 0x0
ME:  FW update req   : 0x0
ME:  (Reserved)      : 0x0
ME:  Current state   : 0x50
ME:  Current PM event: 0x0
ME:  Progress code   : 0x1
ME: Requested BIOS Action: Continue to boot
ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : NO
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : Bring up
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : BUP Phase
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State    : 0x50
memcfg DDR3 clock 1333 MHz
memcfg channel assignment: A: 0, B  1, C  2
memcfg channel[0] config (00620010):
   ECC inactive
   enhanced interleave mode on
   rank interleave on
   DIMMA 4096 MB width x8 dual rank, selected
   DIMMB 0 MB width x8 single rank
memcfg channel[1] config (00000000):
   ECC inactive
   enhanced interleave mode off
   rank interleave off
   DIMMA 0 MB width x8 single rank, selected
   DIMMB 0 MB width x8 single rank
CBMEM:
IMD: root @ bffff000 254 entries.
IMD: root @ bfffec00 62 entries.
Relocate MRC DATA from feffa79c to bffdd000 (1040 bytes)
CBFS provider active.
CBFS @ 700000 size ff440
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 41b00 size 13acd
'fallback/ramstage' located at offset: 741b38 size: 13acd
USB


coreboot-4.1-855-gc584a7c Mon Oct 26 20:01:31 UTC 2015 ramstage starting...
Moving GDT to bfffe8c0...ok
Normal boot.
BS: Entering BS_PRE_DEVICE state.
BS: Exiting BS_PRE_DEVICE state.
BS: BS_PRE_DEVICE times (us): entry 0 run 1245 exit 0
BS: Entering BS_DEV_INIT_CHIPS state.
BS: Exiting BS_DEV_INIT_CHIPS state.
BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 1245 exit 0
BS: Entering BS_DEV_ENUMERATE state.
Enumerating buses...
Show all devs... Before device enumeration.
Root Device: enabled 1
CPU_CLUSTER: 0: enabled 1
APIC: 00: enabled 1
APIC: acac: enabled 0
DOMAIN: 0000: enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:01.0: enabled 0
PCI: 00:02.0: enabled 1
PCI: 00:16.0: enabled 0
PCI: 00:16.1: enabled 0
PCI: 00:16.2: enabled 0
PCI: 00:16.3: enabled 0
PCI: 00:19.0: enabled 1
PCI: 00:1a.0: enabled 1
PCI: 00:1b.0: enabled 1
PCI: 00:1c.0: enabled 0
PCI: 00:1c.1: enabled 1
PCI: 00:1c.2: enabled 0
PCI: 00:1c.3: enabled 1
PCI: 00:1c.4: enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:1c.5: enabled 0
PCI: 00:1c.6: enabled 0
PCI: 00:1c.7: enabled 0
PCI: 00:1d.0: enabled 1
PCI: 00:1e.0: enabled 0
PCI: 00:1f.0: enabled 1
PNP: 00ff.1: enabled 1
PNP: 0c31.0: enabled 1
PNP: 00ff.2: enabled 1
PCI: 00:1f.2: enabled 1
PCI: 00:1f.3: enabled 1
I2C: 00:54: enabled 1
I2C: 00:55: enabled 1
I2C: 00:56: enabled 1
I2C: 00:57: enabled 1
I2C: 00:5c: enabled 1
I2C: 00:5d: enabled 1
I2C: 00:5e: enabled 1
I2C: 00:5f: enabled 1
PCI: 00:1f.5: enabled 0
PCI: 00:1f.6: enabled 1
Compare with tree...
Root Device: enabled 1
 CPU_CLUSTER: 0: enabled 1
  APIC: 00: enabled 1
  APIC: acac: enabled 0
 DOMAIN: 0000: enabled 1
  PCI: 00:00.0: enabled 1
  PCI: 00:01.0: enabled 0
  PCI: 00:02.0: enabled 1
  PCI: 00:16.0: enabled 0
  PCI: 00:16.1: enabled 0
  PCI: 00:16.2: enabled 0
  PCI: 00:16.3: enabled 0
  PCI: 00:19.0: enabled 1
  PCI: 00:1a.0: enabled 1
  PCI: 00:1b.0: enabled 1
  PCI: 00:1c.0: enabled 0
  PCI: 00:1c.1: enabled 1
  PCI: 00:1c.2: enabled 0
  PCI: 00:1c.3: enabled 1
  PCI: 00:1c.4: enabled 1
   PCI: 00:00.0: enabled 1
  PCI: 00:1c.5: enabled 0
  PCI: 00:1c.6: enabled 0
  PCI: 00:1c.7: enabled 0
  PCI: 00:1d.0: enabled 1
  PCI: 00:1e.0: enabled 0
  PCI: 00:1f.0: enabled 1
   PNP: 00ff.1: enabled 1
   PNP: 0c31.0: enabled 1
   PNP: 00ff.2: enabled 1
  PCI: 00:1f.2: enabled 1
  PCI: 00:1f.3: enabled 1
   I2C: 00:54: enabled 1
   I2C: 00:55: enabled 1
   I2C: 00:56: enabled 1
   I2C: 00:57: enabled 1
   I2C: 00:5c: enabled 1
   I2C: 00:5d: enabled 1
   I2C: 00:5e: enabled 1
   I2C: 00:5f: enabled 1
  PCI: 00:1f.5: enabled 0
  PCI: 00:1f.6: enabled 1
Root Device scanning...
root_dev_scan_bus for Root Device
CPU_CLUSTER: 0 enabled
DOMAIN: 0000 enabled
DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [8086/0104] ops
Normal boot.
PCI: 00:00.0 [8086/0104] enabled
Capability: type 0x0d @ 0x88
Capability: type 0x01 @ 0x80
Capability: type 0x05 @ 0x90
Capability: type 0x10 @ 0xa0
Capability: type 0x0d @ 0x88
Capability: type 0x01 @ 0x80
Capability: type 0x05 @ 0x90
Capability: type 0x10 @ 0xa0
PCI: 00:01.0 subordinate bus PCI Express
PCI: 00:01.0 [8086/0101] disabled
PCI: 00:02.0 [8086/0000] ops
PCI: 00:02.0 [8086/0126] enabled
PCI: 00:04.0 [8086/0103] enabled
PCI: 00:16.0: Disabling device
PCI: 00:16.0 [8086/1c3a] ops
PCI: 00:16.0 [8086/1c3a] disabled
PCI: 00:16.1: Disabling device
PCI: 00:16.2: Disabling device
PCI: 00:16.3: Disabling device
PCI: 00:19.0 [8086/1502] enabled
PCI: 00:1a.0 [8086/0000] ops
PCI: 00:1a.0 [8086/1c2d] enabled
PCI: 00:1b.0 [8086/0000] ops
PCI: 00:1b.0 [8086/1c20] enabled
PCH: PCIe Root Port coalescing is enabled
PCI: 00:1c.0: Disabling device
PCI: 00:1c.0: check set enabled
PCH: Remap PCIe function 1 to 0
PCI: 00:1c.1 [8086/0000] bus ops
PCI: 00:1c.1 [8086/1c12] enabled
PCI: 00:1c.2: Disabling device
PCH: Remap PCIe function 3 to 0
PCI: 00:1c.3 [8086/0000] bus ops
PCI: 00:1c.3 [8086/1c16] enabled
PCH: Remap PCIe function 4 to 0
PCI: 00:1c.4 [8086/0000] bus ops
PCI: 00:1c.4 [8086/1c18] enabled
PCI: 00:1c.5: Disabling device
PCI: 00:1c.6: Disabling device
PCI: 00:1c.7: Disabling device
PCH: RPFN 0x76543210 -> 0xfed31a0c
PCH: PCIe map 1c.0 -> 1c.4
PCH: PCIe map 1c.1 -> 1c.0
PCH: PCIe map 1c.3 -> 1c.1
PCH: PCIe map 1c.4 -> 1c.3
PCI: 00:1d.0 [8086/0000] ops
PCI: 00:1d.0 [8086/1c26] enabled
PCI: 00:1e.0: Disabling device
PCI: 00:1f.0 [8086/0000] bus ops
PCI: 00:1f.0 [8086/1c4f] enabled
PCI: 00:1f.2 [8086/0000] ops
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
PCI: 00:1f.2 [8086/1c01] enabled
PCI: 00:1f.3 [8086/0000] bus ops
PCI: 00:1f.3 [8086/1c22] enabled
PCI: 00:1f.5: Disabling device
PCI: 00:1f.6 [8086/1c24] enabled
PCI: 00:1c.0 scanning...
do_pci_scan_bridge for PCI: 00:1c.0
Capability: type 0x10 @ 0x40
Capability: type 0x09 @ 0xe0
PCI: pci_scan_bus for bus 01
PCI: 01:00.0 [8086/0000] ops
PCI: 01:00.0 [8086/0085] enabled
Capability: type 0x01 @ 0xc8
Capability: type 0x05 @ 0xd0
Capability: type 0x10 @ 0xe0
Capability: type 0x10 @ 0x40
Enabling Common Clock Configuration
ASPM: Enabled L1
PCI: 00:1c.1 scanning...
do_pci_scan_bridge for PCI: 00:1c.1
Capability: type 0x10 @ 0x40
Capability: type 0x09 @ 0xe0
PCI: pci_scan_bus for bus 02
PCI: 00:1c.3 scanning...
do_pci_scan_bridge for PCI: 00:1c.3
Capability: type 0x10 @ 0x40
Capability: type 0x09 @ 0xe0
PCI: pci_scan_bus for bus 03
PCI: 03:00.0 [1180/0000] ops
PCI: 03:00.0 [1180/e823] enabled
Capability: type 0x05 @ 0x50
Capability: type 0x01 @ 0x78
Capability: type 0x10 @ 0x80
Capability: type 0x10 @ 0x40
Enabling Common Clock Configuration
ASPM: Enabled L0s and L1
PCI: 00:1f.0 scanning...
scan_lpc_bus for PCI: 00:1f.0
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
PNP: 00ff.1 enabled
PNP: 0c31.0 enabled
recv_ec_data: 0x38
recv_ec_data: 0x33
recv_ec_data: 0x48
recv_ec_data: 0x54
recv_ec_data: 0x32
recv_ec_data: 0x37
recv_ec_data: 0x57
recv_ec_data: 0x57
recv_ec_data: 0x14
recv_ec_data: 0x03
recv_ec_data: 0x10
recv_ec_data: 0x11
EC Firmware ID 83HT27WW-3.20, Version 1.01B
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
WARNING: No CMOS option 'low_battery_beep'.
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
recv_ec_data: 0x00
recv_ec_data: 0x10
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
recv_ec_data: 0x20
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
recv_ec_data: 0x30
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
recv_ec_data: 0x00
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
recv_ec_data: 0xa7
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
recv_ec_data: 0xe2
recv_ec_data: 0x70
PNP: 00ff.2 enabled
scan_lpc_bus for PCI: 00:1f.0 done
PCI: 00:1f.3 scanning...
scan_smbus for PCI: 00:1f.3
smbus: PCI: 00:1f.3[0]->I2C: 01:54 enabled
smbus: PCI: 00:1f.3[0]->I2C: 01:55 enabled
smbus: PCI: 00:1f.3[0]->I2C: 01:56 enabled
smbus: PCI: 00:1f.3[0]->I2C: 01:57 enabled
smbus: PCI: 00:1f.3[0]->I2C: 01:5c enabled
smbus: PCI: 00:1f.3[0]->I2C: 01:5d enabled
smbus: PCI: 00:1f.3[0]->I2C: 01:5e enabled
smbus: PCI: 00:1f.3[0]->I2C: 01:5f enabled
scan_smbus for PCI: 00:1f.3 done
root_dev_scan_bus for Root Device done
done
BS: Exiting BS_DEV_ENUMERATE state.
BS: BS_DEV_ENUMERATE times (us): entry 0 run 272488 exit 0
BS: Entering BS_DEV_RESOURCES state.
found VGA at PCI: 00:02.0
Setting up VGA for PCI: 00:02.0
Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Allocating resources...
Reading resources...
Root Device read_resources bus 0 link: 0
CPU_CLUSTER: 0 read_resources bus 0 link: 0
APIC: 00 missing read_resources
CPU_CLUSTER: 0 read_resources bus 0 link: 0 done
DOMAIN: 0000 read_resources bus 0 link: 0
Adding PCIe enhanced config space BAR 0xf0000000-0xf4000000.
PCI: 00:1a.0 EHCI BAR hook registered
PCI: 00:1c.0 read_resources bus 1 link: 0
PCI: 00:1c.0 read_resources bus 1 link: 0 done
PCI: 00:1c.1 read_resources bus 2 link: 0
PCI: 00:1c.1 read_resources bus 2 link: 0 done
PCI: 00:1c.3 read_resources bus 3 link: 0
PCI: 00:1c.3 read_resources bus 3 link: 0 done
More than one caller of pci_ehci_read_resources from PCI: 00:1d.0
PCI: 00:1f.0 read_resources bus 0 link: 0
PNP: 00ff.1 missing read_resources
PNP: 0c31.0 missing read_resources
PNP: 00ff.2 missing read_resources
PCI: 00:1f.0 read_resources bus 0 link: 0 done
PCI: 00:1f.3 read_resources bus 1 link: 0
PCI: 00:1f.3 read_resources bus 1 link: 0 done
DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
Done reading resources.
Show resources in subtree (Root Device)...After reading.
 Root Device child on link 0 CPU_CLUSTER: 0
  CPU_CLUSTER: 0 child on link 0 APIC: 00
   APIC: 00
   APIC: acac
  DOMAIN: 0000 child on link 0 PCI: 00:00.0
  DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffff flags 40040100 index 10000000
  DOMAIN: 0000 resource base 0 size 0 align 0 gran 0 limit ffffffff flags 40040200 index 10000100
   PCI: 00:00.0
   PCI: 00:00.0 resource base f0000000 size 4000000 align 0 gran 0 limit 0 flags e0000200 index cf
   PCI: 00:01.0
   PCI: 00:02.0
   PCI: 00:02.0 resource base 0 size 400000 align 22 gran 22 limit ffffffffffffffff flags 201 index 10
   PCI: 00:02.0 resource base 0 size 10000000 align 28 gran 28 limit ffffffffffffffff flags 1201 index 18
   PCI: 00:02.0 resource base 0 size 40 align 6 gran 6 limit ffff flags 100 index 20
   PCI: 00:04.0
   PCI: 00:04.0 resource base 0 size 8000 align 15 gran 15 limit ffffffffffffffff flags 201 index 10
   PCI: 00:16.0
   PCI: 00:16.1
   PCI: 00:16.2
   PCI: 00:16.3
   PCI: 00:19.0
   PCI: 00:19.0 resource base 0 size 20000 align 17 gran 17 limit ffffffff flags 200 index 10
   PCI: 00:19.0 resource base 0 size 1000 align 12 gran 12 limit ffffffff flags 200 index 14
   PCI: 00:19.0 resource base 0 size 20 align 5 gran 5 limit ffff flags 100 index 18
   PCI: 00:1a.0
   PCI: 00:1a.0 resource base 0 size 400 align 12 gran 10 limit ffffffff flags 200 index 10
   PCI: 00:1b.0
   PCI: 00:1b.0 resource base 0 size 4000 align 14 gran 14 limit ffffffffffffffff flags 201 index 10
   PCI: 00:1c.4
   PCI: 00:1c.0 child on link 0 PCI: 01:00.0
   PCI: 00:1c.0 resource base 0 size 0 align 12 gran 12 limit ffff flags 80102 index 1c
   PCI: 00:1c.0 resource base 0 size 0 align 20 gran 20 limit ffffffffffffffff flags 81202 index 24
   PCI: 00:1c.0 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80202 index 20
    PCI: 01:00.0
    PCI: 01:00.0 resource base 0 size 2000 align 13 gran 13 limit ffffffffffffffff flags 201 index 10
   PCI: 00:1c.2
   PCI: 00:1c.1
   PCI: 00:1c.1 resource base 0 size 0 align 12 gran 12 limit ffff flags 80102 index 1c
   PCI: 00:1c.1 resource base 0 size 0 align 20 gran 20 limit ffffffffffffffff flags 81202 index 24
   PCI: 00:1c.1 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80202 index 20
   PCI: 00:1c.3 child on link 0 PCI: 03:00.0
   PCI: 00:1c.3 resource base 0 size 0 align 12 gran 12 limit ffff flags 80102 index 1c
   PCI: 00:1c.3 resource base 0 size 0 align 20 gran 20 limit ffffffffffffffff flags 81202 index 24
   PCI: 00:1c.3 resource base 0 size 0 align 20 gran 20 limit ffffffff flags 80202 index 20
    PCI: 03:00.0
    PCI: 03:00.0 resource base 0 size 100 align 12 gran 8 limit ffffffff flags 200 index 10
Unknown device path type: 0
    
Unknown device path type: 0
     resource base 0 size 800000 align 22 gran 22 limit ffffffff flags 200 index 10
Unknown device path type: 0
     resource base 0 size 800000 align 22 gran 22 limit ffffffff flags 1200 index 14
Unknown device path type: 0
     resource base 0 size 1000 align 12 gran 12 limit ffff flags 100 index 18
   PCI: 00:1c.5
   PCI: 00:1c.6
   PCI: 00:1c.7
   PCI: 00:1d.0
   PCI: 00:1d.0 resource base 0 size 400 align 12 gran 10 limit ffffffff flags 200 index 10
   PCI: 00:1e.0
   PCI: 00:1f.0 child on link 0 PNP: 00ff.1
   PCI: 00:1f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0040100 index 10000000
   PCI: 00:1f.0 resource base ff000000 size 1000000 align 0 gran 0 limit 0 flags c0040200 index 10000100
   PCI: 00:1f.0 resource base fec00000 size 1000 align 0 gran 0 limit 0 flags c0000200 index 3
   PCI: 00:1f.0 resource base 1600 size 7c align 0 gran 0 limit 0 flags c0040100 index 10000200
   PCI: 00:1f.0 resource base 15e0 size c align 0 gran 0 limit 0 flags c0040100 index 10000300
    PNP: 00ff.1
    PNP: 00ff.1 resource base 15e0 size 10 align 5 gran 5 limit 0 flags 80000100 index 77
    PNP: 0c31.0
    PNP: 00ff.2
    PNP: 00ff.2 resource base 62 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 00ff.2 resource base 66 size 0 align 0 gran 0 limit 0 flags c0000100 index 62
    PNP: 00ff.2 resource base 1600 size 0 align 0 gran 0 limit 0 flags c0000100 index 64
    PNP: 00ff.2 resource base 1604 size 0 align 0 gran 0 limit 0 flags c0000100 index 66
   PCI: 00:1f.2
   PCI: 00:1f.2 resource base 0 size 8 align 3 gran 3 limit ffff flags 100 index 10
   PCI: 00:1f.2 resource base 0 size 4 align 2 gran 2 limit ffff flags 100 index 14
   PCI: 00:1f.2 resource base 0 size 8 align 3 gran 3 limit ffff flags 100 index 18
   PCI: 00:1f.2 resource base 0 size 4 align 2 gran 2 limit ffff flags 100 index 1c
   PCI: 00:1f.2 resource base 0 size 20 align 5 gran 5 limit ffff flags 100 index 20
   PCI: 00:1f.2 resource base 0 size 800 align 12 gran 11 limit ffffffff flags 200 index 24
   PCI: 00:1f.3 child on link 0 I2C: 01:54
   PCI: 00:1f.3 resource base 400 size 20 align 0 gran 0 limit 41f flags f0000100 index 20
   PCI: 00:1f.3 resource base 0 size 100 align 12 gran 8 limit ffffffffffffffff flags 201 index 10
    I2C: 01:54
    I2C: 01:55
    I2C: 01:56
    I2C: 01:57
    I2C: 01:5c
    I2C: 01:5d
    I2C: 01:5e
    I2C: 01:5f
   PCI: 00:1f.5
   PCI: 00:1f.6
   PCI: 00:1f.6 resource base 0 size 1000 align 12 gran 12 limit ffffffffffffffff flags 201 index 10
DOMAIN: 0000 io: base: 0 size: 0 align: 0 gran: 0 limit: ffff
PCI: 00:1c.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff
PCI: 00:1c.0 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff done
PCI: 00:1c.1 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff
PCI: 00:1c.1 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff done
PCI: 00:1c.3 io: base: 0 size: 0 align: 12 gran: 12 limit: ffff
Unknown device path type: 0
 18 *  [0x0 - 0xfff] io
PCI: 00:1c.3 io: base: 1000 size: 1000 align: 12 gran: 12 limit: ffff done
PCI: 00:1c.3 1c *  [0x0 - 0xfff] io
PCI: 00:02.0 20 *  [0x1000 - 0x103f] io
PCI: 00:19.0 18 *  [0x1040 - 0x105f] io
PCI: 00:1f.2 20 *  [0x1060 - 0x107f] io
PCI: 00:1f.2 10 *  [0x1080 - 0x1087] io
PCI: 00:1f.2 18 *  [0x1088 - 0x108f] io
PCI: 00:1f.2 14 *  [0x1090 - 0x1093] io
PCI: 00:1f.2 1c *  [0x1094 - 0x1097] io
DOMAIN: 0000 io: base: 1098 size: 1098 align: 12 gran: 0 limit: ffff done
DOMAIN: 0000 mem: base: 0 size: 0 align: 0 gran: 0 limit: ffffffff
PCI: 00:1c.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffffffffff
PCI: 00:1c.0 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffffffffff done
PCI: 00:1c.0 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 01:00.0 10 *  [0x0 - 0x1fff] mem
PCI: 00:1c.0 mem: base: 2000 size: 100000 align: 20 gran: 20 limit: ffffffff done
PCI: 00:1c.1 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffffffffff
PCI: 00:1c.1 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffffffffff done
PCI: 00:1c.1 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
PCI: 00:1c.1 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff done
PCI: 00:1c.3 prefmem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffffffffffff
Unknown device path type: 0
 14 *  [0x0 - 0x7fffff] prefmem
PCI: 00:1c.3 prefmem: base: 800000 size: 800000 align: 22 gran: 20 limit: ffffffff done
PCI: 00:1c.3 mem: base: 0 size: 0 align: 20 gran: 20 limit: ffffffff
Unknown device path type: 0
 10 *  [0x0 - 0x7fffff] mem
PCI: 03:00.0 10 *  [0x800000 - 0x8000ff] mem
PCI: 00:1c.3 mem: base: 800100 size: 900000 align: 22 gran: 20 limit: ffffffff done
PCI: 00:02.0 18 *  [0x0 - 0xfffffff] prefmem
PCI: 00:1c.3 20 *  [0x10000000 - 0x108fffff] mem
PCI: 00:1c.3 24 *  [0x10c00000 - 0x113fffff] prefmem
PCI: 00:02.0 10 *  [0x11400000 - 0x117fffff] mem
PCI: 00:1c.0 20 *  [0x11800000 - 0x118fffff] mem
PCI: 00:19.0 10 *  [0x11900000 - 0x1191ffff] mem
PCI: 00:04.0 10 *  [0x11920000 - 0x11927fff] mem
PCI: 00:1b.0 10 *  [0x11928000 - 0x1192bfff] mem
PCI: 00:19.0 14 *  [0x1192c000 - 0x1192cfff] mem
PCI: 00:1f.6 10 *  [0x1192d000 - 0x1192dfff] mem
PCI: 00:1f.2 24 *  [0x1192e000 - 0x1192e7ff] mem
PCI: 00:1a.0 10 *  [0x1192f000 - 0x1192f3ff] mem
PCI: 00:1d.0 10 *  [0x11930000 - 0x119303ff] mem
PCI: 00:1f.3 10 *  [0x11931000 - 0x119310ff] mem
DOMAIN: 0000 mem: base: 11931100 size: 11931100 align: 28 gran: 0 limit: ffffffff done
avoid_fixed_resources: DOMAIN: 0000
avoid_fixed_resources:@DOMAIN: 0000 10000000 limit 0000ffff
avoid_fixed_resources:@DOMAIN: 0000 10000100 limit ffffffff
constrain_resources: PCI: 00:00.0 cf base f0000000 limit f3ffffff mem (fixed)
constrain_resources: PCI: 00:1f.0 10000000 base 00000000 limit 00000fff io (fixed)
constrain_resources: PCI: 00:1f.0 10000200 base 00001600 limit 0000167b io (fixed)
skipping PNP: 00ff.2 at 60 fixed resource, size=0!
skipping PNP: 00ff.2 at 62 fixed resource, size=0!
skipping PNP: 00ff.2 at 64 fixed resource, size=0!
skipping PNP: 00ff.2 at 66 fixed resource, size=0!
avoid_fixed_resources:@DOMAIN: 0000 10000000 base 0000167c limit 0000ffff
avoid_fixed_resources:@DOMAIN: 0000 10000100 base d0000000 limit efffffff
Setting resources...
DOMAIN: 0000 io: base:167c size:1098 align:12 gran:0 limit:ffff
PCI: 00:1c.3 1c *  [0x2000 - 0x2fff] io
PCI: 00:02.0 20 *  [0x3000 - 0x303f] io
PCI: 00:19.0 18 *  [0x3040 - 0x305f] io
PCI: 00:1f.2 20 *  [0x3060 - 0x307f] io
PCI: 00:1f.2 10 *  [0x3080 - 0x3087] io
PCI: 00:1f.2 18 *  [0x3088 - 0x308f] io
PCI: 00:1f.2 14 *  [0x3090 - 0x3093] io
PCI: 00:1f.2 1c *  [0x3094 - 0x3097] io
DOMAIN: 0000 io: next_base: 3098 size: 1098 align: 12 gran: 0 done
PCI: 00:1c.0 io: base:ffff size:0 align:12 gran:12 limit:ffff
PCI: 00:1c.0 io: next_base: ffff size: 0 align: 12 gran: 12 done
PCI: 00:1c.1 io: base:ffff size:0 align:12 gran:12 limit:ffff
PCI: 00:1c.1 io: next_base: ffff size: 0 align: 12 gran: 12 done
PCI: 00:1c.3 io: base:2000 size:1000 align:12 gran:12 limit:2fff
Unknown device path type: 0
 18 *  [0x2000 - 0x2fff] io
PCI: 00:1c.3 io: next_base: 3000 size: 1000 align: 12 gran: 12 done
DOMAIN: 0000 mem: base:d0000000 size:11931100 align:28 gran:0 limit:efffffff
PCI: 00:02.0 18 *  [0xd0000000 - 0xdfffffff] prefmem
PCI: 00:1c.3 20 *  [0xe0000000 - 0xe08fffff] mem
PCI: 00:1c.3 24 *  [0xe0c00000 - 0xe13fffff] prefmem
PCI: 00:02.0 10 *  [0xe1400000 - 0xe17fffff] mem
PCI: 00:1c.0 20 *  [0xe1800000 - 0xe18fffff] mem
PCI: 00:19.0 10 *  [0xe1900000 - 0xe191ffff] mem
PCI: 00:04.0 10 *  [0xe1920000 - 0xe1927fff] mem
PCI: 00:1b.0 10 *  [0xe1928000 - 0xe192bfff] mem
PCI: 00:19.0 14 *  [0xe192c000 - 0xe192cfff] mem
PCI: 00:1f.6 10 *  [0xe192d000 - 0xe192dfff] mem
PCI: 00:1f.2 24 *  [0xe192e000 - 0xe192e7ff] mem
PCI: 00:1a.0 10 *  [0xe192f000 - 0xe192f3ff] mem
PCI: 00:1d.0 10 *  [0xe1930000 - 0xe19303ff] mem
PCI: 00:1f.3 10 *  [0xe1931000 - 0xe19310ff] mem
DOMAIN: 0000 mem: next_base: e1931100 size: 11931100 align: 28 gran: 0 done
PCI: 00:1c.0 prefmem: base:efffffff size:0 align:20 gran:20 limit:efffffff
PCI: 00:1c.0 prefmem: next_base: efffffff size: 0 align: 20 gran: 20 done
PCI: 00:1c.0 mem: base:e1800000 size:100000 align:20 gran:20 limit:e18fffff
PCI: 01:00.0 10 *  [0xe1800000 - 0xe1801fff] mem
PCI: 00:1c.0 mem: next_base: e1802000 size: 100000 align: 20 gran: 20 done
PCI: 00:1c.1 prefmem: base:efffffff size:0 align:20 gran:20 limit:efffffff
PCI: 00:1c.1 prefmem: next_base: efffffff size: 0 align: 20 gran: 20 done
PCI: 00:1c.1 mem: base:efffffff size:0 align:20 gran:20 limit:efffffff
PCI: 00:1c.1 mem: next_base: efffffff size: 0 align: 20 gran: 20 done
PCI: 00:1c.3 prefmem: base:e0c00000 size:800000 align:22 gran:20 limit:e13fffff
Unknown device path type: 0
 14 *  [0xe0c00000 - 0xe13fffff] prefmem
PCI: 00:1c.3 prefmem: next_base: e1400000 size: 800000 align: 22 gran: 20 done
PCI: 00:1c.3 mem: base:e0000000 size:900000 align:22 gran:20 limit:e08fffff
Unknown device path type: 0
 10 *  [0xe0000000 - 0xe07fffff] mem
PCI: 03:00.0 10 *  [0xe0800000 - 0xe08000ff] mem
PCI: 00:1c.3 mem: next_base: e0800100 size: 900000 align: 22 gran: 20 done
Root Device assign_resources, bus 0 link: 0
TOUUD 0x13b600000 TOLUD 0xc2a00000 TOM 0x100000000
MEBASE 0xfe000000
IGD decoded, subtracting 32M UMA and 2M GTT
TSEG base 0xc0000000 size 8M
Available memory below 4GB: 3072M
Available memory above 4GB: 950M
Adding PCIe config bar base=0xf0000000 size=0x4000000
DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:00.0 cf <- [0x00f0000000 - 0x00f3ffffff] size 0x04000000 gran 0x00 mem<mmconfig>
PCI: 00:02.0 10 <- [0x00e1400000 - 0x00e17fffff] size 0x00400000 gran 0x16 mem64
PCI: 00:02.0 18 <- [0x00d0000000 - 0x00dfffffff] size 0x10000000 gran 0x1c prefmem64
PCI: 00:02.0 20 <- [0x0000003000 - 0x000000303f] size 0x00000040 gran 0x06 io
PCI: 00:04.0 10 <- [0x00e1920000 - 0x00e1927fff] size 0x00008000 gran 0x0f mem64
PCI: 00:19.0 10 <- [0x00e1900000 - 0x00e191ffff] size 0x00020000 gran 0x11 mem
PCI: 00:19.0 14 <- [0x00e192c000 - 0x00e192cfff] size 0x00001000 gran 0x0c mem
PCI: 00:19.0 18 <- [0x0000003040 - 0x000000305f] size 0x00000020 gran 0x05 io
PCI: 00:1a.0 EHCI Debug Port hook triggered
PCI: 00:1a.0 10 <- [0x00e192f000 - 0x00e192f3ff] size 0x00000400 gran 0x0a mem
PCI: 00:1a.0 EHCI Debug Port relocated
PCI: 00:1b.0 10 <- [0x00e1928000 - 0x00e192bfff] size 0x00004000 gran 0x0e mem64
PCI: 00:1c.0 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 01 io
PCI: 00:1c.0 24 <- [0x00efffffff - 0x00effffffe] size 0x00000000 gran 0x14 bus 01 prefmem
PCI: 00:1c.0 20 <- [0x00e1800000 - 0x00e18fffff] size 0x00100000 gran 0x14 bus 01 mem
PCI: 00:1c.0 assign_resources, bus 1 link: 0
PCI: 01:00.0 10 <- [0x00e1800000 - 0x00e1801fff] size 0x00002000 gran 0x0d mem64
PCI: 00:1c.0 assign_resources, bus 1 link: 0
PCI: 00:1c.1 1c <- [0x000000ffff - 0x000000fffe] size 0x00000000 gran 0x0c bus 02 io
PCI: 00:1c.1 24 <- [0x00efffffff - 0x00effffffe] size 0x00000000 gran 0x14 bus 02 prefmem
PCI: 00:1c.1 20 <- [0x00efffffff - 0x00effffffe] size 0x00000000 gran 0x14 bus 02 mem
PCI: 00:1c.3 1c <- [0x0000002000 - 0x0000002fff] size 0x00001000 gran 0x0c bus 03 io
PCI: 00:1c.3 24 <- [0x00e0c00000 - 0x00e13fffff] size 0x00800000 gran 0x14 bus 03 prefmem
PCI: 00:1c.3 20 <- [0x00e0000000 - 0x00e08fffff] size 0x00900000 gran 0x14 bus 03 mem
PCI: 00:1c.3 assign_resources, bus 3 link: 0
PCI: 03:00.0 10 <- [0x00e0800000 - 0x00e08000ff] size 0x00000100 gran 0x08 mem
Unknown device path type: 0
 missing set_resources
PCI: 00:1c.3 assign_resources, bus 3 link: 0
PCI: 00:1d.0 10 <- [0x00e1930000 - 0x00e19303ff] size 0x00000400 gran 0x0a mem
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PNP: 00ff.1 missing set_resources
PNP: 00ff.2 missing set_resources
PCI: 00:1f.0 assign_resources, bus 0 link: 0
PCI: 00:1f.2 10 <- [0x0000003080 - 0x0000003087] size 0x00000008 gran 0x03 io
PCI: 00:1f.2 14 <- [0x0000003090 - 0x0000003093] size 0x00000004 gran 0x02 io
PCI: 00:1f.2 18 <- [0x0000003088 - 0x000000308f] size 0x00000008 gran 0x03 io
PCI: 00:1f.2 1c <- [0x0000003094 - 0x0000003097] size 0x00000004 gran 0x02 io
PCI: 00:1f.2 20 <- [0x0000003060 - 0x000000307f] size 0x00000020 gran 0x05 io
PCI: 00:1f.2 24 <- [0x00e192e000 - 0x00e192e7ff] size 0x00000800 gran 0x0b mem
PCI: 00:1f.3 10 <- [0x00e1931000 - 0x00e19310ff] size 0x00000100 gran 0x08 mem64
PCI: 00:1f.3 assign_resources, bus 1 link: 0
PCI: 00:1f.3 assign_resources, bus 1 link: 0
PCI: 00:1f.6 10 <- [0x00e192d000 - 0x00e192dfff] size 0x00001000 gran 0x0c mem64
DOMAIN: 0000 assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Show resources in subtree (Root Device)...After assigning values.
 Root Device child on link 0 CPU_CLUSTER: 0
  CPU_CLUSTER: 0 child on link 0 APIC: 00
   APIC: 00
   APIC: acac
  DOMAIN: 0000 child on link 0 PCI: 00:00.0
  DOMAIN: 0000 resource base 167c size 1098 align 12 gran 0 limit ffff flags 40040100 index 10000000
  DOMAIN: 0000 resource base d0000000 size 11931100 align 28 gran 0 limit efffffff flags 40040200 index 10000100
  DOMAIN: 0000 resource base 0 size a0000 align 0 gran 0 limit 0 flags e0004200 index 3
  DOMAIN: 0000 resource base 100000 size bff00000 align 0 gran 0 limit 0 flags e0004200 index 4
  DOMAIN: 0000 resource base 100000000 size 3b600000 align 0 gran 0 limit 0 flags e0004200 index 5
  DOMAIN: 0000 resource base c0000000 size 2a00000 align 0 gran 0 limit 0 flags f0000200 index 6
  DOMAIN: 0000 resource base f0000000 size 4000000 align 0 gran 0 limit 0 flags f0000200 index 7
  DOMAIN: 0000 resource base a0000 size 20000 align 0 gran 0 limit 0 flags f0000200 index 8
  DOMAIN: 0000 resource base c0000 size 40000 align 0 gran 0 limit 0 flags f0004200 index 9
  DOMAIN: 0000 resource base 20000000 size 200000 align 0 gran 0 limit 0 flags f0004200 index a
  DOMAIN: 0000 resource base 40000000 size 200000 align 0 gran 0 limit 0 flags f0004200 index b
   PCI: 00:00.0
   PCI: 00:00.0 resource base f0000000 size 4000000 align 0 gran 0 limit 0 flags e0000200 index cf
   PCI: 00:01.0
   PCI: 00:02.0
   PCI: 00:02.0 resource base e1400000 size 400000 align 22 gran 22 limit e17fffff flags 60000201 index 10
   PCI: 00:02.0 resource base d0000000 size 10000000 align 28 gran 28 limit dfffffff flags 60001201 index 18
   PCI: 00:02.0 resource base 3000 size 40 align 6 gran 6 limit 303f flags 60000100 index 20
   PCI: 00:04.0
   PCI: 00:04.0 resource base e1920000 size 8000 align 15 gran 15 limit e1927fff flags 60000201 index 10
   PCI: 00:16.0
   PCI: 00:16.1
   PCI: 00:16.2
   PCI: 00:16.3
   PCI: 00:19.0
   PCI: 00:19.0 resource base e1900000 size 20000 align 17 gran 17 limit e191ffff flags 60000200 index 10
   PCI: 00:19.0 resource base e192c000 size 1000 align 12 gran 12 limit e192cfff flags 60000200 index 14
   PCI: 00:19.0 resource base 3040 size 20 align 5 gran 5 limit 305f flags 60000100 index 18
   PCI: 00:1a.0
   PCI: 00:1a.0 resource base e192f000 size 400 align 12 gran 10 limit e192f3ff flags 60000200 index 10
   PCI: 00:1b.0
   PCI: 00:1b.0 resource base e1928000 size 4000 align 14 gran 14 limit e192bfff flags 60000201 index 10
   PCI: 00:1c.4
   PCI: 00:1c.0 child on link 0 PCI: 01:00.0
   PCI: 00:1c.0 resource base ffff size 0 align 12 gran 12 limit ffff flags 60080102 index 1c
   PCI: 00:1c.0 resource base efffffff size 0 align 20 gran 20 limit efffffff flags 60081202 index 24
   PCI: 00:1c.0 resource base e1800000 size 100000 align 20 gran 20 limit e18fffff flags 60080202 index 20
    PCI: 01:00.0
    PCI: 01:00.0 resource base e1800000 size 2000 align 13 gran 13 limit e1801fff flags 60000201 index 10
   PCI: 00:1c.2
   PCI: 00:1c.1
   PCI: 00:1c.1 resource base ffff size 0 align 12 gran 12 limit ffff flags 60080102 index 1c
   PCI: 00:1c.1 resource base efffffff size 0 align 20 gran 20 limit efffffff flags 60081202 index 24
   PCI: 00:1c.1 resource base efffffff size 0 align 20 gran 20 limit efffffff flags 60080202 index 20
   PCI: 00:1c.3 child on link 0 PCI: 03:00.0
   PCI: 00:1c.3 resource base 2000 size 1000 align 12 gran 12 limit 2fff flags 60080102 index 1c
   PCI: 00:1c.3 resource base e0c00000 size 800000 align 22 gran 20 limit e13fffff flags 60081202 index 24
   PCI: 00:1c.3 resource base e0000000 size 900000 align 22 gran 20 limit e08fffff flags 60080202 index 20
    PCI: 03:00.0
    PCI: 03:00.0 resource base e0800000 size 100 align 12 gran 8 limit e08000ff flags 60000200 index 10
Unknown device path type: 0
    
Unknown device path type: 0
     resource base e0000000 size 800000 align 22 gran 22 limit e07fffff flags 40000200 index 10
Unknown device path type: 0
     resource base e0c00000 size 800000 align 22 gran 22 limit e13fffff flags 40001200 index 14
Unknown device path type: 0
     resource base 2000 size 1000 align 12 gran 12 limit 2fff flags 40000100 index 18
   PCI: 00:1c.5
   PCI: 00:1c.6
   PCI: 00:1c.7
   PCI: 00:1d.0
   PCI: 00:1d.0 resource base e1930000 size 400 align 12 gran 10 limit e19303ff flags 60000200 index 10
   PCI: 00:1e.0
   PCI: 00:1f.0 child on link 0 PNP: 00ff.1
   PCI: 00:1f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags c0040100 index 10000000
   PCI: 00:1f.0 resource base ff000000 size 1000000 align 0 gran 0 limit 0 flags c0040200 index 10000100
   PCI: 00:1f.0 resource base fec00000 size 1000 align 0 gran 0 limit 0 flags c0000200 index 3
   PCI: 00:1f.0 resource base 1600 size 7c align 0 gran 0 limit 0 flags c0040100 index 10000200
   PCI: 00:1f.0 resource base 15e0 size c align 0 gran 0 limit 0 flags c0040100 index 10000300
    PNP: 00ff.1
    PNP: 00ff.1 resource base 15e0 size 10 align 5 gran 5 limit 0 flags 80000100 index 77
    PNP: 0c31.0
    PNP: 00ff.2
    PNP: 00ff.2 resource base 62 size 0 align 0 gran 0 limit 0 flags c0000100 index 60
    PNP: 00ff.2 resource base 66 size 0 align 0 gran 0 limit 0 flags c0000100 index 62
    PNP: 00ff.2 resource base 1600 size 0 align 0 gran 0 limit 0 flags c0000100 index 64
    PNP: 00ff.2 resource base 1604 size 0 align 0 gran 0 limit 0 flags c0000100 index 66
   PCI: 00:1f.2
   PCI: 00:1f.2 resource base 3080 size 8 align 3 gran 3 limit 3087 flags 60000100 index 10
   PCI: 00:1f.2 resource base 3090 size 4 align 2 gran 2 limit 3093 flags 60000100 index 14
   PCI: 00:1f.2 resource base 3088 size 8 align 3 gran 3 limit 308f flags 60000100 index 18
   PCI: 00:1f.2 resource base 3094 size 4 align 2 gran 2 limit 3097 flags 60000100 index 1c
   PCI: 00:1f.2 resource base 3060 size 20 align 5 gran 5 limit 307f flags 60000100 index 20
   PCI: 00:1f.2 resource base e192e000 size 800 align 12 gran 11 limit e192e7ff flags 60000200 index 24
   PCI: 00:1f.3 child on link 0 I2C: 01:54
   PCI: 00:1f.3 resource base 400 size 20 align 0 gran 0 limit 41f flags f0000100 index 20
   PCI: 00:1f.3 resource base e1931000 size 100 align 12 gran 8 limit e19310ff flags 60000201 index 10
    I2C: 01:54
    I2C: 01:55
    I2C: 01:56
    I2C: 01:57
    I2C: 01:5c
    I2C: 01:5d
    I2C: 01:5e
    I2C: 01:5f
   PCI: 00:1f.5
   PCI: 00:1f.6
   PCI: 00:1f.6 resource base e192d000 size 1000 align 12 gran 12 limit e192dfff flags 60000201 index 10
Done allocating resources.
BS: Exiting BS_DEV_RESOURCES state.
BS: BS_DEV_RESOURCES times (us): entry 0 run 792794 exit 0
BS: Entering BS_DEV_ENABLE state.
Enabling resources...
PCI: 00:00.0 subsystem <- 17aa/21ce
PCI: 00:00.0 cmd <- 06
PCI: 00:02.0 subsystem <- 17aa/21ce
PCI: 00:02.0 cmd <- 03
PCI: 00:04.0 cmd <- 02
PCI: 00:19.0 subsystem <- 17aa/21ce
PCI: 00:19.0 cmd <- 103
PCI: 00:1a.0 subsystem <- 17aa/21ce
PCI: 00:1a.0 cmd <- 102
PCI: 00:1b.0 subsystem <- 17aa/21ce
PCI: 00:1b.0 cmd <- 102
PCI: 00:1c.0 bridge ctrl <- 0003
PCI: 00:1c.0 subsystem <- 17aa/21ce
PCI: 00:1c.0 cmd <- 106
PCI: 00:1c.1 bridge ctrl <- 0003
PCI: 00:1c.1 subsystem <- 17aa/21ce
PCI: 00:1c.1 cmd <- 100
PCI: 00:1c.3 bridge ctrl <- 0003
PCI: 00:1c.3 subsystem <- 17aa/21ce
PCI: 00:1c.3 cmd <- 107
PCI: 00:1d.0 subsystem <- 17aa/21ce
PCI: 00:1d.0 cmd <- 102
pch_decode_init
PCI: 00:1f.0 subsystem <- 17aa/21ce
PCI: 00:1f.0 cmd <- 107
PCI: 00:1f.2 subsystem <- 17aa/21ce
PCI: 00:1f.2 cmd <- 03
PCI: 00:1f.3 subsystem <- 17aa/21ce
PCI: 00:1f.3 cmd <- 103
PCI: 00:1f.6 subsystem <- 17aa/21ce
PCI: 00:1f.6 cmd <- 02
PCI: 01:00.0 cmd <- 02
PCI: 03:00.0 subsystem <- 17aa/21ce
PCI: 03:00.0 cmd <- 06
done.
BS: Exiting BS_DEV_ENABLE state.
BS: BS_DEV_ENABLE times (us): entry 0 run 38375 exit 0
BS: Entering BS_DEV_INIT state.
Initializing devices...
Root Device init ...
Root Device init finished in 748 usecs
CPU_CLUSTER: 0 init ...
start_eip=0x00001000, code_size=0x00000031
Setting up SMI for CPU
Loading module at 00038000 with entry 00038000. filesize: 0x160 memsize: 0x160
Processing 10 relocs. Offset value of 0x00038000
Adjusting 00038002: 0x00000024 -> 0x00038024
Adjusting 0003801d: 0x0000003c -> 0x0003803c
Adjusting 00038026: 0x00000024 -> 0x00038024
Adjusting 00038054: 0x000000d8 -> 0x000380d8
Adjusting 00038066: 0x00000160 -> 0x00038160
Adjusting 0003806d: 0x000000c0 -> 0x000380c0
Adjusting 00038075: 0x000000c4 -> 0x000380c4
Adjusting 0003807e: 0x000000d0 -> 0x000380d0
Adjusting 00038085: 0x000000cc -> 0x000380cc
Adjusting 0003808b: 0x000000c8 -> 0x000380c8
SMM Module: stub loaded at 00038000. Will call 0011820c(00138980)
Installing SMM handler to 0xc0000000
Loading module at c0010000 with entry c001032f. filesize: 0x1718 memsize: 0x5738
Processing 69 relocs. Offset value of 0xc0010000
Adjusting c0010022: 0x000015a4 -> 0xc00115a4
Adjusting c001003c: 0x000015a4 -> 0xc00115a4
Adjusting c001005b: 0x000015a4 -> 0xc00115a4
Adjusting c001027e: 0x00001718 -> 0xc0011718
Adjusting c0010298: 0x00001720 -> 0xc0011720
Adjusting c00102af: 0x00001720 -> 0xc0011720
Adjusting c00102fc: 0x00001710 -> 0xc0011710
Adjusting c0010312: 0x00001660 -> 0xc0011660
Adjusting c0010338: 0x00001718 -> 0xc0011718
Adjusting c0010346: 0x00001718 -> 0xc0011718
Adjusting c0010353: 0x00001700 -> 0xc0011700
Adjusting c001035e: 0x00001700 -> 0xc0011700
Adjusting c0010372: 0x00001704 -> 0xc0011704
Adjusting c0010378: 0x0000171c -> 0xc001171c
Adjusting c0010380: 0x00001704 -> 0xc0011704
Adjusting c001039d: 0x0000171c -> 0xc001171c
Adjusting c00103a6: 0x00001700 -> 0xc0011700
Adjusting c0010491: 0x000015c0 -> 0xc00115c0
Adjusting c001059f: 0x0000170c -> 0xc001170c
Adjusting c00105c8: 0x0000170c -> 0xc001170c
Adjusting c00105e5: 0x0000170c -> 0xc001170c
Adjusting c001060e: 0x00001708 -> 0xc0011708
Adjusting c001062b: 0x0000170c -> 0xc001170c
Adjusting c0010651: 0x00001708 -> 0xc0011708
Adjusting c0010709: 0x0000170c -> 0xc001170c
Adjusting c001070e: 0x00001708 -> 0xc0011708
Adjusting c001073f: 0x000015d0 -> 0xc00115d0
Adjusting c0010b22: 0x00001724 -> 0xc0011724
Adjusting c0010b51: 0x00001728 -> 0xc0011728
Adjusting c0010b64: 0x00001724 -> 0xc0011724
Adjusting c0010b87: 0x00001728 -> 0xc0011728
Adjusting c0010c4a: 0x00001724 -> 0xc0011724
Adjusting c0010e85: 0x00001728 -> 0xc0011728
Adjusting c0011074: 0x00001728 -> 0xc0011728
Adjusting c0011156: 0x00001710 -> 0xc0011710
Adjusting c0011166: 0x00001710 -> 0xc0011710
Adjusting c001117b: 0x00001710 -> 0xc0011710
Adjusting c001119c: 0x00001710 -> 0xc0011710
Adjusting c00111cb: 0x00001710 -> 0xc0011710
Adjusting c00111ea: 0x00001710 -> 0xc0011710
Adjusting c00111fd: 0x00001734 -> 0xc0011734
Adjusting c0011241: 0x0000172c -> 0xc001172c
Adjusting c001125e: 0x0000172c -> 0xc001172c
Adjusting c001127c: 0x00001734 -> 0xc0011734
Adjusting c0011282: 0x00001730 -> 0xc0011730
Adjusting c001128f: 0x00001710 -> 0xc0011710
Adjusting c00112b5: 0x00001710 -> 0xc0011710
Adjusting c001130a: 0x00001730 -> 0xc0011730
Adjusting c0011361: 0x00001635 -> 0xc0011635
Adjusting c001137c: 0x00001710 -> 0xc0011710
Adjusting c0011393: 0x00001730 -> 0xc0011730
Adjusting c0011463: 0x00001710 -> 0xc0011710
Adjusting c0011491: 0x00001710 -> 0xc0011710
Adjusting c00114da: 0x00001710 -> 0xc0011710
Adjusting c0011578: 0x00001730 -> 0xc0011730
Adjusting c001158c: 0x00001710 -> 0xc0011710
Adjusting c00115a8: 0x000015b4 -> 0xc00115b4
Adjusting c00115b4: 0x000000c0 -> 0xc00100c0
Adjusting c00115b8: 0x000000cc -> 0xc00100cc
Adjusting c00115bc: 0x000000cf -> 0xc00100cf
Adjusting c0011670: 0x0000134b -> 0xc001134b
Adjusting c0011674: 0x000011ac -> 0xc00111ac
Adjusting c0011680: 0x0000128c -> 0xc001128c
Adjusting c0011684: 0x00001153 -> 0xc0011153
Adjusting c0011688: 0x00001174 -> 0xc0011174
Adjusting c001168c: 0x0000116f -> 0xc001116f
Adjusting c0011694: 0x000012b2 -> 0xc00112b2
Adjusting c0011698: 0x00001163 -> 0xc0011163
Adjusting c00116b4: 0x000012f5 -> 0xc00112f5
Loading module at c0008000 with entry c0008000. filesize: 0x160 memsize: 0x160
Processing 10 relocs. Offset value of 0xc0008000
Adjusting c0008002: 0x00000024 -> 0xc0008024
Adjusting c000801d: 0x0000003c -> 0xc000803c
Adjusting c0008026: 0x00000024 -> 0xc0008024
Adjusting c0008054: 0x000000d8 -> 0xc00080d8
Adjusting c0008066: 0x00000160 -> 0xc0008160
Adjusting c000806d: 0x000000c0 -> 0xc00080c0
Adjusting c0008075: 0x000000c4 -> 0xc00080c4
Adjusting c000807e: 0x000000d0 -> 0xc00080d0
Adjusting c0008085: 0x000000cc -> 0xc00080cc
Adjusting c000808b: 0x000000c8 -> 0xc00080c8
SMM Module: placing jmp sequence at c0007c00 rel16 0x03fd
SMM Module: placing jmp sequence at c0007800 rel16 0x07fd
SMM Module: placing jmp sequence at c0007400 rel16 0x0bfd
SMM Module: stub loaded at c0008000. Will call c001032f(00000000)
Initializing southbridge SMI... ... pmbase = 0x0500

SMI_STS: MCSMI PM1 
PM1_STS: WAK PRBTNOR PWRBTN TMROF 
GPE0_STS: GPIO14 GPIO13 GPIO11 GPIO10 GPIO9 GPIO7 GPIO6 GPIO5 GPIO4 GPIO3 GPIO1 GPIO0 
ALT_GP_SMI_STS: GPI14 GPI13 GPI11 GPI10 GPI9 GPI7 GPI6 GPI5 GPI4 GPI3 GPI1 GPI0 
TCO_STS: 
  ... raise SMI#
In relocation handler: cpu 0
New SMBASE=0xc0000000 IEDBASE=0xc0400000 @ 0003fc00
Writing SMRR. base = 0xc0000006, mask=0xff800800
Relocation complete.
Locking SMM.
Initializing CPU #0
CPU: vendor Intel device 206a7
CPU: family 06, model 2a, stepping 07
Enabling cache
CBFS @ 700000 size ff440
CBFS: Locating 'cpu_microcode_blob.bin'
CBFS: Found @ offset 140 size 5800
microcode: sig=0x206a7 pf=0x10 revision=0x29
CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz.
MTRR: Physical address space:
0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6
0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0
0x00000000000c0000 - 0x00000000c0000000 size 0xbff40000 type 6
0x00000000c0000000 - 0x00000000d0000000 size 0x10000000 type 0
0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1
0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0
0x0000000100000000 - 0x000000013b600000 size 0x3b600000 type 6
MTRR addr 0x0-0x10 set to 6 type @ 0
MTRR addr 0x10-0x20 set to 6 type @ 1
MTRR addr 0x20-0x30 set to 6 type @ 2
MTRR addr 0x30-0x40 set to 6 type @ 3
MTRR addr 0x40-0x50 set to 6 type @ 4
MTRR addr 0x50-0x60 set to 6 type @ 5
MTRR addr 0x60-0x70 set to 6 type @ 6
MTRR addr 0x70-0x80 set to 6 type @ 7
MTRR addr 0x80-0x84 set to 6 type @ 8
MTRR addr 0x84-0x88 set to 6 type @ 9
MTRR addr 0x88-0x8c set to 6 type @ 10
MTRR addr 0x8c-0x90 set to 6 type @ 11
MTRR addr 0x90-0x94 set to 6 type @ 12
MTRR addr 0x94-0x98 set to 6 type @ 13
MTRR addr 0x98-0x9c set to 6 type @ 14
MTRR addr 0x9c-0xa0 set to 6 type @ 15
MTRR addr 0xa0-0xa4 set to 0 type @ 16
MTRR addr 0xa4-0xa8 set to 0 type @ 17
MTRR addr 0xa8-0xac set to 0 type @ 18
MTRR addr 0xac-0xb0 set to 0 type @ 19
MTRR addr 0xb0-0xb4 set to 0 type @ 20
MTRR addr 0xb4-0xb8 set to 0 type @ 21
MTRR addr 0xb8-0xbc set to 0 type @ 22
MTRR addr 0xbc-0xc0 set to 0 type @ 23
MTRR addr 0xc0-0xc1 set to 6 type @ 24
MTRR addr 0xc1-0xc2 set to 6 type @ 25
MTRR addr 0xc2-0xc3 set to 6 type @ 26
MTRR addr 0xc3-0xc4 set to 6 type @ 27
MTRR addr 0xc4-0xc5 set to 6 type @ 28
MTRR addr 0xc5-0xc6 set to 6 type @ 29
MTRR addr 0xc6-0xc7 set to 6 type @ 30
MTRR addr 0xc7-0xc8 set to 6 type @ 31
MTRR addr 0xc8-0xc9 set to 6 type @ 32
MTRR addr 0xc9-0xca set to 6 type @ 33
MTRR addr 0xca-0xcb set to 6 type @ 34
MTRR addr 0xcb-0xcc set to 6 type @ 35
MTRR addr 0xcc-0xcd set to 6 type @ 36
MTRR addr 0xcd-0xce set to 6 type @ 37
MTRR addr 0xce-0xcf set to 6 type @ 38
MTRR addr 0xcf-0xd0 set to 6 type @ 39
MTRR addr 0xd0-0xd1 set to 6 type @ 40
MTRR addr 0xd1-0xd2 set to 6 type @ 41
MTRR addr 0xd2-0xd3 set to 6 type @ 42
MTRR addr 0xd3-0xd4 set to 6 type @ 43
MTRR addr 0xd4-0xd5 set to 6 type @ 44
MTRR addr 0xd5-0xd6 set to 6 type @ 45
MTRR addr 0xd6-0xd7 set to 6 type @ 46
MTRR addr 0xd7-0xd8 set to 6 type @ 47
MTRR addr 0xd8-0xd9 set to 6 type @ 48
MTRR addr 0xd9-0xda set to 6 type @ 49
MTRR addr 0xda-0xdb set to 6 type @ 50
MTRR addr 0xdb-0xdc set to 6 type @ 51
MTRR addr 0xdc-0xdd set to 6 type @ 52
MTRR addr 0xdd-0xde set to 6 type @ 53
MTRR addr 0xde-0xdf set to 6 type @ 54
MTRR addr 0xdf-0xe0 set to 6 type @ 55
MTRR addr 0xe0-0xe1 set to 6 type @ 56
MTRR addr 0xe1-0xe2 set to 6 type @ 57
MTRR addr 0xe2-0xe3 set to 6 type @ 58
MTRR addr 0xe3-0xe4 set to 6 type @ 59
MTRR addr 0xe4-0xe5 set to 6 type @ 60
MTRR addr 0xe5-0xe6 set to 6 type @ 61
MTRR addr 0xe6-0xe7 set to 6 type @ 62
MTRR addr 0xe7-0xe8 set to 6 type @ 63
MTRR addr 0xe8-0xe9 set to 6 type @ 64
MTRR addr 0xe9-0xea set to 6 type @ 65
MTRR addr 0xea-0xeb set to 6 type @ 66
MTRR addr 0xeb-0xec set to 6 type @ 67
MTRR addr 0xec-0xed set to 6 type @ 68
MTRR addr 0xed-0xee set to 6 type @ 69
MTRR addr 0xee-0xef set to 6 type @ 70
MTRR addr 0xef-0xf0 set to 6 type @ 71
MTRR addr 0xf0-0xf1 set to 6 type @ 72
MTRR addr 0xf1-0xf2 set to 6 type @ 73
MTRR addr 0xf2-0xf3 set to 6 type @ 74
MTRR addr 0xf3-0xf4 set to 6 type @ 75
MTRR addr 0xf4-0xf5 set to 6 type @ 76
MTRR addr 0xf5-0xf6 set to 6 type @ 77
MTRR addr 0xf6-0xf7 set to 6 type @ 78
MTRR addr 0xf7-0xf8 set to 6 type @ 79
MTRR addr 0xf8-0xf9 set to 6 type @ 80
MTRR addr 0xf9-0xfa set to 6 type @ 81
MTRR addr 0xfa-0xfb set to 6 type @ 82
MTRR addr 0xfb-0xfc set to 6 type @ 83
MTRR addr 0xfc-0xfd set to 6 type @ 84
MTRR addr 0xfd-0xfe set to 6 type @ 85
MTRR addr 0xfe-0xff set to 6 type @ 86
MTRR addr 0xff-0x100 set to 6 type @ 87
MTRR: Fixed MSR 0x250 0x0606060606060606
MTRR: Fixed MSR 0x258 0x0606060606060606
MTRR: Fixed MSR 0x259 0x0000000000000000
MTRR: Fixed MSR 0x268 0x0606060606060606
MTRR: Fixed MSR 0x269 0x0606060606060606
MTRR: Fixed MSR 0x26a 0x0606060606060606
MTRR: Fixed MSR 0x26b 0x0606060606060606
MTRR: Fixed MSR 0x26c 0x0606060606060606
MTRR: Fixed MSR 0x26d 0x0606060606060606
MTRR: Fixed MSR 0x26e 0x0606060606060606
MTRR: Fixed MSR 0x26f 0x0606060606060606
call enable_fixed_mtrr()
MTRR: default type WB/UC MTRR counts: 3/4.
MTRR: WB selected as default type.
MTRR: 0 base 0x00000000c0000000 mask 0x0000000ff0000000 type 0
MTRR: 1 base 0x00000000d0000000 mask 0x0000000ff0000000 type 1
MTRR: 2 base 0x00000000e0000000 mask 0x0000000fe0000000 type 0

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Setting up local apic... apic_id: 0x00 done.
Enabling VMX
model_x06ax: energy policy set to 6
model_x06ax: frequency set to 2500
Turbo is available but hidden
Turbo has been enabled
CPU: 0 has 2 cores, 2 threads per core
CPU: 0 has core 1
CPU1: stack_base 00132000, stack_end 00132ff8
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1 to 1.
After apic_write.
In relocation handler: cpu 1
New SMBASE=0xbffffc00 IEDBASE=0xc0400000 @ 0003fc00
Startup point 1.
Waiting for send to finish...
+Writing SMRR. base = 0xc0000006, mask=0xff800800
Sending STARTUP #2 to 1.
Initializing CPU #1
After apic_write.
CPU: vendor Intel device 206a7
Startup point 1.
CPU: family 06, model 2a, stepping 07
Waiting for send to finish...
Enabling cache
+CBFS @ 700000 size ff440
After Startup.
CBFS: Locating 'cpu_microcode_blob.bin'
CPU: 0 has core 2
CPU2: stack_base 00131000, stack_end 00131ff8
CBFS: Found @ offset 140 size 5800
Asserting INIT.
microcode: sig=0x206a7 pf=0x10 revision=0x29
Waiting for send to finish...
+CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz.
Deasserting INIT.
MTRR: Fixed MSR 0x250 0x0606060606060606
MTRR: Fixed MSR 0x258 0x0606060606060606
MTRR: Fixed MSR 0x259 0x0000000000000000
MTRR: Fixed MSR 0x268 0x0606060606060606
MTRR: Fixed MSR 0x269 0x0606060606060606
MTRR: Fixed MSR 0x26a 0x0606060606060606
MTRR: Fixed MSR 0x26b 0x0606060606060606
MTRR: Fixed MSR 0x26c 0x0606060606060606
MTRR: Fixed MSR 0x26d 0x0606060606060606
MTRR: Fixed MSR 0x26e 0x0606060606060606
MTRR: Fixed MSR 0x26f 0x0606060606060606
Waiting for send to finish...
call enable_fixed_mtrr()
+#startup loops: 2.

MTRR check
Sending STARTUP #1 to 2.
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

After apic_write.
Setting up local apic...Startup point 1.
Waiting for send to finish...
+ apic_id: 0x01 done.
Sending STARTUP #2 to 2.
After apic_write.
Enabling VMX
Startup point 1.
Waiting for send to finish...
+model_x06ax: energy policy set to 6
After Startup.
model_x06ax: frequency set to 2500
CPU #1 initialized
In relocation handler: cpu 2
New SMBASE=0xbffff800 IEDBASE=0xc0400000 @ 0003fc00
Writing SMRR. base = 0xc0000006, mask=0xff800800
CPU: 0 has core 3
CPU3: stack_base 00130000, stack_end 00130ff8
Initializing CPU #2
Asserting INIT.
Waiting for send to finish...
+CPU: vendor Intel device 206a7
Deasserting INIT.
Waiting for send to finish...
+CPU: family 06, model 2a, stepping 07
#startup loops: 2.
Sending STARTUP #1 to 3.
After apic_write.
Enabling cache
Startup point 1.
Waiting for send to finish...
+CBFS @ 700000 size ff440
Sending STARTUP #2 to 3.
After apic_write.
CBFS: Locating 'cpu_microcode_blob.bin'
Startup point 1.
Waiting for send to finish...
+In relocation handler: cpu 3
After Startup.
New SMBASE=0xbffff400 IEDBASE=0xc0400000 @ 0003fc00
CBFS: Found @ offset 140 size 5800
Writing SMRR. base = 0xc0000006, mask=0xff800800
microcode: sig=0x206a7 pf=0x10 revision=0x0
CPU #0 initialized
Waiting for 2 CPUS to stop
Initializing CPU #3
microcode: updated to revision 0x29 date=2013-06-12
CPU: vendor Intel device 206a7
CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz.
CPU: family 06, model 2a, stepping 07
MTRR: Fixed MSR 0x250 0x0606060606060606
Enabling cache
MTRR: Fixed MSR 0x258 0x0606060606060606
CBFS @ 700000 size ff440
MTRR: Fixed MSR 0x259 0x0000000000000000
CBFS: Locating 'cpu_microcode_blob.bin'
MTRR: Fixed MSR 0x268 0x0606060606060606
CBFS: Found @ offset 140 size 5800
MTRR: Fixed MSR 0x269 0x0606060606060606
microcode: sig=0x206a7 pf=0x10 revision=0x29
MTRR: Fixed MSR 0x26a 0x0606060606060606
CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz.
MTRR: Fixed MSR 0x26b 0x0606060606060606
MTRR: Fixed MSR 0x250 0x0606060606060606
MTRR: Fixed MSR 0x26c 0x0606060606060606
MTRR: Fixed MSR 0x258 0x0606060606060606
MTRR: Fixed MSR 0x26d 0x0606060606060606
MTRR: Fixed MSR 0x259 0x0000000000000000
MTRR: Fixed MSR 0x26e 0x0606060606060606
MTRR: Fixed MSR 0x268 0x0606060606060606
MTRR: Fixed MSR 0x26f 0x0606060606060606
MTRR: Fixed MSR 0x269 0x0606060606060606
call enable_fixed_mtrr()
MTRR: Fixed MSR 0x26a 0x0606060606060606

MTRR check
MTRR: Fixed MSR 0x26b 0x0606060606060606
MTRR: Fixed MSR 0x26c 0x0606060606060606
MTRR: Fixed MSR 0x26d 0x0606060606060606
MTRR: Fixed MSR 0x26e 0x0606060606060606
MTRR: Fixed MSR 0x26f 0x0606060606060606
Fixed MTRRs   : Enabled
call enable_fixed_mtrr()
Variable MTRRs: Enabled


MTRR check
Setting up local apic...Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

 apic_id: 0x02 done.
Setting up local apic...Enabling VMX
 apic_id: 0x03 done.
model_x06ax: energy policy set to 6
Enabling VMX
model_x06ax: frequency set to 2500
model_x06ax: energy policy set to 6
CPU #2 initialized
model_x06ax: frequency set to 2500
Waiting for 1 CPUS to stop
CPU #3 initialized
All AP CPUs stopped (16291 loops)
CPU1: stack: 00132000 - 00133000, lowest used address 00132c34, stack used: 972 bytes
CPU2: stack: 00131000 - 00132000, lowest used address 00131c34, stack used: 972 bytes
CPU3: stack: 00130000 - 00131000, lowest used address 00130c34, stack used: 972 bytes
CPU_CLUSTER: 0 init finished in 694113 usecs
PCI: 00:00.0 init ...
Set BIOS_RESET_CPL
CPU TDP: 35 Watts
Disabling PEG12.
Disabling PEG11.
Disabling PEG10.
Disabling PEG60.
Disabling PEG IO clock.
PCI: 00:00.0 init finished in 7211 usecs
PCI: 00:02.0 init ...
GT Power Management Init
GT init timeout
SNB GT2 Power Meter Weights
GT init timeout
GT init timeout
GT Power Management Init (post VBIOS)
Initializing VGA without OPROM.
EDID:
00 ff ff ff ff ff ff 00 06 af 3e 21 00 00 00 00 
21 14 01 04 90 1f 11 78 02 61 95 9c 59 52 8f 26 
21 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 
01 01 01 01 01 01 f8 2a 40 9a 61 84 0c 30 40 2a 
33 00 35 ae 10 00 00 18 a5 1c 40 9a 61 84 0c 30 
40 2a 33 00 35 ae 10 00 00 18 00 00 00 fe 00 41 
55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 
00 42 31 34 30 52 57 30 32 20 56 31 20 0a 00 d0 
Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   06 af 3e 21 00 00 00 00 21 14
version:         01 04
basic params:    90 1f 11 78 02
chroma info:     61 95 9c 59 52 8f 26 21 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    f8 2a 40 9a 61 84 0c 30 40 2a 33 00 35 ae 10 00 00 18
descriptor 2:    a5 1c 40 9a 61 84 0c 30 40 2a 33 00 35 ae 10 00 00 18
descriptor 3:    00 00 00 fe 00 41 55 4f 0a 20 20 20 20 20 20 20 20 20
descriptor 4:    00 00 00 fe 00 42 31 34 30 52 57 30 32 20 56 31 20 0a
extensions:      00
checksum:        d0

Manufacturer: AUO Model 213e Serial Number 0
Made week 33 of 2010
EDID version: 1.4
Digital display
6 bits per primary color channel
Digital interface is not defined
Maximum image size: 31 cm x 17 cm
Gamma: 220%
Check DPMS levels
Supported color formats: RGB 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed timings
Hex of detail: f82a409a61840c30402a330035ae10000018
Did detailed timing
Detailed mode (IN HEX): Clock 110000 KHz, 135 mm x ae mm
               0640 0680 06aa 07da hborder 0
               0384 0387 038a 0390 vborder 0
               -hsync -vsync 
Hex of detail: a51c409a61840c30402a330035ae10000018
Detailed mode (IN HEX): Clock 110000 KHz, 135 mm x ae mm
               0640 0680 06aa 07da hborder 0
               0384 0387 038a 0390 vborder 0
               -hsync -vsync 
Hex of detail: 000000fe0041554f0a202020202020202020
ASCII string: AUO
Hex of detail: 000000fe004231343052573032205631200a
ASCII string: B140RW02 V1 
Checksum
Checksum: 0xd0 (valid)
bringing up panel at resolution 1600 x 900
Borders 0 x 0
Blank 410 x 12
Sync 42 x 3
Front porch 64 x 3
Spread spectrum clock
Dual channel
Polarities 1, 1
Data M1=1922389, N1=8388608
Link frequency 270000 kHz
Link M1=213598, N1=524288
Pixel N=6, M1=14, M2=7, P1=2
Pixel clock 110000 kHz
waiting for panel powerup
panel powered up
PCI: 00:02.0 init finished in 446999 usecs
PCI: 00:04.0 init ...
PCI: 00:04.0 init finished in 746 usecs
PCI: 00:19.0 init ...
PCI: 00:19.0 init finished in 738 usecs
PCI: 00:1a.0 init ...
EHCI: Setting up controller.. done.
PCI: 00:1a.0 init finished in 1992 usecs
PCI: 00:1b.0 init ...
Azalia: base = e1928000
Azalia: codec_mask = 0b
Azalia: Initializing codec #3
Azalia: codec viddid: 80862805
Azalia: No verb!
Azalia: Initializing codec #1
Azalia: codec viddid: 14f12c06
Azalia: No verb!
Azalia: Initializing codec #0
Azalia: codec viddid: 14f1506e
Azalia: verb_size: 52
Azalia: verb loaded.
PCI: 00:1b.0 init finished in 15867 usecs
PCI: 00:1c.0 init ...
Initializing PCH PCIe bridge.
PCI: 00:1c.0 init finished in 1747 usecs
PCI: 00:1c.1 init ...
Initializing PCH PCIe bridge.
PCI: 00:1c.1 init finished in 1747 usecs
PCI: 00:1c.3 init ...
Initializing PCH PCIe bridge.
PCI: 00:1c.3 init finished in 1754 usecs
PCI: 00:1d.0 init ...
EHCI: Setting up controller.. done.
PCI: 00:1d.0 init finished in 1986 usecs
PCI: 00:1f.0 init ...
pch: lpc_init
IOAPIC: Initializing IOAPIC at 0xfec00000
IOAPIC: Bootstrap Processor Local APIC = 0x00
IOAPIC: ID = 0x02
IOAPIC: Dumping registers
  reg 0x0000: 0x02000000
  reg 0x0001: 0x00170020
  reg 0x0002: 0x00170020
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
Set power off after power failure.
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
NMI sources enabled.
CougarPoint PM init
rtc_failed = 0x0
RTC Init
Enabling BIOS updates outside of SMM... Disabling ACPI via APMC:
done.
pch_spi_init
PCI: 00:1f.0 init finished in 23295 usecs
PCI: 00:1f.2 init ...
SATA: Initializing...
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
SATA: Controller in AHCI mode.
ABAR: e192e000
PCI: 00:1f.2 init finished in 6660 usecs
PCI: 00:1f.3 init ...
PCI: 00:1f.3 init finished in 750 usecs
PCI: 00:1f.6 init ...
PCI: 00:1f.6 init finished in 742 usecs
PCI: 01:00.0 init ...
PCI: 01:00.0 init finished in 744 usecs
PCI: 03:00.0 init ...
PCI: 03:00.0 init finished in 758 usecs
PNP: 00ff.2 init ...
PNP: 00ff.2 init finished in 737 usecs
smbus: PCI: 00:1f.3[0]->I2C: 01:54 init ...
I2C: 01:54 init finished in 1492 usecs
smbus: PCI: 00:1f.3[0]->I2C: 01:55 init ...
I2C: 01:55 init finished in 1492 usecs
smbus: PCI: 00:1f.3[0]->I2C: 01:56 init ...
I2C: 01:56 init finished in 1492 usecs
smbus: PCI: 00:1f.3[0]->I2C: 01:57 init ...
I2C: 01:57 init finished in 1492 usecs
smbus: PCI: 00:1f.3[0]->I2C: 01:5c init ...
Locking EEPROM RFID
init EEPROM done
I2C: 01:5c init finished in 15322 usecs
smbus: PCI: 00:1f.3[0]->I2C: 01:5d init ...
I2C: 01:5d init finished in 1492 usecs
smbus: PCI: 00:1f.3[0]->I2C: 01:5e init ...
I2C: 01:5e init finished in 1492 usecs
smbus: PCI: 00:1f.3[0]->I2C: 01:5f init ...
I2C: 01:5f init finished in 1492 usecs
Devices initialized
Show all devs... After init.
Root Device: enabled 1
CPU_CLUSTER: 0: enabled 1
APIC: 00: enabled 1
APIC: acac: enabled 0
DOMAIN: 0000: enabled 1
PCI: 00:00.0: enabled 1
PCI: 00:01.0: enabled 0
PCI: 00:02.0: enabled 1
PCI: 00:16.0: enabled 0
PCI: 00:16.1: enabled 0
PCI: 00:16.2: enabled 0
PCI: 00:16.3: enabled 0
PCI: 00:19.0: enabled 1
PCI: 00:1a.0: enabled 1
PCI: 00:1b.0: enabled 1
PCI: 00:1c.4: enabled 0
PCI: 00:1c.0: enabled 1
PCI: 00:1c.2: enabled 0
PCI: 00:1c.1: enabled 1
PCI: 00:1c.3: enabled 1
PCI: 03:00.0: enabled 1
PCI: 00:1c.5: enabled 0
PCI: 00:1c.6: enabled 0
PCI: 00:1c.7: enabled 0
PCI: 00:1d.0: enabled 1
PCI: 00:1e.0: enabled 0
PCI: 00:1f.0: enabled 1
PNP: 00ff.1: enabled 1
PNP: 0c31.0: enabled 1
PNP: 00ff.2: enabled 1
PCI: 00:1f.2: enabled 1
PCI: 00:1f.3: enabled 1
I2C: 01:54: enabled 1
I2C: 01:55: enabled 1
I2C: 01:56: enabled 1
I2C: 01:57: enabled 1
I2C: 01:5c: enabled 1
I2C: 01:5d: enabled 1
I2C: 01:5e: enabled 1
I2C: 01:5f: enabled 1
PCI: 00:1f.5: enabled 0
PCI: 00:1f.6: enabled 1
PCI: 00:04.0: enabled 1
PCI: 01:00.0: enabled 1
Unknown device path type: 0
: enabled 1
APIC: 01: enabled 1
APIC: 02: enabled 1
APIC: 03: enabled 1
BS: Exiting BS_DEV_INIT state.
BS: BS_DEV_INIT times (us): entry 6 run 1320917 exit 0
BS: Entering BS_POST_DEVICE state.
Finalize devices...
PCI: 00:1f.0 final
Devices finalized
BS: Exiting BS_POST_DEVICE state.
BS: BS_POST_DEVICE times (us): entry 0 run 3489 exit 0
BS: Entering BS_OS_RESUME_CHECK state.
BS: Exiting BS_OS_RESUME_CHECK state.
BS: BS_OS_RESUME_CHECK times (us): entry 0 run 1246 exit 0
BS: Entering BS_WRITE_TABLES state.
Updating MRC cache data.
CBFS @ 700000 size ff440
CBFS: Locating 'mrc.cache'
CBFS: Found @ offset ffc0 size 10000
find_current_mrc_cache_local: picked entry 2 from cache block
SF: Detected W25Q64 with sector size 0x1000, total 0x800000
find_next_mrc_cache: picked next entry from cache block at fff13000
Finally: write MRC cache update to flash at fff13000
CBFS @ 700000 size ff440
CBFS: Locating 'fallback/dsdt.aml'
CBFS: Found @ offset 6200 size 34a1
CBFS @ 700000 size ff440
CBFS: Locating 'fallback/slic'
CBFS: 'fallback/slic' not found.
ACPI: Writing ACPI tables at bfeb9000.
ACPI:    * FACS
ACPI:    * DSDT
ACPI:    * IGD OpRegion
GET_VBIOS: aa55 8086 0 3 0
VBIOS not found.
ACPI:    * FADT
ACPI: added table 1/32, length now 40
ACPI:     * SSDT
Found 1 CPU(s) with 4 core(s) each.
PSS: 2501MHz power 35000 control 0x2000 status 0x2000
PSS: 2500MHz power 35000 control 0x1900 status 0x1900
PSS: 2000MHz power 26404 control 0x1400 status 0x1400
PSS: 1600MHz power 20160 control 0x1000 status 0x1000
PSS: 1200MHz power 14397 control 0xc00 status 0xc00
PSS: 800MHz power 9139 control 0x800 status 0x800
PSS: 2501MHz power 35000 control 0x2000 status 0x2000
PSS: 2500MHz power 35000 control 0x1900 status 0x1900
PSS: 2000MHz power 26404 control 0x1400 status 0x1400
PSS: 1600MHz power 20160 control 0x1000 status 0x1000
PSS: 1200MHz power 14397 control 0xc00 status 0xc00
PSS: 800MHz power 9139 control 0x800 status 0x800
PSS: 2501MHz power 35000 control 0x2000 status 0x2000
PSS: 2500MHz power 35000 control 0x1900 status 0x1900
PSS: 2000MHz power 26404 control 0x1400 status 0x1400
PSS: 1600MHz power 20160 control 0x1000 status 0x1000
PSS: 1200MHz power 14397 control 0xc00 status 0xc00
PSS: 800MHz power 9139 control 0x800 status 0x800
PSS: 2501MHz power 35000 control 0x2000 status 0x2000
PSS: 2500MHz power 35000 control 0x1900 status 0x1900
PSS: 2000MHz power 26404 control 0x1400 status 0x1400
PSS: 1600MHz power 20160 control 0x1000 status 0x1000
PSS: 1200MHz power 14397 control 0xc00 status 0xc00
PSS: 800MHz power 9139 control 0x800 status 0x800
ACPI: added table 2/32, length now 44
ACPI:    * MCFG
ACPI: added table 3/32, length now 48
ACPI:    * TCPA
TCPA log created at bfea6000
ACPI: added table 4/32, length now 52
ACPI:    * MADT
ACPI: added table 5/32, length now 56
current = bfebdd90
ACPI:    * HPET
ACPI: added table 6/32, length now 60
ACPI: done.
ACPI tables: 19920 bytes.
smbios_write_tables: bfea5000
recv_ec_data: 0x38
recv_ec_data: 0x33
recv_ec_data: 0x48
recv_ec_data: 0x54
recv_ec_data: 0x32
recv_ec_data: 0x37
recv_ec_data: 0x57
recv_ec_data: 0x57
recv_ec_data: 0x14
recv_ec_data: 0x03
Root Device (LENOVO ThinkPad T420)
CPU_CLUSTER: 0 (Intel SandyBridge/IvyBridge integrated Northbridge)
APIC: 00 (unknown)
APIC: acac (Intel SandyBridge/IvyBridge CPU)
DOMAIN: 0000 (Intel SandyBridge/IvyBridge integrated Northbridge)
PCI: 00:00.0 (Intel SandyBridge/IvyBridge integrated Northbridge)
PCI: 00:01.0 (Intel SandyBridge/IvyBridge integrated Northbridge)
PCI: 00:02.0 (Intel SandyBridge/IvyBridge integrated Northbridge)
PCI: 00:16.0 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:16.1 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:16.2 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:16.3 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:19.0 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1a.0 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1b.0 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1c.4 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1c.0 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1c.2 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1c.1 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1c.3 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 03:00.0 (unknown)
PCI: 00:1c.5 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1c.6 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1c.7 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1d.0 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1e.0 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1f.0 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PNP: 00ff.1 (Lenovo Power Management Hardware Hub 7)
PNP: 0c31.0 (unknown)
PNP: 00ff.2 (Lenovo H8 EC)
PCI: 00:1f.2 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1f.3 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
I2C: 01:54 (AT24RF08C)
I2C: 01:55 (AT24RF08C)
I2C: 01:56 (AT24RF08C)
I2C: 01:57 (AT24RF08C)
I2C: 01:5c (AT24RF08C)
I2C: 01:5d (AT24RF08C)
I2C: 01:5e (AT24RF08C)
I2C: 01:5f (AT24RF08C)
PCI: 00:1f.5 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:1f.6 (Intel Series 6/7 (Cougar Point/Panther Point) Southbridge)
PCI: 00:04.0 (unknown)
PCI: 01:00.0 (unknown)
Unknown device path type: 0
 (unknown)
APIC: 01 (unknown)
APIC: 02 (unknown)
APIC: 03 (unknown)
SMBIOS tables: 448 bytes.
Writing table forward entry at 0x00000500
Wrote coreboot table at: 00000500, 0x10 bytes, checksum 6ff4
Table forward entry ends at 0x00000528.
... aligned to 0x00001000
Writing coreboot table at 0xbfe9d000
rom_table_end = 0xbfe9d000
... aligned to 0xbfea0000
CBFS @ 700000 size ff440
CBFS: Locating 'cmos_layout.bin'
CBFS: Found @ offset 59c0 size 7cc
 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
 1. 0000000000001000-000000000009ffff: RAM
 2. 00000000000a0000-00000000000fffff: RESERVED
 3. 0000000000100000-000000001fffffff: RAM
 4. 0000000020000000-00000000201fffff: RESERVED
 5. 0000000020200000-000000003fffffff: RAM
 6. 0000000040000000-00000000401fffff: RESERVED
 7. 0000000040200000-00000000bfe9cfff: RAM
 8. 00000000bfe9d000-00000000bfffffff: CONFIGURATION TABLES
 9. 00000000c0000000-00000000c29fffff: RESERVED
10. 00000000f0000000-00000000f3ffffff: RESERVED
11. 0000000100000000-000000013b5fffff: RAM
CBFS @ 700000 size ff440
No FMAP found at 0 offset.
Wrote coreboot table at: bfe9d000, 0xa00 bytes, checksum 637b
coreboot table: 2584 bytes.
IMD ROOT    0. bffff000 00001000
IMD SMALL   1. bfffe000 00001000
CONSOLE     2. bffde000 00020000
MRC DATA    3. bffdd000 00000420
ACPI RESUME 4. bfedd000 00100000
ACPI        5. bfeb9000 00024000
ACPI GNVS   6. bfeb8000 00001000
4f444749    7. bfeb6000 00002000
TCPA LOG    8. bfea6000 00010000
SMBIOS      9. bfea5000 00000800
COREBOOT   10. bfe9d000 00008000
IMD small region:
  IMD ROOT    0. bfffec00 00000400
  CAR GLOBALS 1. bfffeb40 000000c0
  USBDEBUG    2. bfffeae0 00000058
  ROMSTAGE    3. bfffeac0 00000004
  GDT         4. bfffe8c0 00000200
BS: Exiting BS_WRITE_TABLES state.
BS: BS_WRITE_TABLES times (us): entry 16523 run 257699 exit 0
BS: Entering BS_PAYLOAD_LOAD state.
CBFS provider active.
CBFS @ 700000 size ff440
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 55640 size 92e77
'fallback/payload' located at offset: 755678 size: 92e77
Loading segment from rom address 0xfff55678
  code (compression=1)
  New segment dstaddr 0x8200 memsize 0x1aec4 srcaddr 0xfff556cc filesize 0x94a4
Loading segment from rom address 0xfff55694
  code (compression=1)
  New segment dstaddr 0x100000 memsize 0x24fac0 srcaddr 0xfff5eb70 filesize 0x8997f
Loading segment from rom address 0xfff556b0
  Entry Point 0x00008200
Bounce Buffer at bfc10000, 2671792 bytes
Loading Segment: addr: 0x0000000000008200 memsz: 0x000000000001aec4 filesz: 0x00000000000094a4
lb: [0x0000000000100000, 0x000000000013c9f0)
Post relocation: addr: 0x0000000000008200 memsz: 0x000000000001aec4 filesz: 0x00000000000094a4
using LZMA
[ 0x00008200, 0001b69b, 0x000230c4) <- fff556cc
Clearing Segment: addr: 0x000000000001b69b memsz: 0x0000000000007a29
dest 00008200, end 000230c4, bouncebuffer bfc10000
Loading Segment: addr: 0x0000000000100000 memsz: 0x000000000024fac0 filesz: 0x000000000008997f
lb: [0x0000000000100000, 0x000000000013c9f0)
segment: [0x0000000000100000, 0x000000000018997f, 0x000000000034fac0)
 bounce: [0x00000000bfc10000, 0x00000000bfc9997f, 0x00000000bfe5fac0)
Post relocation: addr: 0x00000000bfc10000 memsz: 0x000000000024fac0 filesz: 0x000000000008997f
using LZMA
[ 0xbfc10000, bfe5fac0, 0xbfe5fac0) <- fff5eb70
dest bfc10000, end bfe5fac0, bouncebuffer bfc10000
move suffix around: from bfc4c9f0, to 13c9f0, amount: 2130d0
Loaded segments
BS: Exiting BS_PAYLOAD_LOAD state.
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 295663 exit 0
BS: Entering BS_PAYLOAD_BOOT state.
PCH watchdog disabled
Jumping to boot code at 00008200(bfe9d000)
CPU0: stack: 00133000 - 00134000, lowest used address 00133a30, stack used: 1488 bytes
entry    = 0x00008200
lb_start = 0x00100000
lb_size  = 0x0003c9f0
buffer   = 0xbfc10000
 [    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.1.11-DEBUG (iru at T420) (gcc version 5.2.0 (GCC) ) #2 SMP Mon Oct 26 12:36:07 CST 2015
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=/dev/sda1
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000000fff] type 16
[    0.000000] BIOS-e820: [mem 0x0000000000001000-0x000000000009ffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001fffffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000020000000-0x00000000201fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000020200000-0x000000003fffffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000040000000-0x00000000401fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000040200000-0x00000000bfe9cfff] usable
[    0.000000] BIOS-e820: [mem 0x00000000bfe9d000-0x00000000bfffffff] type 16
[    0.000000] BIOS-e820: [mem 0x00000000c0000000-0x00000000c29fffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000013b5fffff] usable
[    0.000000] console [earlydbg0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.7 present.
[    0.000000] e820: last_pfn = 0x13b600 max_arch_pfn = 0x400000000
[    0.000000] PAT configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- UC  
[    0.000000] e820: last_pfn = 0xbfe9d max_arch_pfn = 0x400000000
[    0.000000] Scanning 1 areas for low memory corruption
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000] init_memory_mapping: [mem 0x13b400000-0x13b5fffff]
[    0.000000] init_memory_mapping: [mem 0x120000000-0x13b3fffff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x11fffffff]
[    0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
[    0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
[    0.000000] init_memory_mapping: [mem 0x40200000-0xbfe9cfff]
[    0.000000] ACPI: Early table checksum verification disabled
[    0.000000] ACPI: RSDP 0x00000000000F0000 000024 (v02 CORE  )
[    0.000000] ACPI: XSDT 0x00000000BFEB90E0 000054 (v01 CORE   COREBOOT 00000000 CORE 00000000)
[    0.000000] ACPI: FACP 0x00000000BFEBC730 0000F4 (v04 CORE   COREBOOT 00000000 CORE 00000000)
[    0.000000] ACPI: DSDT 0x00000000BFEB9280 0034B0 (v02 COREv4 COREBOOT 20110725 INTL 20150619)
[    0.000000] ACPI: FACS 0x00000000BFEB9240 000040
[    0.000000] ACPI: FACS 0x00000000BFEB9240 000040
[    0.000000] ACPI: SSDT 0x00000000BFEBC830 001468 (v02 CORE   COREBOOT 0000002A CORE 0000002A)
[    0.000000] ACPI: MCFG 0x00000000BFEBDCA0 00003C (v01 CORE   COREBOOT 00000000 CORE 00000000)
[    0.000000] ACPI: TCPA 0x00000000BFEBDCE0 000032 (v02 CORE   COREBOOT 00000000 CORE 00000000)
[    0.000000] ACPI: APIC 0x00000000BFEBDD20 00006C (v01 CORE   COREBOOT 00000000 CORE 00000000)
[    0.000000] ACPI: HPET 0x00000000BFEBDD90 000038 (v01 CORE   COREBOOT 00000000 CORE 00000000)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at [mem 0x0000000000000000-0x000000013b5fffff]
[    0.000000] NODE_DATA(0) allocated [mem 0x13b5fb000-0x13b5fefff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000013b5fffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009ffff]
[    0.000000]   node   0: [mem 0x0000000000100000-0x000000001fffffff]
[    0.000000]   node   0: [mem 0x0000000020200000-0x000000003fffffff]
[    0.000000]   node   0: [mem 0x0000000040200000-0x00000000bfe9cfff]
[    0.000000]   node   0: [mem 0x0000000100000000-0x000000013b5fffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000013b5fffff]
[    0.000000] Reserving Intel graphics stolen memory at 0xc0a00000-0xc29fffff
[    0.000000] ACPI: PM-Timer IO Port: 0x508
[    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] e820: [mem 0xc2a00000-0xefffffff] available for PCI devices
[    0.000000] clocksource refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370452778343963 ns
[    0.000000] setup_percpu: NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 33 pages/cpu @ffff88013b200000 s94616 r8192 d32360 u524288
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 1011930
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: root=/dev/sda2 earlyprintk='dbgp,keep'
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 using standard form
[    0.000000] Memory: 3961652K/4112624K available (8660K kernel code, 1195K rwdata, 2644K rodata, 1204K init, 1156K bss, 150972K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	Additional per-CPU info printed with stalls.
[    0.000000] 	RCU restricting CPUs from NR_CPUS=128 to nr_cpu_ids=4.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS:8448 nr_irqs:456 16
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] clocksource hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 2491.814 MHz processor
[    0.000031] Calibrating delay loop (skipped), value calculated using timer frequency.. 4985.27 BogoMIPS (lpj=8306046)
[    0.002001] pid_max: default: 32768 minimum: 301
[    0.002888] ACPI: Core revision 20150410
[    0.006329] ACPI: All ACPI Tables successfully acquired
[    0.007393] Security Framework initialized
[    0.008365] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.010729] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.012493] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.013756] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
[    0.015324] Initializing cgroup subsys blkio
[    0.016142] Initializing cgroup subsys memory
[    0.017009] Initializing cgroup subsys devices
[    0.017879] Initializing cgroup subsys freezer
[    0.018762] Initializing cgroup subsys net_cls
[    0.019647] CPU: Physical Processor ID: 0
[    0.020378] CPU: Processor Core ID: 0
[    0.021133] mce: CPU supports 7 MCE banks
[    0.021889] CPU0: Thermal monitoring enabled (TM1)
[    0.022768] process: using mwait in idle threads
[    0.023631] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8
[    0.024629] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0
[    0.026210] Freeing SMP alternatives memory: 28K (ffffffff82059000 - ffffffff82060000)
[    0.027723] ftrace: allocating 29658 entries in 116 pages
[    0.043605] x2apic: IRQ remapping doesn't support X2APIC mode
[    0.045062] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.079152] smpboot: CPU0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (fam: 06, model: 2a, stepping: 07)
[    0.081037] Performance Events: PEBS fmt1+, 16-deep LBR, SandyBridge events, full-width counters, Intel PMU driver.
[    0.083267] ... version:                3
[    0.084015] ... bit width:              48
[    0.084765] ... generic registers:      4
[    0.085515] ... value mask:             0000ffffffffffff
[    0.086516] ... max period:             0000ffffffffffff
[    0.087514] ... fixed-purpose events:   3
[    0.088266] ... event mask:             000000070000000f
[    0.089785] x86: Booting SMP configuration:
[    0.090519] .... node  #0, CPUs:      #1
[    0.104581] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[    0.106214]  #2 #3
[    0.132909] x86: Booted up 1 node, 4 CPUs
[    0.133773] smpboot: Total of 4 processors activated (19942.11 BogoMIPS)
[    0.137780] devtmpfs: initialized
[    0.141966] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[    0.143719] xor: automatically using best checksumming function:
[    0.178124]    avx       : 24067.200 MB/sec
[    0.178784] pinctrl core: initialized pinctrl subsystem
[    0.179817] RTC time: 15:17:53, date: 10/27/15
[    0.180757] NET: Registered protocol family 16
[    0.194874] cpuidle: using governor ladder
[    0.208211] cpuidle: using governor menu
[    0.208934] ACPI: bus type PCI registered
[    0.209662] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.210938] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf0000000-0xf3ffffff] (base 0xf0000000)
[    0.212665] PCI: MMCONFIG at [mem 0xf0000000-0xf3ffffff] reserved in E820
[    0.213971] PCI: Using configuration type 1 for base access
[    0.215077] perf_event_intel: PMU erratum BJ122, BV98, HSD29 worked around, HT is on
[    0.286575] raid6: sse2x1   gen()  6684 MB/s
[    0.343260] raid6: sse2x1   xor()  5343 MB/s
[    0.399948] raid6: sse2x2   gen()  8423 MB/s
[    0.456633] raid6: sse2x2   xor()  6108 MB/s
[    0.513321] raid6: sse2x4   gen()  9769 MB/s
[    0.570007] raid6: sse2x4   xor()  7329 MB/s
[    0.570843] raid6: using algorithm sse2x4 gen() 9769 MB/s
[    0.571844] raid6: .... xor() 7329 MB/s, rmw enabled
[    0.572845] raid6: using ssse3x2 recovery algorithm
[    0.573772] ACPI: Added _OSI(Module Device)
[    0.574468] ACPI: Added _OSI(Processor Device)
[    0.575344] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.576219] ACPI: Added _OSI(Processor Aggregator Device)
[    0.579831] ACPI : EC: EC started
[    0.580394] ACPI: Interpreter enabled
[    0.581103] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20150410/hwxface-580)
[    0.582973] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150410/hwxface-580)
[    0.584856] ACPI: (supports S0 S3 S5)
[    0.585596] ACPI: Using IOAPIC for interrupt routing
[    0.586617] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.591871] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.592975] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    0.594512] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
[    0.596030] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge
[    0.598102] PCI host bridge to bus 0000:00
[    0.598851] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.599851] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    0.601101] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    0.602349] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[    0.603727] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000c3fff window]
[    0.605100] pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000c7fff window]
[    0.606474] pci_bus 0000:00: root bus resource [mem 0x000c8000-0x000cbfff window]
[    0.607853] pci_bus 0000:00: root bus resource [mem 0x000cc000-0x000cffff window]
[    0.609226] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff window]
[    0.610600] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff window]
[    0.611978] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff window]
[    0.613350] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff window]
[    0.614727] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff window]
[    0.616102] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff window]
[    0.617477] pci_bus 0000:00: root bus resource [mem 0x000e8000-0x000ebfff window]
[    0.618853] pci_bus 0000:00: root bus resource [mem 0x000ec000-0x000effff window]
[    0.620229] pci_bus 0000:00: root bus resource [mem 0x000f0000-0x000fffff window]
[    0.621602] pci_bus 0000:00: root bus resource [mem 0xc2a00000-0xefffffff window]
[    0.622978] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed44fff window]
[    0.624921] pci 0000:00:1a.0: System wakeup disabled by ACPI
[    0.626136] pci 0000:00:1b.0: System wakeup disabled by ACPI
[    0.627869] pci 0000:00:1d.0: System wakeup disabled by ACPI
[    0.634432] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    0.635412] pci 0000:00:1c.1: PCI bridge to [bus 02]
[    0.636510] pci 0000:03:00.0: MMC controller base frequency changed to 50Mhz.
[    0.644558] pci 0000:00:1c.3: PCI bridge to [bus 03]
[    0.645631] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 12 14 15) *11
[    0.648024] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *11 12 14 15)
[    0.650268] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 12 14 15) *11
[    0.652643] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *11 12 14 15)
[    0.654892] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 12 14 15) *11
[    0.657267] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 *11 12 14 15)
[    0.659519] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 12 14 15) *11
[    0.661894] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *11 12 14 15)
[    0.664602] ACPI: Enabled 1 GPEs in block 00 to 3F
[    0.665710] ACPI : EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62
[    0.666924] vgaarb: setting as boot device: PCI:0000:00:02.0
[    0.667985] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.669490] vgaarb: loaded
[    0.669986] vgaarb: bridge control possible 0000:00:02.0
[    0.671044] SCSI subsystem initialized
[    0.671762] Linux video capture interface: v2.00
[    0.672617] pps_core: LinuxPPS API ver. 1 registered
[    0.673613] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti at linux.it>
[    0.675365] PTP clock support registered
[    0.676129] EDAC MC: Ver: 3.0.0
[    0.676888] Advanced Linux Sound Architecture Driver Initialized.
[    0.677990] PCI: Using ACPI for IRQ routing
[    0.680497] NetLabel: Initializing
[    0.681111] NetLabel:  domain hash size = 128
[    0.681989] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.682998] NetLabel:  unlabeled traffic allowed by default
[    0.684009] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[    0.685864] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
[    0.689013] Switched to clocksource hpet
[    0.697454] pnp: PnP ACPI init
[    0.698077] system 00:00: [mem 0xfed1c000-0xfed1ffff] has been reserved
[    0.699250] system 00:00: [mem 0xfed10000-0xfed17fff] has been reserved
[    0.700491] system 00:00: [mem 0xfed18000-0xfed18fff] has been reserved
[    0.701742] system 00:00: [mem 0xfed19000-0xfed19fff] has been reserved
[    0.702996] system 00:00: [mem 0xf0000000-0xf3ffffff] has been reserved
[    0.704241] system 00:00: [mem 0xfed20000-0xfed3ffff] has been reserved
[    0.705492] system 00:00: [mem 0xfed40000-0xfed44fff] has been reserved
[    0.706747] system 00:00: [mem 0xfed45000-0xfed8ffff] has been reserved
[    0.707991] system 00:00: [mem 0x20000000-0x201fffff] has been reserved
[    0.709248] system 00:00: [mem 0x40000000-0x401fffff] has been reserved
[    0.710891] system 00:01: [mem 0xfed00000-0xfed003ff] has been reserved
[    0.712156] system 00:02: [io  0x0500-0x057f] could not be reserved
[    0.713250] system 00:02: [io  0x0480-0x04bf] has been reserved
[    0.714472] pnp: PnP ACPI: found 6 devices
[    0.721586] clocksource acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.723160] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    0.724125] pci 0000:00:1c.0:   bridge window [mem 0xe1800000-0xe18fffff]
[    0.725375] pci 0000:00:1c.1: PCI bridge to [bus 02]
[    0.726385] pci 0000:00:1c.3: PCI bridge to [bus 03]
[    0.727371] pci 0000:00:1c.3:   bridge window [io  0x2000-0x2fff]
[    0.728499] pci 0000:00:1c.3:   bridge window [mem 0xe0000000-0xe08fffff]
[    0.729755] pci 0000:00:1c.3:   bridge window [mem 0xe0c00000-0xe13fffff 64bit pref]
[    0.731316] NET: Registered protocol family 2
[    0.732295] TCP established hash table entries: 32768 (order: 6, 262144 bytes)
[    0.733713] TCP bind hash table entries: 32768 (order: 7, 524288 bytes)
[    0.734973] TCP: Hash tables configured (established 32768 bind 32768)
[    0.736153] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    0.737263] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    0.738536] NET: Registered protocol family 1
[    0.739903] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.741067] software IO TLB [mem 0xbbe9d000-0xbfe9d000] (64MB) mapped at [ffff8800bbe9d000-ffff8800bfe9cfff]
[    0.743064] RAPL PMU detected, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer
[    0.744606] hw unit of domain pp0-core 2^-16 Joules
[    0.745393] hw unit of domain package 2^-16 Joules
[    0.746190] hw unit of domain pp1-gpu 2^-16 Joules
[    0.747047] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29
[    0.748091] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x29
[    0.749142] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x29
[    0.750187] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x29
[    0.751258] microcode: Microcode Update Driver: v2.00 <tigran at aivazian.fsnet.co.uk>, Peter Oruba
[    0.753015] Scanning for low memory corruption every 60 seconds
[    0.754257] futex hash table entries: 1024 (order: 4, 65536 bytes)
[    0.755721] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    0.758381] zpool: loaded
[    0.758794] zbud: loaded
[    0.759365] VFS: Disk quotas dquot_6.6.0
[    0.760061] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.761518] SGI XFS with ACLs, security attributes, realtime, no debug enabled
[    0.763335] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    0.764657] io scheduler noop registered
[    0.765326] io scheduler cfq registered (default)
[    0.766620] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt
[    0.767784] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[    0.768966] pcieport 0000:00:1c.1: Signaling PME through PCIe PME interrupt
[    0.770162] pcieport 0000:00:1c.3: Signaling PME through PCIe PME interrupt
[    0.771326] pci 0000:03:00.0: Signaling PME through PCIe PME interrupt
[    0.772503] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.773452] pciehp 0000:00:1c.3:pcie04: Slot #0 AttnBtn- AttnInd- PwrInd- PwrCtrl- MRL- Interlock- NoCompl+ LLActRep+
[    0.775402] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    0.776787] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/PNP0C09:00/PNP0C0E:00/input/input0
[    0.778704] ACPI: Sleep Button [SLPB]
[    0.779407] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/PNP0C09:00/PNP0C0D:00/input/input1
[    0.781431] ACPI: Lid Switch [LID]
[    0.782010] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2
[    0.783306] ACPI: Power Button [PWRF]
[    0.784002] GHES: HEST is not enabled!
[    0.784704] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.749208] tsc: Refined TSC clocksource calibration: 2491.905 MHz
[    1.750248] clocksource tsc: mask: 0xffffffffffffffff max_cycles: 0x23eb5abbd7b, max_idle_ns: 440795277677 ns
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151027/7dd35029/attachment-0001.asc>

From zaolin at das-labor.org  Tue Oct 27 16:38:30 2015
From: zaolin at das-labor.org (Zaolin)
Date: Tue, 27 Oct 2015 16:38:30 +0100
Subject: [coreboot] Linux kernel hangs
In-Reply-To: <20151027152130.GA8032@das-labor.org>
References: <20151027152130.GA8032@das-labor.org>
Message-ID: <1445960310.5500.2.camel@das-labor.org>

Hi,

yep try this patch. Then it should work again.
http://review.coreboot.org/#/c/12112/

Regards Zaolin

> I'm testing the Lenovo T420 port[1]. After I saw some commits on
> Sandy/Ivy RAM init and native graphics init code, I asked Nicolas
> Reinecke to rebase and update the code. After I flashed the new
> firmware, coreboot runs fine and boot to GRUB payload. However, Linux
> kernel hanged and could not boot. I think there must be something
> wrong with some of the upstream commits.
> 
> [1] http://review.coreboot.org/#/c/11765/
> 
> Iru Cai
> -- 
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From gaumless at gmail.com  Tue Oct 27 17:14:54 2015
From: gaumless at gmail.com (Martin Roth)
Date: Tue, 27 Oct 2015 10:14:54 -0600
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
Message-ID: <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>

The current thought is to create a new branch for 4.2, *THEN* remove
the decided upon code from the master branch.

This removes the maintenance work on master going forward while
providing a known point if someone wants to pick up the boards going
forward.

I don't understand the question about creating a branch for other
boards as well.  The branch would contain all current boards.

The question is really about what boards/code are inactive.  The code
that's being updated right now for the ASUS/KGPE-D16 board looked
inactive for a significant time.


Personally, I think it's a bad plan to remove the AGESA code.
Throwing away the code that AMD has given us is telling them that they
were right, and they shouldn't bother opening the source.  This is a
total contradiction of what we ACTUALLY want, which is the source code
for the binary PI releases.

If it's still decided to remove the AGESA family 10/15 codebases, my
thought would be to wait for at least the 4.3 release.  That's going
to be 3 months from now, giving us some time to finish getting in the
code that's supposed to replace it and giving it time to stabilize.

Martin


On Tue, Oct 27, 2015 at 9:01 AM, Wim Vervoorn <wvervoorn at eltan.com> wrote:
> Sounds like a good idea to create a branch of these but shouldn't that be done for other boards as well.
>
> So when you intend to remove boards to create version 4.2 you create a 4.1 branch of the existing state with those boards included. Then remove all boards that need to be dropped.
>
> When it's handled this way it's probably easier to drop boards that aren't used actively and thereby dropping unnecessary maintenance work.
>
> BR Wim
>
> -----Original Message-----
> From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Peter Stuge
> Sent: Tuesday, October 27, 2015 9:35 AM
> To: coreboot at coreboot.org
> Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
>
> Alex G. wrote:
>> > I'd like to start a discussion about boards, chipsets, drivers, or
>> > other code that can be removed from the tree.
>>
>> All of AGESA fam10 and fam15. With Raptop Engineering upstreaming
>> native support, I don't think we want to haul around the AGESA
>> implementations, which have been troublesome in the past.
>>
>> Actually, branch off those boards, keep them alive in their little
>> branch, but remove them from master.
>
> Hm maybe. It's important that the boards which use AGESA are still available somehow, so that they could be ported to coreboot init if someone has interest in doing that. Maybe a branch is good enough.
>
>
> //Peter
>
> --
> 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


From sielicki at nicky.io  Tue Oct 27 18:09:42 2015
From: sielicki at nicky.io (Nicky Sielicki)
Date: Tue, 27 Oct 2015 12:09:42 -0500
Subject: [coreboot] VGA cleanup advice
Message-ID: <20151027170942.GA996@wetdog>

Hello list,

I'm interested in cleaning up some of the VGA programming in coreboot.

I was trying to figure out why GM45 "native" textmode isn't working. I
noticed the following bit of code

> northbridge/intel/gm45/gma.c:144
>
>	const u8 cr[] = { 0x5f, 0x4f, 0x50, 0x82, 0x55, 0x81, 0xbf, 0x1f,
>		    0x00, 0x4f, 0x0d, 0x0e, 0x00, 0x00, 0x00, 0x00,
>		    0x9c, 0x8e, 0x8f, 0x28, 0x1f, 0x96, 0xb9, 0xa3,
>		    0xff
>	};
>	vga_cr_write(0x11, 0);
>	for (i = 0; i <= 0x18; i++)
>		vga_cr_write(i, cr[i]);
>
>	<...>
>	vga_textmode_init();

That for-loop generates the following statement:

> 'vga_cr_write(0x11, 0x8e)'

Looking at some VGA documentation, and noticing that 0x8e has a MSB of
1, I realized that this statement just locked CRTC registers 00h-07h!
(http://www.osdever.net/FreeVGA/vga/crtcreg.htm#11)

That's no good, because the subsequent call to vga_textmode_init() tries
to write to some of those CRTC registers, and it's not checking if
they're locked. It assumes that no one else is working with VGA
registers.

It's worth noting that GM45 isn't the only platform where this CRTC
locking is occuring. A couple others follow this same practice of
loading the CR registers into an array, writing them, and then calling
vga_textmode_init(). That's probably not what we want, and I'm looking
for advice on cleaning this up.

I think what we want to do is avoid having the VGA registers touched
from outside drivers/pc80/vga/. That means that we need to add or extend
functions to it in order to disincentivize writing them directly-- but
is it possible to accomodate every use case? What functions aren't being
provided currently, and why is it necessary/easiest to write them
directly?

On the other hand, an easier fix is to just have vga_textmode_init()
check that the registers it writes to are unlocked.

Thanks,
Nicky Sielicki


From rminnich at gmail.com  Tue Oct 27 18:59:49 2015
From: rminnich at gmail.com (ron minnich)
Date: Tue, 27 Oct 2015 17:59:49 +0000
Subject: [coreboot] VGA cleanup advice
In-Reply-To: <20151027170942.GA996@wetdog>
References: <20151027170942.GA996@wetdog>
Message-ID: <CAP6exYLy8mznGjWEMiu3ek2-Mo61O9Dvbumg+1XVZoTtfAm=FQ@mail.gmail.com>

On Tue, Oct 27, 2015 at 10:52 AM Nicky Sielicki <sielicki at nicky.io> wrote:

> Hello list,
>
> I'm interested in cleaning up some of the VGA programming in coreboot.
>

Good :-)


>
> I was trying to figure out why GM45 "native" textmode isn't working. I
> noticed the following bit of code
>
> > northbridge/intel/gm45/gma.c:144
> >
> >       const u8 cr[] = { 0x5f, 0x4f, 0x50, 0x82, 0x55, 0x81, 0xbf, 0x1f,
> >                   0x00, 0x4f, 0x0d, 0x0e, 0x00, 0x00, 0x00, 0x00,
> >                   0x9c, 0x8e, 0x8f, 0x28, 0x1f, 0x96, 0xb9, 0xa3,
> >                   0xff
> >       };
> >       vga_cr_write(0x11, 0);
> >       for (i = 0; i <= 0x18; i++)
> >               vga_cr_write(i, cr[i]);
> >
> >       <...>
> >       vga_textmode_init();
>

Next question: why isn't that 0x18 a sizeof(cr)? You might fix that too :-)


>
> That for-loop generates the following statement:
>
> > 'vga_cr_write(0x11, 0x8e)'
>
> Looking at some VGA documentation, and noticing that 0x8e has a MSB of
> 1, I realized that this statement just locked CRTC registers 00h-07h!
> (http://www.osdever.net/FreeVGA/vga/crtcreg.htm#11)
>

Here is something I don't know. Once locked, can they be unlocked, or is it
a one way trip?


>
> That's no good, because the subsequent call to vga_textmode_init() tries
> to write to some of those CRTC registers, and it's not checking if
> they're locked. It assumes that no one else is working with VGA
> registers.
>

yikes. Would it be possible to split the cr[] into two pieces, one to be
called once all vga setup is done, and lock it later?

>
> It's worth noting that GM45 isn't the only platform where this CRTC
> locking is occuring. A couple others follow this same practice of
> loading the CR registers into an array, writing them, and then calling
> vga_textmode_init(). That's probably not what we want, and I'm looking
> for advice on cleaning this up.
>
> I think what we want to do is avoid having the VGA registers touched
> from outside drivers/pc80/vga/. That means that we need to add or extend
> functions to it in order to disincentivize writing them directly-- but
> is it possible to accomodate every use case?


these are good ideas. One thing I've decided with graphics is that it's
probably impossible to cover all use cases. The hardware guys are too
creative.


> On the other hand, an easier fix is to just have vga_textmode_init()
> check that the registers it writes to are unlocked.
>
>
>

I wonder about just separating the locking from the setup bytes and making
locking the last thing called. That way, if people need to add more
functions at some point, they don't have to worry about locking at all.

thanks

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

From tpearson at raptorengineeringinc.com  Tue Oct 27 19:52:32 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Tue, 27 Oct 2015 13:52:32 -0500
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
Message-ID: <562FC7F0.2050800@raptorengineeringinc.com>

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

On 10/27/2015 11:14 AM, Martin Roth wrote:
> The current thought is to create a new branch for 4.2, *THEN* remove
> the decided upon code from the master branch.
> 
> This removes the maintenance work on master going forward while
> providing a known point if someone wants to pick up the boards going
> forward.
> 
> I don't understand the question about creating a branch for other
> boards as well.  The branch would contain all current boards.
> 
> The question is really about what boards/code are inactive.  The code
> that's being updated right now for the ASUS/KGPE-D16 board looked
> inactive for a significant time.
> 
> 
> Personally, I think it's a bad plan to remove the AGESA code.
> Throwing away the code that AMD has given us is telling them that they
> were right, and they shouldn't bother opening the source.  This is a
> total contradiction of what we ACTUALLY want, which is the source code
> for the binary PI releases.
> 
> If it's still decided to remove the AGESA family 10/15 codebases, my
> thought would be to wait for at least the 4.3 release.  That's going
> to be 3 months from now, giving us some time to finish getting in the
> code that's supposed to replace it and giving it time to stabilize.
> 
> Martin

If I may add to this discussion, much of the rationale for dropping
AGESA has to do with the largely incompatible design (and coding style)
of AGESA versus the rest of coreboot.  By encouraging the use of AGESA
over native intialization, not only does the native initialization code
receive less attention, but development of new features (such as
timestamping and early CBMEM) is also hampered.

- From what I understand, what coreboot actually wants is access the
source code, but not necessarily to just use the source code as-is.
Would it make more sense to keep the vendorcode available, but put a
large warning on it that boards using said vendorcode are not supported
(and remove them from Jenkins builds, etc.)?  Maybe even moving those
boards to a different subdirectory (vendor_shim_mainboards) would help
reinforce this idea.

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

iQEcBAEBAgAGBQJWL8fwAAoJEK+E3vEXDOFbaq8IAJM1L/hOMN5u1uitpqtNQVWW
s6iAWYmmemH/1vIzMCk1GBp6RRLpd1Na7fNFIIoCY8hBV2VQY+oLge7AQ2BMqhGQ
exzCKgDLaR9b1icktnho2kDXVShUkv+WMCQPetKXV4VPHZ4sudqjRS1GWqqVtXx2
fKPnopESqreOdBP+dg1fCygN1MeKtZM1Sort2+j0Uxfvog1VNHzZ18AMrZXNQNMr
armK/JwwxAq7Ku5MbxkH0+zV6G+VxrVYfkOV7bEtgcHtnpRRPA32dLGLIwcoM7Ea
xcqrsehZSN+5K8+dskRFGVVWekpb0i7cX+UBg1GiIC7nJXpfIAreRckmtcVkXOY=
=MdqC
-----END PGP SIGNATURE-----


From tpearson at raptorengineeringinc.com  Tue Oct 27 20:01:15 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Tue, 27 Oct 2015 14:01:15 -0500
Subject: [coreboot] VGA cleanup advice
In-Reply-To: <CAP6exYLy8mznGjWEMiu3ek2-Mo61O9Dvbumg+1XVZoTtfAm=FQ@mail.gmail.com>
References: <20151027170942.GA996@wetdog>
 <CAP6exYLy8mznGjWEMiu3ek2-Mo61O9Dvbumg+1XVZoTtfAm=FQ@mail.gmail.com>
Message-ID: <562FC9FB.5070304@raptorengineeringinc.com>

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

On 10/27/2015 12:59 PM, ron minnich wrote:
>
>
> On Tue, Oct 27, 2015 at 10:52 AM Nicky Sielicki <sielicki at nicky.io
> <mailto:sielicki at nicky.io>> wrote:
>
>     Hello list,
>
>     I'm interested in cleaning up some of the VGA programming in coreboot.
>
>
> Good :-)
>
>
>
>     I was trying to figure out why GM45 "native" textmode isn't working. I
>     noticed the following bit of code
>
>     > northbridge/intel/gm45/gma.c:144
>     >
>     >       const u8 cr[] = { 0x5f, 0x4f, 0x50, 0x82, 0x55, 0x81, 0xbf,
>     0x1f,
>     >                   0x00, 0x4f, 0x0d, 0x0e, 0x00, 0x00, 0x00, 0x00,
>     >                   0x9c, 0x8e, 0x8f, 0x28, 0x1f, 0x96, 0xb9, 0xa3,
>     >                   0xff
>     >       };
>     >       vga_cr_write(0x11, 0);
>     >       for (i = 0; i <= 0x18; i++)
>     >               vga_cr_write(i, cr[i]);
>     >
>     >       <...>
>     >       vga_textmode_init();
>
>
> Next question: why isn't that 0x18 a sizeof(cr)? You might fix that too :-)
>
>
>
>     That for-loop generates the following statement:
>
>     > 'vga_cr_write(0x11, 0x8e)'
>
>     Looking at some VGA documentation, and noticing that 0x8e has a MSB of
>     1, I realized that this statement just locked CRTC registers 00h-07h!
>     (http://www.osdever.net/FreeVGA/vga/crtcreg.htm#11)
>
>
> Here is something I don't know. Once locked, can they be unlocked, or is
> it a one way trip?

They can be unlocked again by simply clearing the lock bit.  The CRTC
registers are mainly locked to prevent badly behaved (old DOS mode)
programs from accidentally altering the video timing configuration.

I'm also glad to hear you are working on the GM45 text mode; this is
something I've been wanting to see for many months.

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/

iQEcBAEBAgAGBQJWL8n7AAoJEK+E3vEXDOFbhEUH/RblquUKIqly3cWjvc8jxUEZ
sOhovvUgkKxzw1yOXx+m0NpHW8hYaeq/+hSDD/q3FhUeVEP/SvkUvISOU3D/wCsj
Jm6Hhm5qqlotF56pOZhiBzyswJI7O7KNeWGkzQoVWAjC1Ym97C/rK3N2P/OSmGXL
3mkdpKNVgGrs3ovg4Z9Fo0fStO2PbGldnUA7P/b9XJUGUiRz2Ix1BUKy0CqsaL5A
tjBQYqicr4/2pW+M9o9lwIaanVvbUkVhcY6s1upbnZYHSThn1DGimPBC4ioP17Qz
U8oWP6Zirwf2lMOcn6+vN4xIZJKlpzEA0LzeZuIrm/+SyG5FldS3y50Liah4BHQ=
=SppD
-----END PGP SIGNATURE-----


From rminnich at gmail.com  Tue Oct 27 20:20:25 2015
From: rminnich at gmail.com (ron minnich)
Date: Tue, 27 Oct 2015 19:20:25 +0000
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <562FC7F0.2050800@raptorengineeringinc.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
Message-ID: <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>

The AGESA code was always an awkward fit into coreboot. It was more like a
badly designed artificial limb than a real part of the code base. I
understand the idea of encouraging vendors to commit source but, at this
point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful
in its time but I think I'm with tpearson on this point.

I believe we should drop AGESA on any boards that have native support, and
the sooner the better.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151027/6a9aa06b/attachment.html>

From dhendrix at google.com  Tue Oct 27 20:35:27 2015
From: dhendrix at google.com (David Hendricks)
Date: Tue, 27 Oct 2015 12:35:27 -0700
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
Message-ID: <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>

This all sounds fine from a developer's perspective, but what about AMD's
customers? I honestly have no clue if the decision to use an AMD product
with coreboot hinges on whether AMD's supplied AGESA code is used or not.
But I can imagine ripping out the AMD-supplied code might make it difficult
for AMD to support customers who use coreboot.

I'm sure there are people on this list who _have actually supported
customers_ using AMD products and coreboot, so I'd like to hear their
perspective.

/my $0.02.

On Tue, Oct 27, 2015 at 12:20 PM, ron minnich <rminnich at gmail.com> wrote:

> The AGESA code was always an awkward fit into coreboot. It was more like a
> badly designed artificial limb than a real part of the code base. I
> understand the idea of encouraging vendors to commit source but, at this
> point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful
> in its time but I think I'm with tpearson on this point.
>
> I believe we should drop AGESA on any boards that have native support, and
> the sooner the better.
>
> ron
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151027/61c3ae83/attachment.html>

From adurbin at google.com  Tue Oct 27 20:40:56 2015
From: adurbin at google.com (Aaron Durbin)
Date: Tue, 27 Oct 2015 14:40:56 -0500
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
Message-ID: <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>

On Tue, Oct 27, 2015 at 2:35 PM, David Hendricks <dhendrix at google.com> wrote:
> This all sounds fine from a developer's perspective, but what about AMD's
> customers? I honestly have no clue if the decision to use an AMD product
> with coreboot hinges on whether AMD's supplied AGESA code is used or not.
> But I can imagine ripping out the AMD-supplied code might make it difficult
> for AMD to support customers who use coreboot.
>
> I'm sure there are people on this list who _have actually supported
> customers_ using AMD products and coreboot, so I'd like to hear their
> perspective.
>
> /my $0.02.

The code lives on a branch. People are more than happy to work within
that branch. That's exactly what branches are for.

I'll one up the recommendation and suggest all non-romcc code that
#includes C files gets removed after the branch point. Or do such a
thing in the next release. I'm sick of having to deal with and
fighting against these development constructs.

>
> On Tue, Oct 27, 2015 at 12:20 PM, ron minnich <rminnich at gmail.com> wrote:
>>
>> The AGESA code was always an awkward fit into coreboot. It was more like a
>> badly designed artificial limb than a real part of the code base. I
>> understand the idea of encouraging vendors to commit source but, at this
>> point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful in
>> its time but I think I'm with tpearson on this point.
>>
>> I believe we should drop AGESA on any boards that have native support, and
>> the sooner the better.
>>
>> ron
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
>
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From quickcracktime at gmail.com  Tue Oct 27 21:10:31 2015
From: quickcracktime at gmail.com (Vladimir)
Date: Tue, 27 Oct 2015 23:10:31 +0300
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
Message-ID: <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>

It would be really wrong to remove the whole AGESA code: there are
AMD-based products which are still very alive and actively sold (at the
developing markets) Moving the support for these products to a separate
coreboot branch, could create many inconveniences for those AMD product
owners who would like to test & use the latest and greatest coreboot build:
they will have to backport all the commits of code that's used by all the
boards, to that separate abandoned branch - which would cause a lot of
hassle and would basically cut them off from the development

I agree that removing could be done to some 2009 VIA-based EOL boards that
nobody cares about, but it would be a mistake to do that to all the AMD
products, some of which are still produced to this date and used together
with coreboot by lots of people from this mailing list

Also, that action will send a bad signal to AMD. AMD is actively supporting
the coreboot project and is much more friendly to open source community
than Intel with it's ME and creepy lock-it-all desires. Removing AGESA code
would be an equivalent of telling "we don't need your code" to AMD, one of
the largest coreboot supporters, and that could lead to a terrible
consequences


On 27 October 2015 at 22:40, Aaron Durbin <adurbin at google.com> wrote:

> On Tue, Oct 27, 2015 at 2:35 PM, David Hendricks <dhendrix at google.com>
> wrote:
> > This all sounds fine from a developer's perspective, but what about AMD's
> > customers? I honestly have no clue if the decision to use an AMD product
> > with coreboot hinges on whether AMD's supplied AGESA code is used or not.
> > But I can imagine ripping out the AMD-supplied code might make it
> difficult
> > for AMD to support customers who use coreboot.
> >
> > I'm sure there are people on this list who _have actually supported
> > customers_ using AMD products and coreboot, so I'd like to hear their
> > perspective.
> >
> > /my $0.02.
>
> The code lives on a branch. People are more than happy to work within
> that branch. That's exactly what branches are for.
>
> I'll one up the recommendation and suggest all non-romcc code that
> #includes C files gets removed after the branch point. Or do such a
> thing in the next release. I'm sick of having to deal with and
> fighting against these development constructs.
>
> >
> > On Tue, Oct 27, 2015 at 12:20 PM, ron minnich <rminnich at gmail.com>
> wrote:
> >>
> >> The AGESA code was always an awkward fit into coreboot. It was more
> like a
> >> badly designed artificial limb than a real part of the code base. I
> >> understand the idea of encouraging vendors to commit source but, at this
> >> point, the AMD ship has sailed off to Port Binary Blob. AGESA was
> helpful in
> >> its time but I think I'm with tpearson on this point.
> >>
> >> I believe we should drop AGESA on any boards that have native support,
> and
> >> the sooner the better.
> >>
> >> ron
> >>
> >> --
> >> coreboot mailing list: coreboot at coreboot.org
> >> http://www.coreboot.org/mailman/listinfo/coreboot
> >
> >
> >
> >
> > --
> > David Hendricks (dhendrix)
> > Systems Software Engineer, Google Inc.
> >
> > --
> > 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/20151027/c26d49ce/attachment.html>

From tpearson at raptorengineeringinc.com  Tue Oct 27 21:15:09 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Tue, 27 Oct 2015 15:15:09 -0500
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
Message-ID: <562FDB4D.8040907@raptorengineeringinc.com>

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

On 10/27/2015 03:10 PM, Vladimir wrote:
> It would be really wrong to remove the whole AGESA code: there are
> AMD-based products which are still very alive and actively sold (at the
> developing markets) Moving the support for these products to a separate
> coreboot branch, could create many inconveniences for those AMD product
> owners who would like to test & use the latest and greatest coreboot
> build: they will have to backport all the commits of code that's used by
> all the boards, to that separate abandoned branch - which would cause a
> lot of hassle and would basically cut them off from the development
> 
> I agree that removing could be done to some 2009 VIA-based EOL boards
> that nobody cares about, but it would be a mistake to do that to all the
> AMD products, some of which are still produced to this date and used
> together with coreboot by lots of people from this mailing list
> 
> Also, that action will send a bad signal to AMD. AMD is actively
> supporting the coreboot project and is much more friendly to open source
> community than Intel with it's ME and creepy lock-it-all desires.
> Removing AGESA code would be an equivalent of telling "we don't need
> your code" to AMD, one of the largest coreboot supporters, and that
> could lead to a terrible consequences

AMD is hardly innocent on that front; they require a large binary blob
to execute on the auxiliary CPU at bootup, with unknown security
consequences.  Also, as far as I understand there has been no new AGESA
source release for some time, only binary blobs.

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

iQEcBAEBAgAGBQJWL9tLAAoJEK+E3vEXDOFbGXEH/Ar/eErlZp8biCEOO3EUKXN3
CXpvDMgjsWf8k0jmlW25ythzyEuD1fLsVhD84GvvO0anwMhT66IXtHVAyXUegd7T
+iJd1MmthsSJRNW8xLhu9r+YEZInLAlq56HZ7ebnwbVmeokRhUdfCKUkUshPOO0N
73v5Q7SLQbhR8NwWzDF9jYF/DJyqfkgO1boBxDDGeV5XPzy5Ho+fwPFrH+E47nes
4u1uNxu8MYQvDoQzxIc/HE9scAhl79kuk3GUuiuoe6RlreKPlrFQVK0Rb+yIe/n+
63mz53ZLdHCoglQLiGpMYlrQDSgzwvHH7i+lfavacgctJd7+Q0n5MFh9TppN4Uc=
=G6dr
-----END PGP SIGNATURE-----


From quickcracktime at gmail.com  Tue Oct 27 21:36:47 2015
From: quickcracktime at gmail.com (Vladimir)
Date: Tue, 27 Oct 2015 23:36:47 +0300
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <562FDB4D.8040907@raptorengineeringinc.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
Message-ID: <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>

Although I agree with you that AMD is not innocent as well, if you would
check a "Binary situation" page at coreboot's wiki, you would see that
Intel is in three times more evil (still could not understand why some
incredibly talented coreboot developers are spending so much time fighting
Intel's ME issues, while AMD boards don't have that "dragon you have to
tame" on board)

In any case, it would be very sad to see the AMD code gone from the master
branch. Even the code for some unpopular boards like Intel Atom-based EOL
"Mohron Peak" was allowed to stay! Why AMD boards are considered worse? The
sole idea of AMD code going away, which will affect many alive-and-kicking
coreboot-supported AMD boards, is beyond my comprehension

On 27 October 2015 at 23:15, Timothy Pearson <
tpearson at raptorengineeringinc.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/27/2015 03:10 PM, Vladimir wrote:
> > It would be really wrong to remove the whole AGESA code: there are
> > AMD-based products which are still very alive and actively sold (at the
> > developing markets) Moving the support for these products to a separate
> > coreboot branch, could create many inconveniences for those AMD product
> > owners who would like to test & use the latest and greatest coreboot
> > build: they will have to backport all the commits of code that's used by
> > all the boards, to that separate abandoned branch - which would cause a
> > lot of hassle and would basically cut them off from the development
> >
> > I agree that removing could be done to some 2009 VIA-based EOL boards
> > that nobody cares about, but it would be a mistake to do that to all the
> > AMD products, some of which are still produced to this date and used
> > together with coreboot by lots of people from this mailing list
> >
> > Also, that action will send a bad signal to AMD. AMD is actively
> > supporting the coreboot project and is much more friendly to open source
> > community than Intel with it's ME and creepy lock-it-all desires.
> > Removing AGESA code would be an equivalent of telling "we don't need
> > your code" to AMD, one of the largest coreboot supporters, and that
> > could lead to a terrible consequences
>
> AMD is hardly innocent on that front; they require a large binary blob
> to execute on the auxiliary CPU at bootup, with unknown security
> consequences.  Also, as far as I understand there has been no new AGESA
> source release for some time, only binary blobs.
>
> - --
> 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/
>
> iQEcBAEBAgAGBQJWL9tLAAoJEK+E3vEXDOFbGXEH/Ar/eErlZp8biCEOO3EUKXN3
> CXpvDMgjsWf8k0jmlW25ythzyEuD1fLsVhD84GvvO0anwMhT66IXtHVAyXUegd7T
> +iJd1MmthsSJRNW8xLhu9r+YEZInLAlq56HZ7ebnwbVmeokRhUdfCKUkUshPOO0N
> 73v5Q7SLQbhR8NwWzDF9jYF/DJyqfkgO1boBxDDGeV5XPzy5Ho+fwPFrH+E47nes
> 4u1uNxu8MYQvDoQzxIc/HE9scAhl79kuk3GUuiuoe6RlreKPlrFQVK0Rb+yIe/n+
> 63mz53ZLdHCoglQLiGpMYlrQDSgzwvHH7i+lfavacgctJd7+Q0n5MFh9TppN4Uc=
> =G6dr
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151027/5546c1a1/attachment.html>

From stefan.reinauer at coreboot.org  Tue Oct 27 21:39:38 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Tue, 27 Oct 2015 21:39:38 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
Message-ID: <20151027203937.GA31797@coreboot.org>

* Martin Roth <gaumless at gmail.com> [151026 22:51]:
> I'd like to start a discussion about boards, chipsets, drivers, or
> other code that can be removed from the tree.
> 
> At the coreboot conference in Bonn, we discussed this some. I believe
> that we decided to wait until the next release/branch of the coreboot
> tree before removing anything.  By planning ahead and deleting the
> components immediately after the release, we can list the things that
> have been end-of-lifed in the branch release notes.
> 
> By discussing this on the mailing list instead of just pushing commits
> to the tree, we can get better buy in from all interested parties.
> 
> 
> I'd request that these be boards & chips that are no longer being
> produced, and haven't been updated in a few years.
> 
> These seem like good candidates to start the discussion:
>    mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
>    northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
> 
> As far as I can tell, the last real contributions to these came in
> 2009 - all the changes since then have been cleanup and modifications
> for other changes across the coreboot tree.
 
Since 2009 is really only 6ys ago, I'm a bit hesitant about the VX800
stuff (while leaving the older CN700 / CX700 in the tree)
It also seems VIA gave up on coreboot at this point, so it might not
matter, unless we want to work on bringing them back?

Is anybody in contact with VIA at this point?

> What other directories should be removed from the tree after the next release?

I want to add the following boards (and their chipsets and super ios)
that have been in the tree and basically unmaintained for 10+ys:

 * arima/hdama
 * digitallogic/adl855pc
 * ibm/e325
 * ibm/e326
 * iwill/dk8s2
 * iwill/dk8x
 * newisys/khepri
 * tyan/s2735 
 * tyan/s2850 
 * tyan/s2875 
 * tyan/s2880 
 * tyan/s2881
 * tyan/s2882  
 * tyan/s2885  
 * tyan/s2891  
 * tyan/s2892  
 * tyan/s2895  
 * tyan/s4880  
 * tyan/s4882

 
> Eventually it would be nice to be able to use submissions to
> board-status repo to determine what's being used.  We're just not at
> that point yet.

I think this is a hard problem. Churn on a board's or chipset's code
does not necessarily coincide with a board being used or the other way
around. A target might just be stable and working well.

We need to get to the point where 100% of the boards in the tree are
boot tested 100% of the time.

Stefan



From tpearson at raptorengineeringinc.com  Tue Oct 27 21:41:08 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Tue, 27 Oct 2015 15:41:08 -0500
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
Message-ID: <562FE164.4060803@raptorengineeringinc.com>

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

On 10/27/2015 03:36 PM, Vladimir wrote:
> Although I agree with you that AMD is not innocent as well, if you would
> check a "Binary situation" page at coreboot's wiki, you would see that
> Intel is in three times more evil (still could not understand why some
> incredibly talented coreboot developers are spending so much time
> fighting Intel's ME issues, while AMD boards don't have that "dragon you
> have to tame" on board)
> 
> In any case, it would be very sad to see the AMD code gone from the
> master branch. Even the code for some unpopular boards like Intel
> Atom-based EOL "Mohron Peak" was allowed to stay! Why AMD boards are
> considered worse? The sole idea of AMD code going away, which will
> affect many alive-and-kicking coreboot-supported AMD boards, is beyond
> my comprehension

This is why I was advocating a gentle demotion to second class status.
You can still use the AGESA code where needed, but native intialization
would be preferred for new ports.

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

iQEcBAEBAgAGBQJWL+FhAAoJEK+E3vEXDOFbjmIIAK3Tf/KBLQH92uCJsCn5ekJv
S5hE1LdDBvRXM5p3xZWarqnomfvbxeNP8fg9PfOixxDLLSE/gWKE5B1H119le5Dl
aXU99ge7dMefZ9uxm0zfjKLvCsS/vc7ESqC+KKcYxK0Q1KswF/g6wLeaG8LS18wQ
W83gZCTdFjW8YhTnxu8kzmXDT+2vT5CSSGQoN0d6gD0WZrti7gLCL1m9Nu5stnKt
Kul93N7KmVYhdUAIBzyrsTl5/JV5JzOXgHFVUvhrUa1XqRk5DC1MjHHaTYA6W1kT
+f5m9HnBTGP6G4agtHBiScq/XBCl7+MdMkx3Ecb32QMgyvcSlG3UMLXiax2UHYA=
=nXMZ
-----END PGP SIGNATURE-----


From dhendrix at google.com  Tue Oct 27 22:10:18 2015
From: dhendrix at google.com (David Hendricks)
Date: Tue, 27 Oct 2015 14:10:18 -0700
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <562FE164.4060803@raptorengineeringinc.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <562FE164.4060803@raptorengineeringinc.com>
Message-ID: <CAKOoyUdvH6bLEiw9iiSNwX2Eyn1yarpgvcO8RwDu=rsRwKstrg@mail.gmail.com>

On Tue, Oct 27, 2015 at 1:41 PM, Timothy Pearson <
tpearson at raptorengineeringinc.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/27/2015 03:36 PM, Vladimir wrote:
> > Although I agree with you that AMD is not innocent as well, if you would
> > check a "Binary situation" page at coreboot's wiki, you would see that
> > Intel is in three times more evil (still could not understand why some
> > incredibly talented coreboot developers are spending so much time
> > fighting Intel's ME issues, while AMD boards don't have that "dragon you
> > have to tame" on board)
> >
> > In any case, it would be very sad to see the AMD code gone from the
> > master branch. Even the code for some unpopular boards like Intel
> > Atom-based EOL "Mohron Peak" was allowed to stay! Why AMD boards are
> > considered worse? The sole idea of AMD code going away, which will
> > affect many alive-and-kicking coreboot-supported AMD boards, is beyond
> > my comprehension
>
> This is why I was advocating a gentle demotion to second class status.
> You can still use the AGESA code where needed, but native intialization
> would be preferred for new ports.
>

Ah, thanks for the clarification. I think I had a knee-jerk reaction since
the idea of ripping out AGESA entirely has been floated in the past. This
seems like a decent approach.


>
> - --
> 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/
>
> iQEcBAEBAgAGBQJWL+FhAAoJEK+E3vEXDOFbjmIIAK3Tf/KBLQH92uCJsCn5ekJv
> S5hE1LdDBvRXM5p3xZWarqnomfvbxeNP8fg9PfOixxDLLSE/gWKE5B1H119le5Dl
> aXU99ge7dMefZ9uxm0zfjKLvCsS/vc7ESqC+KKcYxK0Q1KswF/g6wLeaG8LS18wQ
> W83gZCTdFjW8YhTnxu8kzmXDT+2vT5CSSGQoN0d6gD0WZrti7gLCL1m9Nu5stnKt
> Kul93N7KmVYhdUAIBzyrsTl5/JV5JzOXgHFVUvhrUa1XqRk5DC1MjHHaTYA6W1kT
> +f5m9HnBTGP6G4agtHBiScq/XBCl7+MdMkx3Ecb32QMgyvcSlG3UMLXiax2UHYA=
> =nXMZ
> -----END PGP SIGNATURE-----
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151027/ce5254bd/attachment.html>

From rminnich at gmail.com  Tue Oct 27 22:32:40 2015
From: rminnich at gmail.com (ron minnich)
Date: Tue, 27 Oct 2015 21:32:40 +0000
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAKOoyUdvH6bLEiw9iiSNwX2Eyn1yarpgvcO8RwDu=rsRwKstrg@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <562FE164.4060803@raptorengineeringinc.com>
 <CAKOoyUdvH6bLEiw9iiSNwX2Eyn1yarpgvcO8RwDu=rsRwKstrg@mail.gmail.com>
Message-ID: <CAP6exY+7vxpkRJi+m4Xo0+8dcLPQEv6BwY2Yjmgeq0crFQmXng@mail.gmail.com>

I think we can make it clear to AMD that we are grateful for AGESA and
their support, and the way they have helped us to get to a good place in
terms of code; and, further, we can now offer a better option, with code
that really fits well into coreboot.

I don't see demoting AGESA as a bad thing; it's a good thing. AGESA got us
to where we are, and now we take the next step: code that is well
integrated. In fact I think we're all giving AMD a huge vote of confidence
by making the effort to make their chips fit really well into coreboot,
instead of being half-in/half-out. This is going to be a big improvement.

We're not tossing AMD out; we're inviting them into the living room, with a
warm fire and a nice place to sit down and relax :-)

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151027/f5edffa7/attachment-0001.html>

From quickcracktime at gmail.com  Tue Oct 27 23:17:14 2015
From: quickcracktime at gmail.com (Vladimir)
Date: Wed, 28 Oct 2015 01:17:14 +0300
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <562FEE06.4050705@felixheld.de>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <562FEE06.4050705@felixheld.de>
Message-ID: <CALnsgKzcCHB==DMQHYfhGOSfHMELGYv7mL+Zd0E9LZDrUvfLVA@mail.gmail.com>

Thank you for this enlightening message about blobgesa... Luckily AMD was
10 years slow at following Intel's ME example, 10 years since ME first
version, and it was not until 2015 that built-in Platform Secure Processors
completely took over the AMD's Mobility family ( Kaveri from 2014 still
didnt have PSP ) . Desktop family has 2015 Godavari without the PSP. It
seems that PSP-blobgesa plague is going from low end to high end direction,
and - while it took over the mobility family - desktop high end is still
OK, and server family is far from it (so far only low end "seattle" servers
are affected)

Hopefully this blobgesa will be open sourced eventually - its not that far
from reality because AMD open sourced a lot of stuff during the past
months... Also it will be very interesting to see how AMD Zen platforms
will behave

Best regards,
Vladimir Shipovalov


On 28 October 2015 at 00:35, Felix Held <felix-coreboot at felixheld.de> wrote:

>
> if you would check a "Binary situation" page at coreboot's wiki, you would
>> see that Intel is in three times more evil
>>
> That page is outdated. Newer AMD systems have the platform security
> processor, which is quite similiar to the ME.
>
> http://www.uefi.org/sites/default/files/resources/UEFI_PlugFest_AMD_Security_and_Server_innovation_AMD_March_2013.pdf
> has some information on the PSP.
> Chips with PSP are btw. only supported by blobgesa.
>
> Also the AGESA source is quite a mess (I started to do some cleanups
> there, but finally dropped the project, because it wasn't worth the time
> for me) and having native initialization will be much better.
>
> Regards
> Felix
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151028/97bb899f/attachment.html>

From mr.nuke.me at gmail.com  Wed Oct 28 04:56:21 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Tue, 27 Oct 2015 20:56:21 -0700
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
Message-ID: <56304765.7060509@gmail.com>

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

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

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

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

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

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

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

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

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

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

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

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

How will moving code around affect supported boards?

> is beyond my comprehension

BRANCH NOT EQUALS REMOVAL

Does that help?

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

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

* AGESA
reason: integration issues

* binaryPI
reason: integration issues

* FSP 1.0
reason: integration issues

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

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

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

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

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

Hope this clears things up,
Alex

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

> 
> On 27 October 2015 at 23:15, Timothy Pearson
> <tpearson at raptorengineeringinc.com
> <mailto:tpearson at raptorengineeringinc.com>> wrote:
> 
> On 10/27/2015 03:10 PM, Vladimir wrote:
>> It would be really wrong to remove the whole AGESA code: there are
>> AMD-based products which are still very alive and actively sold (at the
>> developing markets) Moving the support for these products to a separate
>> coreboot branch, could create many inconveniences for those AMD product
>> owners who would like to test & use the latest and greatest coreboot
>> build: they will have to backport all the commits of code that's used by
>> all the boards, to that separate abandoned branch - which would cause a
>> lot of hassle and would basically cut them off from the development
> 
>> I agree that removing could be done to some 2009 VIA-based EOL boards
>> that nobody cares about, but it would be a mistake to do that to all the
>> AMD products, some of which are still produced to this date and used
>> together with coreboot by lots of people from this mailing list
> 
>> Also, that action will send a bad signal to AMD. AMD is actively
>> supporting the coreboot project and is much more friendly to open source
>> community than Intel with it's ME and creepy lock-it-all desires.
>> Removing AGESA code would be an equivalent of telling "we don't need
>> your code" to AMD, one of the largest coreboot supporters, and that
>> could lead to a terrible consequences
> 
> AMD is hardly innocent on that front; they require a large binary blob
> to execute on the auxiliary CPU at bootup, with unknown security
> consequences.  Also, as far as I understand there has been no new AGESA
> source release for some time, only binary blobs.
> 
> 
> 
> 
> 


From mytbk920423 at gmail.com  Wed Oct 28 07:54:45 2015
From: mytbk920423 at gmail.com (Iru Cai)
Date: Wed, 28 Oct 2015 14:54:45 +0800
Subject: [coreboot] Linux kernel hangs
In-Reply-To: <1445960310.5500.2.camel@das-labor.org>
References: <20151027152130.GA8032@das-labor.org>
 <1445960310.5500.2.camel@das-labor.org>
Message-ID: <20151028065445.GA8696@mytbk-laptop>

Hi,
On Tue, Oct 27, 2015 at 04:38:30PM +0100, Zaolin wrote:
> Hi,
> 
> yep try this patch. Then it should work again.
> http://review.coreboot.org/#/c/12112/
Thanks. It works fine now after I apply this patch.

However, I then use this patch for more testing:
http://review.coreboot.org/#/c/12087/

Then I modified some code and pushed to gerrit, and git pushed the
patch you gave me too. I don't know if this will make some problems.

Iru


> 
> Regards Zaolin
> 
> > I'm testing the Lenovo T420 port[1]. After I saw some commits on
> > Sandy/Ivy RAM init and native graphics init code, I asked Nicolas
> > Reinecke to rebase and update the code. After I flashed the new
> > firmware, coreboot runs fine and boot to GRUB payload. However, Linux
> > kernel hanged and could not boot. I think there must be something
> > wrong with some of the upstream commits.
> > 
> > [1] http://review.coreboot.org/#/c/11765/
> > 
> > Iru Cai
> > -- 
> > 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151028/a5132b4a/attachment.asc>

From wvervoorn at eltan.com  Wed Oct 28 08:51:29 2015
From: wvervoorn at eltan.com (Wim Vervoorn)
Date: Wed, 28 Oct 2015 07:51:29 +0000
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <56304765.7060509@gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <56304765.7060509@gmail.com>
Message-ID: <26ea2f3f480e4b67be401487197ee141@Eltsrv03.Eltan.local>

Hello Alex,

I totally agree with your mail. This certainly looks like the way to deal with it.

We don't loose anything but make it easier to move forward with new designs at the same time when using branches.

BR Wim.





-----Original Message-----
From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Alex G.
Sent: Wednesday, October 28, 2015 4:56 AM
To: coreboot at coreboot.org
Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

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

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

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

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

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

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

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

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

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

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

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

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

How will moving code around affect supported boards?

> is beyond my comprehension

BRANCH NOT EQUALS REMOVAL

Does that help?

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

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

* AGESA
reason: integration issues

* binaryPI
reason: integration issues

* FSP 1.0
reason: integration issues

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

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

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

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

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

Hope this clears things up,
Alex

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

> 
> On 27 October 2015 at 23:15, Timothy Pearson 
> <tpearson at raptorengineeringinc.com
> <mailto:tpearson at raptorengineeringinc.com>> wrote:
> 
> On 10/27/2015 03:10 PM, Vladimir wrote:
>> It would be really wrong to remove the whole AGESA code: there are 
>> AMD-based products which are still very alive and actively sold (at 
>> the developing markets) Moving the support for these products to a 
>> separate coreboot branch, could create many inconveniences for those 
>> AMD product owners who would like to test & use the latest and 
>> greatest coreboot
>> build: they will have to backport all the commits of code that's used 
>> by all the boards, to that separate abandoned branch - which would 
>> cause a lot of hassle and would basically cut them off from the 
>> development
> 
>> I agree that removing could be done to some 2009 VIA-based EOL boards 
>> that nobody cares about, but it would be a mistake to do that to all 
>> the AMD products, some of which are still produced to this date and 
>> used together with coreboot by lots of people from this mailing list
> 
>> Also, that action will send a bad signal to AMD. AMD is actively 
>> supporting the coreboot project and is much more friendly to open 
>> source community than Intel with it's ME and creepy lock-it-all desires.
>> Removing AGESA code would be an equivalent of telling "we don't need 
>> your code" to AMD, one of the largest coreboot supporters, and that 
>> could lead to a terrible consequences
> 
> AMD is hardly innocent on that front; they require a large binary blob 
> to execute on the auxiliary CPU at bootup, with unknown security 
> consequences.  Also, as far as I understand there has been no new 
> AGESA source release for some time, only binary blobs.
> 
> 
> 
> 
> 

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






From pgeorgi at google.com  Wed Oct 28 09:32:45 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Wed, 28 Oct 2015 09:32:45 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <56304765.7060509@gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
Message-ID: <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>

2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me at gmail.com>:
> Here's a list of things I think should be moved to branches, right after
> the 4.2 release:
So far the idea was to drop things in master after a release, and
create branches for releases (as I did for 4.1 yesterday, in addition
to the tag).
So, when dropping stuff after the 4.2 release, to go back to these
things, you start from the 4.2 branch.

> Now remember, this assumes branches are as first class
> citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
> That shows it can work.
There's a significant difference (and a problem that we'd inherit by
adopting the chromium gerrit model):

The difference is that Chromium firmware branches are made per-board
for devices where not many changes are expected.
The items you point out are most interesting for adding new boards
(nevermind if this actually happens - but the Lenovo *60 stuff wasn't
predicted a year before it happened either, 945 was "dead" then).
If we go for branches for that, developing FSP1.0 coreboot will look
quite different from master-coreboot.

The problem we have with firmware branches over at Chromium is that,
as far non-ChromeOS development is concerned, branches are where
commits are pushed to die. They're not folded back into mainline
Chromium nor coreboot.org. We don't really have a good solution for
that.

If we spawn tons of branches every time something becomes a bit
inconvenient to deal with, we're quickly devolving into u-boot:
vendors will just start maintaining their own branches, and porting
high level features between those requires an immense amount of effort
because there are many years of divergence between them.
If you want a taste of that, try building something on Chromium's
chromeos-2013.04 branch and then port it to upstream master. And that
was just 2.5 years.

tl;dr: hiding problems in branches won't serve us long-term.


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


From quickcracktime at gmail.com  Wed Oct 28 13:59:18 2015
From: quickcracktime at gmail.com (Vladimir)
Date: Wed, 28 Oct 2015 15:59:18 +0300
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
Message-ID: <CALnsgKx4ch7B0Tp86UK-0YSwo-CH3M67FAhFRciwJ60NMgw0GQ@mail.gmail.com>

On 10/28/2015 04:56 AM, Alex Gagniuc wrote:
>
> How will moving [AGESA] code [to a separate branch] affect supported
[AMD] boards?
>

The biggest problem here is:

Various improvements and important bug fixes, that will be introduced to a
master branch and affect all the coreboot boards, will not be automatically
applied to that separate AMD branch. Those coreboot developers which have
AMD boards and want to constantly use and test latest and greatest coreboot
builds, they will have to constantly check the coreboot commit log and
backport all these improvements and fixes to their separate (and soon to be
abandoned) AMD branch. That will be adding lots of unnecessary manual work
and draining lots of workhours, which otherwise could have been spent on
writing the bug reports or improving a coreboot code which is common for
all the coreboot-supported boards.

As result, moving AGESA code will affect - and not only AMD boards: all the
coreboot supported boards will be indirectly negatively affected by that
change...

Luckily Timothy Pearson has advised a perfect solution for this issue:

On 28 October 2015 at 02:23, Timothy Pearson wrote:
>
> Perhaps in the short term we can port the remaining AGESA Fam15h boards
> to native init, and look into moving Fam14h to as much native as
> possible while still keeping the PSP happy with its blobs?
>

If the AGESA boards will be ported to a native init, they will be able to
continue to be supported by a master branch! That approach will allow
coreboot developers with AMD boards to avoid spending time on backporting
the changes and concentrate on developing and testing the latest coreboot
builds from a master branch

Best regards,
Vladimir Shipovalov

On 28 October 2015 at 11:32, Patrick Georgi <pgeorgi at google.com> wrote:

> 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me at gmail.com>:
> > Here's a list of things I think should be moved to branches, right after
> > the 4.2 release:
> So far the idea was to drop things in master after a release, and
> create branches for releases (as I did for 4.1 yesterday, in addition
> to the tag).
> So, when dropping stuff after the 4.2 release, to go back to these
> things, you start from the 4.2 branch.
>
> > Now remember, this assumes branches are as first class
> > citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
> > That shows it can work.
> There's a significant difference (and a problem that we'd inherit by
> adopting the chromium gerrit model):
>
> The difference is that Chromium firmware branches are made per-board
> for devices where not many changes are expected.
> The items you point out are most interesting for adding new boards
> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
> predicted a year before it happened either, 945 was "dead" then).
> If we go for branches for that, developing FSP1.0 coreboot will look
> quite different from master-coreboot.
>
> The problem we have with firmware branches over at Chromium is that,
> as far non-ChromeOS development is concerned, branches are where
> commits are pushed to die. They're not folded back into mainline
> Chromium nor coreboot.org. We don't really have a good solution for
> that.
>
> If we spawn tons of branches every time something becomes a bit
> inconvenient to deal with, we're quickly devolving into u-boot:
> vendors will just start maintaining their own branches, and porting
> high level features between those requires an immense amount of effort
> because there are many years of divergence between them.
> If you want a taste of that, try building something on Chromium's
> chromeos-2013.04 branch and then port it to upstream master. And that
> was just 2.5 years.
>
> tl;dr: hiding problems in branches won't serve us long-term.
>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot 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/20151028/8bae1dce/attachment.html>

From pgeorgi at google.com  Wed Oct 28 14:24:39 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Wed, 28 Oct 2015 14:24:39 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CALnsgKx4ch7B0Tp86UK-0YSwo-CH3M67FAhFRciwJ60NMgw0GQ@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <CALnsgKx4ch7B0Tp86UK-0YSwo-CH3M67FAhFRciwJ60NMgw0GQ@mail.gmail.com>
Message-ID: <CAE-gjdWC-Y-Qxw=cs_87td9J2D=xuA+JP6be9M0CO_i-dYRO1Q@mail.gmail.com>

2015-10-28 13:59 GMT+01:00 Vladimir <quickcracktime at gmail.com>:
> If the AGESA boards will be ported to a native init, they will be able to
> continue to be supported by a master branch! That approach will allow
> coreboot developers with AMD boards to avoid spending time on backporting
> the changes and concentrate on developing and testing the latest coreboot
> builds from a master branch
I agree. Patches accepted.


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


From adurbin at google.com  Wed Oct 28 14:50:10 2015
From: adurbin at google.com (Aaron Durbin)
Date: Wed, 28 Oct 2015 08:50:10 -0500
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
Message-ID: <CAE2855vBni0TDkhq3T5HmGESBHb42Aui6QOduXBQbN5seWehqA@mail.gmail.com>

On Wed, Oct 28, 2015 at 3:32 AM, Patrick Georgi <pgeorgi at google.com> wrote:
> 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me at gmail.com>:
>> Here's a list of things I think should be moved to branches, right after
>> the 4.2 release:
> So far the idea was to drop things in master after a release, and
> create branches for releases (as I did for 4.1 yesterday, in addition
> to the tag).
> So, when dropping stuff after the 4.2 release, to go back to these
> things, you start from the 4.2 branch.
>
>> Now remember, this assumes branches are as first class
>> citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
>> That shows it can work.
> There's a significant difference (and a problem that we'd inherit by
> adopting the chromium gerrit model):
>
> The difference is that Chromium firmware branches are made per-board
> for devices where not many changes are expected.
> The items you point out are most interesting for adding new boards
> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
> predicted a year before it happened either, 945 was "dead" then).
> If we go for branches for that, developing FSP1.0 coreboot will look
> quite different from master-coreboot.
>
> The problem we have with firmware branches over at Chromium is that,
> as far non-ChromeOS development is concerned, branches are where
> commits are pushed to die. They're not folded back into mainline
> Chromium nor coreboot.org. We don't really have a good solution for
> that.
>
> If we spawn tons of branches every time something becomes a bit
> inconvenient to deal with, we're quickly devolving into u-boot:
> vendors will just start maintaining their own branches, and porting
> high level features between those requires an immense amount of effort
> because there are many years of divergence between them.
> If you want a taste of that, try building something on Chromium's
> chromeos-2013.04 branch and then port it to upstream master. And that
> was just 2.5 years.
>

That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.

What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient. From
the few years that I have been involved in this project I have seen
the airplanes pile up in the graveyard. So basically, it seems like
status quo rules. Or the time horizon for change is so long (10 years)
that the result is accumulation of more cruft? To add insult to injury
there's no tenable way of making changes in these areas because the
physical resources are not readily available to test against. As such
there is no progress in fixing those inconveniences which in turn
means an ever increasing burden for making non-periphery changes.

Ignoring the #include "file.c" constructs, a large majority of the
mainboards drive romstage flow entirely within those directories. i.e.
main() starts in mainboard. There is no common/consistent flow for
romstage on x86. That requires chipset as well as mainboard changes to
rectify. How do you propose one goes about doing that? Build test it?
Then have someone come 6 months later and say "hey, this doesn't
work."

> tl;dr: hiding problems in branches won't serve us long-term.

What does serve us long-term? And what are those goals? Is it
quantifiable by the number of mainboards checked into the coreboot.org
repo that build regardless of the maintenance burden?

>
>
> Patrick
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From adurbin at google.com  Wed Oct 28 14:52:15 2015
From: adurbin at google.com (Aaron Durbin)
Date: Wed, 28 Oct 2015 08:52:15 -0500
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CALnsgKx4ch7B0Tp86UK-0YSwo-CH3M67FAhFRciwJ60NMgw0GQ@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <CALnsgKx4ch7B0Tp86UK-0YSwo-CH3M67FAhFRciwJ60NMgw0GQ@mail.gmail.com>
Message-ID: <CAE2855uijfNO7HJXDJTj-rBGCbUHzW-zGg6BNDkx8Qz3vXj3DQ@mail.gmail.com>

On Wed, Oct 28, 2015 at 7:59 AM, Vladimir <quickcracktime at gmail.com> wrote:
> On 10/28/2015 04:56 AM, Alex Gagniuc wrote:
>>
>> How will moving [AGESA] code [to a separate branch] affect supported [AMD]
>> boards?
>>
>
> The biggest problem here is:
>
> Various improvements and important bug fixes, that will be introduced to a
> master branch and affect all the coreboot boards, will not be automatically
> applied to that separate AMD branch. Those coreboot developers which have
> AMD boards and want to constantly use and test latest and greatest coreboot
> builds, they will have to constantly check the coreboot commit log and
> backport all these improvements and fixes to their separate (and soon to be
> abandoned) AMD branch. That will be adding lots of unnecessary manual work
> and draining lots of workhours, which otherwise could have been spent on
> writing the bug reports or improving a coreboot code which is common for all
> the coreboot-supported boards.

Those developers should then take a more active role in improving the
code that is applicable to them. As it stands now, I don't see any
work going in improving those code bases.

>
> As result, moving AGESA code will affect - and not only AMD boards: all the
> coreboot supported boards will be indirectly negatively affected by that
> change...
>
> Luckily Timothy Pearson has advised a perfect solution for this issue:
>
> On 28 October 2015 at 02:23, Timothy Pearson wrote:
>>
>> Perhaps in the short term we can port the remaining AGESA Fam15h boards
>> to native init, and look into moving Fam14h to as much native as
>> possible while still keeping the PSP happy with its blobs?
>>
>
> If the AGESA boards will be ported to a native init, they will be able to
> continue to be supported by a master branch! That approach will allow
> coreboot developers with AMD boards to avoid spending time on backporting
> the changes and concentrate on developing and testing the latest coreboot
> builds from a master branch

There's more to it than just moving to native init. That doesn't
remove the maintenance burden.

>
> Best regards,
> Vladimir Shipovalov
>
> On 28 October 2015 at 11:32, Patrick Georgi <pgeorgi at google.com> wrote:
>>
>> 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me at gmail.com>:
>> > Here's a list of things I think should be moved to branches, right after
>> > the 4.2 release:
>> So far the idea was to drop things in master after a release, and
>> create branches for releases (as I did for 4.1 yesterday, in addition
>> to the tag).
>> So, when dropping stuff after the 4.2 release, to go back to these
>> things, you start from the 4.2 branch.
>>
>> > Now remember, this assumes branches are as first class
>> > citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
>> > That shows it can work.
>> There's a significant difference (and a problem that we'd inherit by
>> adopting the chromium gerrit model):
>>
>> The difference is that Chromium firmware branches are made per-board
>> for devices where not many changes are expected.
>> The items you point out are most interesting for adding new boards
>> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't
>> predicted a year before it happened either, 945 was "dead" then).
>> If we go for branches for that, developing FSP1.0 coreboot will look
>> quite different from master-coreboot.
>>
>> The problem we have with firmware branches over at Chromium is that,
>> as far non-ChromeOS development is concerned, branches are where
>> commits are pushed to die. They're not folded back into mainline
>> Chromium nor coreboot.org. We don't really have a good solution for
>> that.
>>
>> If we spawn tons of branches every time something becomes a bit
>> inconvenient to deal with, we're quickly devolving into u-boot:
>> vendors will just start maintaining their own branches, and porting
>> high level features between those requires an immense amount of effort
>> because there are many years of divergence between them.
>> If you want a taste of that, try building something on Chromium's
>> chromeos-2013.04 branch and then port it to upstream master. And that
>> was just 2.5 years.
>>
>> tl;dr: hiding problems in branches won't serve us long-term.
>>
>>
>> Patrick
>> --
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
>> Hamburg
>> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From peter at stuge.se  Wed Oct 28 15:00:08 2015
From: peter at stuge.se (Peter Stuge)
Date: Wed, 28 Oct 2015 15:00:08 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards
	and	chipsets for 4.2 release
In-Reply-To: <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
References: <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
Message-ID: <20151028140008.27188.qmail@stuge.se>

Patrick Georgi wrote:
> branches are where commits are pushed to die.

Yes, this is a very important point, and is why I don't support Alex'
proposal of moving some things to live only on a branch, and not on master.

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

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

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

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

It's not a good idea to sweep older code under a branchy carpet until
newer code is generally felt to be equal or better. I don't think
that's the case yet, it's just too early.


//Peter


From pgeorgi at google.com  Wed Oct 28 15:15:18 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Wed, 28 Oct 2015 15:15:18 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAE2855vBni0TDkhq3T5HmGESBHb42Aui6QOduXBQbN5seWehqA@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <CAE2855vBni0TDkhq3T5HmGESBHb42Aui6QOduXBQbN5seWehqA@mail.gmail.com>
Message-ID: <CAE-gjdXvWDp96Ht99b3RrbuFJWmVoVGdA4VTPDyPuqVhM-gGqQ@mail.gmail.com>

2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin at google.com>:
> That presupposes there is work going on in those branches that is
> desired to be pushed back into another branch. Anyone can very much
> port forward something if they so choose. That's the point of the
> branching mechanism.
>
> What is your proposal for dealing w/ inconvenience? I haven't seen a
> modicum of change in that area. In fact, what we have seen is more
> boards being added that use the constructs that are inconvenient.
For one: when things are considered too inconvenient (and used and
maintained) to be practical to keep around, remove them. For real.
Claiming that we can stuff them "in branches" is a cop-out, because
they're still dead.

That's also why I proposed to go with tags for releases: When people
are motivated enough to dig out the old stuff and make it work again,
there should be some incentive to bring them up to current standards.
Then they can get back into master.
If somebody is spearheading such an effort and provides test
resources, I think there's even some willingness to help with some of
the more mechanical tasks - like cleaning out #include "file.c" stuff,
but the motivation is rather hard to get by when it's unclear if the
code is ever used again.

People can still take any old commit (tagged, branched, or not) and do
their own thing on github - however I think we're setting standards by
what we do. Opening branches encourages to keep basing work on them,
instead of considering snapshots to be just that.

My main objection to dropping things was that the motivation by the
proponents always looked very similar to "this is inconvenient to me
right now, let's get rid of this".
If we were consequential in following up every such sentiment by
everyone, we'd probably ship a single file, COPYING.


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


From adurbin at google.com  Wed Oct 28 15:30:47 2015
From: adurbin at google.com (Aaron Durbin)
Date: Wed, 28 Oct 2015 09:30:47 -0500
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAE-gjdXvWDp96Ht99b3RrbuFJWmVoVGdA4VTPDyPuqVhM-gGqQ@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <CAE2855vBni0TDkhq3T5HmGESBHb42Aui6QOduXBQbN5seWehqA@mail.gmail.com>
 <CAE-gjdXvWDp96Ht99b3RrbuFJWmVoVGdA4VTPDyPuqVhM-gGqQ@mail.gmail.com>
Message-ID: <CAE2855v4cPANoQzvjHcPVnR0ctfuje99HcgaBZ1ezOYuxC1VKw@mail.gmail.com>

On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <pgeorgi at google.com> wrote:
> 2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin at google.com>:
>> That presupposes there is work going on in those branches that is
>> desired to be pushed back into another branch. Anyone can very much
>> port forward something if they so choose. That's the point of the
>> branching mechanism.
>>
>> What is your proposal for dealing w/ inconvenience? I haven't seen a
>> modicum of change in that area. In fact, what we have seen is more
>> boards being added that use the constructs that are inconvenient.
> For one: when things are considered too inconvenient (and used and
> maintained) to be practical to keep around, remove them. For real.
> Claiming that we can stuff them "in branches" is a cop-out, because
> they're still dead.
>
> That's also why I proposed to go with tags for releases: When people
> are motivated enough to dig out the old stuff and make it work again,
> there should be some incentive to bring them up to current standards.
> Then they can get back into master.
> If somebody is spearheading such an effort and provides test
> resources, I think there's even some willingness to help with some of
> the more mechanical tasks - like cleaning out #include "file.c" stuff,
> but the motivation is rather hard to get by when it's unclear if the
> code is ever used again.

Where is that motivation now? There is no one providing the resources
so the answer is status quo which in turn means an insanely daunting
task in trying to clean up things that just so happen to touch 90% of
the mainboards because of the existing code flow/design. Without the
resources nothing can be done which means accumulation of cruft and no
idea if anyone uses anything. What's the end game there?

Maybe it doesn't matter because all the work required has been
completed going forward so one can just keep cranking out boards, but
I suspect that is not the case. And when another requirement surfaces
that no one was anticipating do we add yet another API/subset on how
to do things? Where's the common base to work against?

>
> People can still take any old commit (tagged, branched, or not) and do
> their own thing on github - however I think we're setting standards by
> what we do. Opening branches encourages to keep basing work on them,
> instead of considering snapshots to be just that.

What are the standards we're setting?

>
> My main objection to dropping things was that the motivation by the
> proponents always looked very similar to "this is inconvenient to me
> right now, let's get rid of this".
> If we were consequential in following up every such sentiment by
> everyone, we'd probably ship a single file, COPYING.

I think you're taking such a notion to the extreme. Probably the
superset of opinion may be that, but I don't think that's practical
nor helpful in this discussion. I've cited very specific things that I
have run into within my development, and I don't see a solution aside
from "tred lightly, hold your nose, and hope for the best". I'd be
happy to help support said improvement work, but there's no path for
such things, and the carrot of getting back into the sacred master
branch is apparently unpalatable for people.

>From my vantage point it seems people want the playground they grew up
with and knew and loved. Therefore, don't ever change my playground.

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


From mr.nuke.me at gmail.com  Wed Oct 28 16:43:37 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Wed, 28 Oct 2015 08:43:37 -0700
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <20151028140008.27188.qmail@stuge.se>
References: <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <20151028140008.27188.qmail@stuge.se>
Message-ID: <5630ED29.2080501@gmail.com>



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

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

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

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

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

Do you offer to maintain the problematic code going forward?

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

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

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

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

Alex


From gaumless at gmail.com  Wed Oct 28 16:48:15 2015
From: gaumless at gmail.com (Martin Roth)
Date: Wed, 28 Oct 2015 09:48:15 -0600
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAE2855v4cPANoQzvjHcPVnR0ctfuje99HcgaBZ1ezOYuxC1VKw@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <CAE2855vBni0TDkhq3T5HmGESBHb42Aui6QOduXBQbN5seWehqA@mail.gmail.com>
 <CAE-gjdXvWDp96Ht99b3RrbuFJWmVoVGdA4VTPDyPuqVhM-gGqQ@mail.gmail.com>
 <CAE2855v4cPANoQzvjHcPVnR0ctfuje99HcgaBZ1ezOYuxC1VKw@mail.gmail.com>
Message-ID: <CA+e+Ov5FrdYddzynDeHcTbD09PpaB1BHzY0XGBOJE8n6=H=WiA@mail.gmail.com>

It seems that we've got more issues than we can address before the
proposed 4.2 release date within the next few days - we're trying to
get this out in October.

Maybe it's time for another 'Major' release where we can remove more
than just the few mainboards and truly obsolete code that I was
thinking of when I started this conversation.

Is there anyone against removal of any of these boards/chipsets after
the 4.2 release, or should we wait for a decision about handling all
of the current issues before we delete anything?

   mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
   northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
 * arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131
 * digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855,
SB: INTEL_I82801DX
 * ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * newisys/khepri  - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB:
INTEL_I82870, SB: INTEL_I82801EX
 * tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111
 * tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151
 * tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:
AMD8131, SB: AMD8151
 * tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
 * tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
 * tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131


I'd vote against the removal of any of the AGESA codebases for this
release with the possible exception of the Family 12 codebase.  It's
only used in the torpedo mainboard, and even that's not well
supported.
I'd vote against the removal of any of the Intel FSP codebases for
this release.  They are recent, and they are definitely still being
used.  Even Rangeley.  Yes, they have their issues.

I could support moving platforms off to the 4.X branch if we decide to
create a 5.0 branch to move forward and get things cleaned up.  Still,
having dealt with several different forks of the coreboot code, my
opinion is that branching is basically going to end the support for
these platforms.  Of course the people that don't use those platforms
don't care whether coreboot is killed off for those platforms, so I'd
ask that these platforms that we're choosing to die be picked
carefully.



On Wed, Oct 28, 2015 at 8:30 AM, Aaron Durbin <adurbin at google.com> wrote:
> On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <pgeorgi at google.com> wrote:
>> 2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin at google.com>:
>>> That presupposes there is work going on in those branches that is
>>> desired to be pushed back into another branch. Anyone can very much
>>> port forward something if they so choose. That's the point of the
>>> branching mechanism.
>>>
>>> What is your proposal for dealing w/ inconvenience? I haven't seen a
>>> modicum of change in that area. In fact, what we have seen is more
>>> boards being added that use the constructs that are inconvenient.
>> For one: when things are considered too inconvenient (and used and
>> maintained) to be practical to keep around, remove them. For real.
>> Claiming that we can stuff them "in branches" is a cop-out, because
>> they're still dead.
>>
>> That's also why I proposed to go with tags for releases: When people
>> are motivated enough to dig out the old stuff and make it work again,
>> there should be some incentive to bring them up to current standards.
>> Then they can get back into master.
>> If somebody is spearheading such an effort and provides test
>> resources, I think there's even some willingness to help with some of
>> the more mechanical tasks - like cleaning out #include "file.c" stuff,
>> but the motivation is rather hard to get by when it's unclear if the
>> code is ever used again.
>
> Where is that motivation now? There is no one providing the resources
> so the answer is status quo which in turn means an insanely daunting
> task in trying to clean up things that just so happen to touch 90% of
> the mainboards because of the existing code flow/design. Without the
> resources nothing can be done which means accumulation of cruft and no
> idea if anyone uses anything. What's the end game there?
>
> Maybe it doesn't matter because all the work required has been
> completed going forward so one can just keep cranking out boards, but
> I suspect that is not the case. And when another requirement surfaces
> that no one was anticipating do we add yet another API/subset on how
> to do things? Where's the common base to work against?
>
>>
>> People can still take any old commit (tagged, branched, or not) and do
>> their own thing on github - however I think we're setting standards by
>> what we do. Opening branches encourages to keep basing work on them,
>> instead of considering snapshots to be just that.
>
> What are the standards we're setting?
>
>>
>> My main objection to dropping things was that the motivation by the
>> proponents always looked very similar to "this is inconvenient to me
>> right now, let's get rid of this".
>> If we were consequential in following up every such sentiment by
>> everyone, we'd probably ship a single file, COPYING.
>
> I think you're taking such a notion to the extreme. Probably the
> superset of opinion may be that, but I don't think that's practical
> nor helpful in this discussion. I've cited very specific things that I
> have run into within my development, and I don't see a solution aside
> from "tred lightly, hold your nose, and hope for the best". I'd be
> happy to help support said improvement work, but there's no path for
> such things, and the carrot of getting back into the sacred master
> branch is apparently unpalatable for people.
>
> From my vantage point it seems people want the playground they grew up
> with and knew and loved. Therefore, don't ever change my playground.
>
>>
>>
>> Patrick
>> --
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
>> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot


From rminnich at gmail.com  Wed Oct 28 16:53:09 2015
From: rminnich at gmail.com (ron minnich)
Date: Wed, 28 Oct 2015 15:53:09 +0000
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CA+e+Ov5FrdYddzynDeHcTbD09PpaB1BHzY0XGBOJE8n6=H=WiA@mail.gmail.com>
References: <CA+e+Ov4yg58sSpYH4nq+9QJSPiX0fgQ+z37-JWMTUV8W-1bf0Q@mail.gmail.com>
 <562EF134.20204@gmail.com> <20151027083459.7160.qmail@stuge.se>
 <93e63a6f398547d5845e1abd39b5334f@Eltsrv03.Eltan.local>
 <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <CAE2855vBni0TDkhq3T5HmGESBHb42Aui6QOduXBQbN5seWehqA@mail.gmail.com>
 <CAE-gjdXvWDp96Ht99b3RrbuFJWmVoVGdA4VTPDyPuqVhM-gGqQ@mail.gmail.com>
 <CAE2855v4cPANoQzvjHcPVnR0ctfuje99HcgaBZ1ezOYuxC1VKw@mail.gmail.com>
 <CA+e+Ov5FrdYddzynDeHcTbD09PpaB1BHzY0XGBOJE8n6=H=WiA@mail.gmail.com>
Message-ID: <CAP6exYLp46CUNYj0S0+p2mFoMFzDU3r4yH599wCOpvYjNZfcAQ@mail.gmail.com>

IIRC I did the IBM e325/6 back in the day and I'm happy to see it die.

ron

On Wed, Oct 28, 2015 at 8:49 AM Martin Roth <gaumless at gmail.com> wrote:

> It seems that we've got more issues than we can address before the
> proposed 4.2 release date within the next few days - we're trying to
> get this out in October.
>
> Maybe it's time for another 'Major' release where we can remove more
> than just the few mainboards and truly obsolete code that I was
> thinking of when I started this conversation.
>
> Is there anyone against removal of any of these boards/chipsets after
> the 4.2 release, or should we wait for a decision about handling all
> of the current issues before we delete anything?
>
>    mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
>    northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
>  * arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855,
> SB: INTEL_I82801DX
>  * ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * newisys/khepri  - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:
> AMD8131
>  * tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB:
> INTEL_I82870, SB: INTEL_I82801EX
>  * tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111
>  * tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151
>  * tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:
> AMD8131, SB: AMD8151
>  * tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB:
> AMD8131
>  * tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB:
> AMD8131
>  * tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB:
> AMD8131
>  * tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>  * tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
>
>
> I'd vote against the removal of any of the AGESA codebases for this
> release with the possible exception of the Family 12 codebase.  It's
> only used in the torpedo mainboard, and even that's not well
> supported.
> I'd vote against the removal of any of the Intel FSP codebases for
> this release.  They are recent, and they are definitely still being
> used.  Even Rangeley.  Yes, they have their issues.
>
> I could support moving platforms off to the 4.X branch if we decide to
> create a 5.0 branch to move forward and get things cleaned up.  Still,
> having dealt with several different forks of the coreboot code, my
> opinion is that branching is basically going to end the support for
> these platforms.  Of course the people that don't use those platforms
> don't care whether coreboot is killed off for those platforms, so I'd
> ask that these platforms that we're choosing to die be picked
> carefully.
>
>
>
> On Wed, Oct 28, 2015 at 8:30 AM, Aaron Durbin <adurbin at google.com> wrote:
> > On Wed, Oct 28, 2015 at 9:15 AM, Patrick Georgi <pgeorgi at google.com>
> wrote:
> >> 2015-10-28 14:50 GMT+01:00 Aaron Durbin <adurbin at google.com>:
> >>> That presupposes there is work going on in those branches that is
> >>> desired to be pushed back into another branch. Anyone can very much
> >>> port forward something if they so choose. That's the point of the
> >>> branching mechanism.
> >>>
> >>> What is your proposal for dealing w/ inconvenience? I haven't seen a
> >>> modicum of change in that area. In fact, what we have seen is more
> >>> boards being added that use the constructs that are inconvenient.
> >> For one: when things are considered too inconvenient (and used and
> >> maintained) to be practical to keep around, remove them. For real.
> >> Claiming that we can stuff them "in branches" is a cop-out, because
> >> they're still dead.
> >>
> >> That's also why I proposed to go with tags for releases: When people
> >> are motivated enough to dig out the old stuff and make it work again,
> >> there should be some incentive to bring them up to current standards.
> >> Then they can get back into master.
> >> If somebody is spearheading such an effort and provides test
> >> resources, I think there's even some willingness to help with some of
> >> the more mechanical tasks - like cleaning out #include "file.c" stuff,
> >> but the motivation is rather hard to get by when it's unclear if the
> >> code is ever used again.
> >
> > Where is that motivation now? There is no one providing the resources
> > so the answer is status quo which in turn means an insanely daunting
> > task in trying to clean up things that just so happen to touch 90% of
> > the mainboards because of the existing code flow/design. Without the
> > resources nothing can be done which means accumulation of cruft and no
> > idea if anyone uses anything. What's the end game there?
> >
> > Maybe it doesn't matter because all the work required has been
> > completed going forward so one can just keep cranking out boards, but
> > I suspect that is not the case. And when another requirement surfaces
> > that no one was anticipating do we add yet another API/subset on how
> > to do things? Where's the common base to work against?
> >
> >>
> >> People can still take any old commit (tagged, branched, or not) and do
> >> their own thing on github - however I think we're setting standards by
> >> what we do. Opening branches encourages to keep basing work on them,
> >> instead of considering snapshots to be just that.
> >
> > What are the standards we're setting?
> >
> >>
> >> My main objection to dropping things was that the motivation by the
> >> proponents always looked very similar to "this is inconvenient to me
> >> right now, let's get rid of this".
> >> If we were consequential in following up every such sentiment by
> >> everyone, we'd probably ship a single file, COPYING.
> >
> > I think you're taking such a notion to the extreme. Probably the
> > superset of opinion may be that, but I don't think that's practical
> > nor helpful in this discussion. I've cited very specific things that I
> > have run into within my development, and I don't see a solution aside
> > from "tred lightly, hold your nose, and hope for the best". I'd be
> > happy to help support said improvement work, but there's no path for
> > such things, and the carrot of getting back into the sacred master
> > branch is apparently unpalatable for people.
> >
> > From my vantage point it seems people want the playground they grew up
> > with and knew and loved. Therefore, don't ever change my playground.
> >
> >>
> >>
> >> Patrick
> >> --
> >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> >> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
> >
> > --
> > coreboot mailing list: coreboot 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/20151028/8db07597/attachment.html>

From stefan.reinauer at coreboot.org  Wed Oct 28 17:11:14 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Wed, 28 Oct 2015 17:11:14 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <CAE2855uijfNO7HJXDJTj-rBGCbUHzW-zGg6BNDkx8Qz3vXj3DQ@mail.gmail.com>
References: <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <CALnsgKx4ch7B0Tp86UK-0YSwo-CH3M67FAhFRciwJ60NMgw0GQ@mail.gmail.com>
 <CAE2855uijfNO7HJXDJTj-rBGCbUHzW-zGg6BNDkx8Qz3vXj3DQ@mail.gmail.com>
Message-ID: <20151028161114.GC31505@coreboot.org>

* Aaron Durbin <adurbin at google.com> [151028 14:52]:
> > Various improvements and important bug fixes, that will be introduced to a
> > master branch and affect all the coreboot boards, will not be automatically
> > applied to that separate AMD branch. Those coreboot developers which have
> > AMD boards and want to constantly use and test latest and greatest coreboot
> > builds, they will have to constantly check the coreboot commit log and
> > backport all these improvements and fixes to their separate (and soon to be
> > abandoned) AMD branch. That will be adding lots of unnecessary manual work
> > and draining lots of workhours, which otherwise could have been spent on
> > writing the bug reports or improving a coreboot code which is common for all
> > the coreboot-supported boards.
> 
> Those developers should then take a more active role in improving the
> code that is applicable to them. As it stands now, I don't see any
> work going in improving those code bases.

And there I am, waiting for people to review my AMD64 cleanup patches
since July ;-) hint hint. 

Stefan



From peter at stuge.se  Wed Oct 28 17:44:15 2015
From: peter at stuge.se (Peter Stuge)
Date: Wed, 28 Oct 2015 17:44:15 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards
	and	chipsets for 4.2 release
In-Reply-To: <5630ED29.2080501@gmail.com>
References: <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <20151028140008.27188.qmail@stuge.se> <5630ED29.2080501@gmail.com>
Message-ID: <20151028164415.10637.qmail@stuge.se>

Alex G. wrote:
> >> branches are where commits are pushed to die.
> > 
> > Yes, this is a very important point, and is why I don't support Alex'
> > proposal of moving some things to live only on a branch, and not on master.
> 
> So, tagging and removing is better than a branch where people can
> continue to work, and submit patches via coreboot.org?

I think you are confusing things. I disagree with removing the things
you listed.

Here's a brief summary of the release process as I understand it:

For each release a tag and a branch are created, and on master some
old things are then immediately removed. I disagree with removing the
things you have listed for this release.


The community works on what interests them. Some work will go only into
the post-release branch, and some work goes only into master. That's OK.

The post-release branch is second class in the sense that anything
happening there does not have to fit into master. It is first class
in the sense that larger changes in master do not have to be worked
into code removed after the release.


However, this is not what we are discussing.

We are discussing whether the things you listed should stay on master
or not, after the current release, and I strongly feel that most if
not all of them should.

I do not think that there is any urgency.


> > Branches *can* work really well, but only when there is a person
> > and/or team actively maintaining that branch, and for that to work
> > well, the branch needs to have a fairly clear policy. The best
> > example of this is the Linux kernel.
> 
> If branches die out they die out. That means there isn't interest in
> that hardware. Big deal.

I'm afraid it just isn't that simple.


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

We are already doing all right there, and I don't see it as problematic.


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

I think that's too large a change compared to how the community has
worked before to be either practical or useful.

I don't think this is a bad end goal for us to have, but I also don't
believe that we can go from A to Z in a single step.


> Just look at the fiasco (in no particular order) Marc, Martin, and
> Ron caused after sandybrdge fsp got removed.

>From what I can tell that was caused by you, but that's getting off topic.


//Peter


From kraxel at redhat.com  Thu Oct 29 10:52:53 2015
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Thu, 29 Oct 2015 10:52:53 +0100
Subject: [coreboot] Proposal: Removing obsolete & EOL boards and
 chipsets for 4.2 release
In-Reply-To: <5630ED29.2080501@gmail.com>
References: <CA+e+Ov461rHFeX4s-NA3JaFPwJG1Lwnhb0Z=ujcHokNGCWM9vQ@mail.gmail.com>
 <562FC7F0.2050800@raptorengineeringinc.com>
 <CAP6exYLT8skFSOjq_zroCg1ZJp_bcM2CuBSm92MqpA8DYCJUMw@mail.gmail.com>
 <CAKOoyUfVrWsOugZvAhYsAz1izrZKw5vLiXTPDu=tCpfLa7oPHg@mail.gmail.com>
 <CAE2855vq+SSoQZX2nZMQQyDqBEY8_K5Wize7m8pKim9jDr3=xQ@mail.gmail.com>
 <CALnsgKz6xFMG7g2i+0EswwDrzbzW07Cm1OSOoXFRDyRNaz-zJA@mail.gmail.com>
 <562FDB4D.8040907@raptorengineeringinc.com>
 <CALnsgKx28eSXYUxth+whjMhH1V+9FSacvd9Hc7X9eMgmmZeAoA@mail.gmail.com>
 <56304765.7060509@gmail.com>
 <CAE-gjdU-uDoqwp59no=gaqyv2KVp5Pnd8oYRNxvKwAxvNsd0eQ@mail.gmail.com>
 <20151028140008.27188.qmail@stuge.se> <5630ED29.2080501@gmail.com>
Message-ID: <1446112373.5722.36.camel@redhat.com>

On Mi, 2015-10-28 at 08:43 -0700, Alex G. wrote:
> 
> On 10/28/2015 07:00 AM, Peter Stuge wrote:
> > Patrick Georgi wrote:
> >> branches are where commits are pushed to die.
> > 
> > Yes, this is a very important point, and is why I don't support Alex'
> > proposal of moving some things to live only on a branch, and not on master.
> 
> So, tagging and removing is better than a branch where people can
> continue to work, and submit patches via coreboot.org?

Typically branches are used for two purposes:

(1) stable releases.  Tag v4.2, branch off, possibly tag v4.2.1 bugfix
    Typically no development happens here, often projects even have the
    policy that fixes need to land in master before they are allowed to
    be cherry-picked into a stable branch.

(2) development branches.  New stuff, intended to be merged in master.

Have a branch to park unliked code there is just a bad excuse IMO.
Don't do that.

If there is dead code, i.e. boards not being sold any more and not
having seen updates (other than tree-wide cleanups) for years -- just
remove them, and document the last release supporting that hardware.

For AGESA I don't think it should be removed.  Even if the plan is to
obsolete the code some day with native support in codeboot -- I think
for the time being it is useful for developers to be able to look at the
code, to be able to build agesa/native versions of a board from the same
coreboot code base, for regression testing and bringing native on par
with agesa ...

cheers,
  Gerd




From tpearson at raptorengineeringinc.com  Thu Oct 29 15:23:45 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Thu, 29 Oct 2015 09:23:45 -0500
Subject: [coreboot] Calling all AMD K8 Opteron users!
Message-ID: <56322BF1.5070406@raptorengineeringinc.com>

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

All,

I am currently attempting to add a dual-package, dual core Socket F K8
Opteron system to the REACTS automated test system, however it appears
that sometime around June / July this year the second CPU package on
such systems stopped working.  What I see is a hang in ramstage (not
romstage) when initializing CPU #3; the hang occurs on the first call to
disable_cache() in model_fxx_init().

I have already spent quite a bit of time fixing up portions of the K8
code and am quickly losing motivation to debug this particular issue on
these thoroughly obsolete CPUs.  The current fallback plan is to enable
single-package testing, however this will effectively allow the
dual-package bitrot to fester and/or grow much worse as the codebase
continues to churn.

Would anyone who has access to an appropriate K8-based Socket F Opteron
machine be willing to run a bisect to see exactly where this hang was
introduced?  My last attempt (which failed) was based on GIT hash
df5446196cd81c4a714f45f92fb379c795c1edb5, so I assume the fault was
introduced in an earlier commit.

Thank you!

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

iQEcBAEBAgAGBQJWMivtAAoJEK+E3vEXDOFbHwsH/1aWI2/aX0V1q9RcJumc5KXn
vRh/Hx6PPemXvWVY2GB8+tq7XJVWDPbNTqNvu2i7Qqxc449rGzJBpsCH2tyxVEqj
pa/m0Mxt221Qn6vc3FjzbTeKGG5K/zWY53JidaN77mAzNicdj8UIO5qYwwLB/+HM
2GiKcqB1rVbso5u4NdgZd6eKRNb7TWnMWkplv6Hn1ZJvMGup4FjCXk/jt2+MOGos
iWClwOvivSIyI6Lbb9zBjZDPz7u0a5DEMctqkTIIle9efPVVuSClJVlj5mOOMx8k
uh/OqSOYkTdXswocBigHoNPvsX4pVG5cs1YnlEoXCz3I57poHCvjTgdTrseSgCs=
=KdWK
-----END PGP SIGNATURE-----


From marcj303 at gmail.com  Thu Oct 29 17:48:37 2015
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 29 Oct 2015 16:48:37 +0000
Subject: [coreboot] coreboot binary policy
Message-ID: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>

Hello coreboot,

As presented and discussed in Bonn, the binary policy is up for review.
http://review.coreboot.org/#/c/12198/

Please limit comments to specific items in this version. If you have
additions for the next version (if needed), the draft document is open for
comment.

https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTCrOwU/edit?usp=sharing

Regards,
Marc



-- 
http://marcjonesconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151029/001402af/attachment.html>

From gaumless at gmail.com  Thu Oct 29 19:55:44 2015
From: gaumless at gmail.com (Martin Roth)
Date: Thu, 29 Oct 2015 12:55:44 -0600
Subject: [coreboot] Document for review: coreboot Gerrit Etiquette and
	Guidelines
Message-ID: <CA+e+Ov5X3WZq-V=jNs86CrhPt2hUsf8W_mLCduWw8-TadXbNxA@mail.gmail.com>

As the community has grown, so has the need to formalize some of the
guidelines that the community lives by. When the community was small,
it was easy to communicate these things just from one person to
another.

Now, with more people joining the community every day, it seems that
it's time to write some of these things down, allowing people to
understand our policies immediately instead of making them learn our
practices as they make mistakes.

As it says in the document: The following rules are the requirements
for behavior in the coreboot codebase in gerrit. These have mainly
been unwritten rules up to this point, and should be familiar to most
users who have been active in coreboot for a period of time. Following
these rules will help reduce friction in the community.

This has been posted to gerrit for review:
http://review.coreboot.org/#/c/12256/

Please post your thoughts and comments either as a reply to this email
or in gerrit.

Thanks.
Martin



coreboot Gerrit Etiquette and Guidelines
========================================

The following rules are the requirements for behavior in the coreboot
codebase in gerrit. These have mainly been unwritten rules up to this
point, and should be familiar to most users who have been active in
coreboot for a period of time. Following these rules will help reduce
friction in the community.


Summary:
--------
These are the expectations for committing, reviewing, and submitting
code into coreboot git and gerrit. While breaking individual rules may
not have immediate consequences, the coreboot leadership may act on
repeated or flagrant violations with or without notice.

* Don't violate the licenses.
* Let non-trivial patches sit in a review state for at least 24 hours
before submission.
* Try to coordinate with platform maintainers when making changes to platforms.
* If you give a patch a -2, you are responsible for giving concrete
recommendations for what could be changed to resolve the issue the
patch addresses.
* Don't modify other people's patches without their consent.
* Be respectful to others when commenting.
* Each patch should be kept to one logical change.
* Don?t submit patches that you know will break other platforms.


More detail:
------------
* Don't violate the licenses. If you're submitting code that you
didn't write yourself, make sure the license is compatible with the
license of the project you're submitting the changes to. If you?re
submitting code that you wrote that might be owned by your employer,
make sure that your employer is aware and you are authorized to submit
the code. See the Developer's Certificate of Origin in the
Signed-off-by policy.
* Let non-trivial patches sit in a review state for at least 24 hours
before submission. Remember that coreboot developers are in timezones
all over the world, and everyone should have a chance to contribute.
Trivial patches would be things like whitespace changes or spelling
fixes. In general, small changes that don?t impact the final binary
output.
* Do not +2 patches that you authored or own, even for something as
trivial as whitespace fixes. When working on your own patches, it?s
easy to overlook something like accidentally updating file permissions
or git submodule commit IDs. Let someone else review the patch.
* Try to coordinate with platform maintainers when making changes to
platforms. The platform maintainers are the users who initially pushed
the code for that platform, as well as users who have made significant
changes to a platform. To find out who maintains a piece of code,
please use util/scripts/maintainers.go or refer to the original author
of the code in git log.
* If you give a patch a -2, you are responsible for giving concrete
recommendations for what could be changed to resolve the issue the
patch addresses. If you feel strongly that a patch should NEVER be
merged, you are responsible for defending your position and listening
to other points of view. Giving a -2 and walking away is not
acceptable, and may cause your -2 to be removed by the coreboot
leadership after a period of time.
* Don't modify other people's patches unless you are specifically
requested to do so by the owner of that patch. Not only is this
considered rude, but your changes could be lost unintentionally when
the owner pushes an update without realizing that you?ve changed
something.
* Be respectful to others when commenting on their patch. Comments
should be kept to the code, and should be kept in a polite tone. If
you feel attacked, resist the urge to attack back - this only
escalates the issue.
* Each patch should be kept to one logical change, which should be
described in the title of the patch. Unrelated changes should be split
out into separate patches. Fixing whitespace on a line you?re editing
is reasonable. Fixing whitespace around the code you?re working on
should be a separate ?cleanup? patch. Larger patches that touch
several areas are fine, so long as they are one logical change. Adding
new chips and doing code cleanup over wide areas are two examples of
this.
* Don?t submit code that you know will break other platforms. If your
patch affects code that is used by other platforms, it should be
compatible with those platforms. While it would be nice to update any
other platforms, you must at least provide a path that will allow
other platforms to continue working.


Recommendations for gerrit activity:
------------------------------------
These guidelines are less strict than the ones listed above. These are
more of the ?good idea? variety. You are requested to follow the below
guidelines, but there will probably be no actual consequences if
they?re not followed. That said, following the recommendations below
will speed up review of your patches, and make the members of the
community do less work.

* Test your patches before submitting them to gerrit. It's also
appreciated if you add a line to the commit message describing how the
patch was tested. This prevents people from having to ask whether and
how the patch was tested.  An example of this sort of comment would be
?TEST=Built platform? or ?TEST=Built and booted platform?
* Take advantage of the lint tools to make sure your patches don?t
contain trivial mistakes. By running ?make gitconfig?, the lint-stable
tools are automatically put in place and will test your patches before
they are committed. As a violation of these tools will cause the
jenkins build test to fail, it?s to your advantage to test this before
pushing to gerrit.
* Don't submit patch trains longer than around 20 patches. Long patch
trains become unmanageable and tie up the build servers for long
periods of time. Rebasing a patch train over and over as you fix
earlier patches in the train can hide comments, and make people review
the code multiple times to see if anything has changed between
revisions.
* Run 'make what-jenkins-does' locally on patch trains before
submitting. This helps verify that the patch train won?t tie up the
jenkins builders for no reason if there are failing patches in the
train.
* Use a topic when pushing a train of patches. This groups the commits
together so people can easily see the connection at the top level of
gerrit. Topics can be set for individual patches in gerrit by going
into the patch and clicking on the icon next to the topic line. Topics
can also be set when you push the patches into gerrit. For example, to
push a set of commits with the the i915-kernel-x60 set, use the
command:
        git push origin HEAD:refs/for/master/i915-kernel-x60
* If one of your patches isn't ready to be merged, make sure it's
obvious that you don't feel it's ready for merge yet. This can be
something like giving it a -1 or -2, or marking in the commit message
that it?s not ready until X. The commit message can be updated easily
when it?s ready to be pushed.  Examples of this are "WIP: title" or
"[NEEDS_TEST]: title".  These can also be pushed as drafts as shown in
the next guideline.
* When pushing patches that are not for submission, these should be
marked as such. This can be done in the title ?[DONOTSUBMIT]?, or can
be pushed as draft commits, so that only explicitly added reviewers
will see them. These sorts of patches are frequently posted as ideas
or RFCs for the community to look at. To push a draft, use the
command:
        git push origin HEAD:refs/drafts/master
* Respond to anyone who has taken the time to review your patches,
even if it's just to say that you disagree. While it may seem annoying
to address a request to fix spelling or 'trivial' issues, it?s
generally easy to handle in gerrit?s built in editor.  It's also
acceptable to add fixes for these sorts of comments to another patch,
but it's recommended that that patch be pushed to gerrit before the
initial patch gets submitted.
* Consider breaking up large individual patches into smaller patches
grouped by areas. This makes the patches easier to review, but
increases the number of patches. The way you want to handle this is a
personal decision, as long as each patch is still one logical change.
* If you have an interest in a particular area or mainboard, set
yourself up as a ?maintainer? of that area by adding yourself to the
MAINTAINERS file in the coreboot root directory. Eventually, this
should automatically add you as a reviewer when an area that you?re
listed as a maintainer is changed.
* Submit mainboards that you?re working on to the board-status repo.
This helps others and shows that these mainboards are currently being
maintained.  At some point, boards that are not up to date in the
board-status repo will probably end up getting deleted from the
coreboot tree.
* Abandon patches that are no longer useful, or that you don?t intend
to keep working on.
* Bring attention to patches that you would like reviewed. Add
reviewers, or even just rebase it against the current codebase to
bring it to the top of the gerrit list. If you?re not sure who would
be a good reviewer, look in the MAINTAINERS file or git history of the
files that you?ve changed, and add those people.
* Familiarize yourself with the commit message guidelines, and try to
follow them. This will help to keep annoying requests to fix your
commit message to a minimum.
* If there have been comments or discussion on a patch, verify that
the comments have been addressed before giving a +2. If you feel that
a comment is invalid, please respond to that comment instead of just
ignoring it.
* Be conscientious when reviewing patches. If you give a patch a +2
and it breaks things, you should feel as responsible as the owner of
the patch for fixing things, and could be called on by the community
to help fix any fallout of the patch. This means you shouldn?t +2 a
patch just because you trust the author of a patch - Make sure you
understand what the implications of a patch might be, or leave the
review to others. Partial reviews, reviewing code style, for example,
can be given a +1 instead of a +2. This also applies if you think the
patch looks good, but may not have the experience to know if there may
be unintended consequences.
* If there is still ongoing discussion to a patch, try to wait for a
conclusion to the discussion before submitting it to the tree. If you
feel that someone is beating a dead horse, maybe just state that and
give a time that the patch will be submitted. If no new objections
have come up instead of submitting the patch immediately and ending
the discussion by force.
* When working with patch trains, for minor requests it?s acceptable
to create a fix addressing a comment in another patch at the end of
the patch train. This minimizes rebases of the patch train while still
addressing the request. For major problems where the change doesn?t
work as intended or breaks other platforms, the change really needs to
go into the original patch.


Expectations contributors should have:
--------------------------------------
* Don't expect that people will review your patch unless you ask them
to. Adding other people as reviewers is the easiest way. Asking for
reviews for individual patches in the IRC channel, or by sending a
direct request to an individual through your favorite messenger is
usually the best way to get a patch reviewed quickly.
* Don't expect that your patch will be submitted immediately after
getting a +2. As stated previously, non-trivial patches should wait at
least 24 hours before being submitted. That said, if you feel that
your patch or series of patches has been sitting longer than needed,
you can ask for it to be submitted on IRC, or comment that it's ready
for submission in the patch. This will move it to the top of the list
where it's more likely to be noticed and acted upon.
* Reviews are about the code. It's easy to take it personally when
someone is criticising your code, but the whole idea is to get better
code into our codebase. Again, this also applies in the other
direction: review code, criticize code, but don?t make it personal.


Requests for clarification and suggestions for updates to these
guidelines should be sent to the coreboot mailing list at
<coreboot at coreboot.org>.


From kyosti.malkki at gmail.com  Fri Oct 30 00:23:50 2015
From: kyosti.malkki at gmail.com (=?UTF-8?B?S3nDtnN0aSBNw6Rsa2tp?=)
Date: Fri, 30 Oct 2015 01:23:50 +0200
Subject: [coreboot] Asus M2N-E no boot, post codes A5 80 73
In-Reply-To: <CAO=iczHZG_fA4-T15TyiJHtV-XRZh_26hfdR+DKo=3CSDJsB3w@mail.gmail.com>
References: <CAO=iczHZG_fA4-T15TyiJHtV-XRZh_26hfdR+DKo=3CSDJsB3w@mail.gmail.com>
Message-ID: <CA+kFwFDzAFZOr9qASBRB2NPC6Wde8KqUZP=dPvy7c8=U=2veUQ@mail.gmail.com>

On Thu, Oct 22, 2015 at 5:59 PM, Bal?zs Vinarz <vinibali1 at gmail.com> wrote:

> Hi.
> I compiled from the source about 6 months and now. The mobo is still
> unable to boot.
> Serial debugs are attached, i tried with many memory-modules in all
> sockets.
> There are two options, when the postcard jumps between codes A5 and 80:
>
>
<clip>


>
>
PCI: 00:18.0 assign_resources, bus 0 link: 0
> PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] size 0x04000000 g#?
>
> #END
>
>
Not sure if this is related, but it stops when writing AGP aperture
resource.

Can you add some more POST codes or debugging in
northbridge/amd/amdk8/misc_control.c: set_agp_aperture() ?

You could try "iommu=0" on line 52 to disable this resource, to see if you
get any further.

As for the board, it may have not been tested for several years now. Try to
go further back in history, like build from 2012. Wiki notes tell
multi-processor was never tested.

Regards,
Ky?sti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151030/60b15b50/attachment.html>

From mr.nuke.me at gmail.com  Fri Oct 30 05:04:03 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Thu, 29 Oct 2015 21:04:03 -0700
Subject: [coreboot] Document for review: coreboot Gerrit Etiquette and
 Guidelines
In-Reply-To: <CA+e+Ov5X3WZq-V=jNs86CrhPt2hUsf8W_mLCduWw8-TadXbNxA@mail.gmail.com>
References: <CA+e+Ov5X3WZq-V=jNs86CrhPt2hUsf8W_mLCduWw8-TadXbNxA@mail.gmail.com>
Message-ID: <5632EC33.7020200@gmail.com>

Hi Martin,

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

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

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

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

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

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

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

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

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

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

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

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

Alex

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

On 10/29/2015 11:55 AM, Martin Roth wrote:
> As the community has grown, so has the need to formalize some of the
> guidelines that the community lives by. When the community was small,
> it was easy to communicate these things just from one person to
> another.
> 
> Now, with more people joining the community every day, it seems that
> it's time to write some of these things down, allowing people to
> understand our policies immediately instead of making them learn our
> practices as they make mistakes.
> 
> As it says in the document: The following rules are the requirements
> for behavior in the coreboot codebase in gerrit. These have mainly
> been unwritten rules up to this point, and should be familiar to most
> users who have been active in coreboot for a period of time. Following
> these rules will help reduce friction in the community.
> 
> This has been posted to gerrit for review:
> http://review.coreboot.org/#/c/12256/
> 
> Please post your thoughts and comments either as a reply to this email
> or in gerrit.
> 
> Thanks.
> Martin
> 
> 
> 
> coreboot Gerrit Etiquette and Guidelines
> ========================================
> 
> The following rules are the requirements for behavior in the coreboot
> codebase in gerrit. These have mainly been unwritten rules up to this
> point, and should be familiar to most users who have been active in
> coreboot for a period of time. Following these rules will help reduce
> friction in the community.
> 
> 
> Summary:
> --------
> These are the expectations for committing, reviewing, and submitting
> code into coreboot git and gerrit. While breaking individual rules may
> not have immediate consequences, the coreboot leadership may act on
> repeated or flagrant violations with or without notice.
> 
> * Don't violate the licenses.
> * Let non-trivial patches sit in a review state for at least 24 hours
> before submission.
> * Try to coordinate with platform maintainers when making changes to platforms.
> * If you give a patch a -2, you are responsible for giving concrete
> recommendations for what could be changed to resolve the issue the
> patch addresses.
> * Don't modify other people's patches without their consent.
> * Be respectful to others when commenting.
> * Each patch should be kept to one logical change.
> * Don?t submit patches that you know will break other platforms.
> 
> 
> More detail:
> ------------
> * Don't violate the licenses. If you're submitting code that you
> didn't write yourself, make sure the license is compatible with the
> license of the project you're submitting the changes to. If you?re
> submitting code that you wrote that might be owned by your employer,
> make sure that your employer is aware and you are authorized to submit
> the code. See the Developer's Certificate of Origin in the
> Signed-off-by policy.
> * Let non-trivial patches sit in a review state for at least 24 hours
> before submission. Remember that coreboot developers are in timezones
> all over the world, and everyone should have a chance to contribute.
> Trivial patches would be things like whitespace changes or spelling
> fixes. In general, small changes that don?t impact the final binary
> output.
> * Do not +2 patches that you authored or own, even for something as
> trivial as whitespace fixes. When working on your own patches, it?s
> easy to overlook something like accidentally updating file permissions
> or git submodule commit IDs. Let someone else review the patch.
> * Try to coordinate with platform maintainers when making changes to
> platforms. The platform maintainers are the users who initially pushed
> the code for that platform, as well as users who have made significant
> changes to a platform. To find out who maintains a piece of code,
> please use util/scripts/maintainers.go or refer to the original author
> of the code in git log.
> * If you give a patch a -2, you are responsible for giving concrete
> recommendations for what could be changed to resolve the issue the
> patch addresses. If you feel strongly that a patch should NEVER be
> merged, you are responsible for defending your position and listening
> to other points of view. Giving a -2 and walking away is not
> acceptable, and may cause your -2 to be removed by the coreboot
> leadership after a period of time.
> * Don't modify other people's patches unless you are specifically
> requested to do so by the owner of that patch. Not only is this
> considered rude, but your changes could be lost unintentionally when
> the owner pushes an update without realizing that you?ve changed
> something.
> * Be respectful to others when commenting on their patch. Comments
> should be kept to the code, and should be kept in a polite tone. If
> you feel attacked, resist the urge to attack back - this only
> escalates the issue.
> * Each patch should be kept to one logical change, which should be
> described in the title of the patch. Unrelated changes should be split
> out into separate patches. Fixing whitespace on a line you?re editing
> is reasonable. Fixing whitespace around the code you?re working on
> should be a separate ?cleanup? patch. Larger patches that touch
> several areas are fine, so long as they are one logical change. Adding
> new chips and doing code cleanup over wide areas are two examples of
> this.
> * Don?t submit code that you know will break other platforms. If your
> patch affects code that is used by other platforms, it should be
> compatible with those platforms. While it would be nice to update any
> other platforms, you must at least provide a path that will allow
> other platforms to continue working.
> 
> 
> Recommendations for gerrit activity:
> ------------------------------------
> These guidelines are less strict than the ones listed above. These are
> more of the ?good idea? variety. You are requested to follow the below
> guidelines, but there will probably be no actual consequences if
> they?re not followed. That said, following the recommendations below
> will speed up review of your patches, and make the members of the
> community do less work.
> 
> * Test your patches before submitting them to gerrit. It's also
> appreciated if you add a line to the commit message describing how the
> patch was tested. This prevents people from having to ask whether and
> how the patch was tested.  An example of this sort of comment would be
> ?TEST=Built platform? or ?TEST=Built and booted platform?
> * Take advantage of the lint tools to make sure your patches don?t
> contain trivial mistakes. By running ?make gitconfig?, the lint-stable
> tools are automatically put in place and will test your patches before
> they are committed. As a violation of these tools will cause the
> jenkins build test to fail, it?s to your advantage to test this before
> pushing to gerrit.
> * Don't submit patch trains longer than around 20 patches. Long patch
> trains become unmanageable and tie up the build servers for long
> periods of time. Rebasing a patch train over and over as you fix
> earlier patches in the train can hide comments, and make people review
> the code multiple times to see if anything has changed between
> revisions.
> * Run 'make what-jenkins-does' locally on patch trains before
> submitting. This helps verify that the patch train won?t tie up the
> jenkins builders for no reason if there are failing patches in the
> train.
> * Use a topic when pushing a train of patches. This groups the commits
> together so people can easily see the connection at the top level of
> gerrit. Topics can be set for individual patches in gerrit by going
> into the patch and clicking on the icon next to the topic line. Topics
> can also be set when you push the patches into gerrit. For example, to
> push a set of commits with the the i915-kernel-x60 set, use the
> command:
>         git push origin HEAD:refs/for/master/i915-kernel-x60
> * If one of your patches isn't ready to be merged, make sure it's
> obvious that you don't feel it's ready for merge yet. This can be
> something like giving it a -1 or -2, or marking in the commit message
> that it?s not ready until X. The commit message can be updated easily
> when it?s ready to be pushed.  Examples of this are "WIP: title" or
> "[NEEDS_TEST]: title".  These can also be pushed as drafts as shown in
> the next guideline.
> * When pushing patches that are not for submission, these should be
> marked as such. This can be done in the title ?[DONOTSUBMIT]?, or can
> be pushed as draft commits, so that only explicitly added reviewers
> will see them. These sorts of patches are frequently posted as ideas
> or RFCs for the community to look at. To push a draft, use the
> command:
>         git push origin HEAD:refs/drafts/master
> * Respond to anyone who has taken the time to review your patches,
> even if it's just to say that you disagree. While it may seem annoying
> to address a request to fix spelling or 'trivial' issues, it?s
> generally easy to handle in gerrit?s built in editor.  It's also
> acceptable to add fixes for these sorts of comments to another patch,
> but it's recommended that that patch be pushed to gerrit before the
> initial patch gets submitted.
> * Consider breaking up large individual patches into smaller patches
> grouped by areas. This makes the patches easier to review, but
> increases the number of patches. The way you want to handle this is a
> personal decision, as long as each patch is still one logical change.
> * If you have an interest in a particular area or mainboard, set
> yourself up as a ?maintainer? of that area by adding yourself to the
> MAINTAINERS file in the coreboot root directory. Eventually, this
> should automatically add you as a reviewer when an area that you?re
> listed as a maintainer is changed.
> * Submit mainboards that you?re working on to the board-status repo.
> This helps others and shows that these mainboards are currently being
> maintained.  At some point, boards that are not up to date in the
> board-status repo will probably end up getting deleted from the
> coreboot tree.
> * Abandon patches that are no longer useful, or that you don?t intend
> to keep working on.
> * Bring attention to patches that you would like reviewed. Add
> reviewers, or even just rebase it against the current codebase to
> bring it to the top of the gerrit list. If you?re not sure who would
> be a good reviewer, look in the MAINTAINERS file or git history of the
> files that you?ve changed, and add those people.
> * Familiarize yourself with the commit message guidelines, and try to
> follow them. This will help to keep annoying requests to fix your
> commit message to a minimum.
> * If there have been comments or discussion on a patch, verify that
> the comments have been addressed before giving a +2. If you feel that
> a comment is invalid, please respond to that comment instead of just
> ignoring it.
> * Be conscientious when reviewing patches. If you give a patch a +2
> and it breaks things, you should feel as responsible as the owner of
> the patch for fixing things, and could be called on by the community
> to help fix any fallout of the patch. This means you shouldn?t +2 a
> patch just because you trust the author of a patch - Make sure you
> understand what the implications of a patch might be, or leave the
> review to others. Partial reviews, reviewing code style, for example,
> can be given a +1 instead of a +2. This also applies if you think the
> patch looks good, but may not have the experience to know if there may
> be unintended consequences.
> * If there is still ongoing discussion to a patch, try to wait for a
> conclusion to the discussion before submitting it to the tree. If you
> feel that someone is beating a dead horse, maybe just state that and
> give a time that the patch will be submitted. If no new objections
> have come up instead of submitting the patch immediately and ending
> the discussion by force.
> * When working with patch trains, for minor requests it?s acceptable
> to create a fix addressing a comment in another patch at the end of
> the patch train. This minimizes rebases of the patch train while still
> addressing the request. For major problems where the change doesn?t
> work as intended or breaks other platforms, the change really needs to
> go into the original patch.
> 
> 
> Expectations contributors should have:
> --------------------------------------
> * Don't expect that people will review your patch unless you ask them
> to. Adding other people as reviewers is the easiest way. Asking for
> reviews for individual patches in the IRC channel, or by sending a
> direct request to an individual through your favorite messenger is
> usually the best way to get a patch reviewed quickly.
> * Don't expect that your patch will be submitted immediately after
> getting a +2. As stated previously, non-trivial patches should wait at
> least 24 hours before being submitted. That said, if you feel that
> your patch or series of patches has been sitting longer than needed,
> you can ask for it to be submitted on IRC, or comment that it's ready
> for submission in the patch. This will move it to the top of the list
> where it's more likely to be noticed and acted upon.
> * Reviews are about the code. It's easy to take it personally when
> someone is criticising your code, but the whole idea is to get better
> code into our codebase. Again, this also applies in the other
> direction: review code, criticize code, but don?t make it personal.
> 
> 
> Requests for clarification and suggestions for updates to these
> guidelines should be sent to the coreboot mailing list at
> <coreboot at coreboot.org>.
> 


From rminnich at gmail.com  Fri Oct 30 05:28:22 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 30 Oct 2015 04:28:22 +0000
Subject: [coreboot] Document for review: coreboot Gerrit Etiquette and
	Guidelines
In-Reply-To: <5632EC33.7020200@gmail.com>
References: <CA+e+Ov5X3WZq-V=jNs86CrhPt2hUsf8W_mLCduWw8-TadXbNxA@mail.gmail.com>
 <5632EC33.7020200@gmail.com>
Message-ID: <CAP6exYLKrXp-6xXNJkiSjE05H11w3mLhAU-b=6iSvrEc8tf5tg@mail.gmail.com>

On Thu, Oct 29, 2015 at 9:04 PM Alex G. <mr.nuke.me at gmail.com> wrote:

> Hi Martin,
>
> It seems that the first part of your document ("Summary", and "More
> detail") is written in direct response to the removal of FSP 1.0 a month
> or so ago.


It might seem that way to you, having been at the eye of that particular
storm. It is not the case, however.


> I don't think that's acceptable. This needs more work.
>
>
>
It's a CL. It would be very helpful if you want to propose specific changes.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151030/0335740c/attachment.html>

From mr.nuke.me at gmail.com  Fri Oct 30 05:47:05 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Thu, 29 Oct 2015 21:47:05 -0700
Subject: [coreboot] Document for review: coreboot Gerrit Etiquette and
 Guidelines
In-Reply-To: <CAP6exYLKrXp-6xXNJkiSjE05H11w3mLhAU-b=6iSvrEc8tf5tg@mail.gmail.com>
References: <CA+e+Ov5X3WZq-V=jNs86CrhPt2hUsf8W_mLCduWw8-TadXbNxA@mail.gmail.com>
 <5632EC33.7020200@gmail.com>
 <CAP6exYLKrXp-6xXNJkiSjE05H11w3mLhAU-b=6iSvrEc8tf5tg@mail.gmail.com>
Message-ID: <5632F649.9070402@gmail.com>

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

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

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

I did. Refresh the page :)

Alex


From rminnich at gmail.com  Fri Oct 30 06:13:15 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 30 Oct 2015 05:13:15 +0000
Subject: [coreboot] Document for review: coreboot Gerrit Etiquette and
	Guidelines
In-Reply-To: <5632F649.9070402@gmail.com>
References: <CA+e+Ov5X3WZq-V=jNs86CrhPt2hUsf8W_mLCduWw8-TadXbNxA@mail.gmail.com>
 <5632EC33.7020200@gmail.com>
 <CAP6exYLKrXp-6xXNJkiSjE05H11w3mLhAU-b=6iSvrEc8tf5tg@mail.gmail.com>
 <5632F649.9070402@gmail.com>
Message-ID: <CAP6exYKe02Hy-5uakK6FZH2cmh-3UT5Yq=SrMhL4pbzUkzz3EQ@mail.gmail.com>

On Thu, Oct 29, 2015 at 9:49 PM Alex G. <mr.nuke.me at gmail.com> wrote:

> My bad.
>
>
>
Apology accepted.

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

From mr.nuke.me at gmail.com  Fri Oct 30 16:44:15 2015
From: mr.nuke.me at gmail.com (Alex G.)
Date: Fri, 30 Oct 2015 08:44:15 -0700
Subject: [coreboot] coreboot binary policy
In-Reply-To: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>
References: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>
Message-ID: <5633904F.3010001@gmail.com>

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

Hi Marc

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

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

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

Alex


From tpearson at raptorengineeringinc.com  Fri Oct 30 17:03:07 2015
From: tpearson at raptorengineeringinc.com (Timothy Pearson)
Date: Fri, 30 Oct 2015 11:03:07 -0500
Subject: [coreboot] coreboot binary policy
In-Reply-To: <5633904F.3010001@gmail.com>
References: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>
 <5633904F.3010001@gmail.com>
Message-ID: <563394BB.3090305@raptorengineeringinc.com>

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

On 10/30/2015 10:44 AM, Alex G. wrote:
> On 10/29/2015 09:48 AM, Marc Jones wrote:
>> Hello coreboot,
> 
> Hi Marc
> 
>> Please limit comments to specific items in this version. If you have
>> additions for the next version (if needed), the draft document is open
>> for comment.
>>
>> https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTCrOwU/edit?usp=sharing
> 
> That looks pretty good. I think you've done a great job of clarifying
> the requirements of ISA vs non-ISA blobs compared to the last version.
> I've made some comments on it to ask for clarification about the
> versioning requirements.
> 
> While not necessarily specific to this version, are we still considering
> forbidding "no-reverse engineering" and "no-modification" clauses for blobs?
> 
> Alex
> 

No modification will be enforced by the hardware very quickly for
critical blobs (it already is on x86); additionally, certain countries
like the United States expressly prohibit modification of copyrighted
software.

The reverse engineering case is also fairly murky in the United States
at least; while prohibiting a "no-reverse engineering" clause is a good
start theoretically, I don't know if it will actually gain the project
anything in reality due to existing law and case precedent.

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

iQEcBAEBAgAGBQJWM5SzAAoJEK+E3vEXDOFbQYQIAJ7doLqNmG1aVDNLwQRyX92U
uNa3Hp++AgA3gUuHU77K+zOFTms7bbSRl9fs0Wb4crABK3B7AKkLJF6kgmgHNdkU
6edxW/bR8pkV+DkFQ7X4DtkwU+13N/agFLXT0lmChGor5fEYDNSY2I0CG8YTPyXr
/5XuyKnPqyqaHM/fzhONaR9yCmn4ftk2mdm+YJPe+veTG/eWrtllFrx501ql1KFg
ECwKTU03EYnc+2qGJF+9zm7inSTEuTOZzLE0MFD/gtfitkcf4MW7WNVYh8YqU/OK
Xq6TalKBL5vywoOW1FIKICvYHoWZAApnLZ9p+jmTRM7a0IZwijfeE/iNVzbkvp4=
=JalF
-----END PGP SIGNATURE-----


From marcj303 at gmail.com  Fri Oct 30 17:03:53 2015
From: marcj303 at gmail.com (Marc Jones)
Date: Fri, 30 Oct 2015 16:03:53 +0000
Subject: [coreboot] coreboot binary policy
In-Reply-To: <5633904F.3010001@gmail.com>
References: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>
 <5633904F.3010001@gmail.com>
Message-ID: <CALrs_3gS4zzY11qV8EJ_h+8CuyG_RcHs5RiLPdvH35LzBtkT6A@mail.gmail.com>

On Fri, Oct 30, 2015 at 9:44 AM Alex G. <mr.nuke.me at gmail.com> wrote:

> On 10/29/2015 09:48 AM, Marc Jones wrote:
> > Hello coreboot,
>
> Hi Marc
>
> > Please limit comments to specific items in this version. If you have
> > additions for the next version (if needed), the draft document is open
> > for comment.
> >
> >
> https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTCrOwU/edit?usp=sharing
>
> That looks pretty good. I think you've done a great job of clarifying
> the requirements of ISA vs non-ISA blobs compared to the last version.
> I've made some comments on it to ask for clarification about the
> versioning requirements.
>
> While not necessarily specific to this version, are we still considering
> forbidding "no-reverse engineering" and "no-modification" clauses for
> blobs?
>
>
Thanks, I think it is all open for discussion and could go in the next
version. It might be a good idea, but that might be too limiting and we
would have to remove all blobs and they would be hosted somewhere else,
which defeates the utility of the blobs dir. We would like intel to push to
blobs/ but I think that would be a huge blocker for them.

Marc


> Alex
>
-- 
http://marcjonesconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151030/c158204e/attachment.html>

From gardner.ben at gmail.com  Fri Oct 30 17:19:24 2015
From: gardner.ben at gmail.com (Ben Gardner)
Date: Fri, 30 Oct 2015 11:19:24 -0500
Subject: [coreboot] PAT memory type issues and cbmem
Message-ID: <CAE7DoPYcCwDjMXyxw724tMPeT3zMy-hcpoUBZk6kAY6XFOtbGw@mail.gmail.com>

cbmem attempts to map 1 MB of memory to read the CB tables.
This is failing on my board due to the PAT configuration under Linux.
If I boot Linux with "nopat", the issue goes away.

I am using the upstream coreboot and SeaBIOS with a custom board based
on the bayleybay_fsp/fsp_baytrail and Linux 4.2.

~ # ./cbmem -V -l
Looking for coreboot table at 0 1048576 bytes.
Mapping 1MB of physical memory at 0x0 (requested 0x0).
Found!
  coreboot table entry 0x11
    Found forwarding entry.
Unmapping 1MB of virtual memory at 0x7fee18224000.
Looking for coreboot table at 7ad9f000 1048576 bytes.
Mapping 1MB of physical memory at 0x7ad9f000 (requested 0x7ad9f000).
  ... failed.  Mapping 1052671B of physical memory at 0x7ad9e000.
Failed to mmap /dev/mem: Resource temporarily unavailable
~ # dmesg | tail -n 4
[  221.700621] x86/PAT: cbmem.orig:1058 conflicting memory types
7ad9f000-7ae9f000 uncached-minus<->write-back 7adb8000-7adbc000
[  221.705419] x86/PAT: reserve_memtype failed [mem
0x7ad9f000-0x7ae9efff], track write-back, req write-back
[  221.710435] x86/PAT: cbmem.orig:1058 conflicting memory types
7ad9e000-7ae9f000 uncached-minus<->write-back 7adb8000-7adbc000
[  221.715501] x86/PAT: reserve_memtype failed [mem
0x7ad9e000-0x7ae9efff], track write-back, req write-back
~ # cat /sys/kernel/debug/x86/pat_memtype_list
PAT memtype list:
uncached-minus @ 0x7ada7000-0x7ada8000
write-back @ 0x7adb8000-0x7adbc000
write-back @ 0x7adbb000-0x7adbd000
write-back @ 0x7addd000-0x7adde000
uncached-minus @ 0x80600000-0x80601000
uncached-minus @ 0x80601000-0x80602000
uncached-minus @ 0x80602000-0x80603000
write-combining @ 0xc0000000-0xd0000000
... snip ...

>From the Linux kernel log:
 MTRR variable ranges enabled:
   0 base 0FF800000 mask FFF800000 write-protect
   1 base 000000000 mask F80000000 write-back
   2 base 07B000000 mask FFF000000 uncachable
   3 base 07C000000 mask FFC000000 uncachable

I'm not sure how to read MTRR ranges, but it looks like the cbtable
falls in the MTRR 1 with type write-back.

>From the SeaBIOS log:
e820 map has 15 items:
  0: 0000000000000000 - 000000000009fc00 = 1 RAM
  1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
  3: 0000000000100000 - 000000007ad8e000 = 1 RAM
  4: 000000007ad8e000 - 0000000080000000 = 2 RESERVED
  5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED
... snip ...

The issue appears to be that the coreboot table memory is marked as
uncached-minus and then Linux (?) is marking the ACPI tables as
write-back.
The 1 MB size is overlapping the ACPI tables.
That makes mmap attempts of the whole coreboot table to fail due to
the mismatched memory types.


I have an older version of coreboot from Sage that does not have this issue.
The difference is that the first uncached-minus entry is not present.

On the Sage-based (4.0) coreboot image:
~ # cat /sys/kernel/debug/x86/pat_memtype_list
PAT memtype list:
write-back @ 0x7add1000-0x7add2000
write-back @ 0x7add4000-0x7add9000
write-back @ 0x7adda000-0x7addc000
uncached-minus @ 0x7ade2000-0x7ade3000
write-combining @ 0xc0000000-0xd0000000
... snip ...

So, I'm trying to figure out a few things:

1) Where does Linux get the PAT table from? The e820 map?

2) What piece of code sets the coreboot table as uncached-minus?

3) Why is that range set as uncached-minus?  Would write-back work?

Thanks,
Ben


From gaumless at gmail.com  Fri Oct 30 17:50:32 2015
From: gaumless at gmail.com (Martin Roth)
Date: Fri, 30 Oct 2015 10:50:32 -0600
Subject: [coreboot] Document for review: coreboot Gerrit Etiquette and
	Guidelines
In-Reply-To: <5632EC33.7020200@gmail.com>
References: <CA+e+Ov5X3WZq-V=jNs86CrhPt2hUsf8W_mLCduWw8-TadXbNxA@mail.gmail.com>
 <5632EC33.7020200@gmail.com>
Message-ID: <CA+e+Ov4RgCvjPpj2JopYDK0mkBfL1iRXVjM0vWPZeEika4wiTw@mail.gmail.com>

Hi Alex,
  Thanks for voicing your concerns.  I do think that most of the
issues you bring up are handled, or aren't as big issues you make them
out to be.  As always, I could be wrong, so I'd again invite others to
give their opinions.  I've tried to address your issues below.

> ... the "maintainer" is given almost absolute veto power
> in all matters relating to that code.
...
> There are also no responsibilities defined for a "maintainer", despite
> such person being given near-inter-stellar of power.
I did try to define maintainers in the document:
* Try to coordinate with platform maintainers when making changes to
  platforms. The platform maintainers are the users who initially pushed the
  code for that platform, as well as users who have made significant changes
  to a platform. To find out who maintains a piece of code, please use
  util/scripts/maintainers.go or refer to the original author of the code in
  git log.
I'm not certain how "Try to coordinate" is being read as "almost
absolute veto power" or "near-inter-stellar of power".

>  Concerns from external reviewers often get
> ignored or brushed off as "don't care".
This is absolutely addressed by these three guidelines:
* Respond to anyone who has taken the time to review your patches.
* If there have been comments or discussion on a patch, verify that the
  comments have been addressed before giving a +2.
* If there is still ongoing discussion to a patch, try to wait for a
conclusion to the discussion before submitting it to the tree.

>  I've seen plenty of cases where patches have been -2'd
> by W at g.com until other @g.com patches were merged, only for the -2 to be
> removed once it was on the contributor to rebase his work.
I haven't seen this, but if you see a situation where you feel like
someone is being treated unfairly, please bring it to the attention of
the coreboot leadership or post something to the mailing list.

> This then creates another significant issue: the bar for contributions
> from such teams is very low, while anyone else experiences a much higher
> bar. This has many times resulted in sub-optimal code being merged, and
> great contributions getting delayed and abandoned.
Again, I feel like if you comment on these patches, the rules above
should handle these issues.  And again, if you feel like something is
unfair, bring attention to it.

> ...  Raptor Eng. was asking around $15000 to upstream ...
> All of a sudden, we've made coreboot a very expensive
> project to support.
Additionally, I specifically reached out to tpearson with these
guidelines to get his feedback before they were posted.  I have tried
to address the concerns he brought up.  If you (or anyone else) feel
like there's something specific we can add here that will help him or
future developers get code submitted, please recommend the addition.

> Then there's talk about a vague "coreboot leadership"...
Patrick addressed this in the review - here's Stefan talking about
coreboot leadership:
http://blogs.coreboot.org/blog/2015/05/11/on-coreboot-leadership/


From adurbin at google.com  Fri Oct 30 17:52:29 2015
From: adurbin at google.com (Aaron Durbin)
Date: Fri, 30 Oct 2015 09:52:29 -0700
Subject: [coreboot] PAT memory type issues and cbmem
In-Reply-To: <CAE7DoPYcCwDjMXyxw724tMPeT3zMy-hcpoUBZk6kAY6XFOtbGw@mail.gmail.com>
References: <CAE7DoPYcCwDjMXyxw724tMPeT3zMy-hcpoUBZk6kAY6XFOtbGw@mail.gmail.com>
Message-ID: <CAE2855sqgS_g_UmginNEdevi5OPOo2tFjK_7Nm4NG9isXBtsBw@mail.gmail.com>

On Fri, Oct 30, 2015 at 9:19 AM, Ben Gardner <gardner.ben at gmail.com> wrote:
> cbmem attempts to map 1 MB of memory to read the CB tables.
> This is failing on my board due to the PAT configuration under Linux.
> If I boot Linux with "nopat", the issue goes away.
>
> I am using the upstream coreboot and SeaBIOS with a custom board based
> on the bayleybay_fsp/fsp_baytrail and Linux 4.2.
>
> ~ # ./cbmem -V -l
> Looking for coreboot table at 0 1048576 bytes.
> Mapping 1MB of physical memory at 0x0 (requested 0x0).
> Found!
>   coreboot table entry 0x11
>     Found forwarding entry.
> Unmapping 1MB of virtual memory at 0x7fee18224000.
> Looking for coreboot table at 7ad9f000 1048576 bytes.
> Mapping 1MB of physical memory at 0x7ad9f000 (requested 0x7ad9f000).
>   ... failed.  Mapping 1052671B of physical memory at 0x7ad9e000.
> Failed to mmap /dev/mem: Resource temporarily unavailable
> ~ # dmesg | tail -n 4
> [  221.700621] x86/PAT: cbmem.orig:1058 conflicting memory types
> 7ad9f000-7ae9f000 uncached-minus<->write-back 7adb8000-7adbc000
> [  221.705419] x86/PAT: reserve_memtype failed [mem
> 0x7ad9f000-0x7ae9efff], track write-back, req write-back
> [  221.710435] x86/PAT: cbmem.orig:1058 conflicting memory types
> 7ad9e000-7ae9f000 uncached-minus<->write-back 7adb8000-7adbc000
> [  221.715501] x86/PAT: reserve_memtype failed [mem
> 0x7ad9e000-0x7ae9efff], track write-back, req write-back
> ~ # cat /sys/kernel/debug/x86/pat_memtype_list
> PAT memtype list:
> uncached-minus @ 0x7ada7000-0x7ada8000
> write-back @ 0x7adb8000-0x7adbc000
> write-back @ 0x7adbb000-0x7adbd000
> write-back @ 0x7addd000-0x7adde000
> uncached-minus @ 0x80600000-0x80601000
> uncached-minus @ 0x80601000-0x80602000
> uncached-minus @ 0x80602000-0x80603000
> write-combining @ 0xc0000000-0xd0000000
> ... snip ...
>
> From the Linux kernel log:
>  MTRR variable ranges enabled:
>    0 base 0FF800000 mask FFF800000 write-protect
>    1 base 000000000 mask F80000000 write-back
>    2 base 07B000000 mask FFF000000 uncachable
>    3 base 07C000000 mask FFC000000 uncachable
>
> I'm not sure how to read MTRR ranges, but it looks like the cbtable
> falls in the MTRR 1 with type write-back.
>
> From the SeaBIOS log:
> e820 map has 15 items:
>   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>   3: 0000000000100000 - 000000007ad8e000 = 1 RAM
>   4: 000000007ad8e000 - 0000000080000000 = 2 RESERVED
>   5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED
> ... snip ...
>
> The issue appears to be that the coreboot table memory is marked as
> uncached-minus and then Linux (?) is marking the ACPI tables as
> write-back.
> The 1 MB size is overlapping the ACPI tables.
> That makes mmap attempts of the whole coreboot table to fail due to
> the mismatched memory types.
>
>
> I have an older version of coreboot from Sage that does not have this issue.
> The difference is that the first uncached-minus entry is not present.
>
> On the Sage-based (4.0) coreboot image:
> ~ # cat /sys/kernel/debug/x86/pat_memtype_list
> PAT memtype list:
> write-back @ 0x7add1000-0x7add2000
> write-back @ 0x7add4000-0x7add9000
> write-back @ 0x7adda000-0x7addc000
> uncached-minus @ 0x7ade2000-0x7ade3000
> write-combining @ 0xc0000000-0xd0000000
> ... snip ...
>
> So, I'm trying to figure out a few things:
>
> 1) Where does Linux get the PAT table from? The e820 map?

It's generated a runtime based on the requests the kernel makes for
specific mapping.
>
> 2) What piece of code sets the coreboot table as uncached-minus?

The kernel does it. e820 is sort of a poor indicator for memory type.
It merges the concept of address space usage and type but it doesn't
do a very good job at it.

>
> 3) Why is that range set as uncached-minus?  Would write-back work?

Please see this thread:
http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html

The actual issue stems from
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f
which maintains a persistent mapping of smbios tables. It uses
dmi_remap() which is '#define dmi_remap ioremap' which is where the
uncached-minus PAT entry comes from. It should be using the same
mechanism as  the ACPI table mappings which uses ioremap_cache().

Hope that helps.

-Aaron


From rminnich at gmail.com  Fri Oct 30 17:56:39 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 30 Oct 2015 16:56:39 +0000
Subject: [coreboot] Document for review: coreboot Gerrit Etiquette and
	Guidelines
In-Reply-To: <CA+e+Ov4RgCvjPpj2JopYDK0mkBfL1iRXVjM0vWPZeEika4wiTw@mail.gmail.com>
References: <CA+e+Ov5X3WZq-V=jNs86CrhPt2hUsf8W_mLCduWw8-TadXbNxA@mail.gmail.com>
 <5632EC33.7020200@gmail.com>
 <CA+e+Ov4RgCvjPpj2JopYDK0mkBfL1iRXVjM0vWPZeEika4wiTw@mail.gmail.com>
Message-ID: <CAP6exYLpWcTnhQOSdLgLQwiWeUfNUqAqoxPkn-TaeJ+_+LvJQA@mail.gmail.com>

Possibly an appendix defining coreboot leadership would help.



On Fri, Oct 30, 2015 at 9:51 AM Martin Roth <gaumless at gmail.com> wrote:

> Hi Alex,
>   Thanks for voicing your concerns.  I do think that most of the
> issues you bring up are handled, or aren't as big issues you make them
> out to be.  As always, I could be wrong, so I'd again invite others to
> give their opinions.  I've tried to address your issues below.
>
> > ... the "maintainer" is given almost absolute veto power
> > in all matters relating to that code.
> ...
> > There are also no responsibilities defined for a "maintainer", despite
> > such person being given near-inter-stellar of power.
> I did try to define maintainers in the document:
> * Try to coordinate with platform maintainers when making changes to
>   platforms. The platform maintainers are the users who initially pushed
> the
>   code for that platform, as well as users who have made significant
> changes
>   to a platform. To find out who maintains a piece of code, please use
>   util/scripts/maintainers.go or refer to the original author of the code
> in
>   git log.
> I'm not certain how "Try to coordinate" is being read as "almost
> absolute veto power" or "near-inter-stellar of power".
>
> >  Concerns from external reviewers often get
> > ignored or brushed off as "don't care".
> This is absolutely addressed by these three guidelines:
> * Respond to anyone who has taken the time to review your patches.
> * If there have been comments or discussion on a patch, verify that the
>   comments have been addressed before giving a +2.
> * If there is still ongoing discussion to a patch, try to wait for a
> conclusion to the discussion before submitting it to the tree.
>
> >  I've seen plenty of cases where patches have been -2'd
> > by W at g.com until other @g.com patches were merged, only for the -2 to be
> > removed once it was on the contributor to rebase his work.
> I haven't seen this, but if you see a situation where you feel like
> someone is being treated unfairly, please bring it to the attention of
> the coreboot leadership or post something to the mailing list.
>
> > This then creates another significant issue: the bar for contributions
> > from such teams is very low, while anyone else experiences a much higher
> > bar. This has many times resulted in sub-optimal code being merged, and
> > great contributions getting delayed and abandoned.
> Again, I feel like if you comment on these patches, the rules above
> should handle these issues.  And again, if you feel like something is
> unfair, bring attention to it.
>
> > ...  Raptor Eng. was asking around $15000 to upstream ...
> > All of a sudden, we've made coreboot a very expensive
> > project to support.
> Additionally, I specifically reached out to tpearson with these
> guidelines to get his feedback before they were posted.  I have tried
> to address the concerns he brought up.  If you (or anyone else) feel
> like there's something specific we can add here that will help him or
> future developers get code submitted, please recommend the addition.
>
> > Then there's talk about a vague "coreboot leadership"...
> Patrick addressed this in the review - here's Stefan talking about
> coreboot leadership:
> http://blogs.coreboot.org/blog/2015/05/11/on-coreboot-leadership/
>
> --
> 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/20151030/37e58e13/attachment.html>

From gardner.ben at gmail.com  Fri Oct 30 18:28:48 2015
From: gardner.ben at gmail.com (Ben Gardner)
Date: Fri, 30 Oct 2015 12:28:48 -0500
Subject: [coreboot] PAT memory type issues and cbmem
In-Reply-To: <CAE2855sqgS_g_UmginNEdevi5OPOo2tFjK_7Nm4NG9isXBtsBw@mail.gmail.com>
References: <CAE7DoPYcCwDjMXyxw724tMPeT3zMy-hcpoUBZk6kAY6XFOtbGw@mail.gmail.com>
 <CAE2855sqgS_g_UmginNEdevi5OPOo2tFjK_7Nm4NG9isXBtsBw@mail.gmail.com>
Message-ID: <CAE7DoPb5TSL8pab2a-b+Jr18S-L2RWpw9Z1h1eTOyHAs9RLnOQ@mail.gmail.com>

On Fri, Oct 30, 2015 at 11:52 AM, Aaron Durbin <adurbin at google.com> wrote:
> On Fri, Oct 30, 2015 at 9:19 AM, Ben Gardner <gardner.ben at gmail.com> wrote:
>> cbmem attempts to map 1 MB of memory to read the CB tables.
>> This is failing on my board due to the PAT configuration under Linux.
>> If I boot Linux with "nopat", the issue goes away.
>>
>> I am using the upstream coreboot and SeaBIOS with a custom board based
>> on the bayleybay_fsp/fsp_baytrail and Linux 4.2.
>>
>> ~ # ./cbmem -V -l
>> Looking for coreboot table at 0 1048576 bytes.
>> Mapping 1MB of physical memory at 0x0 (requested 0x0).
>> Found!
>>   coreboot table entry 0x11
>>     Found forwarding entry.
>> Unmapping 1MB of virtual memory at 0x7fee18224000.
>> Looking for coreboot table at 7ad9f000 1048576 bytes.
>> Mapping 1MB of physical memory at 0x7ad9f000 (requested 0x7ad9f000).
>>   ... failed.  Mapping 1052671B of physical memory at 0x7ad9e000.
>> Failed to mmap /dev/mem: Resource temporarily unavailable
>> ~ # dmesg | tail -n 4
>> [  221.700621] x86/PAT: cbmem.orig:1058 conflicting memory types
>> 7ad9f000-7ae9f000 uncached-minus<->write-back 7adb8000-7adbc000
>> [  221.705419] x86/PAT: reserve_memtype failed [mem
>> 0x7ad9f000-0x7ae9efff], track write-back, req write-back
>> [  221.710435] x86/PAT: cbmem.orig:1058 conflicting memory types
>> 7ad9e000-7ae9f000 uncached-minus<->write-back 7adb8000-7adbc000
>> [  221.715501] x86/PAT: reserve_memtype failed [mem
>> 0x7ad9e000-0x7ae9efff], track write-back, req write-back
>> ~ # cat /sys/kernel/debug/x86/pat_memtype_list
>> PAT memtype list:
>> uncached-minus @ 0x7ada7000-0x7ada8000
>> write-back @ 0x7adb8000-0x7adbc000
>> write-back @ 0x7adbb000-0x7adbd000
>> write-back @ 0x7addd000-0x7adde000
>> uncached-minus @ 0x80600000-0x80601000
>> uncached-minus @ 0x80601000-0x80602000
>> uncached-minus @ 0x80602000-0x80603000
>> write-combining @ 0xc0000000-0xd0000000
>> ... snip ...
>>
>> From the Linux kernel log:
>>  MTRR variable ranges enabled:
>>    0 base 0FF800000 mask FFF800000 write-protect
>>    1 base 000000000 mask F80000000 write-back
>>    2 base 07B000000 mask FFF000000 uncachable
>>    3 base 07C000000 mask FFC000000 uncachable
>>
>> I'm not sure how to read MTRR ranges, but it looks like the cbtable
>> falls in the MTRR 1 with type write-back.
>>
>> From the SeaBIOS log:
>> e820 map has 15 items:
>>   0: 0000000000000000 - 000000000009fc00 = 1 RAM
>>   1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
>>   2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
>>   3: 0000000000100000 - 000000007ad8e000 = 1 RAM
>>   4: 000000007ad8e000 - 0000000080000000 = 2 RESERVED
>>   5: 00000000e0000000 - 00000000f0000000 = 2 RESERVED
>> ... snip ...
>>
>> The issue appears to be that the coreboot table memory is marked as
>> uncached-minus and then Linux (?) is marking the ACPI tables as
>> write-back.
>> The 1 MB size is overlapping the ACPI tables.
>> That makes mmap attempts of the whole coreboot table to fail due to
>> the mismatched memory types.
>>
>>
>> I have an older version of coreboot from Sage that does not have this issue.
>> The difference is that the first uncached-minus entry is not present.
>>
>> On the Sage-based (4.0) coreboot image:
>> ~ # cat /sys/kernel/debug/x86/pat_memtype_list
>> PAT memtype list:
>> write-back @ 0x7add1000-0x7add2000
>> write-back @ 0x7add4000-0x7add9000
>> write-back @ 0x7adda000-0x7addc000
>> uncached-minus @ 0x7ade2000-0x7ade3000
>> write-combining @ 0xc0000000-0xd0000000
>> ... snip ...
>>
>> So, I'm trying to figure out a few things:
>>
>> 1) Where does Linux get the PAT table from? The e820 map?
>
> It's generated a runtime based on the requests the kernel makes for
> specific mapping.
>>
>> 2) What piece of code sets the coreboot table as uncached-minus?
>
> The kernel does it. e820 is sort of a poor indicator for memory type.
> It merges the concept of address space usage and type but it doesn't
> do a very good job at it.
>
>>
>> 3) Why is that range set as uncached-minus?  Would write-back work?
>
> Please see this thread:
> http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html
>
> The actual issue stems from
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f
> which maintains a persistent mapping of smbios tables. It uses
> dmi_remap() which is '#define dmi_remap ioremap' which is where the
> uncached-minus PAT entry comes from. It should be using the same
> mechanism as  the ACPI table mappings which uses ioremap_cache().
>
> Hope that helps.
>
> -Aaron

It does help.
I can confirm that changing that #define in arch/x86/include/asm/dmi.h
fixes the issue:

#define dmi_remap ioremap_cache

~ # cat /sys/kernel/debug/x86/pat_memtype_list
PAT memtype list:
write-back @ 0x7ada7000-0x7ada8000
write-back @ 0x7adb8000-0x7adbc000
write-back @ 0x7adbb000-0x7adbd000
write-back @ 0x7addc000-0x7addd000
write-combining @ 0xc0000000-0xd0000000
... snip ...

Thanks,
Ben


From mr.nuke.me at gmail.com  Fri Oct 30 18:59:08 2015
From: mr.nuke.me at gmail.com (Alex Gagniuc)
Date: Fri, 30 Oct 2015 10:59:08 -0700
Subject: [coreboot] coreboot binary policy
In-Reply-To: <CALrs_3gS4zzY11qV8EJ_h+8CuyG_RcHs5RiLPdvH35LzBtkT6A@mail.gmail.com>
References: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>
 <5633904F.3010001@gmail.com>
 <CALrs_3gS4zzY11qV8EJ_h+8CuyG_RcHs5RiLPdvH35LzBtkT6A@mail.gmail.com>
Message-ID: <CADi83T4bDzmv5VA-RO91c5pH4GQ5eme_HNbUtcve5gwg0J6KpA@mail.gmail.com>

On Fri, Oct 30, 2015 at 9:03 AM, Marc Jones <marcj303 at gmail.com> wrote:
> It might be a good idea, but that might be too limiting

I think historically, it has been assumed that everything in blobs is
open up for RE and modification. There are plenty of examples of
people reverse-engineering stuff in blobs, and also modifying the blob
itself [1]. First and foremost, we should protect the project, and
with that, our contributors.

We can have a process where we might grant exceptions from these
(proposed) rules to certain non-ISA blobs. For example, we might
exempt microcode on the basis that (we believe) It's impractical to
RE, and keeping that avenue open is not of any particular value.

> and we would have to remove all blobs and they would be hosted somewhere else

We can grandfather in existing blobs, or we can have a process where
we keep them for a while (a year?) while we try to work out
appropriate licensing terms with the power-that-be of said blob.

[1] http://review.coreboot.org/4605

Alex


From rminnich at gmail.com  Fri Oct 30 19:14:40 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 30 Oct 2015 18:14:40 +0000
Subject: [coreboot] coreboot binary policy
In-Reply-To: <CADi83T4bDzmv5VA-RO91c5pH4GQ5eme_HNbUtcve5gwg0J6KpA@mail.gmail.com>
References: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>
 <5633904F.3010001@gmail.com>
 <CALrs_3gS4zzY11qV8EJ_h+8CuyG_RcHs5RiLPdvH35LzBtkT6A@mail.gmail.com>
 <CADi83T4bDzmv5VA-RO91c5pH4GQ5eme_HNbUtcve5gwg0J6KpA@mail.gmail.com>
Message-ID: <CAP6exY+euS7j1N7pWNeXPu1R_YR-wiZM0jjARDSjRVQ=fBKvjA@mail.gmail.com>

On Fri, Oct 30, 2015 at 10:59 AM Alex Gagniuc <mr.nuke.me at gmail.com> wrote:

>
> I think historically, it has been assumed that everything in blobs is
> open up for RE and modification.
>

History? What? Only if your timeline is really short. We first started
doing the blobs support in 2001 for graphics. We NEVER held it that we had
a right to RE and modify nvidia blobs. We certainly never RE'ed the
firmware we were trying to replace.

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

From dhendrix at google.com  Fri Oct 30 20:04:22 2015
From: dhendrix at google.com (David Hendricks)
Date: Fri, 30 Oct 2015 12:04:22 -0700
Subject: [coreboot] coreboot binary policy
In-Reply-To: <CALrs_3gS4zzY11qV8EJ_h+8CuyG_RcHs5RiLPdvH35LzBtkT6A@mail.gmail.com>
References: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>
 <5633904F.3010001@gmail.com>
 <CALrs_3gS4zzY11qV8EJ_h+8CuyG_RcHs5RiLPdvH35LzBtkT6A@mail.gmail.com>
Message-ID: <CAKOoyUc=XWfF8W15SJ9kNrD3wU78bBaWFgH2cGSTOAKySdSPpQ@mail.gmail.com>

On Fri, Oct 30, 2015 at 9:03 AM, Marc Jones <marcj303 at gmail.com> wrote:

>
> On Fri, Oct 30, 2015 at 9:44 AM Alex G. <mr.nuke.me at gmail.com> wrote:
>
>> On 10/29/2015 09:48 AM, Marc Jones wrote:
>> > Hello coreboot,
>>
>> Hi Marc
>>
>> > Please limit comments to specific items in this version. If you have
>> > additions for the next version (if needed), the draft document is open
>> > for comment.
>> >
>> >
>> https://docs.google.com/document/d/1wMdDUAZR2Z9V7hcs3IhIOqw6sYQxb3vPEmbITTCrOwU/edit?usp=sharing
>>
>> That looks pretty good. I think you've done a great job of clarifying
>> the requirements of ISA vs non-ISA blobs compared to the last version.
>> I've made some comments on it to ask for clarification about the
>> versioning requirements.
>>
>> While not necessarily specific to this version, are we still considering
>> forbidding "no-reverse engineering" and "no-modification" clauses for
>> blobs?
>>
>>
> Thanks, I think it is all open for discussion and could go in the next
> version. It might be a good idea, but that might be too limiting and we
> would have to remove all blobs and they would be hosted somewhere else,
> which defeates the utility of the blobs dir. We would like intel to push to
> blobs/ but I think that would be a huge blocker for them.
>

+1. It's tough enough for us to get rid of a few lines of GPL boilerplate.
Getting companies to significantly change their boilerplate licensing for
blobs will be a blocker.

Just treat them as we always have.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151030/01e214eb/attachment-0001.html>

From pgeorgi at google.com  Fri Oct 30 21:38:10 2015
From: pgeorgi at google.com (Patrick Georgi)
Date: Fri, 30 Oct 2015 21:38:10 +0100
Subject: [coreboot] Announcing coreboot 4.2
Message-ID: <CAE-gjdWEcROK2tK5zOpW6Fmt6_4naewvjmcXnyJUq-m0-BAkvA@mail.gmail.com>

(Halloween 2015 release - just as scary as that sounds)

Dear coreboot community,

today marks the release of coreboot 4.2, the second release on our
time based release schedule.
Since 4.1 there were 936 commits by 90 authors, increasing the code
base by approximately 17000 lines of code. We saw 35 new contributors
- welcome to coreboot! More than 34 developers were active as
reviewers in that period.
Thanks go to all contributors who helped shape this release.

As with 4.1, the release tarballs are available at
http://www.coreboot.org/releases/. There's also a 4.2 tag and branch
in the git repository.

This marks the first release that features a changelog comparing it to
the previous release. There was some limited testing to make sure that
the code is usable, and it boots on some devices. A structured test
plan will only become part of the release procedure of future
versions.
I'm grateful to Martin for assembling this release's changelog.

This is also the first release that will be followed by the removal of
old, unused code. There will be a policy on how to announce
deprecation and removal of mainboard and chipset code for future
releases.

Regards,
Patrick

Log of commit d5e6618a4f076610e683b174c4dd5108d960c785 to
commit 439a527014fa0cb3e4ef60ba59e5c57c737b4444

Changes between 4.1 and 4.2
---------------------------
Build system:
- Store a minimized coreboot config file in cbfs instead of the full config
- Store the payload config and revision in CBFS when that info is available
- Add -compression option for cbfs-files-y. Valid entries are now -file,
-type, -align, and -compression
- Change Microcode inclusion method from building .h files to pre-built binaries
- Update Builder tests for each commit to test utilities and run lint tools
- Many other small makefile and build changes and fixes
- Remove expert mode as a Kconfig option

Utilities:
- Many fixes and updates to many utilities (158 total commits)
- ifdtool: Update for skylake, handle region masks correctly
- crossgcc: Update to gcc 5.2.0
- kconfig: Add strict mode to fail on kconfig errors and warnings
- vgabios: Significant fixes to remove issues in linking into coreboot code
- Add script to parse MAINTAINERS file
- Add Kconfig lint tool
- Create a common library to share coreboot routines with utilities
- Significant changes and cleanup to cbfstool (81 commits). Major changes:
- Update cbfstool to change the internal location of FSP binaries when adding
them
- Decompress stage files on extraction and turn them into ELF binaries
- Header sizes are now variable, containing extended attributes
- Add compression tags to all cbfs headers so all cbfs files can be compressed
- Add and align CBFS components in one pass instead of two
- Add XIP support for X86 to relocate the romstage when it's added
- Removed locate command as it's no longer needed
- Add bootblock and cbfs_header file types so the master header knows about
them
- Prefer FMAP data to CBFS master header if FMAP data exists
- Add hashes to cbfs file metadata for verification of images

Payloads:
- SeaBIOS: update stable release from 1.7.5 to 1.8.2
- Libpayload had some significant changes (61 commits). Major changes:
- Add support for fmap tables
- Add support for SuperSpeed (3.0) USB hubs
- Updates and bugfixes for DesignWare OTG controller (DWC2)
- Add video_printf to print text with specified foreground &amp; background
colors
- Updates to match changes to cbfs/cbfstool
- Add cbgfx, a library to show graphics and text on a display
- Read cbfs offset and size from sysinfo when available

Vendorcode:
- fsp_baytrail: Support Baytrail FSP Gold 4 release
- AMD binary PI: add support for fan control
- Work to get AMD AGESA to compile correctly as 64-bit code
- Add standalone (XIP) verstage support for x86 to verify romstage

Mainboards:
- New Mainboards:
- apple/macbookair4_2 - Sandy/Ivy Bridge with Panther / Cougar point
chipset
- asus/kgpe-d16 - AMD Family 10, SB700/SR5650 platform
- emulation/spike-riscv - RISCV virtualized platform
- google/chell - Intel Skylake chrome platform
- google/cyan - Intel Braswell chrome platform
- google/glados - Intel Skylake chrome platform
- google/lars - Intel Skylake chrome platform
- intel/kunimitsu - Intel Skylake chrome platform
- intel/sklrvp - Intel Skylake reference platform
- intel/strago - Intel Braswell chrome platform
- Cleanups of many mainboards - several patches each for:
- amd/bettong
- getac/p470
- google/auron, google/smaug and google/veyron_rialto
- pcengines/apu1
- siemens/mc_tcu3
- Combine the google/veyron_(jerry, mighty, minnie, pinkie, shark &amp; speedy)
mainboards into the single google/veyron mainboard directory

Console:
- Add EM100 'hyper term' spi console support in ramstage &amp; smm
- Add console support for verstage

ARM:
- armv7: use asm coded memory operations for 32/16 bit read/write
- Many cleanups to the nvidia tegra chips (40 patches)

RISC-V:
- Add trap handling
- Add virtual Memory setup

X86:
- Remove and re-add Rangeley and Ivy Bridge / panther point FSP platforms
- Update microcode update parser to use stock AMD microcode blobs from CBFS
- ACPI: Align FACS to 64 byte boundary. Fixes FWTS error
- AMD/SB700: Init devices in early boot, restore power state after power
failure. Add IDE/SATA asl code
- Add initial support for AMD Socket G34 processors
- Add tick frequency to timestamp table to calculate boot times more accurately
- Unify X86 romstage / ramstage linking to match other platforms
- Start preparing X86 bootblock for non-memory-mapped BIOS media
- cpu/amd/car: Add Suspend to RAM (S3) support
- Native VGA init fixes on several platforms
- Significant updates to FSP 1.1 code for cleanup and cbfstool changes
- SMMhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG to prevent
the memory sinkhole smm hack
Drivers:
- Add native text mode support for the Aspeed AST2050
- w83795: Add support for for fan control and voltage monitoring
- Intel GMA ACPI consolidation and improvements
- Set up the 8254 timer before running option ROMs
- Resource allocator: Page align memory mapped PCI resources

Lib:
- Derive fmap name from offset/size
- Several edid fixes
- Updates to cbfs matching changes in cbfstool

Submodules:
-----------
3rdparty/blobs:
Total commits: 16
Log of commit 61d663e39bc96530900c3232ccea7365ab9dad0b to
commit aab093f0824b6d26b57a1ce220ba0d577e37ad49
- AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)
- AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1)
- Update microcode to binary blobs. Remove old .h microcode files

3rdparty/arm-trusted-firmware:
- No Changes

3rdparty/vboot:
Total commits: 41
Log of commit fbf631c845c08299f0bcbae3f311c5807d34c0d6 to
commit d6723ed12b429834c2627c009aab58f0db20ce73
- Update the code to determine the write protect line gpio value
- Several updates to futility and image_signing scripts
- Update crossystem to accommodate Android mosys location
- Support reboot requested by secdata
- Add NV flag to default boot legacy OS

util/nvidia/cbootimage:
- No Changes

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


From stefan.reinauer at coreboot.org  Fri Oct 30 21:55:03 2015
From: stefan.reinauer at coreboot.org (Stefan Reinauer)
Date: Fri, 30 Oct 2015 21:55:03 +0100
Subject: [coreboot] coreboot binary policy
In-Reply-To: <CADi83T4bDzmv5VA-RO91c5pH4GQ5eme_HNbUtcve5gwg0J6KpA@mail.gmail.com>
References: <CALrs_3jnaaADjkoxVMyyDUtndRF9vvqdESfjnFSWuiYxvaP9qA@mail.gmail.com>
 <5633904F.3010001@gmail.com>
 <CALrs_3gS4zzY11qV8EJ_h+8CuyG_RcHs5RiLPdvH35LzBtkT6A@mail.gmail.com>
 <CADi83T4bDzmv5VA-RO91c5pH4GQ5eme_HNbUtcve5gwg0J6KpA@mail.gmail.com>
Message-ID: <20151030205503.GA16646@coreboot.org>

* Alex Gagniuc <mr.nuke.me at gmail.com> [151030 18:59]:
> On Fri, Oct 30, 2015 at 9:03 AM, Marc Jones <marcj303 at gmail.com> wrote:
> > It might be a good idea, but that might be too limiting
> 
> I think historically, it has been assumed that everything in blobs is
> open up for RE and modification. There are plenty of examples of
> people reverse-engineering stuff in blobs, and also modifying the blob
> itself [1]. First and foremost, we should protect the project, and
> with that, our contributors.

Alex, I think this is a great suggestion, but as I have explained to you
in person before, from a perspective of reaching a legal agreement this
is almost equivalent (if not more effort) than working on an agreement
to open source that code to begin with. The coreboot project's objective 
is not to reimplement what other people have done, but to change the
industry to create more open computing devices.

That said, if you want to drive an example terms of use with your
employer that fulfills your advanced criteria, you are more than welcome
to do so, and I believe it would serve as a role model in the silicon
industry.

I am happy to help with such an arrangement, and would be even happier
if we could just open source the code in question. But we can take this
offline.

> We can have a process where we might grant exceptions from these
> (proposed) rules to certain non-ISA blobs. For example, we might
> exempt microcode on the basis that (we believe) It's impractical to
> RE, and keeping that avenue open is not of any particular value.

Reverse engineering is impractical in all cases. Specifically this
document is focussing on what BLOBs we can ship in the 3rdparty/blobs
directory, not generally which BLOBs are allowed in coreboot.

In terms of many blobs (like FSP, hint hint), we are not even at the
point where we can redistribute them in 3rdparty/blobs yet. Adding
additional restrictions would, if anything, change nothing at all
(except that our users will have to get their own collection of BLOBs if
they want to participate).

> We can grandfather in existing blobs, or we can have a process where
> we keep them for a while (a year?) while we try to work out
> appropriate licensing terms with the power-that-be of said blob.

I would like to get the existing BLOBs into 3rdparty/blobs first before
we talk about removing them in a year (e.g. FSP, hint hint).

All the best,
Stefan



From rminnich at gmail.com  Fri Oct 30 21:58:34 2015
From: rminnich at gmail.com (ron minnich)
Date: Fri, 30 Oct 2015 20:58:34 +0000
Subject: [coreboot] Announcing coreboot 4.2
In-Reply-To: <CAE-gjdWEcROK2tK5zOpW6Fmt6_4naewvjmcXnyJUq-m0-BAkvA@mail.gmail.com>
References: <CAE-gjdWEcROK2tK5zOpW6Fmt6_4naewvjmcXnyJUq-m0-BAkvA@mail.gmail.com>
Message-ID: <CAP6exYLXWsvFSAnLrT-kFZuJXsapWwdaHkF_ezmnAC8hWo2amQ@mail.gmail.com>

Nice job all. Patrick, I'm looking forward t the next release detailing how
many files and lines were removed :-)

include, oh sad, the 440lx :-)

ron

On Fri, Oct 30, 2015 at 1:38 PM Patrick Georgi <pgeorgi at google.com> wrote:

> (Halloween 2015 release - just as scary as that sounds)
>
> Dear coreboot community,
>
> today marks the release of coreboot 4.2, the second release on our
> time based release schedule.
> Since 4.1 there were 936 commits by 90 authors, increasing the code
> base by approximately 17000 lines of code. We saw 35 new contributors
> - welcome to coreboot! More than 34 developers were active as
> reviewers in that period.
> Thanks go to all contributors who helped shape this release.
>
> As with 4.1, the release tarballs are available at
> http://www.coreboot.org/releases/. There's also a 4.2 tag and branch
> in the git repository.
>
> This marks the first release that features a changelog comparing it to
> the previous release. There was some limited testing to make sure that
> the code is usable, and it boots on some devices. A structured test
> plan will only become part of the release procedure of future
> versions.
> I'm grateful to Martin for assembling this release's changelog.
>
> This is also the first release that will be followed by the removal of
> old, unused code. There will be a policy on how to announce
> deprecation and removal of mainboard and chipset code for future
> releases.
>
> Regards,
> Patrick
>
> Log of commit d5e6618a4f076610e683b174c4dd5108d960c785 to
> commit 439a527014fa0cb3e4ef60ba59e5c57c737b4444
>
> Changes between 4.1 and 4.2
> ---------------------------
> Build system:
> - Store a minimized coreboot config file in cbfs instead of the full config
> - Store the payload config and revision in CBFS when that info is available
> - Add -compression option for cbfs-files-y. Valid entries are now -file,
> -type, -align, and -compression
> - Change Microcode inclusion method from building .h files to pre-built
> binaries
> - Update Builder tests for each commit to test utilities and run lint tools
> - Many other small makefile and build changes and fixes
> - Remove expert mode as a Kconfig option
>
> Utilities:
> - Many fixes and updates to many utilities (158 total commits)
> - ifdtool: Update for skylake, handle region masks correctly
> - crossgcc: Update to gcc 5.2.0
> - kconfig: Add strict mode to fail on kconfig errors and warnings
> - vgabios: Significant fixes to remove issues in linking into coreboot code
> - Add script to parse MAINTAINERS file
> - Add Kconfig lint tool
> - Create a common library to share coreboot routines with utilities
> - Significant changes and cleanup to cbfstool (81 commits). Major changes:
> - Update cbfstool to change the internal location of FSP binaries when
> adding
> them
> - Decompress stage files on extraction and turn them into ELF binaries
> - Header sizes are now variable, containing extended attributes
> - Add compression tags to all cbfs headers so all cbfs files can be
> compressed
> - Add and align CBFS components in one pass instead of two
> - Add XIP support for X86 to relocate the romstage when it's added
> - Removed locate command as it's no longer needed
> - Add bootblock and cbfs_header file types so the master header knows about
> them
> - Prefer FMAP data to CBFS master header if FMAP data exists
> - Add hashes to cbfs file metadata for verification of images
>
> Payloads:
> - SeaBIOS: update stable release from 1.7.5 to 1.8.2
> - Libpayload had some significant changes (61 commits). Major changes:
> - Add support for fmap tables
> - Add support for SuperSpeed (3.0) USB hubs
> - Updates and bugfixes for DesignWare OTG controller (DWC2)
> - Add video_printf to print text with specified foreground &amp; background
> colors
> - Updates to match changes to cbfs/cbfstool
> - Add cbgfx, a library to show graphics and text on a display
> - Read cbfs offset and size from sysinfo when available
>
> Vendorcode:
> - fsp_baytrail: Support Baytrail FSP Gold 4 release
> - AMD binary PI: add support for fan control
> - Work to get AMD AGESA to compile correctly as 64-bit code
> - Add standalone (XIP) verstage support for x86 to verify romstage
>
> Mainboards:
> - New Mainboards:
> - apple/macbookair4_2 - Sandy/Ivy Bridge with Panther / Cougar point
> chipset
> - asus/kgpe-d16 - AMD Family 10, SB700/SR5650 platform
> - emulation/spike-riscv - RISCV virtualized platform
> - google/chell - Intel Skylake chrome platform
> - google/cyan - Intel Braswell chrome platform
> - google/glados - Intel Skylake chrome platform
> - google/lars - Intel Skylake chrome platform
> - intel/kunimitsu - Intel Skylake chrome platform
> - intel/sklrvp - Intel Skylake reference platform
> - intel/strago - Intel Braswell chrome platform
> - Cleanups of many mainboards - several patches each for:
> - amd/bettong
> - getac/p470
> - google/auron, google/smaug and google/veyron_rialto
> - pcengines/apu1
> - siemens/mc_tcu3
> - Combine the google/veyron_(jerry, mighty, minnie, pinkie, shark &amp;
> speedy)
> mainboards into the single google/veyron mainboard directory
>
> Console:
> - Add EM100 'hyper term' spi console support in ramstage &amp; smm
> - Add console support for verstage
>
> ARM:
> - armv7: use asm coded memory operations for 32/16 bit read/write
> - Many cleanups to the nvidia tegra chips (40 patches)
>
> RISC-V:
> - Add trap handling
> - Add virtual Memory setup
>
> X86:
> - Remove and re-add Rangeley and Ivy Bridge / panther point FSP platforms
> - Update microcode update parser to use stock AMD microcode blobs from CBFS
> - ACPI: Align FACS to 64 byte boundary. Fixes FWTS error
> - AMD/SB700: Init devices in early boot, restore power state after power
> failure. Add IDE/SATA asl code
> - Add initial support for AMD Socket G34 processors
> - Add tick frequency to timestamp table to calculate boot times more
> accurately
> - Unify X86 romstage / ramstage linking to match other platforms
> - Start preparing X86 bootblock for non-memory-mapped BIOS media
> - cpu/amd/car: Add Suspend to RAM (S3) support
> - Native VGA init fixes on several platforms
> - Significant updates to FSP 1.1 code for cleanup and cbfstool changes
> - SMMhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG to
> prevent
> the memory sinkhole smm hack
> Drivers:
> - Add native text mode support for the Aspeed AST2050
> - w83795: Add support for for fan control and voltage monitoring
> - Intel GMA ACPI consolidation and improvements
> - Set up the 8254 timer before running option ROMs
> - Resource allocator: Page align memory mapped PCI resources
>
> Lib:
> - Derive fmap name from offset/size
> - Several edid fixes
> - Updates to cbfs matching changes in cbfstool
>
> Submodules:
> -----------
> 3rdparty/blobs:
> Total commits: 16
> Log of commit 61d663e39bc96530900c3232ccea7365ab9dad0b to
> commit aab093f0824b6d26b57a1ce220ba0d577e37ad49
> - AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)
> - AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1)
> - Update microcode to binary blobs. Remove old .h microcode files
>
> 3rdparty/arm-trusted-firmware:
> - No Changes
>
> 3rdparty/vboot:
> Total commits: 41
> Log of commit fbf631c845c08299f0bcbae3f311c5807d34c0d6 to
> commit d6723ed12b429834c2627c009aab58f0db20ce73
> - Update the code to determine the write protect line gpio value
> - Several updates to futility and image_signing scripts
> - Update crossystem to accommodate Android mosys location
> - Support reboot requested by secdata
> - Add NV flag to default boot legacy OS
>
> util/nvidia/cbootimage:
> - No Changes
>
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Gesch?ftsf?hrer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot 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/20151030/a569146d/attachment-0001.html>

From contact at paulk.fr  Sat Oct 31 10:41:28 2015
From: contact at paulk.fr (Paul Kocialkowski)
Date: Sat, 31 Oct 2015 10:41:28 +0100
Subject: [coreboot] FOSDEM deadlines now!
In-Reply-To: <5626B038.80901@gmx.net>
References: <5626B038.80901@gmx.net>
Message-ID: <1446284488.2576.7.camel@collins>

Hi,

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. Not everything I'm
mentioning in the talk was properly documented at this point (especially
regarding work on the KB9012 EC), but I hope to correct that before the
event!

Liberating (modern) computers from the ground up: a tale of Libreboot,
Chromebooks and EC

Abstract:

Most of the computers we use daily are relying on proprietary software
at the lower levels. This includes the bootloader (previously known as
BIOS), firmwares running on various microcontrollers inside peripherals
and controllers and even microcodes inside processors. However, some
devices and platforms perform better than others when it comes to
software freedom at these levels: some are supported by free
bootloaders, such as U-Boot and Coreboot. Thus, it becomes less of a
stretch to liberate those devices, which is also crucial for privacy and
security.

Chromebooks are such good targets, since they ship with Coreboot and a
free embedded controller firmware. While some models still require
proprietary pieces here and there, a few can actually boot up with only
free software and are now supported by Libreboot, the fully free
distribution of Coreboot. In addition, they implement a robust security
model that, for once, does not conflict with the user's interest.

On the other hand, a few recent AMD devices also show real potential for
free software, with possible areas of work for freeing them at the low
levels. In particular, freeing the software running on such an AMD
laptop's embedded controller is currently work in progress, with all the
tools needed in hands.

Description:

Starting from a personal use case, this talk will first draw a general
overview of the current status of free software support at the lower
levels of modern computers, especially bootloaders, firmwares running
inside chips and microcodes, with a particular emphasis on embedded
devices. The common limitations when freeing these devices will be
highlighted, along with the examples of recent Intel and AMD platforms
and how they compare to different kinds of embedded systems on a chip.

With the overall picture of the situation a mind, the rest of the talk
will focus on a few examples of modern computers that were picked up
based on a personal use case and show potential for running with free
software at the lower levels. This will highlight what was already
achieved at this point, what is work in progress and what would be
doable in the future.

The first interesting devices that will be mentioned are Chromebooks,
with mention of how they usually perform better that most other modern
computers when it comes to free software. While not all Chromebooks are
good candidates for running a fully free bootloader (depending on the
platform they're using), a few of them are, such as the C201 Chromebook
(by Asus) that is now supported by Libreboot. This talk will highlight
all the challenges encountered when adding support for this Chromebook
to Libreboot and what is next for liberating it. Other potential
Chromebooks that would be worth supporting in Libreboot will also be
mentioned.

Still guided by a personal incentive, two modern computers, the G505s
laptop (by Lenovo) and the F2A85-M (PRO) mainboard (by Asus) will be
highlighted as they use an AMD platform that shows some potential for
freedom, whereas modern Intel platforms appear to be fatally flawed.
While the road to running those computers in freedom appears to be long,
if not fatally obstructed, there are still some areas of work.

In particular, the road to freeing the G505s's KB9012 embedded
controller will be presented in details, with an emphasis on the
incentive behind it and security considerations regarding embedded
controllers. This last part will show how it was possible to gather
information on the platform, implement access to its internal flash
externally, grab an UART serial port, solder standalone boards for tests
and execute code on the device, up to blinking a LED!

> Stands: Deadline 2015-11-13 (24 days left)
> I can send in the proposal if I'm not going to be alone there.
> How many tables do we want for our stand/booth(s)?
> Who is coming?

I will definitely be around at FOSDEM, not sure I should have a seat at
the table at this point (I'm still pretty new to the community), but I'd
be happy to come by!

-- 
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/20151031/02e2a0b5/attachment.asc>

From robert.maucher at googlemail.com  Sat Oct 31 12:21:01 2015
From: robert.maucher at googlemail.com (robert.maucher)
Date: Sat, 31 Oct 2015 12:21:01 +0100
Subject: [coreboot] unbricking an Acer CB5
Message-ID: <CAMPF0EOv1anovHvKXmjTPNqxJ=inAo-etrOSuGHF5RrGN4i9KQ@mail.gmail.com>

Hello Holger,
I am locking forward to flash coreboot to a cb5-311. So I was searching for
sources and information about it. The only thing i found was this cb5
unbricking mailinglist and the dev info.
How far did you get with the flashing of your cb5? Do you now have corboot
running your cb? Do you know some sources and information that would help
me?

Regards,
Robert Maucher

dev info:
https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-cb5-311-chromebook-13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20151031/20d8ec80/attachment.html>