[flashrom] flashrom schedule 2013 (includes my GSoC proposal mostly :)

[Marc Jones]

Hi Stefan,

Thanks for putting this out there for feedback. While I understand
your perspective on concerns about the outcome, we need to have some
clear goals and expectations in order to score and rank project ideas.
As with all development, we don't always reach the destination we
expected, but we have set out with a goal and direction. I think that
the ideas you have listed are good. There are some improvements you
should make in your application.

When you fill out your application, it will help to break out the
pre-work (easy stuff) and the new code sections. The flashrom release
details are important for what you want to accomplish,  but are not
part of GSoC code development, so leave the detail out of your
application. Please help drive the release in the community
separately.

The support for multiple read and multiple write would be a great
addition to flashrom.

Can you identify how you will improve SPI probing and/or explain the
issues with the current implementations?

Please put some estimates the time you think it will take to do each
of these things.

Feel free to follow up on this thread, or just use this feedback in
your application.

Regards,
Marc


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



-- 
http://se-eng.com