coreboot December 2015

coreboot@coreboot.org

26 participants
42 discussions

Coreboot With Linux Payload Error
by Ercan Ersoy 28 Dec '15

28 Dec '15

Hi, I'm deals compling Coreboot. I compile Coreboot with Linux payload. This run on QEMU. Coreboot works, but kernel panic error I had. How I solve my problem? Coreboot version: 4.1 Coreboot image size: 2 MB GNU/Linux version in Coreboot: 4.1 QEMU version: 2.0.0 QEMU has been emulated processor type: x86 32 bit - Default QEMU has been emulated RAM amount: 64 MB (If I set 1024 MB of RAM, even so I have this error.) Thanks for replying.

1 0

Getting started with coreboot and GSoC
by Hatim Kanchwala 28 Dec '15

28 Dec '15

Hello! I am Hatim Kanchwala from India. I am a sophomore pursuing Bachelor's in Electrical Engineering at the Indian Institute of Technology Patna. I came across coreboot through the Google Summer of Code page. I am aspiring to work with coreboot for GSoC 2016. To get an introduction to coreboot, to its history and its philosophy, I read the wiki and also watched videos on YouTube, including the Google Tech Talk by Ron Minnich, Stefan Reinauer and Peter Stuge. I have downloaded coreboot, built the cross compiler and then built coreboot for emulation with QEMU x86, with SeaBIOS as payload. I managed to do this with the help of documentation from the wiki and a bit of searching through the web and through the mailing list archives. I couldn't try coreboot on my machine as my mainboard isn't supported (yet). Currently, I am trying to build and test coreboot for emulation with QEMU ARM. Unfortunately, I haven't had much progress there, but I will remain at it! I have taken an introductory course in the C language at my University and a basic Digital Circuits course. I have a fair experience with Linux and git. Please tell me how I can get started to contribute to coreboot. I am certain that the skills and knowledge required to contribute is way more than I currently possess, but I am a keen learner. Academically, I am interested in Embedded Systems and Computer Architecture, in which I hope to pursue higher studies. I consider being part of coreboot and contributing to it as an opportunity to learn more about these fields and to learn about open-source development as well. Also, I am looking forward to getting to know people and learning from them! You can find me on IRC (Freenode) under the nick hatim. I am already a member of the #coreboot channel. Thank you for your time and help. Hatim -- http://hatimak.me

3 3

Porting Libreboot to the C201 Chromebook (veyron_speedy)
by Paul Kocialkowski 24 Dec '15

24 Dec '15

Over the past week or so, I've been working to get Libreboot running on the latest ARM Chromebook: the C201, manufactured by Asus (codename veyron_speedy). The laptop is running with a RK3288 SoC and ships with Google's version of Coreboot preinstalled. It should require no proprietary code nor any proprietary firmware load or microcode update to boot, thus it would be a good fit for Libreboot, as a fully free distribution of Coreboot. In addition to that, the device's embedded controller (that handles aspects of power management as well as the keyboard and a few other things) is a microcontroller that is also running free software: the free embedded controller firmware from Google. Aside from that, it has a soldered Wi-Fi/bluetooth BCM4354 chip (cannot be removed) that has a free driver but requires to load a proprietary firmware on the chip. However, it is easy to work around that issue and not use that chip at all, e.g. using an ath9k_htc dongle on one of the two USB ports. The GPU is a Mali T764, on which Luc has been doing some early work to have free software support for it. It is uncertain[0] how long it will take to have an usable free replacement for it, but now that there is that hardware available, free graphics for Mali T GPUs would mean having a recent laptop running fully free software, down to the firmware level, without losing any major hardware feature, something that has hardly ever been achieved yet. Thus, I believe it is of the utmost importance to back Luc up on this, even if big players like ARM are trying hard to make Lima not happen and to make it difficult for Luc to keep going. Another aspect that I still have to look at in-depth is the ability to use hardware video encoding/decoding. The RK3288 has an auxiliary processor for that task, but it is unclear whether it can be used with free software or not, though the first indications that I've gathered are positive. At this point, I've been able to boot up Debian on the device, and the xfce4 interface is quite usable. It even runs big programs like Iceweasel/Firefox and LibreOffice without inconveniences. However, it cannot run desktop environments that depend on GL acceleration, such as gnome-shell, which is a shame since those would be a good fit for it. The CPU is simply too slow for offering a decent experience with software rendering (llvmpipe). Overall, I truly hope this device creates an incentive to free the last remaining parts that can only work with proprietary software to this day. Its potential would be huge, especially since it's a good fit for travellers. With the security model inherited from Chromium OS, this would be one of the safest laptops to be used by journalists or activists. If Tails was to be ported to it, it would become easy to have a secure and anonymous setup. I have successfully fixed and compiled Coreboot and all the necessary bits and pieces for the C201, so I'll be spending the next few days sending patches, discussing how to integrate it to Libreboot and getting the actual work done. I also plan on documenting all my findings (especially things like how to access UART, how to remove the SPI flash's write protect, how to reflash it externally, etc) on my coding blog, for now. Cheers! References: [0]: http://libv.livejournal.com/27461.html -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/

