Skip to content

GitLab

Switch branch/tag
  1. 17 Dec, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Use the maximum decode size infrastructure · 2a9e2455
      Carl-Daniel Hailfinger authored 
      
- Detect max FWH size for Intel
  631xESB/632xESB/3100/ICH6/ICH7/ICH8/ICH9/ICH10.
- Move IDSEL override before decode size checking for the chipsets
  listed above or flashrom will complain based on old values.
- Adjust supported flash buses for the chipsets listed above (none of
  them supports LPC or Parallel).
- Detect max parallel size for AMD/National Semiconductor CS5530.
- Adjust supported flash buses for CS5530/CS5530A.
- Set board-specific max decode size for Elitegroup K7VTA3.
- Set board-specific max decode size for Shuttle AK38N.

Corresponding to flashrom svn r806.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      2a9e2455
  3. 13 Dec, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Internal (onboard) programming was the only feature which could not be disabled · 66ef4e5f
      Carl-Daniel Hailfinger authored 
      
Make various pieces of code conditional on support for internal
programming. Code shared between PCI device programmers and onboard
programming is now conditional as well.

It is now possible to build only with dummy support:
make CONFIG_INTERNAL=no CONFIG_NIC3COM=no CONFIG_SATASII=no
CONFIG_DRKAISER=no CONFIG_SERPROG=no CONFIG_FT2232SPI=no

This allows building for a specific use case only, and it also
facilitates porting to a new architecture because it is possible to
focus on highlevel code only.

Note: Either internal or dummy programmer needs to be compiled in due to
the current behaviour of always picking a default programmer if -p is
not specified. Picking an arbitrary external programmer as default  
wouldn't make sense.

Build and runtime tested in all 1024 possible build combinations. The
only failures are by design as mentioned above.

Corresponding to flashrom svn r797.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarSean Nelson <audiohacked@gmail.com>
      66ef4e5f
  5. 09 Dec, 2009 1 commit
  7. 08 Dec, 2009 1 commit
  9. 26 Nov, 2009 1 commit
  11. 15 Nov, 2009 2 commits
  13. 31 Oct, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add infrastructure to check the maximum supported flash size of chipsets and mainboards · 115d390f
      Carl-Daniel Hailfinger authored 
      
The rationale is to warn users when they, for example, try to flash
a 512KB parallel flash chip but their chipset only supports 256KB,
or they try to flash 512KB and the chipset _does_ theoretically
support 512KB but their special board doesn't wire all address lines
and thus supports only 256 KB ROM chips at maximum.

This has cost Uwe hours of debugging on some board already, until he
figured out what was going on. We should try warn our users where
possible about this.

The chipset and the chip may have more than one bus in common (e.g.
SB600 and Pm49* can both speak LPC+FWH) and on SB600/SB7x0/SB8x0 there
are different limits for LPC and FWH. The only way to tell the user
about the exact circumstances is to spew error messages per bus.

The code will issue a warning during probe (which does fail for some
chips if the size is too big) and abort before the first real
read/write/erase action. If no action is specified, the warning is
printed anyway.
That way, a user can find out why probe might not have worked, and will
be stopped before he/she gets incorrect results.

Add a bitcount function to the infrastructure.

Corresponding to flashrom svn r755.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      115d390f
  15. 06 Oct, 2009 1 commit
  17. 05 Oct, 2009 1 commit
  19. 25 Sep, 2009 1 commit
  21. 23 Sep, 2009 1 commit
  23. 01 Sep, 2009 1 commit
  25. 21 Aug, 2009 1 commit
  27. 13 Aug, 2009 1 commit
  29. 12 Aug, 2009 1 commit
  31. 11 Aug, 2009 1 commit
  33. 10 Aug, 2009 1 commit
  35. 09 Aug, 2009 1 commit
  37. 23 Jul, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      This is a workaround for a bug in SB600 and SB700 · f8555e24
      Carl-Daniel Hailfinger authored 
      
If we only send an opcode and no additional data/address, the SPI
controller will read one byte too few from the chip. Basically, the
last byte of the chip response is discarded and will not end up in the
FIFO. It is unclear if the CS# line is set high too early as well. That
hardware bug is undocumented as of now, but I'm working with AMD to add
a detailed description of it to the errata.

