Skip to content

GitLab

Switch branch/tag
  1. 15 May, 2010 1 commit
  3. 07 May, 2010 1 commit
  5. 28 Apr, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      One of the problems is that --force had multiple meanings · 27023768
      Carl-Daniel Hailfinger authored 
      
- Force chip read by faking probe success.
- Force chip access even if the chip is bigger than max decode size for
  the flash bus.
- Force erase even if erase is known bad.
- Force write even if write is known bad.
- Force writing even if cbtable tells us that this is the wrong image
  for this board.

This patch cleans up --force usage:
- Remove any suggestions to use --force for probe/read from flashrom
  output.
- Don't talk about "success" or "Found chip" if the chip is forced.
- Add a new internal programmer parameter boardmismatch=force. This
  overrides any mismatch detection from cbtable/image comparisons.
- Add a new internal programmer parameter laptop=force_I_want_a_brick.
- Adjust the documentation for --force.
- Clean up the man page a bit whereever it talks about --force or
  laptops.

Additional changes in this patch:
- Add warnings about laptops to the documentation.
- Abort if a laptop is detected. Can be overridden with the programmer
parameter mentioned above.
- Add "Portable" to the list of DMI strings indicating laptops.
- Check if a chip specified with -c is known to flashrom.
- Programmer parameter reliability and consistency fixes.
- More paranoid self-checks.
- Improve documentation.

Corresponding to flashrom svn r996.
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>
      27023768
  7. 27 Mar, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Add runtime and build environment info to the flashrom version message · 132e2ec6
      Carl-Daniel Hailfinger authored 
      