2 1

Re: [coreboot] <vendor> commit messages and their suitability for coreboot.org
by Carl-Daniel Hailfinger 24 Dec '15

24 Dec '15

Hi, given that testing is something I value a lot, I'd like to chip in. On 23.12.2015 17:06, Aaron Durbin via coreboot wrote: > On Tue, Dec 22, 2015 at 7:12 PM, Alex G. <mr.nuke.me(a)gmail.com> wrote: >> [...]For the >> sake of example, I will pick on a RABDOM commit message which follows >> the format: >> >> BUG=chrome-os-partner:48412 >> BUG=chromium:445938 >> BRANCH=None >> TEST=TBD >> [...] >> ### TEST tags ### >> >> The general attitude towards a patch is "if people have to ask how you >> tested it, then you probably need to include it in the commit message". >> There's no hard rule towards the format of the commit message body, so >> TEST tags are perfectly fine. >> >> What is not fine is TEST tags that have no useful information. In this >> case, a feature is introduced, and some later patch, the feature is >> used. Where should the feature get tested? The patch that adds the >> feature? The patch that uses the feature? There are cases where patches >> have to be tested in bulk, and that's fine. Please describe the testing >> methodology only on the last patch of the series. >> > Indeed good feedback on the code review, but it's not there. Actually, > it looks like I didn't backfill what I did. Thanks for the pointer. > >> A very common TEST tag says "built and booted <board>". That's lazy. >> First, every coreboot commit is build-tested build jenkins for each >> board. Restating that the patch builds for a specific board is redundant. > But it's not booted so in that sense it's actually a positive signal. > Jenkins building also doesn't cover all the combinations of options > that something could be impacted by. One of the problems of jenkins is that it didn't detect that qemu normal image (instead of simple fallback-only) didn't compile for half a year. With the expected combinatorial explosion, this is expected, but it still doesn't make me happy. Maybe it would make sense to say "build-tested in a non-jenkins config" if that was tested. >> What does "booted" mean? Does it mean boot to ramstage? Does it mean >> boot to payload? Which payload? Does it mean boot to kernel? Which >> kernel? Does kernel crash or reach shell? Does it bluescreen? Does it >> reach a shell? Graphical shell? Console shell? Is the console over >> serial? Is it over network? Does USB work? Can you access SATA drives? >> From what media was your kernel loaded? >> >> You get the point. "booted" provides no meaningful information. If your >> testing involved "building and booting" a specific board, then please >> leave out the TEST tag from your commit message, or remove it before >> pushing the commit to coreboot.org. > If you juggle that many definitions of 'booted' in your head I can see > why the pedant comes out. It is my understanding that booted means > booting through the OS to userspace. Is there really other > definitions? And if there are wouldn't those be less progressing? > > Again, feel free to ignore it as well. While it may not be beneficial > to you it may be beneficial to others. Would flags help? E.g. payload+linux+net+usb? Would it make sense to include a link to the boot log (that is, coreboot console and dmesg)? Photo of the screen (to confirm gfx)? >From my perspective, it would be great to use REACTS output in a way that helps people check/confirm the awesomeness of a patch. Regards, Carl-Daniel

1 0

<vendor> commit messages and their suitability for coreboot.org
by Alex G. 24 Dec '15

24 Dec '15

