flashrom September 2010

flashrom@flashrom.org

68 participants
216 discussions

Write succes for Tyan Thunder K8WE s2895 with flashrom v0.9.2-r1001 and chip SSTFL49080A
by STEMMELIN, FREDERIC (FREDERIC)** CTR ** 15 Sep '10

15 Sep '10

Hello, i received today my 2 new SST chips for the Tyan S2895 mobo with BIOS version 1.06 alreday flashed by BIOSMAN company. For a quick summary, what is working and what not: WORKING is chip read, and write with flashrom dumpped image NOT WORKING is writing from original Tyan BIOS image (Error: Image size doesn't match, 2895V106.wph, ftp://ftp.tyan.com/bios/S2895_v106.zip) So, what have a done exactly: - used flashrom v0.9.2-r1001 on Ubuntu to dump my current original bios SSTFL49080A with official 1.06 bios version flashed with propriarity tool provided by Tyan company. - md5sum of this dump => 4c3cc932a149e8bf496160814d0a9c74 - powered computer down - replaced original chip with one from BIOSMAN, same SST reference, with bios 1.06 on it (biosman has flashed the chip for me with lastest available bios version 1.06, not myself) - power on computer with biosman chip inside - used flashrom to dump biosman version of 1.06 - md5sum of the biosman 1.06 version => 18ede76905b99e4591122c5a3032bb2b - used flashrom to write original bios from tyan website (files 2895V105.wph or 2895V106.wph) => FAILED with incorrect size error message - used flashrom to write dump made with flashrom from original tyan bios chip => SUCCES (see file: flashrom_Vw_SST-49FL080A_TYAN_s2895_K8WE-flashrom_burn_from_original_tyanchip106_dump.txt) - md5sum after successfull flashing => 4c3cc932a149e8bf496160814d0a9c74 md5sum gives me insurance that dumping flash chip content from first chip and burning to another chip (after computer power down/up to replace chip) is the same, so write function is working pretty The only thing that it is not working is to flash from tyan bios downloaded version (.wph files), as their siez are bigger. Bios SIZE: dump with flashrom => 1048576 bytes ; original Tyan bios file 2895V106.wph => 1050070 bytes I have not tried the erase function so far. Computer seems to work fine so far (Ubuntu gnome), with all bioses version, before and after flashing, bios menu are ok too. Have a nice evening. PS: file flashrom_Vw_SST-49FL080A_TYAN_s2895_K8WE-tyan105origtry1.txt is to show you siez error while trying flashing Tyan original wph bios files (version 105, but same for 106). File names wre truncated by Windows webmail :(

1 0

[commit] r1174 - trunk
by repository service 15 Sep '10

15 Sep '10

Author: hailfinger Date: Wed Sep 15 16:47:56 2010 New Revision: 1174 URL: http://flashrom.org/trac/flashrom/changeset/1174 Log: Add chipset enable for Broadcom OSB4. No docs available. Signed-off-by: Joshua Roys <roysjosh(a)gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/chipset_enable.c Modified: trunk/chipset_enable.c ============================================================================== --- trunk/chipset_enable.c Wed Sep 15 14:02:07 2010 (r1173) +++ trunk/chipset_enable.c Wed Sep 15 16:47:56 2010 (r1174) @@ -802,6 +802,23 @@ return 0; } +static int enable_flash_osb4(struct pci_dev *dev, const char *name) +{ + uint8_t tmp; + + buses_supported = CHIP_BUSTYPE_PARALLEL; + + tmp = INB(0xc06); + tmp |= 0x1; + OUTB(tmp, 0xc06); + + tmp = INB(0xc6f); + tmp |= 0x40; + OUTB(tmp, 0xc6f); + + return 0; +} + /* ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) */ static int enable_flash_sb400(struct pci_dev *dev, const char *name) { @@ -1008,6 +1025,7 @@ {0x1002, 0x439d, OK, "AMD", "SB700/SB710/SB750", enable_flash_sb600}, {0x100b, 0x0510, NT, "AMD", "SC1100", enable_flash_sc1100}, {0x1002, 0x4377, OK, "ATI", "SB400", enable_flash_sb400}, + {0x1166, 0x0200, OK, "Broadcom", "OSB4", enable_flash_osb4}, {0x1166, 0x0205, OK, "Broadcom", "HT-1000", enable_flash_ht1000}, {0x8086, 0x3b00, NT, "Intel", "3400 Desktop", enable_flash_ich10}, {0x8086, 0x3b01, NT, "Intel", "3400 Mobile", enable_flash_ich10},

1 0

[PATCH] SB700 IMC: refuse to write
by Carl-Daniel Hailfinger 15 Sep '10

15 Sep '10

AMD SB700 and later have an integrated microcontroller (IMC) which runs from shared flash. The IMC will happily issue reads while we write, issue writes while we read, and generally cause lots of havoc due to the concurrent accesses it performs while flashrom is running. A failing or corrupted read can be detected since r1145, and the worst case is that the read aborts and the user has to retry. A failing write is much more serious. It can be detected since r1145, but if the SPI interface locks up, we can't continue writing nor can we read the current chip contents. If the IMC is inactive, there is no reason to worry. If the IMC is active, flashrom will refuse to erase/write the chip with this patch. The correct fix would be to stop the IMC during flashing, but apparently the relevant registers are undocumented, so we take the safe route for now until someone from AMD can give us more info. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-sb700_imc_refuse_write/sb600spi.c =================================================================== --- flashrom-sb700_imc_refuse_write/sb600spi.c (Revision 1171) +++ flashrom-sb700_imc_refuse_write/sb600spi.c (Arbeitskopie) @@ -294,6 +294,24 @@ return 0; } + reg = pci_read_byte(dev, 0x40); + msg_pdbg("SB700 IMC is %sactive.\n", (tmp & (1 << 7)) ? "" : "not "); + if (tmp & (1 << 7)) { + /* If we touch any region used by the IMC, the IMC and the SPI + * interface will lock up, and the only way to recover is a + * hard reset, but that is a bad choice for a half-erased or + * half-written flash chip. + * There appears to be an undocumented register which can freeze + * or disable the IMC, but for now we want to play it safe. + */ + msg_perr("The SB700 IMC is active and may interfere with SPI " + "commands. Disabling write.\n"); + /* FIXME: Should we only disable SPI writes, or will the lockup + * affect LPC/FWH chips as well? + */ + programmer_may_write = 0; + } + /* Bring the FIFO to a clean state. */ reset_internal_fifo_pointer(); -- http://www.hailfinger.org/

3 5

[commit] r1173 - trunk
by repository service 15 Sep '10

15 Sep '10

Author: hailfinger Date: Wed Sep 15 14:02:07 2010 New Revision: 1173 URL: http://flashrom.org/trac/flashrom/changeset/1173 Log: AMD SB700 and later have an integrated microcontroller (IMC) which runs from shared flash. The IMC will happily issue reads while we write, issue writes while we read, and generally cause lots of havoc due to the concurrent accesses it performs while flashrom is running. A failing or corrupted read can be detected since r1145, and the worst case is that the read aborts and the user has to retry. A failing write is much more serious. It can be detected since r1145, but if the SPI interface locks up, we can't continue writing nor can we read the current chip contents. If the IMC is inactive, there is no reason to worry. If the IMC is active, flashrom will refuse to erase/write the chip with this patch. The correct fix would be to stop the IMC during flashing, but apparently the relevant registers are undocumented, so we take the safe route for now until someone from AMD can give us more info. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Tested-by: Matthias Kretz <kretz(a)kde.org> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/sb600spi.c Modified: trunk/sb600spi.c ============================================================================== --- trunk/sb600spi.c Wed Sep 15 12:20:16 2010 (r1172) +++ trunk/sb600spi.c Wed Sep 15 14:02:07 2010 (r1173) @@ -294,6 +294,24 @@ return 0; } + reg = pci_read_byte(dev, 0x40); + msg_pdbg("SB700 IMC is %sactive.\n", (reg & (1 << 7)) ? "" : "not "); + if (reg & (1 << 7)) { + /* If we touch any region used by the IMC, the IMC and the SPI + * interface will lock up, and the only way to recover is a + * hard reset, but that is a bad choice for a half-erased or + * half-written flash chip. + * There appears to be an undocumented register which can freeze + * or disable the IMC, but for now we want to play it safe. + */ + msg_perr("The SB700 IMC is active and may interfere with SPI " + "commands. Disabling write.\n"); + /* FIXME: Should we only disable SPI writes, or will the lockup + * affect LPC/FWH chips as well? + */ + programmer_may_write = 0; + } + /* Bring the FIFO to a clean state. */ reset_internal_fifo_pointer();

1 0

[PATCH] Delay between probe and subsequent operations
by Carl-Daniel Hailfinger 15 Sep '10

15 Sep '10

Delay between probe and subsequent operations. Some flash chips need time to exit ID mode, and while we take care of correct timing for the matching probe, subsequent probes may have totally different timing, and that can lead to garbage responses from the flash chip during the first accesses after the probe sequence is done. Delay 100 ms between the last probe and any subsequent operation. To ensure maximum correctness, we would have to reset the chip first in case the last probe function left the chip in an undefined (non-read) state. That will be possible once struct flashchip has a .reset function. This fixes unstable erase/read/write for some flahs chips on nic3com and possible other use cases as well. Thanks to Maciej Pijanka for reporting the issue and testing patches. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-delay_after_probes/cli_classic.c =================================================================== --- flashrom-delay_after_probes/cli_classic.c (Revision 1171) +++ flashrom-delay_after_probes/cli_classic.c (Arbeitskopie) @@ -456,5 +456,10 @@ if (write_it && !dont_verify_it) verify_it = 1; + /* FIXME: We should issue an unconditional chip reset here. This can be + * done once we have a .reset function in struct flashchip. + * Give the chip time to settle. + */ + programmer_delay(100000); return doit(flash, force, filename, read_it, write_it, erase_it, verify_it); } -- http://www.hailfinger.org/

