flashrom
GSoC 2011: flashrom part 5 – Dear Intel
1As mentioned in my GSoC recap, Carl-Daniel and i have sent a letter to Intel to get more information regarding the descriptor section and unlocking the ME flash protection (my official GSoC main project). It was sent about 3 weeks ago (2011-07-29). No reply was received so far. This is the whole message we have sent them: (more…)
GSoC 2011: flashrom part 4 – recap
2Final 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).
flashrom 0.9.4 released
0After 9 months of development since the last stable version we are happy to announce the release of flashrom 0.9.4.
GSoC 2011: flashrom part 3 – Midterm Evaluation
1in 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. (more…)
GSoC 2011: flashrom + filo = ?
0
The answer is flashrom payload, which is capable flashing roms out of usb stick. If you use seabios, you will be able to choose to run this payload instead of booting os. It might be worth for payload developers if we would have a small payload for selecting other payloads out of CBFS
Patches are here. Sorry for weird stuff there
My G
SOC project is not going well, I end up with problems almost everywhere
(Only the good thing is that my exams went well). I spend my time trying to understand what is going on. Yesterday I was running an overflowing code allmost all day, until I found out what is wrong… My E350M1 is still not working (coreboot doesn’t run with 512 kB chip). So I have ordered some chips from ebay. While I’m waiting I have made some PCB adapters to make a dual flash device. Also made additional PCB for RS232<->UART<->USB interface.
I would better go coding… Bye!
GSoC 2011: flashrom part 2 – SFDP
0SFDP (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 0×0 a mandatory header begins with a signature 0×50444653 (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. (more…)
GSoC 2011: flashrom part 1 – Hardware Sequencing
0Hey 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.). (more…)
GSoC project: Coreboot panic room. Diagnostics (also remote flashing)
0- I’m very excited to announce my GSoC project which is intended to bring some light for coreboot users. To begin with, I would like to introduce myself. I’m 20 years old student living in Lithuania. I’m studying Informatics Engineering at Kaunas University of Technology. This year we have two interesting modules here: one about operating systems and the other is introduction to computer architecture, which is crucial for learning coreboot. Some time ago I have played with avr microcontrollers, so I have good soldering skills. One day during my free time I thought:
-
What the hell my old computer’s bios is so badly written that it can’t boot from usb flash and it can’t suspend correctly on Linux? I have a laptop that is running bios stuff more time than the old computer. I thought I can’t live with that and then I found coreboot
I was very excited that it was so configurable, so open alternative
Not to waste time on cheap talks, here is my project:
-
To help developing coreboot code, we have to set-up remote diagnostics (also flashing) interface in coreboot. We will be a able to renew bricked board through serial port or even do some research through registers in case of panic(). This will enable easier development of CAR, chipset, payloads code.
- Abbreviations used later:
- TARGET – machine running coreboot;
- HOST – machine running serial port application, connected to TARGET through serial port
- The platform that I will use for development is traditional x86. In case coreboot is supported on ARM, I will be hapy to buy one board to make my code working on both platforms.
- There will be a diagnostics shell, similar to Serial ICE (or LLshell). Invocation of the shell may occur at any time (when we have (cache or ram) memory or not). It would be invoked by (we should discuss this):
- 1) serial port data received interrupt (HOST triggers diagnostics mode)
- 2) if user specified it in code (we may add something like checkpoints in coreboot’s code where TARGET will send command through serial port to HOST and if receives the answer – it enters diagnostics mode)
- 3) in case of panic() invocation (or something like die())
- In that shell’s loop we will be able:
- 1) to run the code instructed through serial port (like Serial ICE): manage register contents, do some research or even like Carl-Daniel suggested to initialise CAR
- 2) to flash memory through serial port, when we have some memory (CAR or RAM) initialised. Some generic flashing code will be pumped through serial port to memory and then executed.
- Some small specific goals:
- 1) analyse different code handling schemes in cases of memory we have (no memory, CAR, RAM)
- 2) define how Serial ICE will be integrated to coreboot
- 3) integrate defined Serial ICE stuff to coreboot as our new shell
- 4) add memory handling funcions to our new shell (for checking how much memory we have, and if we have – for uploading code to memory)
- —
- 5) analyse flashing protocols
- 6) develop uniform flashing scheme (for SPI, parralel flash…) define what commands are required, where these commands should reside.
- 7) make serial port application for HOST (maybe we will use flashrom’s serprog code, it might require enhancing)
- These are just milestones, some points may change after deeper investigation, when we will have something done.
- We may experience the risk of problems in different operating modes when having different memory (no memory, CAR, RAM).
- Yesterday I was looking at flashrom sources. People have done very good job in preparation for porting it to libpayload. Maybe I should concern making a complete flashrom port on libpayload?
- Anyway, thanks for reading about my project. You are welcome to post some comments (maybe on the mailinglist). Your experience would be helpful.
- Thanks to our mentors for their patience
FOSDEM 2011 photos
1I just found out that nobody wrote a few lines about this year’s FOSDEM 2011. This year we had a booth (aka a “table”) in one of the buildings. We had total 4 speeches. I did one lightning talk about the coreboot and x86 init (video) and a lecture about coreboot and its speed. Carl-Daniel Hailfinger had lightning talk (video) and a talk about RAM Cold Boot Attacks The talks had a great success and a lot people attended. (more…)