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.
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.
On Tue, Apr 23, 2013 at 1:48 PM, Stefan Tauner < stefan.tauner@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@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
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@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@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom
-
David Hendricks -
Marc Jones -
Stefan Tauner