coreboot February 2015

coreboot@coreboot.org

45 participants
93 discussions

Re: [coreboot] GSOC 2015 Preperations
by Alexandru Gagniuc 18 Feb '15

18 Feb '15

On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote: > Hi Everyone, > Hi, > Please update the wiki page with project ideas. > http://www.coreboot.org/Project_Ideas > That's the first unlocked page in the coreboot wiki I have seen for quite some time. Alex

3 2

Re: [coreboot] Unifying IO accessor macros
by David Hendricks 18 Feb '15

18 Feb '15

On Wed, Feb 18, 2015 at 10:52 AM, Julius Werner <jwerner(a)chromium.org> wrote: > >> As Patrick already said, compared to the total effort to integrate > external > >> sources, the issue of argument order is insignificant. In the time you > spent > >> writing this email, you could have found out how to do it with > coccinelle, and > >> could have applied it to any number of sources. > > > > http://review.coreboot.org/8483 > > Remember that those other code bases use writel(v, a), not write32(v, > a). Just going half the way by changing the order but not the name > wouldn't be very useful I think. > Yes, fixing the order is far more important. I wouldn't even care if we still end up with both write32(a, v) or writel(a, v) in the codebase (or u32 vs. uint32_t), so long the usage is consistent and wrappers are trivial. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Re: [coreboot] Unifying IO accessor macros
by Alexandru Gagniuc 18 Feb '15

18 Feb '15

On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote: > As I have noted on http://review.coreboot.org/#/c/7924/ it's very > short sighted to go this route. In assembling a coreboot stack (which > includes libpayload and the payload itself) the code usually comes > from different software systems. Those include libpayload, linux > kernel, u-boot, etc. They all have the write(val, addr) semantics. I > see no good reason to artificially erect an ever present barrier for > integrating code into a coreboot system. > As Patrick already said, compared to the total effort to integrate external sources, the issue of argument order is insignificant. In the time you spent writing this email, you could have found out how to do it with coccinelle, and could have applied it to any number of sources. > Alex, you've clearly stated your opinion you've not justified a reason > for keeping the barrier. If you think that something as simple as this is a barrier, then you're likely just copypasting code. In that case, I do want a barrier to protect you from yourself, and from putting up code that was no reviewed in its entirety. Really, it's not a barrier. Alex

3 2

Re: [coreboot] Unifying IO accessor macros
by Stefan Reinauer 18 Feb '15

18 Feb '15

* Julius Werner <jwerner(a)chromium.org> [150218 00:12]: > I'd like to propose an API change/cleanup for a long-standing problem > with architecture-independent code that people have hit and privately > discussed/cursed multiple times already, but no one really had time to > make the big change/fix yet. (Some earlier discussion among Chromium > people about this is available at http://crbug.com/451388 ) [..] I think nobody disagrees that type checking is a bad idea here. It was a mistake to let type checking free versions of these accessors slip into the tree into the first place. The second part is a little bit more prone to personal preferences. - Using 8 / 16 / 32 / 64 for data size is more explicit that b / w / l / q - (addr, val) is more aligned with other APIs in coreboot - Using the Linux API as a standard will make it easier for people to switch between code bases, and thus is a lot less error prone - Using the Linux API makes it easier to share code with other projects. such as u-boot, Linux, libpayload based projects Since there is no clear winner, I would like to ask you to participate in a poll to measure what people would prefer: http://doodle.com/3dwbudycrypg9xyf Stefan

1 0

[ANNOUNCE] SeaBIOS 1.8.0
by Kevin O'Connor 18 Feb '15

18 Feb '15

The 1.8.0 version of SeaBIOS has now been released. For more information on the release, please see: http://seabios.org/Releases New in this release: * Several USB timing fixes for USB controllers on real hardware * Initial support for USB3 hubs * Initial support for SD cards (on QEMU only) * Initial support for transitioning to 32bit mode using SMIs (on QEMU TCG only) * SeaVGABIOS improvements * Added cursor emulation to coreboot native init vgabios (cbvga) * Added support for read character calls when in graphics mode * Developer documentation added to "docs/" directory in the code repository and several documentation updates * Several bug fixes and code cleanups For information on obtaining SeaBIOS, please see: http://seabios.org/Download

1 0

Re: [coreboot] Unifying IO accessor macros
by Alex G. 18 Feb '15

18 Feb '15

On 02/18/2015 12:52 PM, Julius Werner wrote: > FWIW I sightly prefer write32(a, v) Then go for it. Alex

1 0

Re: [coreboot] Unifying IO accessor macros
by Julius Werner 18 Feb '15

18 Feb '15

>> As Patrick already said, compared to the total effort to integrate external >> sources, the issue of argument order is insignificant. In the time you spent >> writing this email, you could have found out how to do it with coccinelle, and >> could have applied it to any number of sources. > > http://review.coreboot.org/8483 Remember that those other code bases use writel(v, a), not write32(v, a). Just going half the way by changing the order but not the name wouldn't be very useful I think. FWIW I sightly prefer write32(a, v) for purely aesthetic reasons (it's also more in line with our current setbits_le32(a, v)), but I really don't care much as long as we make a decision at all. There's currently ~3500 write32()s in upstream coreboot and ~2800 writel()s in Chromium coreboot (which has more ARM code), so now the impact for going either direction should be roughly the same.

1 0

Re: [coreboot] Unifying IO accessor macros
by Patrick Georgi 18 Feb '15

18 Feb '15

2015-02-18 18:35 GMT+01:00 Aaron Durbin via coreboot <coreboot(a)coreboot.org>: > coreboot is different than: > 1. linux > 2. uboot And similar to Solaris, Windows and the BSDs. As for libpayload, I'd rather import code from BSD than Linux for licensing reasons. > 3. libpayload > 4. Anything using libpayload Which could be fixed (since some changes are necessary in any case) Patrick -- Google Germany GmbH ABC-Str. 19 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores

1 0

Re: [coreboot] Unifying IO accessor macros
by Alexandru Gagniuc 18 Feb '15

18 Feb '15

On Wednesday, February 18, 2015 11:50:04 AM Aaron Durbin wrote: > On Wed, Feb 18, 2015 at 11:41 AM, Alexandru Gagniuc > > And you still haven't responded to my proposal of using EFI style. > > I thought that was a non-sensical proposal. My point exactly. Alex

1 0

Re: [coreboot] Unifying IO accessor macros
by Alexandru Gagniuc 18 Feb '15

18 Feb '15

On Wednesday, February 18, 2015 11:35:13 AM Aaron Durbin wrote: > You still haven't made any counter-argument to the practicalness of being > compatible with the software systems where coreboot gets contribution. > And you still haven't responded to my proposal of using EFI style. Alex

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
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 February 2015