coreboot August 2015

coreboot@coreboot.org

45 participants
86 discussions

by 蝈蝈

Dear Mr/Ms， I am very excited to read the slide "Gerrit: how to cook a plugin in only 10 mins". Now I have a problem about how to build a gerrit plugin to display all the projects' name. Could you help me? Firstly, I built the gerrit platform and achieved the servertime gerrit plugin (the example in the slide). In the attachment, you can find the achievement of this step (servertime.png). Secondly, I followed the flow of the servertime gerrit plugin, I build a new java file (ProjectList.java), and I want to get the list of all the projects' name in the Gerrit through this projectlist gerrit plugin. In the attachment,I just write the head of class ProjectList (projectlist.png), I don't know whether it is right. Could you tell me how to write the class ProjectList to get all the projects' name? I am looking forward to hearing from you. Best Wishes, Zhaoguo Liu National Key Laboratory of Cognitive Neuroscience and Learning No. 19, XinJieKouWai St., HaiDian District, Beijing 100875, P. R. China 夏日畅销榜大牌美妆只要1元夏日畅销榜大牌美妆只要1元

4 years, 11 months

sincerely consult about Gerrit plugin

by 蝈蝈

4 years, 11 months

Re: [coreboot] From wildcat linking to exploring new languages

by Peter Stuge

ron minnich wrote: > If people feel strongly enough about this then we can do an > external repo for now. > > Nico, do you want to set up a github repo There are more options than the coreboot repository and github. If Nico is willing to push the code to coreboot.org then I think a separate repository on coreboot infrastructure is the perfect place. //Peter

4 years, 11 months

Acer Chromebook 15 debug

by John Lewis

Hi Guys, Coolstar Organisation wants to do his Windows thang with one of the Broadwell Chromebooks, so I'm trying to build a working ROM with https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmwar… to give him a hand. Luckily USB debug works with this, so here is what I'm getting. What could I do next? -John. coreboot-5cbe3a8-dirty romstage Sun Aug 23 12:18:55 BST 2015 starting... PM1_STS: 8910 PM1_EN: 0000 PM1_CNT: 00000000 TCO_STS: 0000 0000 GPE0_STS: 1ef82df0 187d4fdf 0005f240 00000000 GPE0_EN: 00000000 00000000 00000000 00000000 GEN_PMCON: 0200 2024 520b Previous Sleep State: S5 CPU: Intel(R) Core(TM) i3-5005U CPU @ 2.00GHz CPU: ID 306d4, Broadwell E0 or F0, ucode: 0000001d CPU: AES supported, TXT NOT supported, VT supported MCH: device id 1604 (rev 09) is Broadwell F0 PCH: device id 9cc5 (rev 03) is Broadwell U Base IGD: device id 1616 (rev 09) is Broadwell U GT2 CPU: frequency set to 2000 MHz SPD: index 1 (GPIO47=0 GPIO9=0 GPIO13=1) 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) Boot Count incremented to 8 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 FMAP found at ffe10000. FMAP: area RW_MRC_CACHE not found No MRC cache found. Starting Memory Reference Code Initializing Policy Installing common PPI MRC: Starting... Initializing Memory MRC: Done. MRC Version 2.6.0 Build 0 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 (00780008): enhanced interleave mode on rank interleave on DIMMA 2048 MB width x16 single rank, selected DIMMB 0 MB width x16 single rank CBMEM: root @ 7cfff000 254 entries. MRC data at ff7d0d9c 6246 bytes Relocate MRC DATA from ff7d0d9c to 7cfeb000 (6246 bytes) create cbmem for dimm information

4 years, 11 months

New on blogs.coreboot.org: coreboot changelog – Weeks of 2015-08-10 and 2015-08-17

by WordPress

4 years, 11 months

coreboot as a system startup device

by Gregg Levine

Hello! Is Google using coreboot as a method to start and manage its systems? Especially since the open source gang at Facebook of all places is realizing that the bottleneck towards getting their systems to run capably happens to be its low level firmware. Of course the chap at the NYLUG meeting for Wednesday 8/26 all but admitted that they were using Intel based servers back there, so I did not mention what goes on here. The presentation should be up on the NYLUG Youtube channel in a matter of weeks. ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

4 years, 11 months

Re: [coreboot] From wildcat linking to exploring new languages

by Carl-Daniel Hailfinger

On 28.08.2015 18:29, ron minnich wrote: > I would really like this to be in the tree. It gives us a chance to do > things in coreboot that go beyond C and assembly. So that's my $.02. Same here. Besides that, SPARK gives us easier provability of code. That is something governments and safety engineers care about, and it makes for great marketing. > What harm would it do? Having it in the tree would be beneficial because it will be easier to bisect than two separate trees. The only thing I'm worried about is whether we can guarantee the complete tree can be built on all of the platforms where it can be built now, but that worry applies in the git submodule case as well. Regards, Carl-Daniel

4 years, 11 months

Re: [coreboot] From wildcat linking to exploring new languages

by Nico Huber

Am 28.08.2015 17:51, schrieb Patrick Georgi: > 2015-08-28 17:35 GMT+02:00 Nico Huber <nico.huber(a)secunet.com>: >> I don't know if the real problem was that libpayload resides in >> it's own repository. > libpayload still shares a repo with coreboot. There were ideas to > separate them, but that never materialized. Ah, sorry. Got confused about that. What I meant is that they are not sharing a (code) tree. >> But having simple device drivers in it's own place >> seems to be a good idea, for me. > If you want, I can setup a repo at coreboot.org, mirrored to > github.com/coreboot, and we hook it up as submodule. That would be convenient for external development... > That would place it somewhere below 3rdparty/ for consistency with the > other submodules. That might hinder people from taking part... > Your code, your decision. I can't decide! why did I dare to ask :) Nico -- M. Sc. Nico Huber Senior Berater SINA-Softwareentwicklung Netzwerk- & Client-Sicherheit / Network & Client Security Division Öffentliche Auftraggeber / Public Authorities secunet Security Networks AG Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325 E-Mail: nico.huber(a)secunet.com Mergenthalerallee 77, 65760 Eschborn, Deutschland www.secunet.com ______________________________________________________________________ Sitz: Kronprinzenstraße 30, 45128 Essen, Deutschland Amtsgericht Essen HRB 13615 Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Pleines Aufsichtsratsvorsitzender: Dr. Peter Zattler ______________________________________________________________________

4 years, 11 months

Re: [coreboot] From wildcat linking to exploring new languages

by Nico Huber

Am 28.08.2015 16:12, schrieb ron minnich: > I would say bring it in to the repo. We have assembly, we have our own C > compiler even, so a higher level language hardly seems a bad idea. If this > can make our code base better in some way, why not use it? I'm not concerned about the language. More about the content `device driver`, which could be used anywhere (actually, I first planed to use it in FILO, why is coreboot doing gfx init anyway?). Also, I was bothered some- times when code got copied from coreboot to libpayload or the other way around. I don't know if the real problem was that libpayload resides in it's own repository. But having simple device drivers in it's own place seems to be a good idea, for me. Anyway, I'll push it next week (I guess) when the code got cleared. Nico > > ron > > On Fri, Aug 28, 2015 at 4:55 AM Nico Huber <nico.huber(a)secunet.com> wrote: > >> Am 21.08.2015 22:47, schrieb ron minnich: >>> This sounds wonderful. I'm all for it. >> Did you just kill any discussion with that line? :) >> >> Things live currently in a small library that I called `libsparkhw` >> (came spontaneously, I don't care much about the name). It contains >> some framework (Timer, I/O, Debugging) to do hardware stuff in SPARK, >> plus the mentioned graphics initialization. I falter to push it directly >> for inclusion into the coreboot repo. Maybe we want a separate reposi- >> tory for it (like libpayload has)? It would also make it easier to use >> it in other components (e.g. bootloaders and such, and of course our own >> products where the code stems from). >> >> We have discussed the licensing and will push this under GPLv2 + later >> if there are no reasonable concerns. >> >> Nico >> -- M. Sc. Nico Huber Senior Berater SINA-Softwareentwicklung Netzwerk- & Client-Sicherheit / Network & Client Security Division Öffentliche Auftraggeber / Public Authorities secunet Security Networks AG Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325 E-Mail: nico.huber(a)secunet.com Mergenthalerallee 77, 65760 Eschborn, Deutschland www.secunet.com ______________________________________________________________________ Sitz: Kronprinzenstraße 30, 45128 Essen, Deutschland Amtsgericht Essen HRB 13615 Vorstand: Dr. Rainer Baumgart (Vors.), Thomas Pleines Aufsichtsratsvorsitzender: Dr. Peter Zattler ______________________________________________________________________

4 years, 11 months

Re: [coreboot] From wildcat linking to exploring new languages

by Patrick Georgi

2015-08-28 16:13 GMT+02:00 Aaron Durbin <adurbin(a)google.com>: > Does this mean we can start writing our userland tools in golang? If you can provide portability guarantees for userland compilers like we do for target compilers... (which is one of my main worries right now: gnat requires an ada compiler to build itself, but even that is pretty portable compared to what's going on with golang) 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

4 years, 11 months

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

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot August 2015