Re: [coreboot] Welcome to the new coreboot.org!

[ron minnich]

It's wonderful.

For fun, I found this, which is *not* the first one, but close.

https://web.archive.org/web/2819124055/http://www.acl.lanl.gov/linuxbios/index.html


On Wed, Sep 7, 2016 at 5:51 PM Stefan Reinauer 
wrote:

> Hi!
>
> As some of you might already have noticed, our new web presence
> has gone live on https://www.coreboot.org/ today!
>
> I want to use this chance to send a big shout out to Philipp Deppenwiese
> and Martin Roth, and all the others that have been involved in making
> this moment happen, for their great work!
>
> With the new web page, our presence has not only arrived in the 21st
> century. We also have a better portal to catch the different groups
> interested in coreboot, in the future: End users, software developers
> and hardware manufacturers.
>
> There will be changes, modifications and optimizations in the next
> couple of days or weeks, but please feel free to send us feedback on
> coreboot's new look and content.
>
> Thanks,
> Stefan
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Welcome to the new coreboot.org!

[Stefan Reinauer]

Hi!

As some of you might already have noticed, our new web presence
has gone live on https://www.coreboot.org/ today!

I want to use this chance to send a big shout out to Philipp Deppenwiese
and Martin Roth, and all the others that have been involved in making
this moment happen, for their great work!

With the new web page, our presence has not only arrived in the 21st
century. We also have a better portal to catch the different groups
interested in coreboot, in the future: End users, software developers
and hardware manufacturers.

There will be changes, modifications and optimizations in the next
couple of days or weeks, but please feel free to send us feedback on
coreboot's new look and content.

Thanks,
Stefan

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

[coreboot] GNU Libreboot, version 20160907 released

[Leah Rowe]

GNU Libreboot 20160907

This release adds one new mainboard to libreboot:
* Intel D945GCLF desktop motherboard (thanks to Arthur Heymans)

For existing boards, there are no new board specific changes.

Get it from:
https://libreboot.org/download/

Other bugfixes:
* Various improvements to the documentation
* re-added "unset superusers" to the grub.cfg, which was needed for some
users depending on the distros that they used

GNU Libreboot 20160902

This is a bugfix release, based on 20160818. It contains no new board
changes. The previous 20160818 release had build errors in the _src
archive, and the _util archive was only source code.

Changes compared to 20160818:
* Fixed bug where ./build module coreboot always returned non-zero status
* Fixed missing symlink of crossgcc when building from _src (thanks
Arthur Heymans)
* Fixed building with the depthcharge payload (ASUS C201)
* Proper ChangeLog now, instead of pasted git log
* Util archive is now binaries again (source code is in the _src archive)
* Documentation is now in HTML format

GNU Libreboot 20160818

This is a brand GNU release. Libreboot joined the GNU project on 14
May 2016. This 18 August 2016 release is the first GNU release of
libreboot.

NEW BOARDS ADDED:
* ASUS Chromebook C201 (ARM laptop) (thanks to Paul Kocialkowski)
* Gigabyte GA-G41M-ES2L motherboard (desktop) (thanks to Damien Zammit)
* Intel D510MO motherboard (desktop) (thanks to Damien Zammit)
* ASUS KCMA-D8 motherboard (desktop) (thanks to Timothy Pearson)
* ASUS KFSN4-DRE motherboard (server) (thanks to Timothy Pearson)
* ASUS KGPE-D16 motherboard (server) (thanks to Timothy Pearson)
For details development history on these boards, refer to the git log
and documentation.

For boards previously supported, many fixes from upstream have been
merged.

Other changes (compared to libreboot 20150518), for libreboot in
general or for previously supported systems:
(this is a summary. For more detailed change list, refer to the git log)

256MiB VRAM allocated on GM45 (X200, T400, T500, R400) instead of
32MiB. This is an improvement over both Lenovo BIOS and Libreboot
20150518, allowing video decoding at 1080p to be smoother. (thanks
Arthur Heymans)
To clarify, GM45 video performance in libreboot 20160818 is better
than on the original BIOS and the previous libreboot release.

64MiB VRAM on i945 (X60, T60, MacBook2,1) now supported in
coreboot-libre, and used by default (in the previous release, it was
8MiB allocated). Thanks to Arthur Heymans.

Higher battery life on GM45 (X200, T400, T500, R400) due to higher
cstates now being supported (thanks Arthur Heymans). C4 power states
also supported.

Higher battery life on i945 (X60, T60, MacBook2,1) due to better CPU
C-state settings. (Deep C4, Dynamicl L2 shrinking, C2E).

