Hi, Just wanted to know how things are going with the GSOC selection process. Sorry if I'm being too eager :) Aarya.
On Sun, Apr 17, 2022 at 2:47 PM Anastasia Klimchuk <[email protected]> wrote: > Aarya, > > This is amazing news, I am super happy to get your project proposal! > It is nice to have you with us :) > > We have long public holidays here (in AU), but I had a quick look and > the proposal looks fine. > > Once the holidays are over, we, together with mentor(s), will go > through the proposal carefully, define next steps, and of course will > inform you on how things are going. For now, you did everything right, > and submitted the project proposal at the right time. Thanks! :) > > On Sat, Apr 16, 2022 at 5:22 AM Aarya Chaumal <[email protected]> > wrote: > > > > Anastasia and Felix, > > > > I submitted my proposal for "optimize erase function selection" > yesterday after which I received an acknowledgment mail saying "Your > project proposal for GSoC 2022 to Flashrom has been submitted. Mentors will > review your proposal and possibly contact you with questions." Just wanted > to ask if you have any questions or suggestions regarding it. > > Also, I have decided not to write a proposal for the other project I was > interested in i.e. "Fix endianness issues" as writing a proposal already > takes a lot of time and effort that I can't give more due to my college > exams. Although, I would love to do it after GSOC if the project remains > available then. > > > > Aarya. > > > > > > On Mon, Apr 11, 2022 at 5:45 PM Nico Huber <[email protected]> wrote: > >> > >> Hi Aarya, > >> > >> On 11.04.22 13:46, Aarya Chaumal wrote: > >> > In the "Optimizing Erase Function Selection" project what is > considered a > >> > minimum level of success. I think it should be that the resulting > average > >> > erase time should be similar to the theoretical value based on the > >> > implemented algorithm and less than the current erase time. > >> > >> theoretical values are hard to get right. Beside the documented > >> delays of a flash chip, we have delays in the programmer and in > >> case of external programmers round-trip delays on the bus where > >> they are attached (e.g. USB, UART). > >> > >> As the current code is implicitly optimized for smaller changes, > >> I would define basic success as reducing the programming time > >> for a full flash-chip write (could be tested by writing random > >> data) without increasing the time for a small change (e.g. > >> write random data with a layout region of 4KiB). > >> > >> > Are there any > >> > other objectives that need to be achieved for the project? > >> > >> IIRC, the description mentioned a prerequisite: We need to know > >> in advance if the programmer will be able to execute a specific > >> erase command. This is very important so we can get rid of the > >> current fallback strategy that simply tries the next command > >> if one fails. > >> > >> The fallback strategy is somewhat controversial anyway: If the > >> programmer rejects a command, it's reasonable to try another. > >> However if an erase fails due to hardware trouble (transfer > >> failure or even the flash chip failing), trying again with a > >> bigger erase block size can make things worse. > >> > >> > > >> > Also what stretch objectives could be there for the project? > >> > >> Maybe optimization for more write patterns (re-writing a full > >> flash doesn't happen very often). However, we'll have to see > >> if that is possible/necessary. Maybe one could take the indi- > >> vidual erase times of a flash chip into account. For instance > >> if a 4KiB erase takes x ms and a 64KiB erase takes 10*x, then > >> it might speed things up to use the bigger erase block even if > >> it wouldn't have to be fully erased. > >> > >> Nico > > > > -- > Anastasia. >
_______________________________________________ flashrom mailing list -- [email protected] To unsubscribe send an email to [email protected]
