coreboot February 2014

coreboot@coreboot.org

52 participants
148 discussions

Re: [coreboot] how to model the Quark architecture
by mrnuke 25 Feb '14

25 Feb '14

On Tuesday, February 25, 2014 07:46:50 AM ron minnich wrote: > I plan to use the intel code as as guide, but not pull it in directly. We > have source, we should do it right. I am going to take Aaron's suggestion > and structure it as baytrail is structured. > I was thinking we could put the existing code in vendorcode/, and call that from our stages. No need to make a complete rewrite, and no need to maintain a fork. Of course, this is probably easier said than done, but then we do the same for AGESA. Alex

1 0

Re: [coreboot] how to model the Quark architecture
by ron minnich 25 Feb '14

25 Feb '14

I plan to use the intel code as as guide, but not pull it in directly. We have source, we should do it right. I am going to take Aaron's suggestion and structure it as baytrail is structured. FSP is fine for binary distros, but it's not a good fit if we have the ability to do the whole thing in source form. ron On Tue, Feb 25, 2014 at 5:41 AM, Stojsavljevic, Zoran < zoran.stojsavljevic(a)intel.com> wrote: > -----Original Message----- > > From: coreboot-bounces(a)coreboot.org [mailto: > coreboot-bounces(a)coreboot.org] On Behalf Of Patrick Georgi > > Sent: Tuesday, February 25, 2014 1:13 PM > > To: coreboot(a)coreboot.org > > Subject: Re: [coreboot] how to model the Quark architecture > > > > One problem is that in coreboot development we care about style > (although there will be disagreement to which degree). > > And not just in a formal way (which indent could solve), but I'd rather > not see things like > > (BIT31 | BIT30 | BIT29 | .. all the way down to .. | BIT 1 | BIT 0) in > our tree. > > > > While looking terribly enterprisey, it's just terrible. > > Intel code, at least as far as it is public and not part of the Linux > kernel, manages to collect all the horrible code standards in a single > place. > > I can imagine... Myself, I started looking into the some INTEL source > code, and... But maybe for Quark FSP, there are only three functions which > need to wrap the above mentioned Quark source code, as per general FSP spec: > ROM stage - FSP calls: > TempRamInitEntry(); > FspInitEntry(); > > RAM stage - FSP calls: > NotifyPhaseEntry() - twice invoked! > > Maybe this can isolate (temporarily) the coding style problem, and expose > just FSP I/F - APIs as they are created by FSP spec (as to support and > unify access for other binary FSP blobs) for another CPUs... For the very > beginning! > > This what I have proposed binds to current Coreboot FSP support/framework > for other INTEL CPUs (and can be easily cloned/replicated for Quark > framework, for/per the current INTEL architecture)... I hope! > > Zoran > _______ > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] how to model the Quark architecture
by Stojsavljevic, Zoran 25 Feb '14

25 Feb '14