Text mode on GM45 (X200, T400, T500, R400) now works, making it
possible to use MemTest86+ comfortably. (thanks to Nick High from
coreboot)

Dual channel LVDS displays on GM45 (T400, T500) are now automatically
detected in coreboot-libre. (thanks Vladimir Serbinenko from coreboot)

Partial fix in coreboot-libre for GRUB display on GM45, for dual
channel LVDS higher resolution LCD panels (T400, T500). (thanks Arthur
Heymans)

Massively improved GRUB configuration, making it easier to boot more
encrypted systems automatically, and generally a more useful menu for
booting the system (thanks go to Klemens Nanni of the autoboot project).
Libreboot now uses the grub.cfg provided by the installed GNU/Linux
distribution automatically, if present, switching to that
configuration. This is done across many partitions, where libreboot
actively searches for a configuration file
(also on LVM volumes and encrypted volumes). This should make
libreboot more easy to use for non-technical users, without having to
modify the GRUB configuration used in libreboot.

Utilities archives is now source only. You will need to compile the
packages in there (build scripts included, and a script for installing
build dependencies in Trisquel 7). (binary utility archives are
planned again in the next release, when the new build system is merged)

SeaGRUB is now the default payload on all x86 boards. (SeaBIOS
configured to load a compressed GRUB payload from CBFS immediately,
without providing an interface in SeaBIOS. This way, GRUB is still
used but now BIOS services are available, so you get the best of both
worlds). Thanks go to Timothy Pearson of coreboot for this idea.

crossgcc is now downloaded and built as a separate module to
coreboot-libre, with a universal revision used to build all boards.

Individual boards now have their own coreboot revision and patches,
independently of each other board. This makes maintenance easier.

Updated all utilities, and modules (coreboot, GRUB, etc) to newer
versions, with various bugfixes and improvements upstream.

RTC century byte issue now fixed on GM45 in coreboot-libre, so the
date should now be correctly displayed when running the latest linux
kerne

Re: [coreboot] Proposal for new "Commenting" wiki text

[Nico Huber]

On 05.09.2016 18:34, tmiket wrote:
> On 2016-09-04 12:36, Martin Roth wrote:
>> Hey Nico,Thanks for writing that up and not just letting this drop
>> with no
>> resolution and action.
>>
>> To anyone just coming in on the discussion, here's what we're talking
>> about
>> changing:
>> https://www.coreboot.org/Coding_Style#Commenting
> 
> I am new to this discussion and to coreboot.

Welcome to coreboot, then :)

> 
> This appears to be a "hidden" page in that the TOC on top left doesn't have
> a link called Coding Style.  Is this a new work in progress page?

I wouldn't call it "hidden". As with most wikis, there is just no com-
prehensive TOC.

>
> It appears more detailed than the corresponding Coding Style in the
> Development Guidelines page.

Actually, that page links to Coding_Style in section 2.5. But maybe we
should link it on the Welcome page, too.

Regards,
Nico

> 
> I'm asking because I start a new job that uses coreboot and I'm working
> my way through the online documentation.
> Cheers,
> T.mike
> 
>>
>> I'd suggest just a couple of changes to your update:
>>
>> Let's define what a "short" comment is to avoid future arguments that
>> 10
>> lines is short:
>>>   /* This is the preferred style for
>>>  two or three line comments that
>>>  avoids excessive blank lines. */
>>
>> And I'm not certain of this paragraph, and I'd recommend removing or
>> changing it a bit.
>>
>>> In case of doubt, the author of the code shall have the last word on
>>> comment styles. He should know best which style makes his code most
>>> readable.
>>
>> 1) I think that Stefan as the project leader should have the decision
>> about
>>  anything that is controversial enough to need a last word.
>> 2) What if the author is female?  :)  Maybe use 'they' as the pronoun
>> if this
>>
>> paragraph is left in.  Not a big deal, but I'd like to be inclusive.
>>
>> 3) I think this might be just asking for arguments.  I'm not talking
>> about anyone
>> specific, just thinking of discussions in the past.
>>  -- "As the author I LIKE ascii art in my comments and I get the final
>> say."
>>  -- We're going to get lawyer arguments: "It says above that the c99
>> style
>> is valid - why can't we just prefix the whole 16 line block with
>> '//'"?
>>  -- "I know it says not to say 'increment i', but as the author, I
>> think it's
>>  helpful."
>> 4) I think this would be the only "the author has the final say"
>> policy - what
>> happens when someone rewrites the comment in a following patch?  Who
>> is the author?
>>
>> Maybe we could change it from "has the last word" to something saying
>> like:
>>
>>> If the author has reasonable arguments for breaking the recommended
>>> style guide to improve readability, others should be respectful of
>> those
>>> differences.
>>
>> I think this preserves the intent without some of the issues.
>>
>> Martin
>>
>> On Sun, Sep 4, 2016 at 8:42 AM, Nico Huber  wrote:
>>
>>> Hi folks,
>>>
>>> I think we kind of agreed that the wiki text about "Commenting"
>>> should
>>> change. So here is my proposal, feel free to edit, add something or
>>> just
>>> ack or complain about it.
>>>
 == Commenting ==

 Comments are good, but there is also a danger of over-commenting.