There's a trend I've been noticing about commit messages which is to follow google's format for everything coreboot. Please stop this. Here's why google's format is not suitable in many respects. For the sake of example, I will pick on a RABDOM commit message which follows the format: commonlib: add cbfs_vb2_hash_contents() Provide a common routine to hash the contents of a cbfs region. The cbfs region is hashed in the following order: 1. potential cbfs header at offset 0 2. potential cbfs header retlative offset at cbfs size - 4 3. For each file the metadata of the file and it is not an empty file then the data as well. BUG=chrome-os-partner:48412 BUG=chromium:445938 BRANCH=None TEST=TBD ## Summary line ## So what's wrong with this? Let's look at the first line. * indicates component, check * sentence not capitalized, let not pick on this point here * Sentence content: And this is where I want to get. What does cbfs_vb2_hash_contents() do? Does it hash an entire imagine? multiple cbfses? only one file? These are things that someone looking over a git shortlog must not ask -- it just wastes time. A much better description is: "commonlib: Add function to hash contents of a CBFS region" Here's what I did different: * I used english, not C to describe the change * I used wording that makes sense for people less technical than me * I didn't just throw C names in the summarry This ties into the "document what, not how" idea. Stretching that a little, I documented what the function does, not how it's named. ## Commit message body ## The body does a decent job of explaining the content in more detail. We could go into whether a certain piece belongs in a source comment, or commit message, but that's besides the point I'm trying to make here. ### BUG tags ### Now we get to the tags. Why are tags considered harmful? First off, "BUG=chrome-os-partner:48412" is not publicly accessible. As a result, that information is completely useless to coreboot.org. So how would one go about this? Instead of a pointer to effectively unusable data, say "This fixes a bug where ...". Now we come to the "BUG=chromium:445938" line. That is publicly accessible. When referring to external bug trackers, please include a short description of the bug, such as: "This fixes a bug where ...(chromium bug #445938)". If the "bug report" in question is a feature request, then just leave out references to it. It's not a bug in the correct sense of the word, and in the coreboot sense of the word. ### BRANCH tags ### coreboot.org does not use branches. Even if it did, any reference to a "BRANCH" does not make sense, as git is responsible for handling branches. Please leave these lines out entirely. ### TEST tags ### The general attitude towards a patch is "if people have to ask how you tested it, then you probably need to include it in the commit message". There's no hard rule towards the format of the commit message body, so TEST tags are perfectly fine. What is not fine is TEST tags that have no useful information. In this case, a feature is introduced, and some later patch, the feature is used. Where should the feature get tested? The patch that adds the feature? The patch that uses the feature? There are cases where patches have to be tested in bulk, and that's fine. Please describe the testing methodology only on the last patch of the series. A very common TEST tag says "built and booted <board>". That's lazy. First, every coreboot commit is build-tested build jenkins for each board. Restating that the patch builds for a specific board is redundant. What does "booted" mean? Does it mean boot to ramstage? Does it mean boot to payload? Which payload? Does it mean boot to kernel? Which kernel? Does kernel crash or reach shell? Does it bluescreen? Does it reach a shell? Graphical shell? Console shell? Is the console over serial? Is it over network? Does USB work? Can you access SATA drives? >From what media was your kernel loaded? You get the point. "booted" provides no meaningful information. If your testing involved "building and booting" a specific board, then please leave out the TEST tag from your commit message, or remove it before pushing the commit to coreboot.org. ### <vendor>-centrism ### Many times, commits look like: funnychip: Enable flux capacitor calibration funnyboard: Enable flux capacitor in devicetree When they should actually look like: soc/funnychip: Enable flux capacitor calibration funnyvendor/funnyboard: Enable flux capacitor in devicetree It's understandable that a vendor works only on a very limited part of the codebase, and for them referring by codename alone is obvious. However, if your internal policy is not to follow coreboot.org namespacing policy, when those patches are pushed to coreboot.org, please make sure they are properly namespace. For example, if you tell me that you enable clock gating on an mcp509, how will someone know if that is a southbridge, soc, or SPI chip? By prefixing, and that's why you should do it too (TM). And my favorite "built and booted glados": * You build glados? I didn't know you worked for Aperture, Inc. * Oooh, you meant "built and booted google/glados". NVM then ### Tags in general ### Tags are meant for machine-parsable content. coreboot commit message body are inherently meant to be read by a human, and thus are by design, human-readable. This fundamental contradiction means that tags will always be second-class to clear sentences and well-structured paragraphs. If you can avoid tags in the first place, please do so. ## Closing remarks ## google "owns" most of the brand-name, respectable coreboot developers. When those individuals make the mistakes I pointed here, it's very easy for an observing new contributor to mistake those as the official policy of the project. Because if all the respected names do it, it must be right, right? People make mistakes. I have the luck of doing coreboot for a company which does coreboot (and is not google). I've shown people how to think about coreboot and write upstreamable patches. Those very same people have corrected me on code reviews. I make mistakes. If you're reading this, and are from planet Earth, you make mistakes. If you're one of the very respected names I mentioned earlier, you make mistakes... because nobody is perfect. There's much more work going on in coreboot than the patches in google's little world, or intel's little world, or raptor's little world, or minifree's little world. When I write patches, I do my best to be courteous to those outside my little world. I do my best to write short patches that people not familiar with the hardware can review. I do my best to properly namespace and describe the patch in the first line, so that someone looking over 100+ patches can have a better idea of whether or not that patch is relevant to him (or her). I always think in terms of "would this be acceptable to coreboot.org" ? Most developers think in those terms, and are held to that standard. It's easy to do things like not properly prefix a title because you only have 65 characters available, and it's inconvenient to spend time thinking of a better title. It's easy to add nonsensical tags because your employers tools will automootically check for such tags, what you do when you submit your work to your employer for a paycheck is up to you, but please make sure that work ending up on coreboot.org is free of these easy to fix mistakes. And if you're someone else observing this discussion, please keep in mind that the people I mentioned earlier are well-intentioned. They try to keep the chromium and coreboot.org branches in sync, and that's neither an easy task, nor something they are asked to do. Before someone decides to take my side, and start accusations, please keep in mind these people are well-intentioned. Alex