2 3

[commit] r1172 - trunk
by repository service 15 Sep '10

15 Sep '10

Author: hailfinger Date: Wed Sep 15 12:20:16 2010 New Revision: 1172 URL: http://flashrom.org/trac/flashrom/changeset/1172 Log: Delay between probe and subsequent operations. Some flash chips need time to exit ID mode, and while we take care of correct timing for the matching probe, subsequent probes may have totally different timing, and that can lead to garbage responses from the flash chip during the first accesses after the probe sequence is done. Delay 100 ms between the last probe and any subsequent operation. To ensure maximum correctness, we would have to reset the chip first in case the last probe function left the chip in an undefined (non-read) state. That will be possible once struct flashchip has a .reset function. This fixes unstable erase/read/write for some flahs chips on nic3com and possible other use cases as well. Thanks to Maciej Pijanka for reporting the issue and testing patches. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de> Modified: trunk/cli_classic.c Modified: trunk/cli_classic.c ============================================================================== --- trunk/cli_classic.c Wed Sep 15 02:17:37 2010 (r1171) +++ trunk/cli_classic.c Wed Sep 15 12:20:16 2010 (r1172) @@ -456,5 +456,10 @@ if (write_it && !dont_verify_it) verify_it = 1; + /* FIXME: We should issue an unconditional chip reset here. This can be + * done once we have a .reset function in struct flashchip. + * Give the chip time to settle. + */ + programmer_delay(100000); return doit(flash, force, filename, read_it, write_it, erase_it, verify_it); }

