[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