<div dir="ltr">I think the stuff you laid out would be fine to list explicitly as project objectives :-) The GSoC FAQ states that continuing work on a project is fine so long as some "new" work is done as part of your participation. I think the idea was to ensure students get a chance to diversify their role in the project since some projects have a few very big parts that people focus on for several months or years. Flashrom has a lot of smaller parts and the stuff you mentioned seems diverse and new enough to satisfy the requirement IMO.<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Apr 23, 2013 at 1:48 PM, Stefan Tauner <span dir="ltr"><<a href="mailto:stefan.tauner@student.tuwien.ac.at" target="_blank">stefan.tauner@student.tuwien.ac.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If mentors agree I would rather not set all project details in stone.<br>
My previous project of unlocking the ME had a very distinct goal but<br>
the outcome was something completely different but probably more useful<br>
to the project than if I would have succeeded IMHO :) Also, progress on<br>
single points might be delayed due to missing feedback or reviewing.<br>
<br>
Main coding period is from 2013-06-17 till 2013-09-23.<br>
Until then I would like to tag another stable release (0.9.6 was<br>
released in August 2012) and merge the larger chunks of the patch pile.<br>
While this might create intermittent problems without proper review it<br>
will guarantee that there wont be too many conflicts with the code to<br>
come and it will merge stuff that should have been merged way earlier...<br>
If there will be others working on flashrom (panic room, serialice or<br>
even "native" flashrom project(s)), this is even more important.<br>
<br>
Here is the list of the most important things I want to merge shortly<br>
after tagging the next stable:<br>
<br>
mine:<br>
- Layout patches<br>
- Automatic unmapping and rounding of physmaps<br>
- Internal DMI decoder<br>
others:<br>
- any makefile-related changes and patches that are waiting on<br>
makefile changes only if possible (e.g. libusb stuff)<br>
- rayer_spi/lpt_spi (if they do not make it into the stable)<br>
<br>
Please suggest other stuff that you think is ready (I probably forgot<br>
about some)!<br>
<br>
My goals for the actual coding season are (in planned chronological<br>
order):<br>
- integrate Nico's libflashrom patches<br>
- refine and merge check_trans patch(es). They will be very<br>
useful/required for the following goals to be implemented (safely).<br>
- add support for multiple write operations<br>
* similar to erasers but maybe using distinct enter/exit function<br>
pointers<br>
- add support for multiple read operations (like writes), allowing to:<br>
- add support for 4B-addressing (needed for chips >= 16MB)<br>
I have received sample chips from Spansion and Macronix (S25FL256,<br>
S25FL512, MX25L25635), but I need to adapt my programmer to work with<br>
SOIC16 packages.<br>
- improve SPI probing. Something long overdue IMHO. There are less<br>
than a dozen ways to identify SPI flash chips. Nevertheless flashrom<br>
uses no more than 3 and even those in a rather awkward way.<br>
* Determine the best way to allow for multiple probing results/matches<br>
per chip and/or how to separate SPI probing from the rest. Possibly<br>
split struct flashchip into a generic part and a more specific<br>
Non-SPI/SPI union.<br>
* Design a method to rank the received results and match the chip-<br>
* Implement probing accordingly.<br>
* Add more/generify probing methods (EDI).<br>
* Mark chips still not distinguishable (on permissive<br>
programmers/safely) as evil twins.<br>
<br>
Somewhere inbetween I will probably have to create a unified and<br>
distinct type for on-chip addresses, and possibly address ranges too<br>
(and functions to operate on those as if they were sets (union,<br>
intersection, difference)).<br>
<br>
If there is still time I could do other infrastructure improvements like<br>
automatic recovery if something fails etc. or reduce my TODO list<br>
(which is essentially the same thing). If there is a lot more time I<br>
would work on the locking interface that and/or improvements regarding<br>
the "Internal programmer improvements for complex systems" project.<br>
<br>
If everything works out as planned I would like to release another<br>
stable (or at least release candidate) a few months after the big<br>
changes have been merged, certainly before 2014.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Kind regards/Mit freundlichen Grüßen, Stefan Tauner<br>
<br>
_______________________________________________<br>
flashrom mailing list<br>
<a href="mailto:flashrom@flashrom.org">flashrom@flashrom.org</a><br>
<a href="http://www.flashrom.org/mailman/listinfo/flashrom" target="_blank">http://www.flashrom.org/mailman/listinfo/flashrom</a></font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>David Hendricks (dhendrix)<br>
Systems Software Engineer, Google Inc.
</div></div>