Skip to content

GitLab

Switch branch/tag
  1. 04 Jan, 2010 1 commit
  3. 05 Sep, 2009 2 commits
    • Carl-Daniel Hailfinger's avatar
      Store block sizes and corresponding erase functions in struct flashchip · f38431a5
      Carl-Daniel Hailfinger authored 
      
I decided to fill in the info for a
few chips to illustrate how this works both for uniform and non-uniform
sector sizes.

struct eraseblock{
int size; /* Eraseblock size */
int count; /* Number of contiguous blocks with that size */
};

struct eraseblock doesn't correspond with a single erase block, but with
a group of contiguous erase blocks having the same size.
Given a (top boot block) flash chip with the following weird, but
real-life structure:

top
16384
8192
8192
32768
65536
65536
65536
65536
65536
65536
65536
bottom

we get the following encoding:
{65536,7},{32768,1},{8192,2},{16384,1}

Although the number of blocks is bigger than 4, the number of block
groups is only 4. If you ever add some flash chips with more than 4
contiguous block groups, the definition will not fit into the 4-member
array anymore and gcc will recognize that and error out. No undetected
overflow possible. In that case, you simply increase array size a bit.
For modern flash chips with uniform erase block size, you only need one
array member anyway.

Of course data types will need to be changed if you ever get flash chips
with more than 2^30 erase blocks, but even with the lowest known erase
granularity of 256 bytes, these flash chips will have to have a size of
a quarter Terabyte. I'm pretty confident we won't see such big EEPROMs
in the near future (or at least not attached in a way that makes
flashrom usable). For SPI chips, we even have a guaranteed safety factor
of 4096 over the maximum SPI chip size (which is 2^24). And if such a
big flash chip has uniform erase block size, you could even split it
among the 4 array members. If you change int count to unsigned int
count, the storable size doubles. So with a split and a slight change of
data type, the maximum ROM chip size is 2 Terabytes.

Since many chips have multiple block erase functions where the
eraseblock layout depends on the block erase function, this patch
couples the block erase functions with their eraseblock layouts.
struct block_eraser {
  struct eraseblock{
    unsigned int size; /* Eraseblock size */
    unsigned int count; /* Number of contiguous blocks with that size */
  } eraseblocks[NUM_ERASEREGIONS];
  int (*block_erase) (struct flashchip *flash, unsigned int blockaddr, unsigned int blocklen);
} block_erasers[NUM_ERASEFUNCTIONS];

Corresponding to flashrom svn r719.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      f38431a5
    • Carl-Daniel Hailfinger's avatar
      Unify some probe functions that basically correspond to probe_jedec() · 4e9cebb2
      Carl-Daniel Hailfinger authored 
      
Use the correct reset sequence for 82802AB. Detailed explanation:
The reset sequence before ID reading was correct, so ID always
worked. But the reset sequence after ID reading was a copy-paste
leftover from probe_jedec and didn't have any effect. I dug up
flash_and_burn from the freebios-v1 tree and found out that 82802ab.c
was indeed a copy of jedec.c with lots of experimental unannotated #if 0
and #if 1.
About the wait_82802ab change:
Before the patch, wait_82802ab entered read status mode, switched to ID
mode, then tried an incorrect and unsupported JEDEC command to exit ID
mode. Nobody ever saw that this failed because all subsequent function
calls had the correct reset sequence at the beginning.
With the patch, wait_82802ab enters read status mode, then switches back
to read mode with the official reset command.

Corresponding to flashrom svn r717.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      4e9cebb2
  5. 15 Jun, 2009 1 commit
  7. 05 Jun, 2009 1 commit
  9. 16 May, 2009 2 commits
  11. 12 May, 2009 1 commit
  13. 06 Mar, 2009 1 commit
  15. 05 Mar, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Use helper functions to access flash chips · 61a8bd27
      Carl-Daniel Hailfinger authored 
      
Right now we perform direct pointer manipulation without any abstraction
to read from and write to memory mapped flash chips. That makes it
impossible to drive any flasher which does not mmap the whole chip.

Using helper functions readb() and writeb() allows a driver for external
flash programmers like Paraflasher to replace readb and writeb with
calls to its own chip access routines.

This patch has the additional advantage of removing lots of unnecessary
casts to volatile uint8_t * and now-superfluous parentheses which caused
poor readability.

I used the semantic patcher Coccinelle to create this patch. The
semantic patch follows:
@@
expression a;
typedef uint8_t;
volatile uint8_t *b;
@@
- *(b) = (a);
+ writeb(a, b);
@@
volatile uint8_t *b;
@@
- *(b)
+ readb(b)
@@
type T;
T b;
@@
(
 readb
|
 writeb
)
 (...,
- (T)
- (b)
+ b
 )

In contrast to a sed script, the semantic patch performs type checking
before converting anything.

Tested-by: Joe Julian

Corresponding to flashrom svn r418 and coreboot v2 svn r3971.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarFENG Yu Ning <fengyuning1984@gmail.com>
      61a8bd27
  17. 25 Jan, 2009 1 commit
  19. 21 Jul, 2008 1 commit
    • Peter Stuge's avatar
      Winbond W39V040C and MSI K8T Neo2-F · cce2682d
      Peter Stuge authored 
      
W39V040C does standard JEDEC commands except chip erase so add a small driver.
probe_w39v040c() prints the block lock pin status when a chip is found.

The Neo2 board enable matches on 8237-internal IDE and onboard NIC PCI IDs.

Many thanks to Daniel McLellan for testing all of this on hardware!
Build tested by Uwe.

Corresponding to flashrom svn r304 and coreboot v2 svn r3431.
Signed-off-by: default avatarPeter Stuge <peter@stuge.se>
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      cce2682d
  21. 16 Mar, 2008 1 commit
  23. 17 Oct, 2007 1 commit
  25. 09 Sep, 2007 1 commit
  27. 29 Aug, 2007 1 commit
  29. 23 Aug, 2007 2 commits
  31. 24 May, 2007 2 commits
  33. 23 May, 2007 2 commits
  35. 06 Apr, 2007 1 commit
  37. 01 Apr, 2007 1 commit
  39. 06 Feb, 2007 1 commit
  41. 07 Nov, 2006 1 commit
  43. 26 Nov, 2005 1 commit
  45. 08 Dec, 2004 2 commits
  47. 07 Dec, 2004 2 commits
  49. 30 Sep, 2004 1 commit
  51. 20 Mar, 2004 1 commit
  53. 12 Sep, 2003 1 commit
  55. 28 Feb, 2003 1 commit
  57. 06 Sep, 2002 1 commit

Powered by Integricloud