1 0

Fwd: flashrom test on MSI PM8M3-V 4.1
by Shahar Or 15 Sep '10

15 Sep '10

---------- Forwarded message ---------- From: Shahar Or <mightyiampresence(a)gmail.com> Date: Wed, 15 Sep 2010 08:59:02 +0200 Subject: Re: flashrom test on MSI PM8M3-V 4.1 To: Uwe Hermann <uwe(a)hermann-uwe.de> Dear ones, It is the V H, actually. Thanks for noticing. Blessings, Shahar On 9/15/10, Uwe Hermann <uwe(a)hermann-uwe.de> wrote: > On Sat, Sep 04, 2010 at 11:39:58AM +0000, Shahar Or wrote: >> DMI string system-product-name: "MS-7211" > [...] >> SUCCESS. >> COMPLETE. >> Verifying flash... VERIFIED. > > Look good, thanks, we marked the "MSI MS-7211 (PM8M3-V)" as tested. > Just to make sure, you have the "PM8M3-V", not the "PM8M3-V H", right? > > > Thanks, Uwe. > -- > http://hermann-uwe.de | http://sigrok.org > http://randomprojects.org | http://unmaintained-free-software.org > -- Sent from my mobile device -- Sent from my mobile device

1 0

[PATCH] New chip IDs
by Carl-Daniel Hailfinger 15 Sep '10

15 Sep '10

