GSoC
Google Summer of Code
GSoC 2011: flashrom part 2 – SFDP
2SFDP (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…)
GSoC2011(Week 1): Analysis of U-boot ARM boot code
2This is such a busy week. At the end of last week, I have just ordered my OpenRD-Ultimate box but sadly it will be delivered at the end of June. So if I just wait for that box, I will not be able to test my code. That’s terrible! After talking with my mentor, I decided first porting coreboot to RealView Versatile/PB926EJ-S board then to OpenRD-Ultimate. Since qemu can emulate PB926EJ-S, I can test my code on it quickly and freely. After this work, the basic layout, libs and headers for ARM are ready to use. So I can start to port coreboot to OpenRD-Ultimate then.
(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
coreboot GSoC 2011
0coreboot has been accepted as a GSoC 2011 mentoring organization. This is coreboot’s fifth year in GSoC participation.
If you are a prospective student, mentor, or have project ideas, please visit the wiki for more information.
GSoC 2010, TianoCore as a payload :(
2It’s been an interesting summer. It didn’t at all turn out how I expected, but it is what it is. TianoCore as a software project turned out to be massively more complex than I anticipated when I submitted my proposal, and the level of knowledge required was quite a bit deeper than I expected… it’s one of those cases where I didn’t know what I didn’t know. I’ll have to talk to a couple of my professors about that, to see if there’s some elective class that explains the things I’ve missed.
Sorry, that’s vague, let me give an example. Coreboot does it’s thing, hardware initialization, then passes control to the payload. This seems to be the equivalent of the dreaded “goto”, which is actually pretty cool. Coreboot doesn’t care what happens next. So hypothetically, I have some code, anything, I want to use it as a payload. I compile it, then what? Well, it depends (as you all know), how was it compiled? Is it an elf? PE32? Something else? Where exactly is the entry point to this binary blob? (That’s a rhetorical question, please don’t answer it in the comments.) You would have thought at some point in one of my classes executable formats would have come up, just as an example. Or calling conventions. Or hundreds of other little things that I’d never seen or heard of before I suddenly realized that I needed to understand them. So that’s what I ended up spending much of the summer on. Write code… stop and realize what I’m doing doesn’t make sense/won’t work/is the wrong approach, then start over.
One of the things that drew me to coreboot as a project was that as a computer engineering student, I took a lot of classes focusing on the physical side of computing, starting with physics and circuits classes, moving up through logic gates to chip design. On the other side, programming started at a pretty high level with c++, then worked down, till I got to the computer architecture and operating system classes, and assembly language (not x86, unfortunately). I would expect that as a “computer engineer” I should understand the whole stack, that the physical, EE stuff and the CS stuff would meet in the middle. But they haven’t (and they won’t: I’m about to graduate, and there aren’t any crucial classes left to take). I knew this going into GSoC, and coreboot seemed like the perfect project to fill the gap (and give something back to the open source world that I’ve gotten so much out of). Well, like I said, the gap turned out to be a lot bigger than I expected. (To abuse the metaphor a little more, anyone remember when Evel Knievel tried to jump the Snake River Canyon? That’s kind of how I feel about my summer of code.) (more…)
flashrom GSoC 2010 wrap-up
0My GSoC 2010 flashrom project has been a full success, and I managed to add lots of features to flashrom which were not part of the original requirements as well.
GSoC USB: Conclusion
0Now that GSoC is coming to an end, I prepared the patches and pushed the code upstream.
r5691 contains the work done until today, which is what I’ll post as my final result to GSoC, too. Work won’t end on it however, so expect more patches in the future.
OHCI
OHCI works – except for interrupt transfers, which are mostly used (in boot environments at least) for keyboards.
xHCI
That one is more complicated than the other controllers combined, and while I made a couple of stupid mistakes that held me up for longer than I wanted, there are aspects in xHCI that make the bootstrap of the driver harder than I’d like it to be.
Once you got the command and event channels set up, it seems that xHCI provides a neat interface for getting all kinds of status information out of it. The only problem is that setting up these channels seems to be more complicated than the entire bring up of UHCI – at least, that’s where I’m stuck right now.
I’ll get back to it, but I hope that a couple of days of doing something else will help me to finally see the problem.
Conclusion
Doing both drivers was ambitious. While I didn’t have the burden of creating the stack design, and learning USB in the first place, like I had in 2007 (when I worked on UHCI for GSoC), it’s still two specifications to understand, two way of communication between the controller and the host system, and finally two drivers to write.
It was fun, but I’ll be more conservative in choosing my project, and estimating the required effort, next time. It’s much easier (and also more satisfying) to add some tasks when the job is done early than to remove them – especially when you get to strip milestones because the hardware is acting up.