coreboot March 2014

coreboot@coreboot.org

57 participants
180 discussions

Re: [coreboot] Classification of blobs and respecting your freedom

by ron minnich

Ah, that's what I meant by persistent. Let's take your name and get rid of mine, and we're still at 2 axes? ron On Wed, Mar 26, 2014 at 12:40 PM, David Hendricks <dhendrix(a)google.com> wrote: > On Wed, Mar 26, 2014 at 12:29 PM, ron minnich <rminnich(a)gmail.com> wrote: >> >> I agree with david. >> >> Simple classifications are better. I think I found two axes. >> >> persistent > > > Add to that "always on" versus "boot/resume path". > >> >> replacable >> >> persistent and not replaceable --> this system may not be usable >> non-persistent and not replaceable --> requires a close look >> >> replaceable --> we're ok with enough effort >> >> are there more? >> >> ron > > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc.

6 years, 11 months

Re: [coreboot] Classification of blobs and respecting your freedom

by David Hendricks

On Wed, Mar 26, 2014 at 12:29 PM, ron minnich <rminnich(a)gmail.com> wrote: > I agree with david. > > Simple classifications are better. I think I found two axes. > > persistent > Add to that "always on" versus "boot/resume path". > replacable > > persistent and not replaceable --> this system may not be usable > non-persistent and not replaceable --> requires a close look > > replaceable --> we're ok with enough effort > > are there more? > > ron > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

6 years, 11 months

Re: [coreboot] Classification of blobs and respecting your freedom

by ron minnich

I agree with david. Simple classifications are better. I think I found two axes. persistent replacable persistent and not replaceable --> this system may not be usable non-persistent and not replaceable --> requires a close look replaceable --> we're ok with enough effort are there more? ron

6 years, 11 months

Re: [coreboot] Classification of blobs and respecting your freedom

by David Hendricks

On Wed, Mar 26, 2014 at 9:47 AM, ron minnich <rminnich(a)gmail.com> wrote: > I think it's good and well written. I'd replace your 'panic levels' with 4 > simple classifications and leave it at that. > Yep, good write-up overall. I never liked the "panic level" rating, or at least the numbers. It seems rather arbitrary. As much as folks dislike binary MRC, for example, I wouldn't even put it in the same ballpark as the management engine since the ME is an always-on, persistent, non-ISA blob with similar access capabilities. Scoring them one point apart at the top of a scale from 1 to "9000+" seems to diminish those important distinctions. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

6 years, 11 months

Classification of blobs and respecting your freedom

by mrnuke

In the search for a good LTS (long term support) laptop, I've had to think hard of which blobs could be consider acceptable, and which would disqualify candidates. I've made a write-up about this classification here[1]. The idea is simple: find out which blobs would disqualify the machine from being Respects Your Freedom (RYF) certifiable. RYF capability, in my opinion, is a very important feature of any laptop which we plan to support for a long while. A machine as old as the x60 has seen a steady increase in its user base since the GluGlug has received RYF certification. Almost every week, I see a few people asking on IRC about how to flash coreboot on the X60, or how to unbrick it. A number of those people are using the pre-built images supplied by libreboot. Did I convince you RYF is essential? Maybe not. Is it definitely desireable. For an LTS candidate, it's pretty darn important. And while you may not give much importance to RYF, the X60's desirability is something we want to continue to repeat in the future. There is a niche market thirsty for this king of thing. That means we must start caring about RYF, whether you like it or not. With RYF, there are a number of elements that need to come together in harmony. I have tried to understand how we, as firmware hackers, could better accommodate the situation. There is a lot we can do to make sure that a machine can take the path to RYF certification. I will call that RYF-capable. Note that "capable" does not necessarily mean "certifiable". What I mean by "RYF capable" is that it is reasonable for a group of community hackers to get together and eliminate any offending blobs. This is where the classification comes in. We need to be able to talk about blobs in terms of simple criteria. With this classification, all essential blobs must be reasonably removable. So, while the RYF-certified machine may have reduced functionality than the same RYF-capable machine, a machine will never be RYF-certified, if it is not RYF-capable. Anyhow, I wanted to ask what you guys think about the classification. Alex [1] http://www.coreboot.org/Binary_situation#Classification_of_blobs

6 years, 11 months

Changes to the coreboot Project Structure -- the non-aneurysmal way

by mrnuke

