coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

Thinkpad X230: store the proprietary VGA bios in the blobs repo?
by Martin Kepplinger 16 May '18

16 May '18

Hi, As documented at https://www.coreboot.org/Board:lenovo/x230#Proprietary_components.27_status and verified by my recent tests, anyone running GRUB on the harddrive or Windows, needs an extracted VGA bios binary on the X230. This is identical for all X230 models. There have been vga bios binaries in the blobs repo in the past, so why not put this in? Is there a place inside blobs, the coreboot build can pick it up from, automatically? I guess a new config option would be needed here, but I'm not entirely sure. Unfortunately I haven't yet found a license applying to it. I'm thankful for hints. thanks, martin

3 2

Re: [coreboot] Proposing a change to Coding Style
by Felix Held 16 May '18

16 May '18

Hi! > I hereby propose that > going forward, we should always wrap conditional blocks in braces, even > one-liners. I'd also like to have this change, since it might prevent bugs and doesn't add too much verbosity. Related question: Should the else line in if else statements look like this: } else { The else won't start in the same column as the corresponding if, but this would save one line compared to having the closing curly brace on one line and the else on the next one. Regards Felix

2 1

Re: [coreboot] Proposing a change to Coding Style
by Vadim Bendebury 16 May '18

16 May '18

Speaking of coding style: there is no pre-upload check configured in the coreboot git repo, if I am not mistaken, should one be added? As for this particular change - I don't like wasting vertical space, but looks like overwhelming sentiment is supporting this proposal, so I sure can live with it, especially if there is a pre-upload check to enforce it. -vb On Wed, May 16, 2018 at 8:16 AM Patrick Georgi via coreboot < coreboot(a)coreboot.org> wrote: > Hi everybody, > > after just running into an issue on the EC code base, I hereby propose that > going forward, we should always wrap conditional blocks in braces, even > one-liners. > That is: > > if (foo) { > bar(); > } > > instead of > > if (foo) > bar(); > > It doesn't hurt too much but saves us from accidentally adding baz() after > bar(), forgetting to add the - now required - braces. If we get rough > consensus over this, I'd change Coding_Style to match. > > > Thoughts? > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Proposing a change to Coding Style
by Nico Huber 16 May '18

16 May '18

On 16.05.2018 17:15, Patrick Georgi via coreboot wrote: > Hi everybody, > > after just running into an issue on the EC code base, I hereby propose that > going forward, we should always wrap conditional blocks in braces, even > one-liners. > That is: > > if (foo) { > bar(); > } > > instead of > > if (foo) > bar(); > > It doesn't hurt too much but saves us from accidentally adding baz() after > bar(), forgetting to add the - now required - braces. If we get rough > consensus over this, I'd change Coding_Style to match. > +2 as long as we make it clear that we are talking about future code. Nobody should run around and revise existing code; it's too easy to "fix" code that is working fine but is badly indented. Nico

1 0

Re: [coreboot] Proposing a change to Coding Style
by Jonathan A. Kollasch 16 May '18

16 May '18

On Wed, May 16, 2018 at 05:15:44PM +0200, Patrick Georgi via coreboot wrote: > Hi everybody, > > after just running into an issue on the EC code base, I hereby propose that > going forward, we should always wrap conditional blocks in braces, even > one-liners. > That is: > > if (foo) { > bar(); > } > > instead of > > if (foo) > bar(); > > It doesn't hurt too much but saves us from accidentally adding baz() after > bar(), forgetting to add the - now required - braces. If we get rough > consensus over this, I'd change Coding_Style to match. I whole-heartedly endorse this proposal. I was recently disappointed to see these braces being removed from code that I wrote. I had included these braces based on the same reasoning you use here. At the very least, I would like to see the coding style not forbid these "extra" braces. Jonathan Kollasch

1 0

Re: [coreboot] Proposing a change to Coding Style
by ron minnich 16 May '18

16 May '18

I sfrongly support this idea. The list of bugs that have occurred due to simple lacking {} is long. It's even harder now that people who use Python and C sometimes glitch when moving back and forth and forget that indentation in C is meaningless. I ran a piece of broken C (multi-line if missing {}) by a Python/C programmer just now, with this error, and they did not even call it out, even after I gave them some hints. They were in Python mode today. It's one extra set of {} but a huge amount of potential to reduce attack surface. A bit more text is worth the insurance. ron On Wed, May 16, 2018 at 8:17 AM Patrick Georgi via coreboot < coreboot(a)coreboot.org> wrote: > Hi everybody, > > after just running into an issue on the EC code base, I hereby propose that > going forward, we should always wrap conditional blocks in braces, even > one-liners. > That is: > > if (foo) { > bar(); > } > > instead of > > if (foo) > bar(); > > It doesn't hurt too much but saves us from accidentally adding baz() after > bar(), forgetting to add the - now required - braces. If we get rough > consensus over this, I'd change Coding_Style to match. > > > Thoughts? > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > <https://maps.google.com/?q=ABC-Str.+19,+20354+Hamburg&entry=gmail&source=g> > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Proposing a change to Coding Style
by Patrick Georgi 16 May '18

16 May '18

Hi everybody, after just running into an issue on the EC code base, I hereby propose that going forward, we should always wrap conditional blocks in braces, even one-liners. That is: if (foo) { bar(); } instead of if (foo) bar(); It doesn't hurt too much but saves us from accidentally adding baz() after bar(), forgetting to add the - now required - braces. If we get rough consensus over this, I'd change Coding_Style to match. Thoughts? Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

SPI TPM question
by Jorge Fernandez Monteagudo 15 May '18

15 May '18

Hi all! This is my first message to the list. I would like to know if the TPM1.2 is supported through SPI? Enabling SPI_TPM and TPM in my board configuration throw an error. From src/drivers/spi/tpm/Kconfig I can see the dependency: config SPI_TPM bool "SPI TPM" depends on TPM2 Any options to get TPM1.2 SPI support? Thanks! Jorge

1 0

Re: [coreboot] coreboot release 4.8 - Targeting May 15.
by Paul Menzel 15 May '18

15 May '18

Dear Martin, Am Donnerstag, den 03.05.2018, 20:21 -0500 schrieb Martin Roth: > The coreboot 4.8 release is planned for May 15. That's the day that we'll > choose the commit to base the release on and create the release tag in > git. The tarballs will be available on the website shortly afterwards. Thank you for getting the next release out. It’d be great to have the two changes below included. 1. payloads/cbui: Add new payload CBUI [1] and libpayload dependencies 2. cbfs/payload type: Fix build warning and whitespace in name [2] […] Thanks, Paul [1] https://review.coreboot.org/#/c/coreboot/+/23586/ [2] https://review.coreboot.org/#/c/coreboot/+/26240/

1 0

Re: [coreboot] [flashrom] MX66l51235f
by Nico Huber 14 May '18

14 May '18

Hi Ron, On 14.05.2018 18:01, ron minnich wrote: > anyone got the incantation to flash this with an sf100 ;-) TLDR; If it doesn't work with current master, you can try [1]. 512M, huh? what's that for, UbuntuBoot? xD You need 4-byte addresses to access the full chip and that's rather delicate with Dediprog (because we don't control the SPI commands directly for read and write). The chip supports an extended address register for the most significant byte, though it's unclear to me if this register's state is maintained between Dediprog commands. So it might just work with flashrom master, or might wreak havoc ;) [1] https://review.coreboot.org/19858/

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2018