Hi Nico:
El 22/04/16 a las 08:35, Nico Huber escribió:
Hi All,
I'm interested too in this feature. My use case is internal flashing on modern Intel systems where parts of the flashchip are read protected. This is a priority for me during the next week, but I believe my time is better spent reviewing someone else' patch than reinventing my own.
There are also other patches floating around that look like tackling the same problem. I'll look at these today:
https://www.flashrom.org/pipermail/flashrom/2013-September/011599.html along with a branch on github: https://github.com/stefanct/flashrom/tree/layout
https://www.flashrom.org/pipermail/flashrom/2014-October/012967.html
On 21.04.2016 22:36, Salvador Eduardo Tropea wrote:
What about reading the whole erase regions affected by each interval? (like David points out)
Another option to enforce the whole erase region is read, is to simply constrain the used block erasers to those that match the layout. This would simplify things a lot. And, IMO, you can have a layout with erase block aligned regions in most use cases.
You are right, forcing the sections to be aligned makes a lot of sense and simplifies things a lot. But this is an important restriction, and I think that some people will need to define unaligned regions. So I think the software must support unaligned regions, even when the user should try to always align them. In my case I have a 4 MiB flash with 4 kiB pages. The FPGA only needs 32300 bytes for configuration. The rest could be used to store data. One really good use could be that a softcore (a CPU implemented in the FPGA) uses it as ROM for code execution. In this case reserving a group of pages makes much more sense than just starting at arbitrary addresses. But again: this is the most common use, but I think flashrom should be able to handle cases where the regions aren't aligned. I didn't post my whole patch because I want to refine it, in fact this discussion already introduced a very important change ;-) Additionally, I have to separate 3 different features that I'm introducing ;-) I'm attaching the output of "svn -diff", just in case you want to take a look at it. Is not intended to be merged because, as I said, it contains 3 different features.
Regards, SET