coreboot

GSoC 2014 [flashrom] Rise like a phoenix

The best plan is no plan at all, then everything goes according to the plan. (Jacek Bukowski)

I am 142% on track according to my proposal so far if you take the quote above seriously. But even if you don’t the progress so far is way better than I would have hoped for when I applied. I made 22 commits so far during the official coding period (starting with 2014-05-19 or within ~16 days), and 49 if you count from the date of project acceptance (2014-04-21, i.e. ~37 days). That’s pretty significant for a project that normally does 100-150 commits per year. Not all of the patches were authored by myself, and some of them were bitrotting for an extended period of time before I revived them. I have also reviewed, rebased and merged patches sent in by foreigners as well as long-term contributors. Even Carl-Daniel awakes periodically from hiatus and helps where he can. So flashrom seems to be pretty vivid again, yay.

Two of the most interesting sets of changes are the eventually committed support for AMD’s Yangtze-based SPI controller (found in Kabini and Tamesh), and finer-grained display of support/test status of hardware. For example we can now clearly indicate if a flash chip is actually a ROM that can only be probed and read. This has become necessary when we added our first ROM chip, Macronix MX23L3254. The results can be seen in the wiki as well as flashrom’s -L output. Besides that there were also various new chips and even two programmers committed with another 1-3 waiting.

It is still a bit early to nail down any fundamental changes I want to tackle, but I think I’ll manage to rewrite the probing algorithm completely this year. I have made one huge step towards that by getting rid of the .probe_timing field of struct flashchip. It was used by some probing functions of parallel chips but there were only about 5 concrete values so they could easily be wrapped into stub functions. This is – as Carl-Daniel correctly stated – not what we normally do… replacing data in tables with code, but in this case I think it is completely justified. The next big step will be to turn the probing loop inside-out. Currently we iterate over all flash chips, filter the ones compatible with the selected programmer, and execute the respective probing function stored. Naturally this creates the same results over and over again because there is only about a dozen different probing functions. That does not only take a lot of unnecessary time but also makes it hard to support more than one probing function. It should be the other way round: we should iterate over all possible probing functions and match the results with the stored flash chips. I will report back how far I got with that in my next post.

GSoC (board-)status update

Two weeks went past fast. Our industry partners have been kind and I received some new boards for coreboot testing. I think I spent three workdays on just the initial hardware setups and SPI recovery tools for the boards.

You should already see a posted board status report for Gizmosphere/Gizmo built from coreboot.org toolchain and source tree. I have Adlink/CoreModule2-GF (aka LiPPERT/Frontrunner-AF) and PCEngines/apu1c4 next on my list to report. Latter board also requires it coreboot sources to be rebased and published.

These are all Agesa Family14 boards, more or less intended for embedded application use. When applicable, I will try to do some demonstration of the capabilities of Sage EDK and SmartProbe as those seem to be somewhat standard commercially available toolkit for AMD Embedded Partners. It is clear we cannot beat a JTAG based in-circuit debugger with an alternative running over USB, but we may get surprisingly close by improving the command set of the GDB stub we run in ramstage.

Most of my time is still on solving some early memory space mapping issues for AMD platforms. As expected, reviews and test reports there are progressing slowly. My goal with these is to have CBMEM and USB consoles work in romstage too and additionally some boards currently lack S3 resume support and/or have PCI-e reset problems. I expect most of my development to work unmodified for fam15, fam15tn and fam16kb.

As a sidedish there has been more than the typical amount of review work for me on the table. Edward has done an amazing job sorting out the superio spaghetti romcc left us with. There was also a fair amount of discussion around IRQ routing and new Intel FSP ports to look at.

cbfs_media [Week 1]

This post covers the complete set-up and building coreboot for cubieboard. Due to lack of documentation for this, I had to spend sometime figuring out the details; hence decided to write it myself to help others in the future.

Step 1: Build Payload

As mentioned here, what we have to do first is to build a payload to use later for coreboot.rom. A suitable ARM payload is the sunxi/uboot. Now, there are two ways to build uboot: natively or from another system. To build from another system, we need to get a suitable toolchain. For that you need to do:

apt-get install gcc-arm-linux-gnueabihf

Too many issues are faced to get this toolchain set up right 😐 A more suitable and convenient method is to build uboot natively from the cubieboard itself (thanks #cubieboard for the tip :P). For this follow the instructions here. tl;dr Clone repository, choose you target board, make (without CROSS_COMPILE). This completes building the payload. NOTE: The correct file to use as the payload is “u-boot”, not u-boot.bin. The “u-boot” file is the non-SPL part of uboot in elf format. The log for successful build can be seen here.

file u-boot
u-boot: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

2. Step 2: Build coreboot

Before following the instructions on the coreboot/Build_HOWTO, you first need the latest development code; which contains the mmc driver needed to load romstage, etc.

You need to make crossgcc first. This might take a lot of time: be patient 😛 Some missing toolchain errors can arise. Get past them by:

apt-get install bison flex patch
add-apt-repository ppa:linaro-maintainers/toolchain

Once this is done, set your suitable configuration in make menuconfig. Make sure to disable CONFIG_VGA_ROM_RUN (set by default), since it doesnt work for ARM boards. Just make and wait. Your coreboot.rom is ready. 🙂

This image needs to be placed on the SD card:

dd if=build/BOOT0 of=/path/to/sdcard/blockdev bs=1024 seek=8

Now pfff! this is enough to get coreboot up and running! 😀

For the next week; our plan is to Identify locations of the map() and read() calls; and to determine size of each map(). The driver is currently configured to pull the entire cbfs into ram; so we work to reduce size of these mappings.

[Pre-GSoC] Set up Phase – II

Hi All! This is in continuation with the previous blog post regarding set up. This post will contain the brief walk-through the process of setting up the cubieboard.

The first step is to burn the linux image on the micro SD card, and then use this micro SD card to boot the board. The BerryBoot interface is quite user-friendly and we can follow the instructions on it to successfully complete the process. Details for this can be found here.

The latest set of linux distributions that are available can be seen when we power on the board with the micro SD card inserted. This image depicts the screen as visible:

After completing the installation process (takes about 10 minutes) we successfully install Linaro Ubuntu 2012.11

The Home screen looks like this:

Thus, the set-up process is completed. A schematic for the cubieboard can be found here. Also, a cool video with the whole process can be seen here.

It is 20th May, and now its time to get cracking on the summer of code! 😀 My abode for the next few months:

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…

I 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. 😉

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!