|
|
| (20 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| = General info = | | == Information and Links == |
|
| |
|
| The [[flashrom]] project will hopefully participate in GSoC 2013 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications (for both projects) and available mentors, there will be usually one or two slots for flashrom projects. Most of the information on the coreboot site is also valid for flashrom students, please read them.
| | Flashrom is applying for participation in [https://developers.google.com/open-source/gsoc/timeline GSoC 2022] (also known as Google Summer of Code). We will update this page in March 2022 once the registration is confirmed. |
|
| |
|
| If you want to apply, it is probably a good idea to subscribe to our [[Mailinglist|mailing list]] and take a look at our page with [[easy projects]]. You can show us that you are able to work with our codebase and/or read datasheets by solving some of the problems noted there. It is a good idea to talk to us before you start though (list items may already be worked on/partially solved by by other prospective students).
| | You are very welcome to look at our list of project ideas in [https://docs.google.com/document/d/1AxMobB2v8Dv2uUwZPZ_vCmmONYDJuliHcnjfWOs4qIs/edit?usp=sharing this doc]. |
|
| |
|
| The list below is an idea collection and not set in stone. If you're interested, please talk to us on the [[Mailinglist|flashrom mailing list]] and/or on [[IRC]] irc://irc.freenode.net/#flashrom and we can make them more concrete together depending on your skills and interests.
| | If you are interested to propose your own idea for GSoC project, have a look at [https://docs.google.com/document/d/1DSg1FykuI7Z3JDY1Qtk8C6JjvpsYISMEwyV4932jtBI/edit?usp=sharing this template]. |
|
| |
|
| == flashrom contact == | | == How to contact us == |
|
| |
|
| If you are interested in becoming a GSoC student, please contact the flashrom [[Mailinglist|mailing list]] or visit our [[IRC]] channel <code>#flashrom</code> on [https://webchat.freenode.net irc.freenode.net]. Please note that most of the developers live in Europe, so responses on IRC may be a bit slow if people are asleep. | | If you are interested in becoming a GSoC student, please have a look at our [[Contact]] page. |
|
| |
|
| If you need to contact someone directly, [mailto:marcj303@gmail.com Marc Jones] is the GSoC admin for coreboot (our sister project which handles GSoC administration for flashrom). | | If you need to contact someone directly, Anastasia Klimchuk (aklm), Felix Singer (flx) and Angel Pons (hell) are our GSoC Admins. |
|
| |
|
| == How to apply == | | == Why you should choose a Flashrom project for GSoC == |
|
| |
|
| The procedure for applying for a flashrom idea/project is identical to the coreboot application procedure. Please follow the link [http://www.coreboot.org/GSoC#coreboot_Summer_of_Code_Application coreboot Summer of Code Application].
| | * Flashrom offers you the opportunity to work with modern hardware “right on the iron”. |
| | * Hardware is fun. And it’s complicated. You will learn that datasheets are just loose guidelines to the hardware and real insight is gained by systematic tinkering. |
| | * Flashrom is the only multi-platform open source solution for flash EEPROM reading/writing for lots of different devices: on-mainboard flash (for BIOS/EFI/coreboot), graphics/network card flash (for firmware), and dozens of specialized programmer devices. If you want to update your BIOS/EFI/coreboot or update some firmware from a running Linux/*BSD/... system, then flashrom is the only choice you have. |
| | * Flashrom does hardware access (like firmware/drivers), but completely in user space and without the hassles present in firmware or OS kernels. That way you can write complex hardware access with ease. |
| | * Flashrom has a worldwide developer and user base. Big companies like Google and individual users use and contribute to it. |
| | * We are a very passionate team – so you will interact directly with the project initiators and project leaders. |
| | * We have a friendly and helpful community. Flashrom has some extremely talented and helpful experts in all things flash active in the project, and many of our friends from the coreboot project participate in flashrom as well. They are ready to assist and mentor students participating in GSoC. |
|
| |
|
| = Why work on flashrom for GSoC 2013? = | | == Contents of your application == |
|
| |
|
| ''TL;DR: It's cool. Seriously. (Similar reasons as coreboot.)''
| | Please have a look at our project proposal template [https://docs.google.com/document/d/1DSg1FykuI7Z3JDY1Qtk8C6JjvpsYISMEwyV4932jtBI/edit?usp=sharing here]. |
|
| |
|
| * flashrom offers you the opportunity to work with modern hardware “right on the iron”.
| | == Contributor commitments & requirements == |
| * Hardware is fun and weird. You will learn that datasheets are just loose guidelines to the hardware and real insight is gained by systematic tinkering.
| |
| * flashrom is the only multi-platform open source solution for flash EEPROM reading/writing for lots of different devices: on-mainboard flash (for BIOS/EFI/coreboot), graphics/network card flash (for firmware), and dozens of specialized programmer devices. If you want to update your BIOS/EFI/coreboot or update some firmware from a running Linux/*BSD/... system, flashrom is the only choice you have.
| |
| * flashrom does hardware access (like firmware/drivers), but completely in user space and without the hassles present in firmware or OS kernels. That way you can write complex hardware access with ease.
| |
| * flashrom has a worldwide developer and user base. Big companies like Google and individual users both use it and contribute to it.
| |
| * We are a very passionate team – so you will interact directly with the project initiators and project leaders.
| |
| * We have a large, helpful and friendly community. flashrom has some extremely talented and helpful experts in all things flash active in the project, and many of our friends from the coreboot project participate in flashrom as well. They are ready to assist and mentor students participating in GSoC 2013.
| |
|
| |
|
| == Why NOT work on flashrom for GSoC 2013? ==
| | What does it mean to be a Flashrom GSoC contributor? |
|
| |
|
| * If you want to create content for Adobe/Macromedia Flash, this is not the right project for you. We are working with flash chips based on EEPROM technology, something completely different from Adobe Flash. (You wouldn't believe how many questions we get about this.)
| | Google Summer of Code is a significant time commitment for you. |
|
| |
|
| = GSoC Student requirements =
| | Medium-sized projects are estimated to take 175 hours, while large-sized projects are estimated to take 350 hours. The standard program duration is 12 weeks and in consultation with the mentor it can be extended to 22 weeks. Please keep in mind that the actual number of hours you spend on the project highly depends on your skills and previous experience. |
|
| |
|
| ''TL;DR: Pretty much the same requirements as coreboot: GSoC is a full time job, send a small patch before student application deadline, interact with the community.''
| | GSoC provides some ways allowing you to be more flexible, but make sure that your schedule (exams, courses) give you sufficient amount of spare time. |
|
| |
|
| What will be required of you to be a flashrom GSoC student?
| | # Prior to project acceptance, you need to demonstrate that you can work with the flashrom codebase. |
| | ## You need to be able to read and write C code. |
| | ## You need to be able to work with our git repository. Check our [https://www.flashrom.org/Development_Guidelines Development Guidelines] for details. |
| | ## Look at [https://review.coreboot.org/q/project:flashrom Pending Patches] to see what’s going on, who are our active developers and code reviewers, what does code review look like. |
| | ## By the time you have submitted your application, you should have downloaded and built flashrom as well as applied some patches. Run flashrom on real hardware or try at least the dummy programmer driver. |
| | ## Send a patch to Gerrit for review. Check [[Easy projects]] or ask for simple tasks on the mailing list or on IRC. Please include your flashrom output and test results in the commit message and/or comments to the patch. |
| | # To pass and to be paid by Google, we require that you meet certain milestones. |
| | ## First, you should be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the "community bonding period" between acceptance and official start. |
| | ## You need to have made progress and committed significant code before the mid-term point and by the final. |
| | ## Once a week, you will post what’s happening on your project on the mailing list. This way you will measure and share progress with the community, and the community at large will be able to help you. GSoC is not a private contract between your mentor and you. If you have your own blog, you are very welcome to post updates there, and we will link your blog from our website. |
| | ## You need to be active on IRC and the mailing list. Sending massive patches for midterm and final without any communication in between is not sufficient. |
|
| |
|
| Google Summer of Code is a full (day)time job. This means we expect roughly 40 hours per week on your project, during the three months of coding. Obviously we have flexibility, but if your schedule (exams, courses) does not give you this amount of spare time, then maybe you should not apply.
| | We don't expect our contributors to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task. |
|
| |
|
| # Prior to project acceptance, you have demonstrated that you can work with the flashrom codebase.
| | And finally, here are [https://google.github.io/gsocguides/student/ official guidelines for contributors]. |
| #* You need to be able to read and write C code and know what a pointer is.
| |
| #* You need to be able to work with our source code repository (check out the code, generate a diff/patch for your changes, apply a patch from someone else). We use subversion, but some up-to-date git mirrors are available. Don't worry, you can learn everything you need from scratch in less than 30 minutes and we'll help you.
| |
| #* By the time you have submitted your application, you should have downloaded and built flashrom as well als applied some patches. Run flashrom in QEMU, on real hardware or try at least the dummy programmer driver if you're afraid of hardware problems. Please email your flashrom output and test results to the flashrom mailing list.
| |
| #* Send a patch to the [[Mailinglist|mailing list] for review. Check [[Easy projects]] or ask for simple tasks on the mailing list or on IRC.
| |
| # To pass and to be paid by Google requires that you meet certain milestones.
| |
| #* First, you must be in good standing with the community before the official start of the program. We suggest you post some design emails to the mailing list, and get feedback on them, both before applying, and during the "community bonding period" between acceptance and official start.
| |
| #* You must have made progress and committed significant code before the mid-term point and by the final.
| |
| # We require that accepted students to maintain a [http://blogs.coreboot.org/ blog on coreboot.org] (our sister project managing GSoC for us), where you will write about your project weekly. This is a way to measure progress and for the community at large to be able to help you. GSoC is not a private contract between your mentor and you.
| |
| # Student must be active on IRC and the mailing list. Sending massive patches for midterm and final without any communication in between is not sufficient.
| |
| | |
| We don't expect our students to be experts in our problem domain, but we don't want you to fail because some basic misunderstanding was in your way of completing the task.
| |
| | |
| = Project ideas =
| |
| | |
| Most of the ideas below are fleshed out, some (laptop support) are not (due to being unrealistic for GSoC unless you have strong prior expertise in our problem domain, and in that case we'll gladly expand the description if you ask).
| |
| | |
| Some ideas have a strong focus on hardware "drivers", others are almost completely focused on overall code architecture. If you have questions, just ask.
| |
| | |
| == Support more chips - Implement (obscure and) unsupported features - Try to make flashrom write EEPROMs ==
| |
| | |
| Most unsupported chips need some architectural work in flashrom's core because they behave substantially different to most other chips. The same applies to EEPROMs. Some yet unsupported features like OTP, locking or GPIO control may have been seen too obscure and not in the scope of flashrom. It might be fun to work on them and evaluate the resulting changes to flashrom's core. The main objective here is not to produce mergeable code for upstream, but to show what changes to the existing code would have to be done. If those are sustainable without breaking anything and do not bloat flashrom too much, integrating the code is of course a subgoal.
| |
| | |
| '''Helpful Knowledge/Skills'''
| |
| * Reading datasheets
| |
| * Depends heavily on exact goal
| |
| | |
| '''Main Mentor'''
| |
| * [[User:Hailfinger|Carl-Daniel Hailfinger]]
| |
| | |
| == libflashrom - Multiple UIs for flashrom ==
| |
| libflashrom is the name for the part of flashrom's code that forms its core and should eventually be independent from any user interface. This allows easy creation of user interfaces and integration to existing applications. There exists a patch set implementing this idea by [http://patchwork.coreboot.org/project/flashrom/list/?submitter=3002 Nico Huber] already, but it was not reviewed yet. It would certainly be a good starting point for anyone looking into this project.
| |
| | |
| In general implementing this idea requires the following steps:
| |
| * code cleanup (e.g. removal of stray exit() calls and returning proper error codes instead)
| |
| * API design and implementation
| |
| *: It is not enough to just separate the code from the existing user interface. There must also be added some glue code so that the separate parts can be developed independently. For example there has to be a generic way to query programmer modules for their available options so that UI code can present them to the user without knowing about that specific programmer before. You can find a few thoughts at [[libflashrom]].
| |
| | |
| It is probably a good idea to work in parallel on a user interface so that you become aware of problems and missing API bits. Naturally the existing command line interface should continue to work (but be separated). This is also an easy way to evaluate your work. If we see that your UI code can work independent of the libflashrom code in the way it should while providing the interaction possibilities we deem(ed) useful, you have been definitely successful.
| |
| | |
| Some obvious UI ideas are:
| |
| * flashrom TUI (text mode user interface) (for command line and flashrom-as-payload)
| |
| * flashrom GUI (graphics mode user interface) (should be cross-platform, has been tried a few times and may be based on those attempts)
| |
| | |
| There have been a number of attempts to create a flashrom GUI, but [[Qflashrom]] is probably the only one of interest for you.
| |
| | |
| '''Helpful Knowledge/Skills'''
| |
| * Abstraction/refactoring of existing code and library design
| |
| * Knowing the flashrom code base
| |
| * Cross-platform GUI toolkit
| |
| | |
| '''Main Mentor'''
| |
| * [[User:Hailfinger|Carl-Daniel Hailfinger]]
| |
| | |
| == ROM image parsing and preparation ==
| |
| flashrom does not analyze the images fed to it.
| |
| Therefor it is not able to detect if the image is correct for the target computer neither to automatically derive [[Board Enable|Board Enables]], detect write protected regions or bootblocks etc.
| |
| There exist a number of tools already to dissect, unpack and analyze images.
| |
| Some of them reside in the (aptly named) [http://www.coreboot.org/Bios_extract '''Bios extract'''] [http://review.coreboot.org/gitweb?p=bios_extract.git repository].
| |
| Another pair of tools are [https://github.com/NikolajSchlej/FD44Editor '''FD44Editor'''] and [https://github.com/NikolajSchlej/FD44Copier '''FD44Copier'''] which can show, edit, and extract lots of information of UEFI images of Intel-based ASUS boards and prepare it to be flashed back. The [http://hardforum.com/showthread.php?t=1726429 companion thread] tells how to use them and what they do more in-depth.
| |
| Then there is '''ich_descriptor_tool''' residing in the flashrom repository, which is able to parse the descriptor region found on most Intel platforms and there is an automatic board enable finder authored by Roxfan which is yet unreleased. If the license permits it other code can of course be used too.
| |
| | |
| The goal of this project is to unify (some of) the tools above, adding further functionality and creating a library that can be used to prepare images before they are fed to flashrom and possibly by flashrom itself.
| |
| | |
| '''Helpful Knowledge/Skills'''
| |
| * Grasping foreign code quickly
| |
| * Previous reverse engineering experiences
| |
| | |
| '''Main Mentor'''
| |
| * [[User:Roysjosh|Joshua Roys]]
| |
| | |
| == Locking and unlocking of access protections of flash chips ==
| |
| | |
| Many chips support some kind of write protection. Currently flashrom just tries to disable it if needed to be able to write freely. [http://git.chromium.org/gitweb/?p=chromiumos/third_party/flashrom.git;a=summary Google's flashrom branch] has some further support, which was not accepted upstream. Your task would be to design and implement acceptable data structures, APIs and user interfaces to make a generic approach to lock and unlock of flash regions possible.
| |
| | |
| '''Helpful Knowledge/Skills'''
| |
| * Working with git
| |
| * Reading datasheets
| |
| | |
| '''Main Mentor'''
| |
| * [http://www.coreboot.org/User:Dhendrix David Hendricks]
| |
| | |
| == Internal programmer improvements for complex systems ==
| |
| The notion of an "internal" programmer has historically implied a single
| |
| physical device (i.e. mainboard "southbridge") which connects to an external
| |
| flash chip. Recent systems have grown significantly more complex and often involve
| |
| multiple separate microcontrollers which are accessed via the host
| |
| chipset. Examples include management controllers which are integrated in
| |
| the mainboard chipset but act independently and embedded controllers
| |
| typically found in laptop devices.
| |
| | |
| The goal of this project is to re-factor flashrom's internal programmer:
| |
| * Elegantly coordinate firmware update processes between components (i.e. setting devices in "update" mode, etc).
| |
| * Enforce policies on a potentially platform-specific basis, such as non-fatal read/write failures caused by a management controller.
| |
| * Better abstraction for host ↔ EC I/O resources.
| |
| * Board-specific handling for non-standard ECs.
| |
| | |
| You can find a lot more detailed [http://www.flashrom.org/pipermail/flashrom/2013-March/010704.html project description] in our mailing list archive.
| |
| While there exists some code and architectural ideas already, this project is rather hard and requires at least some familiarity with flashrom's code base.
| |
| | |
| '''Helpful Knowledge/Skills'''
| |
| * Knowing the flashrom code base (esp. internal programmer flow) absolutely needed
| |
| * Abstraction/refactoring of existing code and library design
| |
| | |
| '''Main Mentor'''
| |
| * [http://www.coreboot.org/User:Dhendrix David Hendricks]
| |
| | |
| == Generic flashrom infrastructure improvements ==
| |
| Below is a list of smaller projects to improve/refactor some core features of flashrom.
| |
| A number of other things of various difficulty can be done too/instead.
| |
| You should probably have some experience with the code base already to work on these effectively.
| |
| | |
| * Automatic recovery in case something goes wrong
| |
| * Partial reflashing
| |
| * Bytewise flashing (similar to the point above)
| |
| * Support for multiple read and write functions per chip
| |
| * Sanitize (SPI) probing
| |
| | |
| '''Helpful Knowledge/Skills'''
| |
| * Knowing the flashrom code base
| |
| * Abstraction/refactoring of existing code and library design
| |
| | |
| '''Main Mentor'''
| |
| * [[User:Hailfinger|Carl-Daniel Hailfinger]]
| |
| | |
| == Laptop support - Support for ECs (Embedded Controllers) ==
| |
| | |
| This one is really HARD. If you're lucky and if you have datasheets, you can add support for a single laptop in maybe 1 month. If you're unlucky, it can take the whole GSoC or more. If there is interest, we'll try to find an embedded controller which won't cause you to give up in frustration. Still, it might be beneficial if you're willing to solder (to recover from a bricked board).
| |
| | |
| '''Helpful Knowledge/Skills'''
| |
| * Previous reverse engineering experiences
| |
| * External Programmer
| |
| * Stamina/patience
| |
| | |
| '''Main Mentor'''
| |
| * [[User:Hailfinger|Carl-Daniel Hailfinger]]
| |
| | |
| == Design and implementation of a native USB flashing protocol ==
| |
| All existing free USB-based flash programmers have a very naive interface.
| |
| The SPI programmers usually act as a simple USB to SPI bridge, mostly tunneling the plain SPI traffic via a USB communications device class (CDC) aka. RS-232 tunnel.
| |
| Since USB communication has rather long round trip times this has some performance disadvantages.
| |
| It would be much more elegant to tell the programmer what to do more abstractedly instead of sending it the complete flash protocol communication contents which just needs to be forwarded to the chip.
| |
| This requires a lot of knowledge at the external programmer though because much of what flashrom does needs to be done by its firmware.
| |
| Adding an instruction set interpreted by the programmer might help to keep the complexity within sane bounds.
| |
| You can find some preliminary design ideas about such a protocol by Peter Stuge in his [http://git.stuge.se/?p=qiprog.git;a=blob;f=doc/qiprog_protocol.txt git repo].
| |
| A programmer based on some embedded platform (e.g. an ARM cortex-m board) should be built utilizing the protocol to evaluate the performance and implementation effort.
| |
| | |
| '''Helpful Knowledge/Skills'''
| |
| * USB
| |
| * The embedded platform you want to use
| |
| * Flash chip protocols (see [[Technology]])
| |
| | |
| '''Main Mentor'''
| |
| * Peter Stuge?
| |
| | |
| == Recovery of dead boards and onboard flash updates ==
| |
| * flashrom as payload
| |
| * flashrom as UEFI application
| |
| * flashrom remote flashing for coreboot panic room mode
| |
| * flashrom remote flashing with modified SerialICE
| |
| This is heavily overlapping with the [http://www.coreboot.org/Project_Ideas#coreboot_panic_room coreboot panic room] idea. Please see there for further details.
| |