Hi, Today I had my first meet with my mentors Thomas and Simon, and we discussed a few things involving the timeline and initial tasks for the project. There are mainly two parts to the project : 1. Developing a strategy to optimize the selection of the erase function to reduce the overall time required to do the operation 2. Filtering out the erase functions that the programmer does not support For now, I'm working on the first one. Also, I will be writing a test case to check whether the erase functions in the flashchips struct are sorted according to the block size.
Aarya
Hi, Over the last few weeks, my mentors and I worked on the algorithm to be implemented for erase function selection, and it's finally complete. Please look at this https://drive.google.com/file/d/1z6a3i7yW4NQhz67ImTFDg7zTrDzX_K9W/view?usp=sharing document containing the details and a flowchart of the decided algorithm. Feel free to ask anything that is unclear. Any suggestions are welcome too. I have also written a test case to ensure that all the erase functions in the flashchips struct are in increasing order of their erase block size. https://review.coreboot.org/c/flashrom/+/64961 Next, we'll start to implement the above algorithm.
Aarya.
On Wed, May 25, 2022 at 1:14 AM Aarya Chaumal aarya.chaumal@gmail.com wrote:
Hi, Today I had my first meet with my mentors Thomas and Simon, and we discussed a few things involving the timeline and initial tasks for the project. There are mainly two parts to the project :
- Developing a strategy to optimize the selection of the erase function
to reduce the overall time required to do the operation 2. Filtering out the erase functions that the programmer does not support For now, I'm working on the first one. Also, I will be writing a test case to check whether the erase functions in the flashchips struct are sorted according to the block size.
Aarya
Hi Aarya,
On 10.06.22 15:59, Aarya Chaumal wrote:
Over the last few weeks, my mentors and I worked on the algorithm to be implemented for erase function selection, and it's finally complete. Please look at this
the depicted strategy looks quite good, IMO :) I originally thought we could solve the problem without a global view (building the list of everything that needs to be erased). But having read your flow chart, I believe it's a very good solution.
I have two remarks on the selection of later erase functions, i.e. the step
Are more than half the subsectors within the current sector also marked
You already mentioned at the beginning that we might have a problem if the region is not erase-block aligned. If this is the case, we should choose the smallest erase block to minimize the risk to hit any read/ write protection, e.g. check
region start <= current sector start && current sector end <= region end
If not, skip the sector for the current erase function.
And because we have to deal with a non-homogeneous sector selection (marked subsectors of different sizes) eventually, we shouldn't count "subsectors" but bytes, I guess.
And many thanks for drawing the picture! its quite helpful. We should definitely keep a final version in the documentation.
Nico
Hi Nico, Thanks for your suggestions. Please look at the modified diagram. https://drive.google.com/file/d/1jmUIewkIHdsBq3fQ9MVyAzCu7ySjoMqG/view?usp=sharing
On Tue, Jun 14, 2022 at 3:45 AM Nico Huber nico.h@gmx.de wrote:
Hi Aarya,
On 10.06.22 15:59, Aarya Chaumal wrote:
Over the last few weeks, my mentors and I worked on the algorithm to be implemented for erase function selection, and it's finally complete.
Please
look at this
the depicted strategy looks quite good, IMO :) I originally thought we could solve the problem without a global view (building the list of everything that needs to be erased). But having read your flow chart, I believe it's a very good solution.
I have two remarks on the selection of later erase functions, i.e. the step
Are more than half the subsectors within the current sector also marked
You already mentioned at the beginning that we might have a problem if the region is not erase-block aligned. If this is the case, we should choose the smallest erase block to minimize the risk to hit any read/ write protection, e.g. check
region start <= current sector start && current sector end <= region end
If not, skip the sector for the current erase function.
I have added this condition to the new flowchart.
And because we have to deal with a non-homogeneous sector selection (marked subsectors of different sizes) eventually, we shouldn't count "subsectors" but bytes, I guess.
Thanks for pointing this out. We shall use addresses (start and end address of a sector) to mark/recognize the sectors.
Aarya.
And many thanks for drawing the picture! its quite helpful. We should definitely keep a final version in the documentation.
Nico
-
Aarya Chaumal -
Nico Huber