Skip to content

GitLab

Switch branch/tag
  1. 20 Jan, 2010 1 commit
    • Michael Karcher's avatar
      Matching board via DMI · 6701ee83
      Michael Karcher authored 
      
If a board is not uniquely identifiable by PCI device/subsystem IDs, a
string can be specified to be looked for (case-sensitive, substring or
anchored) for now in one of the following DMI items in addition to matching
the PCI IDs:
 - System Manufacturer
 - System Product Name
 - System Version
 - Baseboard Manufacturer
 - Baseboard Product Name
 - Baseboard Version

Strings are anchored re-like (^ at the beginning, $ at the end), but
there are no plans to support full regular expressions and matched to any
of the mentioned fields.

The match is only made if DMI info is available and the string matches.
If no DMI info is available and the PCI IDs match, a warning is printed
as the board can not be autodetected.

It's still open to discussion whether we add an DMI override switch to
specify a string that will definitely match, and whether this switch is
only used if no DMI is available or whether it overrides or augments DMI
data.

DMI data is currently read using dmidecode. This tool is available for
all major platforms except MacOS X. I heard that there also is a MacOS X
version of dmidecode, but didn't investigate that.

Corresponding to flashrom svn r874.
Signed-off-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: default avatarLuc Verhaegen <libv@skynet.be>
Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      6701ee83
  3. 19 Jan, 2010 1 commit
    • Carl-Daniel Hailfinger's avatar
      Dediprog SF100 support · d38fac8c
      Carl-Daniel Hailfinger authored 
      
Reverse engineered from USB logs. I never touched that programmer nor
did I ever see the associated software.
Disabled by default until it is complete. The driver needs to be hooked
up to the SPI core before it will do anything besides init and
diagnostics.

I successfully reverse engineered all commands, but some are still
somewhat magic.
Logs from "flashrom -p dediprog -V" are appreciated.

Probe and read should work, erase/write is expected to explode.
The programmer will set voltage to 0 on exit.

Thanks a lot to Stefan Reinauer and Patrick Georgi for providing USB
logs and for testing the result.

Corresponding to flashrom svn r870.
Signed-off-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: default avatarStefan Reinauer <stepan@coresystems.de>
      d38fac8c
  5. 12 Jan, 2010 1 commit
  7. 09 Jan, 2010 2 commits
  9. 07 Jan, 2010 2 commits
  11. 06 Jan, 2010 4 commits
  13. 04 Jan, 2010 1 commit
  15. 24 Dec, 2009 2 commits
  17. 22 Dec, 2009 2 commits
  19. 14 Dec, 2009 1 commit
  21. 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
  23. 27 Nov, 2009 1 commit
    • Michael Karcher's avatar
      Use common jedec functionality where appropriate · 1c296ca8
      Michael Karcher authored 
      
The deleted function in en29f002a.c is reintroduced as
write_by_byte_jedec in jedec.c as it contains no chip-specific
instructions. It is not yet used in other chip drivers, as key addresses
(0x2AAA/0x5555) are often specified with less bits. After crosschecking
datasheets, most of the fixmes can probably be resolved as indicated in
them, causing significant code reduction.

The common JEDEC code for bytewise programming does not program 0xFF
at all. The chips that had a dedicated bytewise flash function which
has been changed to write_jedec_1 thus changed flashing behaviour
and the "write" test flag has been removed. This applies to: AMD
Am29F002BB/Am29F002NBB AMD Am29F002BT/Am29F002NBT (TEST_OK_PREW before)
AMIC A29002B AMIC A29002T (TEST_OK_PREW before) EON EN29F002(A)(N)B EON
EN29F002(A)(N)T (TEST_OK_PREW before) Macronix MX29F001B (TEST_OK_PREW
before) Macronix MX29F001T (TEST_OK_PREW before) Macronix MX29F002B
Macronix MX29F002T (TEST_OK_PREW before) Macronix MX29LV040

Similar analysis should be performed for the read id stuff.

Corresponding to flashrom svn r785.
Signed-off-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: default avatarSean Nelson <audiohacked@gmail.com>
Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      1c296ca8
  25. 26 Nov, 2009 1 commit
    • Michael Karcher's avatar
      Refine support for the JEDEC Software Data Protection · 972cec28
      Michael Karcher authored 
      
This patch removes the extremely dangerous unprotect_jedec function
which is not used at all within flashrom code, and renames the
misleadingly named protect_jedec function to start_program_jedec.

Calls to protect_jedec after flashing are removed, because a) on LPC
chips, the command sent by protoct_jedec is not even in the datasheet
and b) on parallel chips, the block write command issued before already
contained the software protection sequence, so software protection is
definitely enabled.

This patch also removes two clones of protect_jedec

Background: JEDEC Software Data Protection started as an optional
feature, which was disabled on the first single-voltage-flash chips.
The software data protection is the need to prefix a write with a magic
"write enable" command, while without write protection every write
access into the chip's address space modifies flash content. This magic
write enable command also tells the flash chip that the programmer
obviously support sending write-enable commands and turns off the "any
write modifies flash content" mode. There also exist a two-command (6
writes) sequence that disables Software Data Protection completey, which
should only ever be used to prepare updating with a device that can't
handle software data protection.

Corresponding to flashrom svn r783.
Signed-off-by: default avatarMichael Karcher <flashrom@mkarcher.dialup.fu-berlin.de>
Acked-by: default avatarSean Nelson <audiohacked@gmail.com>
Acked-by: default avatarCarl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
      972cec28
  27. 24 Nov, 2009 2 commits
  29. 23 Nov, 2009 1 commit
  31. 21 Nov, 2009 1 commit
  33. 17 Nov, 2009 1 commit
  35. 15 Nov, 2009 1 commit
  37. 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
  39. 01 Oct, 2009 1 commit
  41. 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
  43. 28 Sep, 2009 1 commit
  45. 23 Sep, 2009 1 commit
  47. 18 Sep, 2009 1 commit
  49. 16 Sep, 2009 1 commit
  51. 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
  53. 02 Sep, 2009 1 commit
  55. 19 Aug, 2009 3 commits
  57. 12 Aug, 2009 2 commits

Powered by Integricloud