2 1

Coreboot contract work in Beaverton, OR
by Mark C. Mason 23 Dec '15

23 Dec '15

We need to hire someone on a contract basis to help us fine-tune the current coreboot to our new design based on the ASROCK IMB-A180 motherboard (AMD G-Series SOC). Please contact me directly if you are qualified and interested. Part of the work would occur in our Beaverton, OR offices. -- Mark C. Mason SW Engineer Direct line: 503-748-7877 Email: mark(a)edt.com Engineering Design Team (EDT), Inc. - a HEICO company 1400 NW Compton Drive, Suite 315 Beaverton, Oregon 97006 (U.S.A.) Phone: 503-690-1234 / 800-435-4320 Fax: 503-690-1243 Web: www.edt.com Confidentiality Notice: The information contained in this email and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged. If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return email, and delete the original message and all copies from your system. Thank you.

1 0

Re: [coreboot] [SeaBIOS] 5 basic features provided by CSM, which SeaBIOS does provide?
by Kevin O'Connor 22 Dec '15

22 Dec '15

On Mon, Dec 21, 2015 at 12:57:33PM +0000, Stojsavljevic, Zoran wrote: > Hello Kevin, > > All Good with setting CSM ON for legacy support. You need it for 16 bit BIOSes, and for legacy OSes, such as WIN XP or WIN 7 and derivatives. > > Here is the question I am wondering: What if I decide to bring FSP -> Coreboot -> SeaBIOS -> WIN 8.1 32. Do I really need SeaBIOS with option set to: CSM ON (I brought WIN 8.1 32 on CC2 with SeaBIOS and feature CSM ON)? In other words, can I bring WIN 8.1 32 on FSP -> Coreboot -> SeaBIOS with CSM OFF? > > The same question for: FSP -> Coreboot -> SeaBIOS -> WIN 8.1 64? I guess, here is CSM ON mandatory. Am I correct? > > Could I have a true 32 or 64 UEFI compliant OS on BSP: FSP -> Coreboot -> SeaBIOS -> UEFI OS sans/without CSM feature ON? The same one I have after bringing on UEFI 32/64 BIOS UEFI 32/64 OS (CSM is OFF always)? > In all of the above situations you must compile SeaBIOS with CONFIG_COREBOOT=y and CONFIG_CSM=n. CONFIG_CSM is mutually exclusive with CONFIG_COREBOOT, and if one is planning to run SeaBIOS directly from coreboot then one must use CONFIG_COREBOOT=y. -Kevin

1 0

Re: [coreboot] [SeaBIOS] 5 basic features provided by CSM, which SeaBIOS does provide?
by Kevin O'Connor 21 Dec '15

21 Dec '15

On Fri, Dec 18, 2015 at 08:43:37AM +0000, Stojsavljevic, Zoran wrote: > Hello both lists, Jiming, > > There are 5 basic features, provided by CSM SeaBIOS payload, and I > am looking to list of these features. > > Could you, please, provide to me list of these features, and some > description, and/or pointer to these descriptions? I don't fully understand your question. One can build SeaBIOS as a Compatibility Support Module (CSM) for UEFI, and this has been tested with OVMF on virtual machines. It's theoretically also possible to use it as a CSM on real hardware with a UEFI payload on coreboot, but to the best of my knowledge that has never been tested. When SeaBIOS is used as a CSM module, it provides legacy 16bit BIOS support on UEFI machines to bootloaders and option roms that require that support. The only link I have for SeaBIOS CSM is: http://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support… Cheers, -Kevin

2 1

hyper_threading in CMOS/NVRAM seems useless in many CPU models
by Iru Cai 21 Dec '15

21 Dec '15

Hi, I just tried to disable hyper-threading in my machine, and I found the hyper_threading setting in NVRAM is useless. I searched in the code and found only a few number of CPU code has in its Makefile.inc `subdirs-y += ../hyperthreading', which can read the hyper_threading NVRAM option and enable/disable hyper-threading. Iru

1 0

coreboot.org redirect to tracker.coreboot.org
by Paul Menzel 19 Dec '15

19 Dec '15

Dear coreboot administrators, www.coreboot.org and coreboot.org redirect to tracker.coreboot.org. Thanks, Paul

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2015