GSoC [early debugging] There is so much source

Not much new or fancy development yet. A time-consuming dive into sources of AMD platforms took place during the last two weeks as I need to fully understand what is going on with the memory management there. We need to find solution for CAR migration on these platforms, and while at it, let’s evolve these boards too for DYNAMIC_CBMEM.

Originally I had scheduled improvements for these platforms for July, but coordination of making changes to vendorcode might become a bottleneck, so I thought I better start early. In this process fifteen (15) or so copies of heap management sources of AGESA boards got combined into one. As a bonus, some family14 and family15 boards are now a bit closer for having S3 suspend/resume support.

I am expecting some more gear for coreboot development arrive later this week, I should then be fully equipped for my GSoC tasks.

[Pre-GSoC] Set-up Phase-I

Hi! This past week went in gearing up and getting ready for the Coding phase to start. I intend to use the community bonding period for set-up of necessary hardware and studying the 1000 SLOC of the existing cbfs_media interface.

I had ordered my cubieboard, the back-bone  for this project last week, to avoid any hassle due to unavailability of hardware when the coding phase actually started. I received it this week. Along with it, all other supplements like the micro-SD cards, card-reader, HDMI-cable, etc were gathered. Hardware setup : Check! :)

The Cubieboard has 4GB of internal memory (NAND Flash), which comes pre-loaded with Android 4.0.4, on power-on we can see it operating. For our purpose, we would need  linux on it. So, the next step is to run Linux on this board.  BerryBoot makes this very easy. We use the manual installation using SD card image, found on that link.  A very good article that I found, which describes the set-up really well can be found here.

I would write another post next week that will show some of the results of this installation.

Also, I am spending some time reading the existing cbfs_media interface, can be found here. The regions patch by Aaron highlights the direction we would be taking, with the aim of reducing the buffer size for mappings, i.e. the aim of the project, as explained in the previous post.

This Bonding Period =  Spending time on the IRC + Initial Set-up + Slogging through source codes 😛 + Writing blogs (a first for me 😀 )

GSoC [early debugging] The very short introduction

Oh dear, what did I get into again. My GSoC 2014 project page  gives you an idea of things to expect during this summer of code and seems like I have promised to deliver a lot this time. More like a complete in-circuit-debugging solution of x86 boot firmware over some readily available and low-cost USB hardware. I only scratched the surface with my GSoC 2013 when I did not get much further than a working usbdebug and some intense clean-up and preparation on the CBMEM side.

There has been serious use of usbdebug combined with SerialICE to troubleshoot and/or reverse-engineer proprietary firmwares. Tests have been done to connect GDB stub built into coreboot over BeagleBone even before debug target has initialized RAM.  Also other pieces of my project plan have already seen proof-of-concepts but the quality or the flexibility have not reached the requirements to see them in widespread use in coreboot community.

We can see more practical uses for SerialICE if we could connect QEMU, GDB, SerialIce and radare together, and visualize some of the system bus topologies at runtime. With the amount of support CPU and chipset vendors have shown towards open-source firmware development the last years, I consider this as a key part for any further community-driven mainboard ports on coreboot.

GSoC 2014 [flashrom] Do I need to introduce myself?

Hello, my name is Stefan Tauner and I am participating for the third time in GSoC with a flashrom-related project. If you don’t know me then you have to be new here and should write an introduction post instead of me. :) If you really have no idea then please take a brief look at my introductory posts from last year.

I finally managed to finish my master thesis shortly after this year’s accepted GSoC proposals were announced, so this year will be the last time I’ll participate as a student – unless I find time to do it again during my potential PhD project…

Anyway, instead of writing about my goals for this year, I want to share a few graphs related to flashrom development. The first one draws the number of lines added by individual contributors over time. Note that this includes all patches a developer submitted to our Subversion repository even if he is not the original author. The more horizontal a lines is the less active the committer is. Sadly there are a lot of horizontal lines…