This patch uses code from Idwer Vollering and Maciej Pijanka.
I've added Makefile support and compiler version printing and
restructured the code heavily.
The code prints runtime system information and buildtime libpci
information (I couldn't find any runtime libpci version function). Due
to our ability to cross-compile flashrom, buildtime system information
from "uname -mrs" doesn't help diagnosing any problems. That's why only
libpci and gcc are buildtime info, and the rest is runtime info.

Examples:

openSUSE 10.3, i686, gcc 4.2.1, with PCI support:
flashrom v0.9.1-r971 on Linux 2.6.22.19-0.2-default (i686), built with
libpci 2.2.6, GCC 4.2.1 (SUSE Linux)

openSUSE 10.3, i686, llvm-clang-2.6.99svn97231, with PCI support:
flashrom v0.9.1-r971 on Linux 2.6.22.19-0.2-default (i686), built with
libpci 2.2.6, LLVM 1/clang 1

openSUSE 11.1, x86_64, gcc 4.3.2, with PCI support:
flashrom v0.9.1-r972 on Linux 2.6.27.29-0.1-default (x86_64), built with
libpci 3.0.1, GCC 4.3.2 [gcc-4_3-branch revision 141291]

openSUSE 10.3, i686, gcc 4.2.1, without PCI support:
flashrom v0.9.1-r971 on Linux 2.6.22.19-0.2-default (i686), built with
GCC 4.2.1 (SUSE Linux)

Windows/cygwin, i686, gcc 4.3.4, without PCI support:
flashrom v0.9.1-r973 on CYGWIN_NT-5.1 1.7.1(0.218/5/3) (i686), built
with GCC 4.3.4 20090804 (release) 1

FreeBSD 8.0, i386, gcc 4.2.1, with PCI support:
flashrom v0.9.1-r973 on FreeBSD 8.0-RELEASE-p2 (i386), built with libpci
3.1.7, GCC 4.2.1 20070719  [FreeBSD]

Corresponding to flashrom svn r987.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: default avatarIdwer Vollering <vidwer@gmail.com>
Acked-by: default avatarMaciej Pijanka <maciej.pijanka@gmail.com>
      132e2ec6
  9. 22 Mar, 2010 1 commit
  11. 13 Mar, 2010 1 commit
  13. 08 Mar, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Write granularity is chip specific · e8e369fc
      Carl-Daniel Hailfinger authored 
      
The following write granularities exist according to my datasheet
survey: - 1 bit. Each bit can be cleared individually. - 1 byte. A byte
can be written once. Further writes to an already written byte cause
the contents to be either undefined or to stay unchanged. - 128 bytes.
If less than 128 bytes are written, the rest will be erased. Each write
to a 128-byte region will trigger an automatic erase before anything is
written. Very uncommon behaviour. - 256 bytes. If less than 256 bytes
are written, the contents of the unwritten bytes are undefined.

Note that chips with default 256-byte writes, which keep the original
contents for unwritten bytes, have a granularity of 1 byte.

Handle 1-bit, 1-byte and 256-byte write granularity.

Corresponding to flashrom svn r927.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarSean Nelson <audiohacked@gmail.com>
Acked-by: default avatarDavid Hendricks <dhendrix@google.com>
      e8e369fc
  15. 21 Feb, 2010 1 commit
  17. 19 Feb, 2010 1 commit
  19. 14 Feb, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Allow the registration of functions to be called at programmer shutdown · cc389fc6
      Carl-Daniel Hailfinger authored 
      
Some programmers want to run certain functions during programmer
shutdown, but the function choice depends on the code path taken
during programmer init. Rather than rebuilding the whole init logic in
the shutdown function, it is now possible to register functions for
execution on programmer shutdown. The behaviour is similar to atexit(),
but the registered functions will be run on programmer shutdown instead
of on exit and the functions will be called with a void * argument
that is specified on registration. Registered functions must have
the prototype void function(void *); and will be executed in reverse
registration order directly before calling the programmer-specific
shutdown() function. It is recommended to have shutdown() only disable
programmer/hardware access and leave all code path sensitive shutdown to
functions registered with register_shutdown().

The most prominent use case is resetting the EC after flashing on
laptops.

Note: There are quite a few code paths in flashrom which proceed to
terminate flashrom without any programmer shutdown. Those code paths
will not get the benefit of register_shutdown() and they should be
changed wherever possible.

Corresponding to flashrom svn r904.
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>
      cc389fc6
  21. 11 Feb, 2010 1 commit
  23. 25 Jan, 2010 1 commit
  25. 19 Jan, 2010 2 commits
  27. 18 Jan, 2010 1 commit
  29. 10 Jan, 2010 1 commit
  31. 07 Jan, 2010 1 commit
  33. 24 Dec, 2009 1 commit
  35. 14 Dec, 2009 1 commit
  37. 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
  39. 25 Nov, 2009 1 commit
  41. 24 Nov, 2009 2 commits
  43. 23 Nov, 2009 1 commit
  45. 17 Nov, 2009 1 commit
  47. 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
  49. 01 Oct, 2009 2 commits
  51. 30 Sep, 2009 1 commit
    • Uwe Hermann's avatar
      Add initial support for flashing some NVIDIA graphics cards · 2bc98f6c
      Uwe Hermann authored 
      
The new option is '-p gfxnvidia', rest of the interface is as usual.

I tested a successful identify and read on a "RIVA TNT2 Model 64/Model 64 Pro"
card for now, erase and write did NOT work properly so far!

Please do not attempt to write/erase cards yet, unless you can recover!

In addition to the NVIDIA handling code it was required to call
programmer_shutdown() in a lot more places, otherwise the graphics card
will be disabled in the init function, but never enabled again as the
shutdown function is not called.
The shutdown handling may be changed to use atexit() later.

Corresponding to flashrom svn r737.
Signed-off-by: default avatarUwe Hermann <uwe@hermann-uwe.de>
Acked-by: default avatarLuc Verhaegen <libv@skynet.be>
      2bc98f6c
  53. 28 Sep, 2009 1 commit
  55. 18 Sep, 2009 1 commit
  57. 16 Sep, 2009 2 commits
  59. 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
  61. 02 Sep, 2009 1 commit
  63. 19 Aug, 2009 4 commits
  65. 13 Aug, 2009 1 commit

Powered by Integricloud