>>> NEVER
 try to explain HOW your code works in a comment: it's much better
>>> to
 write the code so that the _working_ is obvious, and it's a waste
>>> of
 time to explain badly written code.

 Generally, you want your comments to tell WHAT your code does, not
>>> HOW.
 Also, try to avoid complex comments inside a function body: if the
 function is so complex that you need to separately comment parts
>>> of it,
 you should probably go back to chapter 6 for a while.  You can
>>> make
 small comments to note or warn about something particularly clever
>>> (or
 ugly), but try to avoid excess.  Instead, put the comments at the
>>> head
 of the function, telling people what it does, and possibly WHY it
>>> does
 it.

 coreboot style for comments is the C89 "/* ... */" style. You may
>>> also
 use C99-style "// ..." comments.

 The preferred style for concise multi-line comments that explain a
 single piece of code is:

 /* This is the preferred style for
 shorter multi-line comments that
 avoids excessive blank lines. */

 Note that there shouldn't be leading asterisks on new lines in the
 concise style.

 The preferred style for long multi-line comments is:

 /*
 * This is the preferred style for multi-line
 * comments in the coreboot source code.
 *
 * Description: A column of asterisks on the left side,
 * with beginning and ending almost-blank lines.
 */

 Some rules of thumb to decide which style to use:
 * If you are commenting a whole function (indentation level 0) or
 something high level (indentation level 1), use the long 

Re: [coreboot] Proposal for new "Commenting" wiki text (was: [RFC] Deciding on style for multi-line comments)

[Nico Huber]

On 06.09.2016 00:04, Vadim Bendebury wrote:
> On Sun, Sep 4, 2016 at 7:42 AM, Nico Huber  wrote:
> 
>> Hi folks,
>>
>> I think we kind of agreed that the wiki text about "Commenting" should
>> change. So here is my proposal, feel free to edit, add something or just
>> ack or complain about it.
>>
>>> == Commenting ==
>>>
>>> Comments are good, but there is also a danger of over-commenting. NEVER
>>> try to explain HOW your code works in a comment: it's much better to
>>> write the code so that the _working_ is obvious, and it's a waste of
>>> time to explain badly written code.
>>>
>>> Generally, you want your comments to tell WHAT your code does, not HOW.
>>> Also, try to avoid complex comments inside a function body: if the
>>> function is so complex that you need to separately comment parts of it,
>>> you should probably go back to chapter 6 for a while.  You can make
>>> small comments to note or warn about something particularly clever (or
>>> ugly), but try to avoid excess.  Instead, put the comments at the head
>>> of the function, telling people what it does, and possibly WHY it does
>>> it.
>>>
>>> coreboot style for comments is the C89 "/* ... */" style. You may also
>>> use C99-style "// ..." comments.
>>>
>>> The preferred style for concise multi-line comments that explain a
>>> single piece of code is:
>>>
>>>   /* This is the preferred style for
>>>  shorter multi-line comments that
>>>  avoids excessive blank lines. */
>>
> 
> why does the concise style have to be so different from the verbose style?
> Lines starting with '* ' are easier identifiable as comments.

Well, until now, there were only arguments against and none for the lea-
ding asterisk. In [1] Linus calls it "visually unbalanced".

And let me quote my argument:
> But I'm really with Linus when it comes to the leading, single asterisk.
> It looks totally weird, IMHO
> 
>   /* A small, concise comment
>  that doesn't fit a single line */
> 
> is easier for the eye than
> 
>   /* A small, concise comment
>* that doesn't fit a single line */
> 
> where your eyes somehow stick on the asterisk first and then have to
> search for the real start of the line.

Nico

[1] https://lkml.org/lkml/2016/7/8/625

