Author: stefanct

This week I have a very important directive to share with you:

Working (and especially debugging) in a methodological way does not only mean that every step should be taken on scientific grounds, but that the order of steps should be in an effective order too.

Why do I mention that? Last week I told you that the nice guys at Sage and AMD have sent me an ASRock Kabini board. I received it the following day (which amazed me quite a bit, because it came from US hence it had to undergo a customs check too…), hooked everything up: an old 300W ATX power supply (way overpowered for a 10W SoC) which I have used for coreboot development in the past, USB keyboard and mouse, network, a USB key with Ubuntu and a power button. I switched the PSU on, pressed the button and the fan began to rotate… for a few hundred milliseconds. WTF? I stripped away the non-essential connections and tried again – no change. I thought it could be the PSU – maybe the load is too small or something. But since I had no other supply easily accessible I decided to look at other possible causes: I checked all jumper settings (and there are quite a few of them) and noted a difference between the docs and the actual board regarding the jumpering of an always-on feature (which was a dead end but seemed very promising first), I cleared CMOS memory, reseated the DIMM etc. I even hooked up the flash chip to my logic analyzer to see if it tries to read commands from it… but there was no single proof of life.

So what do you think, is the board dead?

Did you spot the error I made? I hope you did with the blunt hint in the beginning. 🙂 After pulling another PSU out of an old PC and hooking it up everything was fine. *sigh*

When getting the board up eventually I just did a few quick tests (including the flashrom hack that Wei Hu contributed after some discussion in my previous blog post (oh who would have thought that these blog posts are useful at all!? :P)) and put it aside again for hacking in the weeks to come.

The remaining time was spent again on bringing flashrom up to shape for release, waiting for Carl-Daniel and negotiating with a Micron representative over support for their (i.e Numonyx’ and ST’s) chips in flashrom. It has not been the first time for me to mail back and forth with flash vendors, but it is always quite tedious to explain non-technicians and/or people with no idea about open source what we have to offer and what we need; often language barriers play a role too. For example I tried to explain to a Macronix guy about 3 or 4 times why I can not truthfully fill out the sampling order form completely (i.e. the company field) before I gave up. I can’t remember if I filled out the form in the end or not, but I received the samples eventually. Together with the Micron samples that should arrive this week and other samples I received previously I will soon have more than 1GB of SPI flash space at my desk, yay. 🙂

This week I was busy preparing flashrom for the 0.9.7 release and queue up some overdue patches to be merged shortly after. This includes the infamous layout patches which I need to polish a bit since quite some time has passed since they were created and the surrounding conditions have changed a bit. Not only did flashrom evolve quite a bit (the original version of the layout patches were part of my GSoC 2011 contributions(!)), but I have learned a few tricks in the meantime too, I hope. Progress is rather slow because I am waiting for Carl-Daniel’s input to various issues but there is no response. That’s also the reason why I chose the subject for this blog post ;).

When I stumbled over a discussion in #coreboot about the new AMD SoCs (Kabini et al, preliminary BKDG), I discovered that they apparently contain a new flash interface supporting all kind of neat stuff (e.g. Multi I/O). This would match parts of my GSoC project perfectly and so I made a joke by asking who will send me a board. To my pleasant and big surprise I received a private message a few minutes later and a brand new ASRock IMB-A180-H is currently on the way to me. I want to express my gratitude to Martin Roth from Sage who was so kind to arrange this and Sage and AMD for paying for it. 🙂

Lately I’ve been looking at libpayload a bit since it will probably play some role in Kyösti’s project in conjunction with libflashrom. So it is also important that I grasp it before I am working on libflashrom. I got (lib)flashrom to compile locally with a slightly patched version of libpayload (patches pushed upstream of course). I hope to get the changes needed in flashrom out before release (NB: I am talking about the current state of libflashrom not about Nico’s patchset). After that I’ll continue to queue up/refine overdue patches – the main focus will be on Nico’s libflashrom.

My name is Stefan Tauner and I am still studying computer engineering at the Vienna University of Technology. I participated in one of coreboot’s GSoC projects in 2011 and continued to contribute mainly to flashrom since then. I became pretty much its main contributor in the process so I could not just leave afterwards. Also, some of my patches from back then are still not merged so when coreboot was accepted for this year’s GSoC the goal was clear: increase the patch pile even more. 😉 Naturally I’ll be working on flashrom’s core. I plan to add some infrastructure improvements which are kind of overdue. Please see my full proposal for details.

Final evaluation deadline for this year’s GSoC is in 2 weeks. Most of what i have written in my midterm evaluation is still valid.

We have formulated and sent an email to various Intel representatives in the hope to get at least a few hints regarding ME unlocking (and descriptor semantics). I had the idea to send them a mail earlier, but thought it is an ludicrous attempt from all i have gathered regarding Intel’s cooperation with coreboot. Carl-Daniel suggested giving it a go anyway and it provided me a good excuse to not work on REing until we get an answer. Of course we have not received any reply to date 🙁

So i think it is quite clear that my main GSoC project will fail to be delivered on time. But i won’t vanish after GSoC and i still plan to implement ME unlocking eventually.

What’s up besides the GSoC project?

The integration of my patches still lacks reviewing power. Everyone but Carl-Daniel seems to be not much interested in my work and he has not the time to look at everything i produce. Right now flashrom has about 150 patches requiring some action to merge them. Thereof are 41 from me (TBH there is a number of patches that are just rebased and improved a little bit) and 37 from Carl-Daniel. meh.