Add loads of additional debugging to SB600/SB700 init.

Add explanatory comments for unintuitive code flow.

Thanks go to Uwe for testing quite a few iterations of the patch.

Kill the SB600 flash chip status register special case, which was a
somewhat misguided workaround for that hardware erratum.

Note for future added features in the SB600 SPI driver: It may be
possible to read up to 15 bytes of command response with overlapping
reads due to the ring buffer design of the FIFO if the command can be
repeated without ill effects. Same for skipping up to 7 bytes between
command and response.

Corresponding to flashrom svn r661.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      f8555e24
  39. 28 Jun, 2009 2 commits
  41. 18 Jun, 2009 1 commit
  43. 17 Jun, 2009 1 commit
  45. 16 Jun, 2009 1 commit
  47. 15 Jun, 2009 1 commit
  49. 02 Jun, 2009 1 commit
  51. 01 Jun, 2009 1 commit
  53. 31 May, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add bus type annotation to struct flashchips · 1dfe0ff1
      Carl-Daniel Hailfinger authored 
      
Right now, the annotation only differentiates between SPI and non-SPI.
Anyone who knows more about a specific flash chip should feel free to
update it.

The existing flashbus variable was abused to denote the SPI controller
type. Use an aptly named variable for that purpose.

Once this patch is merged, the chipset/programmer init functions can set
supported flash chip types and flashrom can automatically select only
matching probe/read/erase/write functions. A side benefit of that will
be the elimination of the Winbond W29EE011 vs. AMIC A49LF040A conflict.

Corresponding to flashrom svn r556.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      1dfe0ff1
  55. 26 May, 2009 1 commit
  57. 22 May, 2009 1 commit
  59. 17 May, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Use accessor functions for MMIO · 78185dcb
      Carl-Daniel Hailfinger authored 
      
Some MMIO accesses used volatile, others didn't (and risked
non-execution of side effects) and even with volatile, some accesses
looked dubious.

Since the MMIO accessor functions and the onboard flash accessor
functions are functionally identical (but have different signatures),
make the flash accessors wrappers for the MMIO accessors.

For some of the conversions, I used Coccinelle. Semantic patch follows:

@@ typedef uint8_t; expression a; volatile uint8_t *b; @@ - b[a] + *(b
+ a) @@ expression a; volatile uint8_t *b; @@ - *(b) |= (a); + *(b) =
*(b) | (a); @@ expression a; volatile uint8_t *b; @@ - *(b) = (a); +
mmio_writeb(a, b); @@ volatile uint8_t *b; @@ - *(b) + mmio_readb(b) @@
type T; T b; @@ ( mmio_readb | mmio_writeb ) (..., - (T) - (b) + b )

Corresponding to flashrom svn r524.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>

Uwe tested read, write, erase with this patch on a random board to make
sure nothing breaks.
Acked-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
      78185dcb
  61. 16 May, 2009 2 commits
  63. 15 May, 2009 1 commit
  65. 10 May, 2009 1 commit
    • Carl-Daniel Hailfinger's avatar
      Create a SB600 SPI detection heuristic · dbfa0291
      Carl-Daniel Hailfinger authored 
      
I know that the data sheets say we can't read the ROM straps, but
creative interpretation of the data sheets yielded a heuristic which
should work pretty well.

NOTE: If you test this, make sure you power down and _unplug_ the
machine for a few minutes before you boot and run flashrom with this
patch.
If the machine is not unplugged for some time, the test will yield
incorrect results.
If you run a slightly older flashrom version than svn HEAD, the test
will yield incorrect results.
If you run any flashrom version (except svn HEAD plus this patch) after
poweron, the test will yield incorrect results.

Explanation:
Older flashrom versions unconditionally write to registers which are
used for this heuristic. These registers are in the S5 power domain, so
even powering down does not clear them, you really have to unplug the
machine and remove the battery if this is a laptop.

Corresponding to flashrom svn r491.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      dbfa0291
  67. 08 May, 2009 1 commit
  69. 07 May, 2009 1 commit
  71. 06 May, 2009 2 commits

Powered by Integricloud