> 
> --vb
> 
> 
> 
> 
>>>
>>> Note that there shouldn't be leading asterisks on new lines in the
>>> concise style.
>>>
>>> The preferred style for long multi-line comments is:
>>>
>>>   /*
>>>* This is the preferred style for multi-line
>>>* comments in the coreboot source code.
>>>*
>>>* Description: A column of asterisks on the left side,
>>>* with beginning and ending almost-blank lines.
>>>*/
>>>
>>> Some rules of thumb to decide which style to use:
>>> * If you are commenting a whole function (indentation level 0) or
>>>   something high level (indentation level 1), use the long style.
>>> * If you want to explain a single piece of code and your comment
>>>   doesn't span multiple paragraphs, use the concise style.
>>> * Otherwise you might want to ask yourself why what you're going to
>>>   explain doesn't deserve an own function.
>>>
>>> It's also important to comment data, whether they are basic types or
>>> derived types.  To this end, use just one data declaration per line (no
>>> commas for multiple data declarations).  This leaves you room for a
>>> small comment on each item, explaining its use.
>>>
>>> In case of doubt, the author of the code shall have the last word on
>>> comment styles. He should know best which style makes his code most
>>> readable.
>>
>> Nico
>>
> 


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

Re: [coreboot] Proposal for new "Commenting" wiki text (was: [RFC] Deciding on style for multi-line comments)

[Nico Huber]

On 04.09.2016 21:36, Martin Roth wrote:
> Hey Nico,
> Thanks for writing that up and not just letting this drop with no
> resolution and action.
> 
> To anyone just coming in on the discussion, here's what we're talking about
> changing:
> https://www.coreboot.org/Coding_Style#Commenting
> 
> 
> I'd suggest just a couple of changes to your update:
> 
> Let's define what a "short" comment is to avoid future arguments that 10
> lines is short:
>>   /* This is the preferred style for
>>  two or three line comments that
>>  avoids excessive blank lines. */
> 

Sounds good.

> 
> And I'm not certain of this paragraph, and I'd recommend removing or
> changing it a bit.
> 
>> In case of doubt, the author of the code shall have the last word on
>> comment styles. He should know best which style makes his code most
>> readable.
> 
> 1) I think that Stefan as the project leader should have the decision about
>  anything that is controversial enough to need a last word.
> 2) What if the author is female?  :)  Maybe use 'they' as the pronoun if
> this
> paragraph is left in.  Not a big deal, but I'd like to be inclusive.
> 3) I think this might be just asking for arguments.  I'm not talking about
> anyone
> specific, just thinking of discussions in the past.
>  -- "As the author I LIKE ascii art in my comments and I get the final say."
>  -- We're going to get lawyer arguments: "It says above that the c99 style
> is valid - why can't we just prefix the whole 16 line block with '//'"?
>  -- "I know it says not to say 'increment i', but as the author, I think
> it's
>  helpful."
> 4) I think this would be the only "the author has the final say" policy -
> what
> happens when someone rewrites the comment in a following patch?  Who
> is the author?
> 
> Maybe we could change it from "has the last word" to something saying like:
> 
>> If the author has reasonable arguments for breaking the recommended
>> style guide to improve readability, others should be respectful of those
>> differences.
> 
> I think this preserves the intent without some of the issues.
> 

Yes, that's much better. I just included that paragraph as I remembered
something like "the author should know best" from the discussion.

Thank you,

Nico


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

[coreboot] Coreboot with ipxe for Pc Engines Alix2d13

[Reto Rayen]

Hello guys

I did tried now to bring up a «Pc Engines Alix2D13» with ipxe. But still it is 
not working. I freshly cloned the latest coreboot repo today evening and 
enabled ipxe as payload within the coreboot config. But it never starts/appears 
in the boot sequence. Below you find a log of the boot sequence and my coreboot 
config file. It’s mostly Default values. It uses a vsa Image to boot up. 
Otherwise coreboot would not work. For me it Looks like, that the pci devices 
never get detected correctly and because of this the ipxe payload is not 
started. Below the links to the boot sequence and config files:

Coreboot Log: http://pastebin.com/40Bz8uAm
Coreboot Config: http://pastebin.com/vFRwi4hi

Any help is very appreciated


Kind regards
Reto Rayen
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] anyone use coreboot on Lenovo T520?

[Iru Cai]

Hi community,

I've had this problem for a long time, but I don't feel like to ask it
until some one ask me about this problem.

Lenovo T520 has a BIOS chip under the magnesium structure frame, and
it may have a WSON package, so I solder a pin connector at the `J100'
solder place. (https://www.coreboot.org/Board:lenovo/t520#Flashing)
However, I don't know whether it can cause problems. I flashed two
pieces of T520 mainboard (without nVIDIA GPU) before, and after it had
coreboot installed, the system could hang randomly, I don't know what
had happened. I hadn't tested it with the pin connector soldered and
factory firmwae.

So I hope some one with this laptop can report some status in using.

Regards,
Iru


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot