[flashrom] [RFC] JEDEC refactor w/ conversion notes and file eliminations
Sean Nelson
audiohacked at gmail.com
Fri Dec 25 07:03:53 CET 2009
This patch demonstrates how we could refactor the jedec code. After the
refactor
we can delete these:
* am29f040b
* en29f002a -> file_not_used
* m29f002
* mx29f002
* pm29f002
* sst49lf040
* w49f002u
These files can be deleted if we *could* find a way to integrate the
problems
into jedec.c:
* w29ee011 -> checks specifically for w29ee011
* w39v040c -> checks for lock in probe: address 0xfff2
* pm49fl00x -> uses chip protect code
* m29f002 -> block based writing
* m29f400bt -> block based writing
I was looking through these two files and saw that they used variable block
sizes for writing sectors, maybe we can do something simpler to
block_erasers:
* m29f002
* m29f400bt
There are a few files that performs another map_flash_registers() after
successful probe, I was wondering if we could add the re-mapping to
probe_jedec_common or if its safe to omit the function call:
* pm49fl00x
* stm50flw0x0x
* w39v080fa
List of chips that use a specific addressing for command codes:
0x2AA based chips:
* am29f040b
* mx29f002
* pm29f002
0xAAA based chips:
* m29f002
* m29f400bt
0x2AAA based chips:
* pm49fl00x
* sst49lf040
* stm50flw0x0x
* w29ee011
* w39v040c
* w39v080fa
* w49f002u
If you want I can send my full notes so you can see what each file's
functions
can be converted to, on request. I don't know if my methods for the
address mask
is proper. If you can think of a better way, I'm all ears. Yes, I did
work on
this all Christmas Eve.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jedec_w_notes.diff
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20091224/d0d7bcc5/attachment.ksh>
More information about the flashrom
mailing list