Sorry for the totally meaningless subject. I wanted to get the current state of one of my ID-collection trees out there. Maybe someone finds it useful. The patch is WIP, but hey... if parts of it are mergeable, even better. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-newchips/flashchips.c =================================================================== --- flashrom-newchips/flashchips.c (Revision 1171) +++ flashrom-newchips/flashchips.c (Arbeitskopie) @@ -1335,6 +1335,8 @@ .read = spi_chip_read, }, +/* The AT25F512, AT25F1024 and AT25F2048 apparently support a 0x62 chip erase? */ + { .vendor = "Atmel", .name = "AT25F512B", Index: flashrom-newchips/flashchips.h =================================================================== --- flashrom-newchips/flashchips.h (Revision 1171) +++ flashrom-newchips/flashchips.h (Arbeitskopie) @@ -58,12 +58,15 @@ #define AM_29F400BT 0x23 #define AM_29F800BB 0x58 #define AM_29F800BT 0xD6 +#define AMD_AM29LV001B 0x6D +#define AMD_AM29LV001T 0xED #define AM_29LV002BB 0xC2 #define AM_29LV002BT 0x40 #define AM_29LV004BB 0xB6 #define AM_29LV004BT 0xB5 #define AM_29LV008BB 0x37 #define AM_29LV008BT 0x3E +#define AMD_AM29LV010 0x6E #define AM_29LV040B 0x4F #define AM_29LV080B 0x38 /* Same as Am29LV081B */ #define AM_29LV200BB 0xBF @@ -121,14 +124,21 @@ #define AT_25DF641 0x4800 #define AT_25DQ161 0x8600 #define AT25F512 /* No device ID found in datasheet. Vendor ID - * can be read with AT25F512A_RDID */ + * can be read with AT25F512A_RDID. + * ID is 0x65??? + */ #define AT_25F512A 0x65 /* Needs AT25F512A_RDID */ #define AT_25F512B 0x6500 #define AT25F1024 /* No device ID found in datasheet. Vendor ID - * can be read with AT25F512A_RDID */ + * can be read with AT25F512A_RDID. + * ID is 0x60 or 0x40??? + */ #define AT_25F1024A 0x60 /* Needs AT25F512A_RDID */ +#define ATMEL_AT25F2048 0x63 /* Special RDID */ #define AT_25FS010 0x6601 #define AT_25FS040 0x6604 +#define ATMEL_AT25DF021 0x4300 +#define ATMEL_AT25DF041 0x4401 #define AT_26DF041 0x4400 #define AT_26DF081 0x4500 /* guessed, no datasheet available */ #define AT_26DF081A 0x4501 @@ -136,6 +146,8 @@ #define AT_26DF161A 0x4601 #define AT_26DF321 0x4700 /* Same as 25DF321 */ #define AT_26F004 0x0400 +#define ATMEL_AT29LV512 0x3D +#define ATMEL_AT29LV010A 0x35 /* Same as AT29BV010A? */ #define AT_29C040A 0xA4 #define AT_29C010A 0xD5 #define AT_29C020 0xDA @@ -166,7 +178,11 @@ #define AT_45DB321D 0x2701 /* Buggy data sheet */ #define AT_45DB642 /* No ID available */ #define AT_45DB642D 0x2800 -#define AT_49BV512 0x03 +#define AT_49BV512 0x03 /* Same as AT49F512? */ +#define ATMEL_AT49F001 0x05 +#define ATMEL_AT49F001T 0x04 +#define ATMEL_AT49F010 0x87 +#define ATMEL_AT49LV010 0x17 /* Same as AT49BV010? */ #define AT_49F020 0x0B #define AT_49F002N 0x07 /* for AT49F002(N) */ #define AT_49F002NT 0x08 /* for AT49F002(N)T */ @@ -360,6 +376,7 @@ */ #define PMC_ID 0x7F9D /* PMC */ #define PMC_ID_NOPREFIX 0x9D /* PMC, missing 0x7F prefix */ +#define PMC_PM25LD512 0x20 /* Uses PMC_ID instead of the usual PMC_ID_NOPREFIX */ #define PMC_25LV512 0x7B #define PMC_25LV010 0x7C #define PMC_25LV020 0x7D @@ -412,9 +429,9 @@ #define SST_25WF010 0x2502 #define SST_25WF020 0x2503 #define SST_25WF040 0x2504 -#define SST_25VF512A_REMS 0x48 /* REMS or RES opcode */ +#define SST_25VF512A_REMS 0x48 /* REMS or RES opcode, also SST25VF512? */ #define SST_25VF010_REMS 0x49 /* REMS or RES opcode */ -#define SST_25VF020_REMS 0x43 /* REMS or RES opcode */ +#define SST_25VF020_REMS 0x43 /* REMS or RES opcode, also SST25LF020? */ #define SST_25VF040_REMS 0x44 /* REMS or RES opcode, same as SST25LF040A */ #define SST_25VF040B 0x258D #define SST_25VF040B_REMS 0x8D /* REMS or RES opcode */ @@ -434,6 +451,7 @@ #define SST_27VF020 0xAA #define SST_28SF040 0x04 #define SST_29EE512 0x5D +#define SST_29LE512 0x3D /* Same as SST29VE512 */ #define SST_29EE010 0x07 #define SST_29LE010 0x08 /* Same as SST29VE010 */ #define SST_29EE020A 0x10 /* Same as SST29EE020 */ @@ -451,6 +469,7 @@ #define SST_39VF020 0xD6 /* Same as 39LF020 */ #define SST_39VF040 0xD7 /* Same as 39LF040 */ #define SST_39VF080 0xD8 /* Same as 39LF080/39VF080/39VF088 */ +#define SST_45VF010 0x42 /* FIXME */ #define SST_49LF040B 0x50 #define SST_49LF040 0x51 #define SST_49LF020 0x61 @@ -469,10 +488,11 @@ /* * ST25P chips are SPI, first byte of device ID is memory type, second * byte of device ID is related to log(bitsize) at least for some chips. + * ST is now called Numonyx. */ #define ST_ID 0x20 /* ST / SGS/Thomson */ #define ST_M25P05A 0x2010 -#define ST_M25P05_RES 0x10 /* Same code as M25P10. */ +#define ST_M25P05_RES 0x10 /* Same code as M25P10. Datasheet error? Should be 0x05? */ #define ST_M25P10A 0x2011 #define ST_M25P10_RES 0x10 /* Same code as M25P05. */ #define ST_M25P20 0x2012 @@ -530,6 +550,9 @@ #define SM_MVC_29C51002B 0xA2 /* Identical chips: {F,S,V}29C51002B */ #define SM_MVC_29C51004B 0xA3 /* Identical chips: {F,S,V}29C51004B */ +#define TENX_ID_NOPREFIX 0x5E /* Tenx Technologies, 0x7F7F5E */ +#define TENX_ICE25P05 0x01 /* Maybe? */ + #define TI_ID 0x97 /* Texas Instruments */ #define TI_OLD_ID 0x01 /* TI chips from last century */ #define TI_TMS29F002RT 0xB0 @@ -540,10 +563,10 @@ * byte of device ID is related to log(bitsize). */ #define WINBOND_NEX_ID 0xEF /* Winbond (ex Nexcom) serial flashes */ -#define WINBOND_NEX_W25X10 0x3011 -#define WINBOND_NEX_W25X20 0x3012 -#define WINBOND_NEX_W25X40 0x3013 -#define WINBOND_NEX_W25X80 0x3014 +#define WINBOND_NEX_W25X10 0x3011 /* W25X10A? */ +#define WINBOND_NEX_W25X20 0x3012 /* W25X20A? */ +#define WINBOND_NEX_W25X40 0x3013 /* W25X40A? */ +#define WINBOND_NEX_W25X80 0x3014 /* W25X80A? */ #define WINBOND_NEX_W25X16 0x3015 #define WINBOND_NEX_W25X32 0x3016 #define WINBOND_NEX_W25X64 0x3017 @@ -565,7 +588,7 @@ #define WINBOND_W19B323MT 0x13 #define WINBOND_W19B324MB 0x97 #define WINBOND_W19B324MT 0x16 -#define WINBOND_W29C010 0xC1 /* Same as W29C010M, W29C011A, W29EE011, W29EE012, and ASD AE29F1008 */ +#define WINBOND_W29C010 0xC1 /* Same as W29C010M, W29C011A, W29EE011, W29EE012, and ASD AE29F1008 (is there a W29C011?) */ #define WINBOND_W29C020 0x45 /* Same as W29C020C, W29C022 and ASD AE29F2008 */ #define WINBOND_W29C040 0x46 /* Same as W29C040P */ #define WINBOND_W29C512A 0xC8 /* Same as W29EE512 */ -- http://www.hailfinger.org/

1 0

[PATCH] SPI bitbanging: request/release bus
by Carl-Daniel Hailfinger 15 Sep '10

15 Sep '10

SPI bitbanging on devices which speak SPI natively has a dual-use problem: We need to shut down normal SPI operations to do the bitbanging ourselves. Once we're done, it makes a lot of sense to reenable "normal" SPI operations again. Add request_bus/release_bus functions to struct bitbang_spi_master. Add a bitbang shutdown function (not used yet). Change MCP SPI and Intel NIC SPI to use the new request/release bus infrastructure. There are multiple possible strategies for bus request/release: - Request at the start of a SPI command, release immediately afterwards. - Request at the start of a SPI multicommand, release once all commands of the multicommand are done. - Request on programmer init, release on shutdown. Each strategy has its own advantages. For now, we will stay with the first strategy which worked fine so far. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-bitbang_spi_init_errorcheck_request_release_bus/bitbang_spi.c =================================================================== --- flashrom-bitbang_spi_init_errorcheck_request_release_bus/bitbang_spi.c (Revision 1164) +++ flashrom-bitbang_spi_init_errorcheck_request_release_bus/bitbang_spi.c (Arbeitskopie) @@ -53,6 +53,18 @@ return bitbang_spi_master->get_miso(); } +static void bitbang_spi_request_bus(void) +{ + if (bitbang_spi_master->request_bus) + bitbang_spi_master->request_bus(); +} + +static void bitbang_spi_release_bus(void) +{ + if (bitbang_spi_master->release_bus) + bitbang_spi_master->release_bus(); +} + int bitbang_spi_init(const struct bitbang_spi_master *master, int halfperiod) { /* BITBANG_SPI_INVALID is 0, so if someone forgot to initialize ->type, @@ -61,19 +73,44 @@ */ if (!master || master->type == BITBANG_SPI_INVALID || !master->set_cs || !master->set_sck || !master->set_mosi || !master->get_miso) { - msg_perr("Incomplete bitbanging SPI master setting! Please " - "report a bug at flashrom(a)flashrom.org\n"); + msg_perr("Incomplete SPI bitbang master setting! " + "Please report a bug at flashrom(a)flashrom.org\n"); return 1; } + if (bitbang_spi_master) { + msg_perr("SPI bitbang master already initialized! " + "Please report a bug at flashrom(a)flashrom.org\n"); + return 1; + } + bitbang_spi_master = master; bitbang_spi_half_period = halfperiod; + /* FIXME: Run bitbang_spi_request_bus here or in programmer init? */ bitbang_spi_set_cs(1); bitbang_spi_set_sck(0); bitbang_spi_set_mosi(0); return 0; } +int bitbang_spi_shutdown(const struct bitbang_spi_master *master) +{ + if (!bitbang_spi_master) { + msg_perr("Shutting down an uninitialized SPI bitbang master! " + "Please report a bug at flashrom(a)flashrom.org\n"); + return 1; + } + if (master != bitbang_spi_master) { + msg_perr("Shutting down a mismatched SPI bitbang master! " + "Please report a bug at flashrom(a)flashrom.org\n"); + return 1; + } + + /* FIXME: Run bitbang_spi_release_bus here or per command? */ + bitbang_spi_master = NULL; + return 0; +} + static uint8_t bitbang_spi_readwrite_byte(uint8_t val) { uint8_t ret = 0; @@ -96,6 +133,11 @@ { int i; + /* FIXME: Run bitbang_spi_request_bus here or in programmer init? + * Requesting and releasing the SPI bus is handled in here to allow the + * programmer to use its own SPI engine for native accesses. + */ + bitbang_spi_request_bus(); bitbang_spi_set_cs(0); for (i = 0; i < writecnt; i++) bitbang_spi_readwrite_byte(writearr[i]); @@ -105,6 +147,8 @@ programmer_delay(bitbang_spi_half_period); bitbang_spi_set_cs(1); programmer_delay(bitbang_spi_half_period); + /* FIXME: Run bitbang_spi_release_bus here or in programmer init? */ + bitbang_spi_release_bus(); return 0; } Index: flashrom-bitbang_spi_init_errorcheck_request_release_bus/nicintel_spi.c =================================================================== --- flashrom-bitbang_spi_init_errorcheck_request_release_bus/nicintel_spi.c (Revision 1164) +++ flashrom-bitbang_spi_init_errorcheck_request_release_bus/nicintel_spi.c (Arbeitskopie) @@ -91,20 +91,10 @@ { uint32_t tmp; - /* - * Requesting and releasing the SPI bus is handled in here to allow - * the chipset to use its own SPI engine for native reads. - */ - if (val == 0) - nicintel_request_spibus(); - tmp = pci_mmio_readl(nicintel_spibar + FLA); tmp &= ~(1 << FL_CS); tmp |= (val << FL_CS); pci_mmio_writel(tmp, nicintel_spibar + FLA); - - if (val == 1) - nicintel_release_spibus(); } static void nicintel_bitbang_set_sck(int val) @@ -142,6 +132,8 @@ .set_sck = nicintel_bitbang_set_sck, .set_mosi = nicintel_bitbang_set_mosi, .get_miso = nicintel_bitbang_get_miso, + .request_bus = nicintel_request_spibus, + .release_bus = nicintel_release_spibus, }; int nicintel_spi_init(void) Index: flashrom-bitbang_spi_init_errorcheck_request_release_bus/mcp6x_spi.c =================================================================== --- flashrom-bitbang_spi_init_errorcheck_request_release_bus/mcp6x_spi.c (Revision 1164) +++ flashrom-bitbang_spi_init_errorcheck_request_release_bus/mcp6x_spi.c (Arbeitskopie) @@ -66,18 +66,9 @@ static void mcp6x_bitbang_set_cs(int val) { - /* Requesting and releasing the SPI bus is handled in here to allow the - * chipset to use its own SPI engine for native reads. - */ - if (val == 0) - mcp6x_request_spibus(); - mcp_gpiostate &= ~(1 << MCP6X_SPI_CS); mcp_gpiostate |= (val << MCP6X_SPI_CS); mmio_writeb(mcp_gpiostate, mcp6x_spibar + 0x530); - - if (val == 1) - mcp6x_release_spibus(); } static void mcp6x_bitbang_set_sck(int val) @@ -106,6 +97,8 @@ .set_sck = mcp6x_bitbang_set_sck, .set_mosi = mcp6x_bitbang_set_mosi, .get_miso = mcp6x_bitbang_get_miso, + .request_bus = mcp6x_request_spibus, + .release_bus = mcp6x_release_spibus, }; int mcp6x_spi_init(int want_spi) Index: flashrom-bitbang_spi_init_errorcheck_request_release_bus/programmer.h =================================================================== --- flashrom-bitbang_spi_init_errorcheck_request_release_bus/programmer.h (Revision 1164) +++ flashrom-bitbang_spi_init_errorcheck_request_release_bus/programmer.h (Arbeitskopie) @@ -131,6 +131,8 @@ void (*set_sck) (int val); void (*set_mosi) (int val); int (*get_miso) (void); + void (*request_bus) (void); + void (*release_bus) (void); }; #if CONFIG_INTERNAL == 1 @@ -443,6 +445,7 @@ /* bitbang_spi.c */ int bitbang_spi_init(const struct bitbang_spi_master *master, int halfperiod); +int bitbang_spi_shutdown(const struct bitbang_spi_master *master); int bitbang_spi_send_command(unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr); int bitbang_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len); int bitbang_spi_write_256(struct flashchip *flash, uint8_t *buf, int start, int len); -- http://www.hailfinger.org/

2 3

[commit] r1171 - trunk
by repository service 15 Sep '10

15 Sep '10

Author: hailfinger Date: Wed Sep 15 02:17:37 2010 New Revision: 1171 URL: http://flashrom.org/trac/flashrom/changeset/1171 Log: SPI bitbanging: request/release bus. SPI bitbanging on devices which speak SPI natively has a dual-use problem: We need to shut down normal SPI operations to do the bitbanging ourselves. Once we're done, it makes a lot of sense to reenable "normal" SPI operations again. Add request_bus/release_bus functions to struct bitbang_spi_master. Add a bitbang shutdown function (not used yet). Change MCP SPI and Intel NIC SPI to use the new request/release bus infrastructure. Cosmetic changes to a few error messages (80 column limit). There are multiple possible strategies for bus request/release: - Request at the start of a SPI command, release immediately afterwards. - Request at the start of a SPI multicommand, release once all commands of the multicommand are done. - Request on programmer init, release on shutdown. Each strategy has its own advantages. For now, we will stay with the first strategy which worked fine so far. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/bitbang_spi.c trunk/mcp6x_spi.c trunk/nicintel_spi.c trunk/programmer.h Modified: trunk/bitbang_spi.c ============================================================================== --- trunk/bitbang_spi.c Wed Sep 15 02:13:02 2010 (r1170) +++ trunk/bitbang_spi.c Wed Sep 15 02:17:37 2010 (r1171) @@ -53,6 +53,18 @@ return bitbang_spi_master->get_miso(); } +static void bitbang_spi_request_bus(void) +{ + if (bitbang_spi_master->request_bus) + bitbang_spi_master->request_bus(); +} + +static void bitbang_spi_release_bus(void) +{ + if (bitbang_spi_master->release_bus) + bitbang_spi_master->release_bus(); +} + int bitbang_spi_init(const struct bitbang_spi_master *master, int halfperiod) { /* BITBANG_SPI_INVALID is 0, so if someone forgot to initialize ->type, @@ -61,19 +73,44 @@ */ if (!master || master->type == BITBANG_SPI_INVALID || !master->set_cs || !master->set_sck || !master->set_mosi || !master->get_miso) { - msg_perr("Incomplete bitbanging SPI master setting! Please " - "report a bug at flashrom(a)flashrom.org\n"); + msg_perr("Incomplete SPI bitbang master setting!\n" + "Please report a bug at flashrom(a)flashrom.org\n"); + return 1; + } + if (bitbang_spi_master) { + msg_perr("SPI bitbang master already initialized!\n" + "Please report a bug at flashrom(a)flashrom.org\n"); return 1; } + bitbang_spi_master = master; bitbang_spi_half_period = halfperiod; + /* FIXME: Run bitbang_spi_request_bus here or in programmer init? */ bitbang_spi_set_cs(1); bitbang_spi_set_sck(0); bitbang_spi_set_mosi(0); return 0; } +int bitbang_spi_shutdown(const struct bitbang_spi_master *master) +{ + if (!bitbang_spi_master) { + msg_perr("Shutting down an uninitialized SPI bitbang master!\n" + "Please report a bug at flashrom(a)flashrom.org\n"); + return 1; + } + if (master != bitbang_spi_master) { + msg_perr("Shutting down a mismatched SPI bitbang master!\n" + "Please report a bug at flashrom(a)flashrom.org\n"); + return 1; + } + + /* FIXME: Run bitbang_spi_release_bus here or per command? */ + bitbang_spi_master = NULL; + return 0; +} + static uint8_t bitbang_spi_readwrite_byte(uint8_t val) { uint8_t ret = 0; @@ -96,6 +133,11 @@ { int i; + /* FIXME: Run bitbang_spi_request_bus here or in programmer init? + * Requesting and releasing the SPI bus is handled in here to allow the + * programmer to use its own SPI engine for native accesses. + */ + bitbang_spi_request_bus(); bitbang_spi_set_cs(0); for (i = 0; i < writecnt; i++) bitbang_spi_readwrite_byte(writearr[i]); @@ -105,6 +147,8 @@ programmer_delay(bitbang_spi_half_period); bitbang_spi_set_cs(1); programmer_delay(bitbang_spi_half_period); + /* FIXME: Run bitbang_spi_release_bus here or in programmer init? */ + bitbang_spi_release_bus(); return 0; } Modified: trunk/mcp6x_spi.c ============================================================================== --- trunk/mcp6x_spi.c Wed Sep 15 02:13:02 2010 (r1170) +++ trunk/mcp6x_spi.c Wed Sep 15 02:17:37 2010 (r1171) @@ -66,18 +66,9 @@ static void mcp6x_bitbang_set_cs(int val) { - /* Requesting and releasing the SPI bus is handled in here to allow the - * chipset to use its own SPI engine for native reads. - */ - if (val == 0) - mcp6x_request_spibus(); - mcp_gpiostate &= ~(1 << MCP6X_SPI_CS); mcp_gpiostate |= (val << MCP6X_SPI_CS); mmio_writeb(mcp_gpiostate, mcp6x_spibar + 0x530); - - if (val == 1) - mcp6x_release_spibus(); } static void mcp6x_bitbang_set_sck(int val) @@ -106,6 +97,8 @@ .set_sck = mcp6x_bitbang_set_sck, .set_mosi = mcp6x_bitbang_set_mosi, .get_miso = mcp6x_bitbang_get_miso, + .request_bus = mcp6x_request_spibus, + .release_bus = mcp6x_release_spibus, }; int mcp6x_spi_init(int want_spi) Modified: trunk/nicintel_spi.c ============================================================================== --- trunk/nicintel_spi.c Wed Sep 15 02:13:02 2010 (r1170) +++ trunk/nicintel_spi.c Wed Sep 15 02:17:37 2010 (r1171) @@ -91,20 +91,10 @@ { uint32_t tmp; - /* - * Requesting and releasing the SPI bus is handled in here to allow - * the chipset to use its own SPI engine for native reads. - */ - if (val == 0) - nicintel_request_spibus(); - tmp = pci_mmio_readl(nicintel_spibar + FLA); tmp &= ~(1 << FL_CS); tmp |= (val << FL_CS); pci_mmio_writel(tmp, nicintel_spibar + FLA); - - if (val == 1) - nicintel_release_spibus(); } static void nicintel_bitbang_set_sck(int val) @@ -142,6 +132,8 @@ .set_sck = nicintel_bitbang_set_sck, .set_mosi = nicintel_bitbang_set_mosi, .get_miso = nicintel_bitbang_get_miso, + .request_bus = nicintel_request_spibus, + .release_bus = nicintel_release_spibus, }; int nicintel_spi_init(void) Modified: trunk/programmer.h ============================================================================== --- trunk/programmer.h Wed Sep 15 02:13:02 2010 (r1170) +++ trunk/programmer.h Wed Sep 15 02:17:37 2010 (r1171) @@ -131,6 +131,8 @@ void (*set_sck) (int val); void (*set_mosi) (int val); int (*get_miso) (void); + void (*request_bus) (void); + void (*release_bus) (void); }; #if CONFIG_INTERNAL == 1 @@ -443,6 +445,7 @@ /* bitbang_spi.c */ int bitbang_spi_init(const struct bitbang_spi_master *master, int halfperiod); +int bitbang_spi_shutdown(const struct bitbang_spi_master *master); int bitbang_spi_send_command(unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr); int bitbang_spi_read(struct flashchip *flash, uint8_t *buf, int start, int len); int bitbang_spi_write_256(struct flashchip *flash, uint8_t *buf, int start, int len);

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom September 2010