Hm.... I returned from the vacation, and I am reading this thread. The best to adopt Quark to Coreboot will be to go to: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2 Then to download EDK2 (or from INTEL site, as mention before) for Quark. This should be all Open Source Code, as my best understanding is (somebody correct me if I am wrong). Then to do minimalistic configuration of EDK2, and practically to assemble Quark FSP. And to extract this FSP (SEC and PEI phases, which is not easy at all) as source code from Quark EDK2 source code. Incorporate this into Coreboot as Quark FSP source code. Rest supposed to be straight forward... As Sage did it for IVB (using IVB FSP as binary blob), similar idea for Quark, as then it complies to Coreboot model, with all done by source code (strange to read this for INTEL, isn't it!). _______ Other idea is old one, from this thread, to incorporate the whole EDK2 into Coreboot, but then, EDK2 is UEFI compliant BIOS, as my best understanding is (why then to run Coreboot, instead from UEFI BIOS to transition to legacy GRUB 0.97 with some security features incorporated)! Best Regards, Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". -----Original Message----- From: coreboot-bounces(a)coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Aaron Durbin Sent: Tuesday, February 18, 2014 7:40 PM To: coreboot Subject: Re: [coreboot] how to model the Quark architecture On Tue, Feb 18, 2014 at 10:33 AM, Peter Stuge <peter(a)stuge.se> wrote: > ron minnich wrote: >> I can't understand the point here. >> docs or code would help. > > Aaron Durbin wrote: >> Could you please provide explicit examples having c struct fields >> represented in devicetree that model another address space? > > No I can not. > > I do not have the capacity to deliver the ready-made architecture to > you guys. > > > I'm sorry I said anything, I was silly to think that design discussion > would be possible. I'm sorry you feel that way. I was asking for an example so I could better understand what you were getting at. You mentioned HT being a mistake, and since you noted that I was hoping you had an idea on what you wanted to see. And I don't think anyone was asking for a 'ready-made architecture.' I was seeking clarity. You clearly have opinions on mistakes made in the past, and I was seeking expansion on those opinions aside from the initial statements. Were you wanting some sort of attribute that suggested there is another address space of registers that need to be accessed? And all those registers detailed? -Aaron -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

gerrit changes: Forge author behaviour
by Patrick Georgi 24 Feb '14

24 Feb '14

Hi, I extended our gerrit installation to support "forge author" safely. Forge author is the capability to push changes with an author field different from your own. This is useful when sending patches you've got from someone else while preserving attribution. One downside of this capability, due to which we disabled it for a while, is that it's possible for a change to go through gerrit without the original author noticing. Maybe the author had issues with the change because it was still unfinished - but good enough for others. This is what happened for us. So we now have a new column in gerrit, "AMR" for "Author-Must-Review" that's active if a change is sent with different author and committer fields. Under the new policy, the original author must review the change positively (meaning +1 or +2) before submission is allowed. Of course, the usual rules (Verified +1, Code-Review +2) still apply. There is one notable exception: Since there are some large upstreaming efforts every now and then (mostly by Google), this rule is inconvenient and counter-productive there. We can assume that within such groups, people allow their "designated upstreamer" to push changes for them. Because of this, the feature allows to add teams, where people can publish changes for each others without the new requirement. If you have such needs, please tell me about your team and I'll set it up. This is in testing mode - if you find any weird behaviour or you run into walls because of this change, please tell me. If that model doesn't work out, we'll revert it. But for now, these are the rules. Regards, Patrick

2 1

coreboot accepted to GSoC 2014
by Patrick Georgi 24 Feb '14

24 Feb '14

Hi, coreboot has been accepted to this year's GSoC. Students can apply with projects between March 10th and March 21st, but of course it helps to prepare a project proposal early and with feedback from coreboot developers. If you know someone who's eligible (higher education student) and has interest in firmware development, please pass this on. If you're interested yourself, all the better: you've already subscribed to the right list. More information can be found on GSoC's platform "Melange", https://google-melange.appspot.com/gsoc/org2/google/gsoc2014/coreboot Project ideas can be discussed here, or on IRC: http://www.coreboot.org/IRC Regards, Patrick Georgi

1 0

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02
by HacKurx 24 Feb '14

24 Feb '14

> Peter wrote: >> You might want to test my patch which exposes the IDS options in Kconfig: Thank you for adding this great feature that I hope will be added by default in Kconfig. Unfortunately, this option has no more help me to solve my problem with the richland architecture. With no response from AMD I despair. -- Best regards,

1 0

Need Help!!
by Kevin Rodriguez Roman 21 Feb '14

21 Feb '14

I need help. They gave me a motherboard "asrock g31m-s rev 1.10" problem. Any operating system tells me it is incompatible with ACPI and ACPI 1.1 supposed to support. The only way to make it work with linux kernel is passing to the "acpi = no" parameter. It came with bios version 1.6 (checksum ok) and the un updating with 2.1 "asrock g31m-s rev 2" since rev 1.10 could not find it anywhere. My question is, will this be a hardware problem, will be solved by installing a ROM open-source, for this I need to add the code to the chipset LE82G31 coreboot project. I am from Cuba. Thanks in advance.

1 0

Re: [coreboot] Acer C710-2856 coreboot+seabios blue screen?
by John Lewis 21 Feb '14

21 Feb '14

On 21/02/14 02:02, Justin Roylance wrote: > Ok, so I have downloaded and compiled flashrom from source and it sees > my Winbond flash chip "W25Q64.V". When I first installed coreboot I > backed up my original firmware, but I have two files. The first is from > the command "flashrom -r stock-firmware.rom", and the second is from the > command "chromeos-firmwareupdate --sb_extract ." Both files are the > same size, but diff tells me that they are different. I understand that > the first one is the stock firmware read straight from the flash chip, > and the second command gets you a copy of the parts of the current > firmware which can't be read by flashrom if running on the target > machine. So, which one of these two files do I flash back into my C7? They should be identical save for a missing/invalid serial number from the (S)hell(Ball) created ROM. Flash back the backup ROM. > I read at http://chromebooklinux.blogspot.com/2013_09_01_archive.html > that you can check the validity of a firmware backup by looking at > address 0x00001000 of the firmware file, if that byte contains 0xFF the > backup is invalid, but neither of my two original backup files have 0xFF > at that address. Basically, if you backed the ROM up when the write-protect screw/jumper was still on, you would have a Management Engine binary which is garbage. Even that is okay though, as it won't completely brick your Chromebook, it will just switch it off every 30 mins. Since I haven't completely bricked my chromebook I > want to make sure I don't flash a bad firmware backup in as this might > be my last chance to save it without requiring an external programmer. > > I'm still not sure what went wrong with the original flash, it sounds as though the PCI id's in the ROM for the graphics card are wrong, except that normally you'd get a completely blank screen, not a blue one. I'll have to keep an eye out if anyone else reports that issue. John.

1 0

Re: [coreboot] Acer C710-2856 coreboot+seabios blue screen?
by Justin Roylance 21 Feb '14

21 Feb '14

Ok, so I have downloaded and compiled flashrom from source and it sees my Winbond flash chip "W25Q64.V". When I first installed coreboot I backed up my original firmware, but I have two files. The first is from the command "flashrom -r stock-firmware.rom", and the second is from the command "chromeos-firmwareupdate --sb_extract ." Both files are the same size, but diff tells me that they are different. I understand that the first one is the stock firmware read straight from the flash chip, and the second command gets you a copy of the parts of the current firmware which can't be read by flashrom if running on the target machine. So, which one of these two files do I flash back into my C7? I read at http://chromebooklinux.blogspot.com/2013_09_01_archive.html that you can check the validity of a firmware backup by looking at address 0x00001000 of the firmware file, if that byte contains 0xFF the backup is invalid, but neither of my two original backup files have 0xFF at that address. Since I haven't completely bricked my chromebook I want to make sure I don't flash a bad firmware backup in as this might be my last chance to save it without requiring an external programmer. On Thu, Feb 20, 2014 at 1:56 AM, Idwer Vollering <vidwer(a)gmail.com> wrote: > > > > 2014-02-20 9:38 GMT+01:00 Justin Roylance <justin.roylance(a)gmail.com>: > > the flashrom utility in Kubuntu says no chipset found and no EEPROM/flash >> device found. >> > > The version that Kubuntu ships could very well be outdated. (dist-)upgrade > your installation and/or see > http://flashrom.org/Downloads#Installation_from_source > > >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Acer C710-2856 coreboot+seabios blue screen?
by Idwer Vollering 20 Feb '14

20 Feb '14

2014-02-20 9:38 GMT+01:00 Justin Roylance <justin.roylance(a)gmail.com>: > the flashrom utility in Kubuntu says no chipset found and no EEPROM/flash > device found. > The version that Kubuntu ships could very well be outdated. (dist-)upgrade your installation and/or see http://flashrom.org/Downloads#Installation_from_source > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2014