Skip to content

GitLab

Switch branch/tag
  1. 15 Jun, 2012 1 commit
  3. 06 May, 2012 1 commit
  5. 01 Mar, 2012 1 commit
  7. 18 Dec, 2011 1 commit
  9. 14 Dec, 2011 1 commit
    • Carl-Daniel Hailfinger's avatar
      Use struct flashctx instead of struct flashchip for flash chip access · 63fd9026
      Carl-Daniel Hailfinger authored 
      
Struct flashchip is used only for the flashchips array and for
operations which do not access hardware, e.g. printing a list of
supported flash chips.

struct flashctx (flash context) contains all data available in
struct flashchip, but it also contains runtime information like
mapping addresses. struct flashctx is expected to grow additional
members over time, a prime candidate being programmer info.
struct flashctx contains all of struct flashchip with identical
member layout, but struct flashctx has additional members at the end.

The separation between struct flashchip/flashctx shrinks the memory
requirement of the big flashchips array and allows future extension
of flashctx without having to worry about bloat.

Corresponding to flashrom svn r1473.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
      63fd9026
  11. 23 Nov, 2011 1 commit
  13. 09 Nov, 2011 1 commit
  15. 18 Sep, 2011 2 commits
  17. 08 Sep, 2011 1 commit
  19. 15 Aug, 2011 1 commit
  21. 28 Jul, 2011 1 commit
  23. 27 Jul, 2011 1 commit
  25. 11 May, 2011 1 commit
    • Michael Karcher's avatar
      Kill central list of SPI programmers · b9dbe48b
      Michael Karcher authored 
      
Remove the array spi_programmer, replace it by dynamic registration
instead. Also initially start with no busses supported, and switch to
the default non-SPI only for the internal programmer.

Also this patch changes the initialization for the buses_supported variable
from "everything-except-SPI" to "nothing". All programmers have to set the
bus type on their own, and this enables register_spi_programmer to just add
the SPI both for on-board SPI interfaces (where the internal programmer
already detected the other bus types), as well as for external programmers
(where we have the default "none").

Corresponding to flashrom svn r1299.
Signed-off-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      b9dbe48b
  27. 27 Apr, 2011 1 commit
  29. 27 Oct, 2010 1 commit
  31. 13 Oct, 2010 1 commit
  33. 05 Sep, 2010 1 commit
  35. 27 Jul, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Split off programmer.h from flash.h · 5b997c3e
      Carl-Daniel Hailfinger authored 
      
Programmer specific functions are of absolutely no interest to any file
except those dealing with programmer specific actions (special SPI
commands and the generic core).

The new header structure is as follows (and yes, improvements are
possible):
flashchips.h  flash chip IDs
chipdrivers.h  chip-specific read/write/... functions
flash.h  common header for all stuff that doesn't fit elsewhere
hwaccess.h hardware access functions
programmer.h  programmer specific functions
coreboot_tables.h  header from coreboot, internal programmer only
spi.h SPI command definitions

Corresponding to flashrom svn r1112.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      5b997c3e
  37. 14 Jul, 2010 2 commits
  39. 10 Jul, 2010 1 commit
  41. 08 Jul, 2010 1 commit
  43. 06 Jul, 2010 1 commit
  45. 03 Jul, 2010 1 commit
  47. 26 May, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Handle the following architectures in generic flashrom code · cceafa2a
      Carl-Daniel Hailfinger authored 
      
- x86/x86_64 (little endian)
- PowerPC (big endian)
- MIPS (big+little endian)

No changes to programmer specific code. This means any drivers with MMIO
access will _not_ suddenly start working on big endian systems, but with
this patch everything is in place to fix them.

Compilation should work on all architectures listed above for all
drivers except nic3com and nicrealtek which require PCI Port IO which is
x86-only for now.

To compile without nic3com and nicrealtek, run
make distclean
make CONFIG_NIC3COM=no CONFIG_NICREALTEK=no

Thanks to Misha Manulis for testing early versions of this patch on
PowerPC (big endian) with the satasii programmer.
Thanks to Segher Boessenkool for design review and for helping out with
compiler tricks and pointing out that we need eieio on PowerPC.
Thanks to Vladimir Serbinenko for compile testing on MIPS (little
endian) and PowerPC (big endian) and for runtime testing on MIPS (little
endian).
Thanks to David Daney for compile testing on MIPS (big endian).
Thanks to Uwe Hermann for compile and runtime testing on x86_64.

DO NOT RUN flashrom ON NON-X86 AFTER APPLYING THIS PATCH!
This patch only provides the infrastructure, but does not convert any
drivers, so flashrom will compile, but it won't do the right thing on
non-x86 platforms.

Corresponding to flashrom svn r1013.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarMisha Manulis <misha@manulis.com>
Acked-by: default avatarVladimir 'phcoder/φ-coder' Serbinenko <phcoder@gmail.com>
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
Acked-by: default avatarSegher Boessenkool <segher@kernel.crashing.org>
      cceafa2a
  49. 30 Mar, 2010 1 commit
  51. 25 Mar, 2010 1 commit
  53. 13 Mar, 2010 1 commit
  55. 26 Feb, 2010 1 commit
  57. 10 Jan, 2010 1 commit
  59. 22 Dec, 2009 1 commit
  61. 05 Sep, 2009 1 commit
    • 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
  63. 02 Sep, 2009 1 commit
  65. 12 Aug, 2009 1 commit
  67. 10 Aug, 2009 1 commit
  69. 14 Jul, 2009 1 commit
  71. 12 Jul, 2009 1 commit
  73. 11 Jul, 2009 1 commit
  75. 10 Jul, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add SPI multicommand infrastructure · d0478299
      Carl-Daniel Hailfinger authored 
      
Some SPI opcodes need to be sent in direct succession after each other
without any chip deselect happening in between. A prominent example is
WREN (Write Enable) directly before PP (Page Program). Intel calls the
first opcode in such a row "preopcode".

Right now, we ignore the direct succession requirement completely and it
works pretty well because most onboard SPI masters have a timing or
heuristics which make the problem disappear.
The FT2232 SPI flasher is different. Since it is an external flasher,
timing is very different to what we can expect from onboard flashers and
this leads to failure at slow speeds.

This patch allows any function to submit multiple SPI commands in a
stream to any flasher. Support in the individual flashers isn't
implemented yet, so there is one generic function which passes the each
command in the stream one-by-one to the command functions of the
selected SPI flash driver.
Tested-by: default avatarJakob Bornecrantz <wallbraker@gmail.com>

Corresponding to flashrom svn r645.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarJakob Bornecrantz <wallbraker@gmail.com>
      d0478299

Powered by Integricloud