lines of code by author over timeI was curious how my hiatus during my thesis work was affecting flashrom development so I created two graphs spanning the last year. This includes not only the final months of my thesis but also last year’s GSoC. One diagram shows the number of average commits per day each month and the other one depicts the emails sent to the flashrom mailing list on average per day each month. The bars for May 2014 are based on only 4 days worth of data, and I really hope that at the end of May it would not show about 25 Emails per day anymore or I’ll have to work on my project from a rehab facility. 😉

Average commits per dayEmails per day

In my next post I’ll lay out my plans for this summer. My (in)formal proposal can be found here. I was quite surprised that it has been accepted instead of my second and more focused proposal for a GUI tool to prepare coreboot images. OTOH, after a short trip into C++ land at the end of my thesis, I am quite delighted that I don’t have to wrestle with Qt and the like…

Moin!: A new beginning

Hi All, I am Naman Govil from India and I will start working with coreboot this summer as a part of Google Summer of Code-2014. I am a junior year undergrad from International Institute of Information Technology, Hyderabad (IIIT-H), pursuing my majors in Electronics and Communication Engineering. I have been actively dealing with programmable devices ever since the start of my program. I am a hardware designer at heart, and getting a chance to combine hardware with programming makes for an interesting and gripping combo for me- enter coreboot! 😀

While searching for appropriate orgs to pursue a GSoC project, I stumbled upon coreboot. Open BIOS had a ring to it and so I decided to see the projects done here.  It gripped me instantly. I was pretty confident to pursue my project here and got to work early.

This summer, I will be doing a project on providing a generic Interface based on CBFS access patterns for ARM SoCs. The aim would be to optimize and enhance the CBFS_media interface used for accessing data, currently in x86 systems, to suit low-end ARM SoCs. An ARM-specific CBFS access pattern would enable coreboot to load its stages efficiently,  which will form the basis for establishing full support for coreboot on SoCs, and in-turn help bridge the gap between coreboot and ARM mainboards. The chosen ARM board for this project is a cubieboard 1.0,  due to its existing support for coreboot.

There will two main targets to improve the CBFS access. First, to reduce the size of buffers used to read data, thus reducing wastage of ram.  Next, the current API for uncompressing a file to a location requires that the entire deflated source needs to be in memory. The second and more important objective would be to bring a pipelined decompression strategy.

The last part of the project will be  to have management of the resources being used, i.e  avoiding any memory leakings while executing commands.

Project Deliverables would include:

  • A CBFS access mechanism (for when the underlying medium is not memory mapped, unlike for x86 systems), which will allow ARM-based SoCs, for example: the Cubieboard, BeagleBoard, etc to boot efficiently.
  • The API would be tested with a back-end,like the MultiMedia Card, to demonstrate and debug the generic interface.
  • The verification step is to compare the size of the cbfs cache required for the cubieboard using this access method with the old one. In the end it should be dramatically reduced.
  • By the end, we will have a reliable method to boot coreboot on ARM SoCs.

I hope I can complete the project satisfactorily and have a great learning experience with the community. Waiting for an awesome summer ahead! 😀



GSoC 2014 Projects

Congratulations coreboot’s GSoC students.  coreboot has three students working on coreboot for GSoC 2014 .


Title: Enhance early coreboot debugging

Student: Kyösti Mälkki

Mentors: Martin Roth and Rudolf Marek


Title: Generic Interface using alternate CBFS access patterns for ARM SoCs

Student: Naman Govil

Mentors Aaron Durbin and Marc Jones


Title: The yearly flashrom maintenance and enhancement proposal

Student: Stefan Tauner

Mentors Carl-Daniel Hailfinger and David Hendricks


Each student is required to post progress to this blog.  We expect first posts later this week. Stay tuned for progress!

coreboot GSoC 2014

We are excited to announce that coreboot has been selected for Google Summer of Code 2014.  As with previous years, coreboot will also support flashrom and SerialICE projects.

All the information you need is on the coreboot GSOC page and the following project ideas pages:

We are in the Get Familiar period before the Application Period opens. Join the mailing list and IRC #coreboot. Start to get familiar with coreboot, our development process, and with the coreboot community. Discuss project ideas and scope with coreboot developers.
Student Application Period: March 10 – March 21