With the help of Florian ‘florz’ Zumbiehl i was also able to find, fix and report a bug in dmidecode which has direct influence on flashrom. Due to an error in decoding the chassis type in dmidecode, flashrom falsely declares some boards to be mobile devices, which makes it shout a big warning at the user unnecessarily.

I’ve been also working on rebasing, improving and reviewing (very) old patches of others whose discussions just stopped (for example when contributors did not send improvements). My hope is that this will help us shorting the long patch queue, but i doubt that it will suffice 😉

To conclude (or begin) my recap of my GSoC involvement this year, i’d like to first thank google for doing this. This sounds quite pathetic, especially if one knows me better. But it really got me involved in FOSS development with the intensity i wished for (by providing a monetary motivation to get really started). There was some involvement in the past (bug reports and fixes etc.), but flashrom was apparently a nice target to get more involved and learn a lot, not so much about REing and technical details (as i expected and hoped in the beginning), but regarding project management in FOSS (my own proposal, but also flashrom and its patch queue/processing and “upper management’s” free time constraints), interacting with contributers and users, and mastering git (the latter is quite ironical because flashrom does not use it (yet)). It’s a bit sad, that flashrom does not have more contributers (especially reviewers). This is obviously a problem and it might be the time to discuss the development process as a whole. The question is with whom should i discuss this if no one is there 🙂

Although my formal project will not be finished on time, i think i have served the flashrom project well and from the feedback i received so far, Carl-Daniel is also happy with my work. So i think i can declare it as successful after all and i would like to thank everyone involved (so far).

in schools essays that stray away from topic are often graded strictly. if one applies similar principles to my gsoc work it would probably degrade to “satisfactory” or worse. when i submitted my application for gsoc, most of my time line consisted of reverse engineering tasks. the plan was to quickly implement hardware sequencing and start reversing some vendor tools to find out how they unlock the ME.

what really happened is something i think is at least as useful as working ME unlocking code: flashrom got an almost full-time maintainer. 😉
i am handling a big chunk of the daily work (support requests on the mailing list and on IRC, keeping our database of tested devices up to date etc.) and i try to fix all problems in flashrom that i become aware of. this has led to countless already accepted patches and many which are still not reviewed yet. Continue reading GSoC 2011: flashrom part 3 – Midterm Evaluation

SFDP (Serial Flash Discoverable Parameters) is a JEDEC standard for querying the capabilities of serial flash chips. This allows software like flashrom to support chips without having all properties hard-coded beforehand. SFDP is structured in tables which are laid out in their own linear address space (independent from the “normal” range used to access the stored data). Starting at address 0x0 a mandatory header begins with a signature 0x50444653 (or ‘S’, ‘F’, ‘D’, ‘P’ in ASCII) followed by versioning data and the number of parameter headers. These headers are 64b long and have fields for versioning data, identification, length and offset where the real stuff i.e. the parameter table resides. There is one mandatory table and up to 255 can be added optionally. In the current version of the standard (2011-04) only the mandatory table is defined, but vendors are free (and quite encouraged by the standard) to add their customized tables and from the few data sheets i have seen mentioning SFDP the vendors do that (see below).

I spare you from the nasty details, but keep in mind that the mandatory table allows to retrieve the following properties:

• the total size of the device
• 4 (unified) block erasers (size of erase blocks and associated opcode)
• address mode (24b, 32b or both)
• status register write enable (none, WREN or EWSR)
• lots of fast read-related stuff (like modes supported and number of wait states/dummy cycles needed in each)

The good news is: this would be enough to allow flashrom to work with unknown (yet unreleased) chips without recompilation!

The even better news is: i have a patch for that 😉

The bad news: i am not sure if there exists any hardware that supports it yet. Continue reading GSoC 2011: flashrom part 2 – SFDP

Hey there!

My name is Stefan Tauner and I am the one GSoC student working on flashrom this summer. I live in Vienna/Austria where i am studying computer engineering since 2005 (almost done, I only need to find someone writing my thesis for me… should ask some politicians where they got their ghostwriters…).

Since I started playing around with flashrom and proposed my GSoC project in March I have been quite active in the small flashrom universe. The current main maintainers and contributers – Carl-Daniel Hailfinger, Stefan Reinauer and Michael Karcher – were all very busy and so i was drawn into handling the daily support with the help of other regulars (most outstandingly Idwer Vollering, thank you!). This proved to offer very good opportunities to dive into the code base to answer the questions of others and to get familiar with the overall design. It also led to numerous (mostly tiny) patches authored by me which can be viewed on our patchwork site.

Although I think this was all quite fruitful and also in the best interest of flashrom the main objective is something else: Add support to unlock flash regions on newer Intel chipsets. Many details can be read on the thread leading to my GSoC application here. In this post i will focus on a tiny related bit, that i have already implemented and is currently under review: Hardware Sequencing.

Two weeks ago I wrote a lengthy mail to our mailing list (which you certainly should follow if you are interested in our work!) about my plans to implement hardware sequencing for Intel chipsets and some related questions. You can read it at our mail archive site too, but i will republish it here almost in full (please forgive me the left out capitalization etc.). Continue reading GSoC 2011: flashrom part 1 – Hardware Sequencing