coreboot September 2016

coreboot@coreboot.org

51 participants
82 discussions

Re: [coreboot] Proposal for new "Commenting" wiki text
by tmiket 07 Sep '16

07 Sep '16

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. 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? It appears more detailed than the corresponding Coding Style in the Development Guidelines page. 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 <nico.h(a)gmx.de> 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 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

2 1

Re: [coreboot] Proposal for new "Commenting" wiki text (was: [RFC] Deciding on style for multi-line comments)
by Nico Huber 07 Sep '16

07 Sep '16

On 06.09.2016 00:04, Vadim Bendebury wrote: > On Sun, Sep 4, 2016 at 7:42 AM, Nico Huber <nico.h(a)gmx.de> 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 >> >

1 0

Re: [coreboot] Proposal for new "Commenting" wiki text (was: [RFC] Deciding on style for multi-line comments)
by Nico Huber 07 Sep '16

07 Sep '16

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

1 0

Coreboot with ipxe for Pc Engines Alix2d13
by Reto Rayen 07 Sep '16

07 Sep '16

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

1 0

anyone use coreboot on Lenovo T520?
by Iru Cai 07 Sep '16

07 Sep '16

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

1 0

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 06 Sep '16

06 Sep '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. 11 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 1 of 1 defect(s) ** CID 1362515: Memory - corruptions (STRING_SIZE) /util/kconfig/conf.c: 602 in main() ________________________________________________________________________________________________________ *** CID 1362515: Memory - corruptions (STRING_SIZE) /util/kconfig/conf.c: 602 in main() 596 break; 597 case allnoconfig: 598 case allyesconfig: 599 case allmodconfig: 600 case alldefconfig: 601 case randconfig: >>> CID 1362515: Memory - corruptions (STRING_SIZE) >>> Assigning: "name" = "getenv". "name" is now tainted. 602 name = getenv("KCONFIG_ALLCONFIG"); 603 if (!name) 604 break; 605 if ((strcmp(name, "") != 0) && (strcmp(name, "1") != 0)) { 606 if (conf_read_simple(name, S_DEF_USER)) { 607 fprintf(stderr, ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Porting Coreboot to SolidPC (intel braswell n37xx)
by Malte Grosse 05 Sep '16

05 Sep '16

Hey All, is anyone interested in porting coreboot to solidpc: http://wiki.solid-run.com/doku.php?id=products:ibx:solidpc I can provide some free hardware samples for developers. just let me know kind regards Malte

1 0

GNU Libreboot, version 20160902 released
by Leah Rowe 02 Sep '16

02 Sep '16

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. Get it from https://libreboot.org/download/ 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 kernel, instead of seeing 1970-01-01 when you boot (thanks to Alexander Couzens from coreboot) Build system now uses multiple CPU cores when building, speeding up building for some people. Manually specifying how many cores are needed is also possible, for those using the build system in a chroot environment. (thanks go to Timothy Pearson from coreboot) In the build system (git repository), https:// is now used when cloning coreboot. http:// is used as a fallback for GRUB, if git:// fail s. New payload, the depthcharge bootloader (free bootloader maintained by Google) for use on the ASUS Chromebook C201. (thanks go to Paul Kocialkowski) Various fixes to the ich9gen utility (e.g. flash component density is now set correctly in the descriptor, gbe-less descriptors now supported) The official documentation included in the release in provided in texinfo format, instead of HTML; this was one of the requirements for joining GNU. (the other requirement is a new build system, to comply with GNU standards, e.g. Makefiles, and common Makefile entries present in all GNU software. As of Libreboot 20160818, this new build system is not yet merged, but will be in the release afterwards) ChangeLog and NEWS files are included in the release, to comply with GNU standards (they are dumps of the git-log output) -- Leah Rowe Libreboot developer Use free software. Free as in freedom. https://www.gnu.org/philosophy/free-sw.html Use a free operating system, GNU/Linux. https://www.gnu.org/ Use a free BIOS. https://libreboot.org/ Support freedom. Join the Free Software Foundation. https://fsf.org/ Minifree Ltd, trading as Ministry of Freedom | Registered in England, No. 9361826 | VAT No. GB202190462 Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK | Web: http://minifree.org/