Not so long ago, Stefan announced some pretty drastic changes to the project structure. While I believe he wanted to discuss the direction and find a mutually agreeable direction, his email still raised the aneurysm level to over nine thousand. So, how about we take the good ideas out of there and start putting them in practice. Today, I'll be focusing on the idea of MAINTAINERS. While it's nice to jump straight to maintainer trees, that's a long ways away, and I'm not even sure we reached consensus on it. Couple that with the changes needed to be done to _both_ gerrit configuration, _and_ gerrit workflow, this matter is better left for another day. What we can do, however, is to start assigning maintainership of different sub-directories. Two ways to do it: (i) One big MAINTARES file in top-level directory (ii) One small MAINTAINER file in each directory with an assigned maintainer Number (i) is human friendly, while (ii) is parser-friendly (I would hope). Now comes the fun part: For directories with a maintainer, gerrit implements a MMA criteria. That's short for "Maintainer Must Approve". People are still welcome to do reviews, bikeshed, etc, but the maintainer has veto power. For directories without a maintainer, the old workflow applies (no MMA). This should reduce confusion from conflicting reviews, and definitely reduce number of incidents where a patch gets merged with a review from a person who is not fully qualified to, well, do the review. Masters, of Gerrit, the pleasure of training gerrit to implement this change is left entirely to you. Alex

6 years, 11 months

Miniboot

by The Gluglug

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is focussed on users (non-developers). Most coreboot users only have perhaps a few machines that they are building for. Maybe even just one. Yet they are downloading the entire coreboot source tree and selecting which board they want, configuring it, etc. My idea: --> a small set of source files (such as from src/mainboard/vendor/board) --> a script (perhaps a simple git checkout) which fetches the needed parts of the source from the main branch, for building that board --> default/"sane" configurations pre-defined for that board. Advantages: --> less headache for developers (user already has most of what they need, less likely to request support) --> less to download (less waiting required, especially for people with slow connections) Essentially, I have in mind a more "modular" coreboot. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTMhFiAAoJEP9Ft0z50c+UTjYIAMXvzhJFEcrNACgqssRfZpzf Xa3C1WaAI/EByzVl11i2eSFaKipqqzCD/DkHwqroXbszNATqgKXMoYGTy/lSM7zr j/254QlxMEwd5MA6hmzrJEFFRUW2t/wYGsS48NP5R3YSJlE9Fga1ogvQJg4qgduP pFmy1i48R+I5O7/SRmaPz1Tprw+q0KaaSF5+elh8Ymq5Zq6zJTu/DSI/mNM6FUjs VOP+bmq2Yiik8DmgVUjhKKpShd2GIhXatRYSjD5otnBgO9kOss+HXvNnGmRd01YU I9Fbne1VhOruI3qS8tMmKWcLvbipyoaQ9QgpL+OuotiBdAqufMjvfT7cC9idv0g= =5YKe -----END PGP SIGNATURE-----

6 years, 11 months

Re: [coreboot] GSoC-2014 Coreboot project

by Scott Duplichan

