On 2011-04-10 21:33, Jordan Justen wrote: > On Sun, Apr 10, 2011 at 03:53, Jan Kiszka <jan.kis...@web.de> wrote: >> Commit 5145b3d1cc revealed a bug in the lazy ROMD switch-back logic, but >> resolved it by breaking that feature. This approach addresses the issue >> by switching back to ROMD after a certain amount of read accesses >> without further unlock sequences. > > Without this change, the code will stay in flash mode until a single > read occurs. The code sequence you are wanting to support using will > issue a read before trying to unlock again? > > Actually, I suppose it will want to verify the written data before > moving on, so this does make sense.
Precisely. The drivers (e.g. Linux) compare two successive reads for bit flips. In their absence, the result was written. The guest I'm optimizing for does 5 reads per write. > > Is the overhead of switching the modes significant enough to justify > the lazy switch-back? (If so, maybe I'll look at this for cfi01 too.) As we call into cpu_register_physical_memory, the overhead is tremendous, an order of magnitude IIRC, which will sum up to huge delays when reflashing a complete multi-MB firmware image e.g. Jan
signature.asc
Description: OpenPGP digital signature