1 0

GNU Libreboot, version 20160818 released
by Leah Rowe 02 Sep '16

02 Sep '16

1 0

Re: [coreboot] Can boards wake up from S3/4/5 by specific keystroke
by Marshall Dawson 01 Sep '16

01 Sep '16

Zheng, I suspect it's a special keyboard as you suggested. Here is some text from the M93/p Tiny User Guide: *Note: The USB 3.0 connector 4 supports the smart power on feature. If you connect aLenovo-recommended USB 1.1 keyboard to this connector, you can power on the computer or wake it upfrom S4 hibernation mode by pressing Alt+P on the keyboard. Ensure that you use a Lenovo-recommendedkeyboard that supports the smart power on feature.* The last sentence seems to stress that you need a Lenovo keyboard, or maybe they've partnered with others as well. I wonder if the KB is made aware of the sleep state, and then only passes the keystroke through if it's Alt-p. Thanks, Marshall On Thu, Sep 1, 2016 at 2:26 AM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Hello Zheng, > > Since you are asking again, I looked into this problem, in order to > understand the whole PM domain more... Here is my assessment, so I > would advise you to try several options for such a problem. > > I would advise to you the following steps (which, unfortunately, have > nothing to do with Coreboot for the initial test): > > [1] To install the latest BIOS for ThinkCentre M6600q (Lenovo), or to > use the current, present in the platform; > [2] To drive CMOS settings to PM (Power Management) and check if PM is > properly enabled in BIOS (this is a MUST!); > [3] Then, if both steps are done, to install Ubuntu or Fedora Linux > distros (I personally prefer Fedora); > [4] To install the following package in given distro: pm-utils! > https://pm-utils.freedesktop.org/wiki/ > http://pm-utils.freedesktop.org/releases/pm-utils-1.4.1.tar.gz > [5] Then to configure, make and install this package (I did it on my > VM F24 for this purpose, traces imported): > [zoran@localhost Downloads]$ cp pm-utils-1.4.1.tar.gz > /home/zoran/projects/pm-utils > [zoran@localhost Downloads]$ cd /home/zoran/projects/pm-utils > /home/zoran/projects/pm-utils > [zoran@localhost pm-utils]$ ls -al > total 212 > drwxrwxr-x. 2 zoran zoran 4096 Sep 1 09:32 . > drwxrwxr-x. 8 zoran zoran 4096 Sep 1 08:59 .. > -rw-rw-r--. 1 zoran zoran 208687 Sep 1 09:32 pm-utils-1.4.1.tar.gz > [zoran@localhost pm-utils]$ tar -xf pm-utils-1.4.1.tar.gz > [zoran@localhost pm-utils]$ cd pm-utils-1.4.1/ > [zoran@localhost pm-utils-1.4.1]$ ./configure > [zoran@localhost pm-utils-1.4.1]$ make > [zoran@localhost pm-utils-1.4.1]$ sudo make install > [zoran@localhost pm-utils-1.4.1]$ which pm-suspend > /usr/local/sbin/pm-suspend <<======================== S3 state > [zoran@localhost pm-utils-1.4.1]$ which pm-hibernate > /usr/local/sbin/pm-hibernate <<======================= S4 state > > And then try to exercise given commands, and to revive platform using > keyboard/mouse wake up. > > We'll go from there, and we'll try to debug ThinkCentre M6600q > (Lenovo) if it does not work at this stage. > > Maybe somebody can advise you with Coreboot solution... But > essentially, above proposed method by me should work! > > Best Regards, > Zoran > > On Thu, Aug 25, 2016 at 1:05 PM, Zheng Bao <fishbaoz(a)hotmail.com> wrote: > > > > All, > > > > Some customers says ThinkCentre M6600q (lenovo) has the feature of wake > up the system by pressing ALT-P on USB keyboard. > > > > I am wondering how it is implemented? Is it done in chipset, BIOS, or a > special keyboard? > > > > > > Or when the BIOS wakeup, it reads the keystroke to see if it matches the > pre-defined key. Does it sounds reasonable? > > > > > > Zheng > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2016