Allen Yan [mailto:lexkde@gmail.com] wrote: ]Oh, sorry, incorrect address! ]http://www.google-]melange.com/gsoc/proposal/public/google/gsoc2014/jinyiyan/5629499534213120 ] ]TianoCore as Coreboot payload ]JinyiYan ] ]Short description: The combination of coreboot + TianoCore ]is the most straightforward option to provide a complete, ]opensource UEFI environment. This proposal should mention that only x86 systems will be supported if that is the case. To provide a complete, opensource x86 UEFI some items not listed in this project proposal are needed: 1) UEFI support for writing to flash memory. The UEFI name is Firmware Volume Block protocol. One module for Intel systems and another module for AMD systems would probably cover most x86 motherboards. All current open source UEFI solutions use a substitute that either fails to capture OS writes to UEFI NVRAM variables, or does not preserve these writes through a power down. The most visible effect of the substitute firmware volume block driver is loss of the NVRAM variable that points to the boot device. When this variable is lost, Linux will no longer boot. Windows can still boot due to an automatic repair mechanism. In all cases, the boot order in a multiboot system will be lost. The use of the substitute firmware volume block driver causes other limitations such as such as loss of configuration settings. 2) USB OHCI support. Without this the USB keyboard on AMD systems will not work until after the OS boots. 3) Another missing item is UEFI MP Services. This one might not be essential. It is needed if UEFI code needs to launch the AP for such things as gathering SMBIOS data or for setting the SMM base address register. There is a discussion on the EDK2 Devel mailing list about the possibility of an open source solution: https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg06354.html ]Based on coreboot-pkg, the project intends to implement ]some new features like UEFI CBFS driver and a GOP driver ]based on pre-initialized framebuffer. How will the CBFS Driver be used? Will the GOP driver support multiple video solutions? If so, how? If I use a brand XYZ video card how will the GOP driver find the details of the frame buffer? I know it is possible because operating systems do it. But the proposal should explain it for those of us who are not graphics experts. ]Please complete the standard Google SoC application and project ]proposal. Prospective coreboot GSoC student should provide the ]following information as part of their application. If you are ]applying for a flashrom or SerialICE project use common sense ]when using the template below, this is part of the test. ;) ] ]Name: Jinyi Yan ]Email: lexkde(a)gmail.com ]IM/IRC/Skype/other contact:irc.freenode.net: ] #coreboot, #flashrom nick: Jinyi-Yan ]Web Page / Blog / Microblog / Portfolio: ]Country/Timezone:China/UTC+08 ]Normal working hours(UTC): 10:00~16:00 ]School:University of Chinese Academy of Sciences ]Expected graduation date: 2015 ] ] ]coreboot welcomes students from all backgrounds and levels ]of experience. To be seriously considered for coreboot GSoC, ]we recommend joining the mailing list and IRC channel. ]Introduce yourself and mention that you are a prospective ]GSoC student. Ask questions and discuss the project that ]you are considering. Community involvement is a key ]component of coreboot development. By the time you have ]submitted your application, you should have downloaded, ]built a and booted coreboot in QEMU, SimNow, or on real ]hardware. Please, email your serial output results to ]the mailing list. ] ]The following information will help coreboot match students ]with mentors and projects. ] ] ] Please comment on your software and firmware experience. ] ] I used to be a mainboard BIOS engineer in ASUS Technology ]Suzhou Co., Ltd for about two years (2007.7~2009.2). When at ]AsusTek Suzhou, my work is mainly responsible for bios porting ]and fixing bug. There were four mainboards P5KPL-S, P5QL-E, ]P5QL-SE, P5QL. All based on Intel platform and AMI Legacy BIOS Core. ] In the second half year of 2008, I worked on pre-development ]of EFI-BIOS for ASUS mainboard. I wrote a Dual bootblock module ]and added NTFS support(read only) for AutoRecovery module using ]AMI Apito platform (based on EFI). ] ] The most important is that I still have plenty training ]materials(EFI training and hardware initialization, ]kinds of intel chipset datasheet before 2009) from the company. If the intel chipset documents are not publically available you should not list them in your proposal. The reason is that companies sometimes ask engineers to destroy non-public documents once they leave the company or finish the project. ]They can let me grasp the concepts that I‘ve forgot quickly and ]do proper choice. ] ] ] Have you participated in the coreboot community before? ] ] No. ] ] Have you contributed to an open source project? Which one? ] What was your experience? ] ] Not happened before. ] ] Have you built and run coreboot? Did you have problems? ] ] Yes. With SeaBIOS as payload, It's a easy job. ] ] Did you find and fix a coreboot bug? Did you send a patch to ] Gerrit? Please provide a link to the Gerrit page. ] ] Not now! ] ] Please provide an overview of your project (in your own words). ] ] Coreboot-pkg provides a nice start. In the project idea ]webpage, there lists two possible tasks, one is a minimal ]GOP driver, the other is a CBFS EFI driver. I consider the ]“minimal GOP driver” is more hardware related but “CBFS EFI ]driver” is less hardware related or simpler. ]Considering the GOP driver can be workaround by integrating ]SeaBIOS as CSM in Tianocore payload, A much simpler INT10h video solution is: DuetPkg/BiosVideoThunkDxe/BiosVideo.inf (with some available bug fixes and enhancements applied) There is no need for full CSM. ]then maybe I should work out the simpler tasks “CBFS” driver first. ] ] As mentioned in webpage “www.coreboot.org/TianoCore”, ]the GOP driver piggybacks on the coreboot framebuffer. ]So, it's based on the VGA BIOS, but provide a new interface ]other than int 10h. So it sounds like coreboot will install the legacy video option rom and then make INT10h calls to get the frame buffer info. If the day ever comes where legacy video option roms are no longer shipped, this GOP driver will no longer work. Yet that will be the time when a GOP driver is most needed. Why not extract and use the OEM GOP driver? What problem will writing the piggyback GOP driver solve? ] In my view, this project may suffer less issues caused ]by SB chips, CPU and MRC code because coreboot would run ]well in supported mainboard. ] That is very nice. In my mind, the Tianocore payload ]should be start execution from DXE phase. For now, I don't ]know exactly the details that how coreboot pass control to ]Tianocore DXE phase. In my mind, in Tiano, the original ]PPI phase will send proper information to DXE through hand ]off block (HOB) in the system memory. ] ] Provide break down of your project in small specific ]weekly goals. Think about the potential timeline. ] ] 1. How will you accomplish this goal? What is your ]working style? ] a) building a test enviroment. Consider stating if the build will work from Linux, Windows, or both. ] Both emulator and real mainboard are needed. It is good you specifically mention real mainboard. It is usually more work than an emulation only boot. But then the question becomes which mainboard(s)? For example, AMD mainboards use OHCI for the low speed USB used with keyboards. Intel uses UHCI. Open source EDK2 UEFI supports UHCI but not OHCI. As a result, open source UEFI does not support the USB keyboard on AMD systems unless you pass it through a USB2.0 hub as a work around. There are also some relatively easy to fix problems when EDK2 is used on AMD boards. ]As Vladimir's suggestion, I'd better ]use GRUB's ability to chainload payloads for testing. So, ]the coreboot and the tianocore payload are separated. ]Maybe I should use EFI shell AP to test the drivers. ] b) bonding with the cooreboot communities. Patrick ]Georgi, Stefan Reinauer, David Woodhouse and Vladimir ]Serbinenko seems main contributor to coreboot-pkg. ] ] c) Grasp the code base of Coreboot interface to ]payload, CBFS and the knowledge of UEFI in the community ]bonding period. ] ] d) coding, testing, coding... get CBFS driver worked ]on the emulator before mid-term evaluations. ] ] e) get the code worked on a real coreboot mainboard. ]If everything goes well, the GOP driver would be checked. ] ] I think continuous working time is important for me, ]because I want to grasp the whole image of the project ]at first, then begin to read corresponding datasheets ]and code base carefully and write some test at the same ]time. I'd like to work from 6 p. m.(UTC 10) to 12 p. m. ](UTC 16) for GSoC 2014 from Monday to Saturday and go on ]programming in the day on Sunday. ] ] 2. Explain what risks or potential problems your ]project might experience. ] I concern about the proper debug method and test ]environment. Debug information output from serial port ]is nice. Maybe the debug card is also needed. About ]test environment, I need to purchase a coreboot ]mainboard and a few flash chips. As suggestion from ]IRC(phcoder-1creen), I should run in simulator first. ] The potential problem is lack of document if I ]failed to test the project on the real hardware. I ]also notice that there's little training materials ]for coreboot, but not a serious problem. ] ] 3. What would you expect as a minimum level of ]success? ] 1) get a worked CBFS driver on emulator. 2) Make ]windows load with tianocore. There is already a coreboot UEFI payload that boots Windows and Linux: http://notabs.org/coreboot/duet-payload/index.htm So goal 2 doesn't break any new ground. ] 4. Do you have a stretch goal? ] Implementing a GOP driver that piggybacks on the ]coreboot framebuffer or writing some training ]materials for coreboot. ] ] What are your other time commitments? Do you have ]a job, classes, vacations? When and how long? ] ] I have a three weeks vacations. During that I ]could contribute more then 8 hours a day.

