1. 14 May, 2009 4 commits
  2. 13 May, 2009 2 commits
    • Carl-Daniel Hailfinger's avatar
      There are various reasons why a SPI command can fail · 3e9dbea1
      Carl-Daniel Hailfinger authored
      
      Among others, I have seen the following problems: - The SPI opcode is
      not supported by the controller. ICH-style controllers exhibit this if
      SPI config is locked down. - The address in in a prohibited area. This
      can happen on ICH for any access (BBAR) and for writes in chipset write
      protected areas. - There is no SPI controller.
      
      Introduce separate error codes for unsupported opcode and prohibited
      address.
      
      Add the ability to adjust REMS and RES addresses to the minium supported
      read address with the help of spi_get_valid_read_addr(). That function
      needs to call SPI controller specific functions like reading BBAR on
      ICH.
      
      Corresponding to flashrom svn r500.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      3e9dbea1
    • Uwe Hermann's avatar
      Add support for 3COM NICs as "external programmer" and Atmel AT49BV512 · b4dcb718
      Uwe Hermann authored
      
      This allows flashrom to identify, read, write, erase and verify flash chips
      on (some) 3COM network cards. The patch uses the external programmer
      infrastructure, the network card is basically treated as an external
      flash programmer.
      
      Usage:
      
      $ ./flashrom -p nic3com
      flashrom v0.9.0-r498
      Found NIC "3COM 3C905C: EtherLink 10/100 PCI (TX)" (10b7:9200), addr = 0xa400
      Calibrating delay loop... OK.
      Found chip "Atmel AT49BV512" (64 KB) at physical address 0xffff0000.
      No operations were specified.
      
      $ ./flashrom -p nic3com -E
      flashrom v0.9.0-r498
      Found NIC "3COM 3C905C: EtherLink 10/100 PCI (TX)" (10b7:9200), addr = 0xa400
      Calibrating delay loop... OK.
      Found chip "Atmel AT49BV512" (64 KB) at physical address 0xffff0000.
      Erasing flash chip... SUCCESS.
      
      $ ./flashrom -p nic3com -wv backup.bin
      flashrom v0.9.0-r498
      Found NIC "3COM 3C905C: EtherLink 10/100 PCI (TX)" (10b7:9200), addr = 0xa400
      Calibrating delay loop... OK.
      Found chip "Atmel AT49BV512" (64 KB) at physical address 0xffff0000.
      Flash image seems to be a legacy BIOS. Disabling checks.
      Programming page: 1023 at address: 0x0000ffc0
      Verifying flash... VERIFIED.
      
      $ ./flashrom -p nic3com -r backup.bin
      flashrom v0.9.0-r498
      Found NIC "3COM 3C905C: EtherLink 10/100 PCI (TX)" (10b7:9200), addr = 0xa400
      Calibrating delay loop... OK.
      Found chip "Atmel AT49BV512" (64 KB) at physical address 0xffff0000.
      Reading flash... done.
      
      I have tested this on actual hardware (see PCI IDs above) and all
      operations worked fine.
      
      Support for other 3COM cards will follow (I added some more which should
      be supportable by this code, but they're untested so far), as well as
      support for NICs from other vendors.
      
      The patch also adds support for the Atmel AT49BV512 which is soldered
      onto the 3COM NIC I used for testing.
      
      Corresponding to flashrom svn r499.
      Signed-off-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      Acked-by: default avatarMateusz Murawski <matowy@tlen.pl>
      Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      b4dcb718
  3. 11 May, 2009 1 commit
  4. 09 May, 2009 3 commits
  5. 08 May, 2009 2 commits
  6. 06 May, 2009 1 commit
  7. 01 May, 2009 2 commits
  8. 28 Apr, 2009 1 commit
  9. 24 Apr, 2009 1 commit
  10. 23 Apr, 2009 1 commit
  11. 21 Apr, 2009 1 commit
  12. 06 Mar, 2009 1 commit
  13. 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
  14. 26 Jan, 2009 8 commits
  15. 23 Jan, 2009 1 commit
  16. 07 Jan, 2009 1 commit
  17. 15 Dec, 2008 1 commit
    • FENG yu ning's avatar
      Various ichspi.c refinements · f041e9b5
      FENG yu ning authored
      
      * add a generic preop-opcode-pair table.
      
      * rename ich_check_opcodes to ich_init_opcodes.
      
      * let ich_init_opcodes do not need to access flashchip structure:
        . move the definition of struct preop_opcode_pair to a better place
        . remove preop_opcode_pairs from 'struct flashchip'
        . modify ich_init_opcodes and generate_opcodes so that they do not access the flashchip structure
      
      * call ich_init_opcodes during chipset enable. Now OPCODES generation mechanism works.
      
      * fix a coding style mistake.
      
      Corresponding to flashrom svn r367 and coreboot v2 svn r3814.
      Signed-off-by: default avatarFENG yu ning <fengyuning1984@gmail.com>
      Acked-by: default avatarPeter Stuge <peter@stuge.se>
      f041e9b5
  18. 10 Dec, 2008 1 commit
  19. 08 Dec, 2008 1 commit
  20. 04 Dec, 2008 1 commit
  21. 03 Dec, 2008 1 commit
  22. 28 Nov, 2008 3 commits
  23. 18 Nov, 2008 1 commit
    • Carl-Daniel Hailfinger's avatar
      Check for failed SPI command execution · 598ec58e
      Carl-Daniel Hailfinger authored
      
      Although SPI itself does not have a mechanism to signal command failure,
      the SPI host may be unable to send a given command over the wire due
      to security or hardware limitations. The current code ignores these
      mechanisms completely and simply assumes almost every command succeeds.
      Complain if SPI command execution fails.
      
      Since locked down Intel chipsets (like the one we had problems with
      earlier) only allow a small subset of commands, find the common subset
      of commands between the chipset and the ROM in the chip erase case. That
      is accomplished by the new spi_chip_erase_60_c7() which can be used for
      chips supporting both 0x60 and 0xc7 chip erase commands.
      
      Both parts of the patch address problems seen in the real world. The
      increased verbosity for the error case will help us diagnose and address
      problems better.
      
      Corresponding to flashrom svn r345 and coreboot v2 svn r3757.
      Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      Otherwise: Acked-by: Stefan Reinauer <stepan@coresystems.de>
      598ec58e