To be a mentor, you must be a coreboot contributor in good standing (review and commit rights). If you would like to be a member, please add your name to the coreboot GSoC mentors section and signup and connect with coreboot in melange.

Feel free to contact me (IRC:marcj) if you have any questions.

Pencils down

This is it. The beginning for QiProg has ended. It has been a long and tedious journey to equip the Stellaris Launchpad for Low Pin Count mastering. The hardware is built, and it works. The software is there, although its contribution to the ecosystem is somewhat minimal — it is more of a bridge than a road in itself. The real value lies in the firmware. To the best of my knowledge, LPC bus mastering has not been implemented in a microcontroller without using ASICs or FPGAs. The vessels are here, and now it is time for the explorers to start their journeys.

Why do I talk like this is project is not over? It is not over. Although I have attained the minimal goals, there is a whole new world to explore. Integration in flashrom was one of the targets I had really hoped for, but was unable to complete. Is writing of the chip working? Yes. Is it reliable? Writing and verifying predetermined patterns works. Disturbingly, when I plugged in output from /dev/urand, the write did not verify. Some bits were simply not programmed, although the majority of the chip matched. Is it the LPC bus mastering that is at fault, is it the command sequence, or are we not giving the chip enough time to complete the operation? Will chips other than the SST 49LF080A work? Can we write a complete ROM image and boot a machine? This is the exploration phase: we have built it, now let’s make the most of it.

Time has been tight for the last month. I had forgotten to plan for the start of the fall semester, and my time since this event has been severely crippled. I wish I could have achieved more. I took the last two days off from the University to organize the last few weeks’ salad of stashed and uncommitted changes into readable patches.

I don’t feel sad, just tired. Exhausted, I have nothing left to keep me entertained but an Alec Bradley Presando cigar, which I have been saving for a special occasion. This is that occasion: QiProg has stopped being a commitment, and became a hobby, a child, something to care for. Now is the time to build your VultureProg, get the software, and start reporting those issues you know you will encounter. I’m in Houston, and I don’t have a problem.

GSoC [early debugging] closure

Time to stop coding was last week and I feel I have barely touched the surface of my original project proposal.

My biggest contribution comes in the form of usbdebug patches: Most mainboards with USB 2.0 EHCI controller should now be able to produce console logging on USB port. More importantly, one has now the option of using some low-cost ARM development kit boards as a replacement for the Net20DC dongle device. Digging into ARM was not really in my original plans and setting up the required environment took more time that I had hoped for.

I had the idea of collecting a trace of PCI configuration in CBMEM. Turned out I first had to do some cleanup on both PCI and CBMEM and while those have been submitted (with a minimal amount of testing) the tracing part I did not start at all. On the other hand, cleanup on CBMEM has enabled timestamp collection and CBMEM console for ramstage for most mainboards and I have a fairly clear vision what needs to be done to extend these to romstages as well.  I think there would be interest to have these features on ARMv7 too, just takes a bit of coordination and access to platform.

On the so-called “coreboot panic room” tasks I did not submit any code. I liked the idea of using some BeagleBone board as a proxy and having the possibility to switch between SerialICE debugging or GDB or pre-OS flash programmer. If time permits, there might even be some integration or interaction with radare coming up next months for SerialICE.


GSoC 2013 [flashrom] blog post #8

After my last post I continued to improve our flashrom build bot and it now uses VirtualBox’ safe state feature which allows to bring up and down VMs in a matter of seconds. Also, I was able to fully parallelize the builds. Using the safe state feature alone improves the duration of a full build from 4m55.930s to 2m10.496s. The fully parallel execution gets it down to 25.807s, yay.

This week I have merged a mix of old and new patches that fix a few things, add support for other things, and most importantly… gets rid of the dependency on dmidecode: I have finally committed my internal DMI decoder. Compiling for DOS and under various BSDs should be easier now, the AMD patches are slowly getting reviewed… clearly there is some progress, but obviously not enough to reach my original goals for GSoC…