6 years, 11 months

Re: [coreboot] A new, modern coreboot long-term support laptop

by mrnuke

On Tuesday, March 25, 2014 02:14:12 PM ron minnich wrote: > On Tue, Mar 25, 2014 at 1:26 PM, David Hendricks <dhendrix(a)google.com>wrote: > > On Tue, Mar 25, 2014 at 12:17 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > >> On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote: > >> > On Tue, Mar 25, 2014 at 10:57 AM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > >> Construction quality? > > > > Subjective. IMO it's nice. > > It's wonderful IMHO. > This is turning interesting. Any chance a handful of non-commercial coreboot entities could get a few early samples? > I understand the ARM limitations but the EC on those AMD platforms bothers > me. > If it's usable as a day-to-day laptop, the ARM limitations are irrelevant. Alex

6 years, 11 months

Re: [coreboot] A new, modern coreboot long-term support laptop

by ron minnich

On Tue, Mar 25, 2014 at 1:26 PM, David Hendricks <dhendrix(a)google.com>wrote: > On Tue, Mar 25, 2014 at 12:17 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote: > >> On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote: >> > On Tue, Mar 25, 2014 at 10:57 AM, mrnuke <mr.nuke.me(a)gmail.com> wrote: >> >> I'm assuming BLO is not persistent. >> > > It's been a while since I've looked closely at it, but I think it does > remain persistent in the resume path. > I think you're right. > >> Construction quality? > > > Subjective. IMO it's nice. > It's wonderful IMHO. I understand the ARM limitations but the EC on those AMD platforms bothers me. ron

6 years, 11 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2014