flashrom May 2011

flashrom@flashrom.org

55 participants
236 discussions

Re: [flashrom] Intel SandyBridge serie 6 chipsets support
by Stefan Tauner 31 May '11

31 May '11

On Mon, 30 May 2011 13:57:21 +0200 Mohammed-Amine.Rebai(a)bull.net wrote: > Hallo Stefan, hello! > Wir könnten eigentlich deutsch sprechen ;). we could, but it would upset those nasty dutch people and all those who cant make any sense out of german even more ;) i tricked your client to reply not directly to me but to the mailing list with a special header in my email so that everyone else can read your replies too (and answer them). that is because often people (new to mailing lists or just unwary) just reply to the sender and not to the list as well (you did so too in your reply to idwer). usually there is a button or menu entry to "reply to all" which also includes previously "cc:"-tagged addresses in your reply. hth > Ja, unsere Kunden benützen auch flashrom. Wir haben usere EFI shell > flashing tool, aber die Kunden benützen das Linux Shell am liebsten, > besonders wenn du viele Clusters/Servers flashen muss. understandable :) > Aber mein Problem ist vor diesen Sachen. « chipset_flash_enable » findet > nicht das PCH: > « This chipset supports the following protocols: Non-SPI. WARNING: > No chipset found. Flash detection will most likely fail. » > > und das PCH device_id (Vendor ID:0x8086, Device ID:0x244e ) existiert > nicht in das «chipset_enables » stuct. ( mein PCH heisst Patsburg oder > C200 chipset ). ah ok i was not aware that those are missing. my laptop is based on ibex peak/QS57 and i have not checked if the newer ones are actually there. i will put that on my todo list. > Wenn ich « enable_flash_ich10 » Funktion nötige, es funkioniert auch > nicht. > Maximum FWH chip size: 0x0 bytes BIOS Lock Enable: > disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x0 tried to set 0xdc > to 0x1 on ICH10 failed (WARNING ONLY) Root Complex Register Block > address = 0x0 Error accessing ICH RCRB, 0x4000 bytes at 0x00000000 > /dev/mem mmap failed: Resource temporarily unavailable ok that certainly does not look right. could you please send us a full log of the output of flashrom -VV with the added pci id please? > Ich werde vielleicht eine neue funktion schreiben ;). that would of course be very appreciated. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 4

Re: [flashrom] Intel SandyBridge serie 6 chipsets support
by Idwer Vollering 30 May '11

30 May '11

2011/5/30 <Mohammed-Amine.Rebai(a)bull.net>: > Dear Mr Vollering, > > I am sorry for the language mixing, I was not aware that other people than > my replier ( Stefan Tauner ) would receive my answer. That is the difference between replying and replying to all recipients ;) > Due to his informal answer ( smiles etc ) I tried to answer back the same way. > > As a Bios engineer, as far as I know, we only use your software to flash the > Bios in some cases where we are under Linux. Our usual way to flash our > machines is a Bios Integrated utility under EFI Shell. > > Thanks again for your help and for the nice job you are doing. Thanks. The build you're offering (flashrom-bin-x86_64-20081003.tar) looks outdated though, it is from 2008 and targets 64-bit hardware only. Is that on purpose, e.g. you exclusively sell 64-bit hardware? > > Best Regards > Amine Rebai > > > > > > > > De : Idwer Vollering <vidwer(a)gmail.com> > A : Mohammed-Amine.Rebai(a)bull.net > Cc : flashrom(a)flashrom.org > Date : 30/05/2011 15:15 > Objet : Re: [flashrom] Intel SandyBridge serie 6 chipsets support > ________________________________ > > > 2011/5/30 <Mohammed-Amine.Rebai(a)bull.net>: >> Hallo Stefan, >> >> Wir könnten eigentlich deutsch sprechen ;). >> >> Ja, unsere Kunden benützen auch flashrom. Wir haben usere EFI shell >> flashing >> tool, aber die Kunden benützen das Linux Shell am liebsten, besonders wenn >> du viele Clusters/Servers flashen muss. >> >> Stimmt, das SPI interface in « Intel Chipset Serie 6 » ist fast wie die >> vorausgegangen. Es gibt ME protection und special « unlocking sequence » >> mit >> special opcodes. >> >> Aber mein Problem ist vor diesen Sachen. « chipset_flash_enable » findet >> nicht das PCH: >> « This chipset supports the following protocols: Non-SPI. >> WARNING: No chipset found. Flash detection will most likely fail. » >> >> und das PCH device_id (Vendor ID:0x8086, Device ID:0x244e ) existiert >> nicht >> in das «chipset_enables » stuct. ( mein PCH heisst Patsburg oder C200 >> chipset ). >> >> Wenn ich « enable_flash_ich10 » Funktion nötige, es funkioniert auch >> nicht. >> Maximum FWH chip size: 0x0 bytes BIOS Lock Enable: >> disabled, >> BIOS Write Enable: disabled, BIOS_CNTL is 0x0 tried to set 0xdc to >> 0x1 on ICH10 failed (WARNING ONLY) Root Complex Register Block >> address = 0x0 Error accessing ICH RCRB, 0x4000 bytes at 0x00000000 >> /dev/mem mmap failed: Resource temporarily unavailableIch werde >> vielleicht eine neue funktion schreiben ;). >> Vielen Dank. >> >> Mit freundlichen Grüßen >> Amine Rebai > > It is not very "freundlich" (friendly) to write a reply in an other > language than English, given the fact that your first message was > written in English. > > Also, the download named flashrom-bin-x86_64-20081003.tar [1] is > behind a 'paywall' / customer login. There is no trace of "flashrom is > GPL software" at that website, where can anyone download, if there are > any, your patches? > > Thanks, > Idwer > > [1] > http://support.bull.com/ols/product/platforms/hw-extremcomp/bullx-R/dl/tool… > >> >> >> >> >> De : Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> >> A : Mohammed-Amine.Rebai(a)bull.net >> Cc : flashrom(a)flashrom.org >> Date : 27/05/2011 20:02 >> Objet : Re: [flashrom] Intel SandyBridge serie 6 chipsets support >> ________________________________ >> >> >> On Fri, 27 May 2011 14:58:57 +0200 >> Mohammed-Amine.Rebai(a)bull.net wrote: >> >>> Dear Flahsrom representant, >> hello! >> >>> I am a Bios engineer at BULL, a major european server and supercomputer >>> company «www.bull.com » . >>> >>> First of all, I would like to thank you for the great job you are doing, >>> we use your utility a lot. >> nice to hear that, thank you. is it offered to your customers too? >> >>> I would like to know if you are planning to support the Bios SPI flash >>> flashing on the Intel SandyBridge architecture, especially the Intel 6 >>> series chipset/C200/Patsburg platform controller hub? >> >> the spi interface of the 6 series chipset is very similar to the >> previous ones and as long as there is no locking in place (i am talking >> about PR0-PR4 and related "security" stuff) it may already work, have >> you tried it? >> >> in case of locking in place (that might be a requirement in nowadays >> chipsets due to the requirement of using the ME) flashrom would not >> work yet. i am working on this problem within the scope of my google >> summer of code project which should be completed by the end of summer. >> dont hold your breath though please ;) >> >> -- >> Kind regards/Mit freundlichen Grüßen, Stefan Tauner >> >> >> _______________________________________________ >> flashrom mailing list >> flashrom(a)flashrom.org >> http://www.flashrom.org/mailman/listinfo/flashrom >> > >

1 0

Re: [flashrom] Intel SandyBridge serie 6 chipsets support
by Idwer Vollering 30 May '11

30 May '11

2011/5/30 <Mohammed-Amine.Rebai(a)bull.net>: > Hallo Stefan, > > Wir könnten eigentlich deutsch sprechen ;). > > Ja, unsere Kunden benützen auch flashrom. Wir haben usere EFI shell flashing > tool, aber die Kunden benützen das Linux Shell am liebsten, besonders wenn > du viele Clusters/Servers flashen muss. > > Stimmt, das SPI interface in « Intel Chipset Serie 6 » ist fast wie die > vorausgegangen. Es gibt ME protection und special « unlocking sequence » mit > special opcodes. > > Aber mein Problem ist vor diesen Sachen. « chipset_flash_enable » findet > nicht das PCH: > « This chipset supports the following protocols: Non-SPI. > WARNING: No chipset found. Flash detection will most likely fail. » > > und das PCH device_id (Vendor ID:0x8086, Device ID:0x244e ) existiert nicht > in das «chipset_enables » stuct. ( mein PCH heisst Patsburg oder C200 > chipset ). > > Wenn ich « enable_flash_ich10 » Funktion nötige, es funkioniert auch nicht. > Maximum FWH chip size: 0x0 bytes BIOS Lock Enable: disabled, > BIOS Write Enable: disabled, BIOS_CNTL is 0x0 tried to set 0xdc to > 0x1 on ICH10 failed (WARNING ONLY) Root Complex Register Block > address = 0x0 Error accessing ICH RCRB, 0x4000 bytes at 0x00000000 > /dev/mem mmap failed: Resource temporarily unavailableIch werde > vielleicht eine neue funktion schreiben ;). > Vielen Dank. > > Mit freundlichen Grüßen > Amine Rebai It is not very "freundlich" (friendly) to write a reply in an other language than English, given the fact that your first message was written in English. Also, the download named flashrom-bin-x86_64-20081003.tar [1] is behind a 'paywall' / customer login. There is no trace of "flashrom is GPL software" at that website, where can anyone download, if there are any, your patches? Thanks, Idwer [1] http://support.bull.com/ols/product/platforms/hw-extremcomp/bullx-R/dl/tool… > > > > > De : Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > A : Mohammed-Amine.Rebai(a)bull.net > Cc : flashrom(a)flashrom.org > Date : 27/05/2011 20:02 > Objet : Re: [flashrom] Intel SandyBridge serie 6 chipsets support > ________________________________ > > > On Fri, 27 May 2011 14:58:57 +0200 > Mohammed-Amine.Rebai(a)bull.net wrote: > >> Dear Flahsrom representant, > hello! > >> I am a Bios engineer at BULL, a major european server and supercomputer >> company «www.bull.com » . >> >> First of all, I would like to thank you for the great job you are doing, >> we use your utility a lot. > nice to hear that, thank you. is it offered to your customers too? > >> I would like to know if you are planning to support the Bios SPI flash >> flashing on the Intel SandyBridge architecture, especially the Intel 6 >> series chipset/C200/Patsburg platform controller hub? > > the spi interface of the 6 series chipset is very similar to the > previous ones and as long as there is no locking in place (i am talking > about PR0-PR4 and related "security" stuff) it may already work, have > you tried it? > > in case of locking in place (that might be a requirement in nowadays > chipsets due to the requirement of using the ME) flashrom would not > work yet. i am working on this problem within the scope of my google > summer of code project which should be completed by the end of summer. > dont hold your breath though please ;) > > -- > Kind regards/Mit freundlichen Grüßen, Stefan Tauner > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom >

1 0

Success: MSI G31TM-P21 (MS-7529)
by Peter Lemenkov 30 May '11

30 May '11

Hello. I just successfully reflashed one MSI board. work ~/7529v46: sudo flashrom -w A7529IMS.460 flashrom v0.9.3-r1299 on Linux 2.6.38.6-27.fc15.x86_64 (x86_64), built with libpci 3.1.7, GCC 4.6.0 20110428 (Red Hat 4.6.0-6), little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. Found chipset "Intel ICH7/ICH7R", enabling flash write... OK. This chipset supports the following protocols: SPI. Found chip "Winbond W25Q80" (1024 KB, SPI) at physical address 0xfff00000. Flash image seems to be a legacy BIOS. Disabling checks. Erasing and writing flash chip... Done. Verifying flash... VERIFIED. work ~/7529v46: http://msi.com/product/mb/G31TM-P21.html -- With best regards, Peter Lemenkov.

1 0

[PATCH] Macronix MX25L6445E
by Wagner, Helge (GE Intelligent Platforms) 30 May '11

30 May '11

Hi, i have tried to reprogram a Macronix MX25L6445E flash chip. This worked, but gave me an error message: ERASE FAILED at 0x0001107f! Expected=0xff, Read=0x00, failed byte count from 0x00010000-0x0001ffff: 0x9c15 ERASE FAILED! Looking deeper into the datasheet, i saw that the MX25L6445E has the same ID as the MX25L6405, but with (at least) one difference: The MX25L6405 has a block size of 64KByte for erase function 20h, while the MX25L6445E is using 4KByte sector size for the same erase function 20h. As a result the spi_block_erase_20() will fail for the MX25L6445E (while the spi_block_erase_d8() which is used then will succeed). I have now re-ordered the erase functions for the MX25L6405/MX25L6445E: spi_block_erase_d8 - first spi_block_erase_60 - second spi_block_erase_c7 - third spi_block_erase_20 - last So if one of the d8/60/c7 erase functions are successfull, the spi_block_erase_20 will never be called. To be sure that the spi_block_erase_20 works for both the MX25L6405 and the MX25L6445E, we could change the block erase size from 64K to 4K. This should work even for the MX25L6405, but with the side effect of the erase taking longer than needed. Any comments? Please find my patches included. Signed-off-by: Helge Wagner <Helge.Wagner(a)ge.com> Regards, Helge Helge Wagner Software Engineer GE Intelligent Platforms

1 0

Re: [flashrom] Intel SandyBridge serie 6 chipsets support
by Stefan Tauner 30 May '11

30 May '11

On Fri, 27 May 2011 14:58:57 +0200 Mohammed-Amine.Rebai(a)bull.net wrote: > Dear Flahsrom representant, hello! > I am a Bios engineer at BULL, a major european server and supercomputer > company «www.bull.com » . > > First of all, I would like to thank you for the great job you are doing, > we use your utility a lot. nice to hear that, thank you. is it offered to your customers too? > I would like to know if you are planning to support the Bios SPI flash > flashing on the Intel SandyBridge architecture, especially the Intel 6 > series chipset/C200/Patsburg platform controller hub? the spi interface of the 6 series chipset is very similar to the previous ones and as long as there is no locking in place (i am talking about PR0-PR4 and related "security" stuff) it may already work, have you tried it? in case of locking in place (that might be a requirement in nowadays chipsets due to the requirement of using the ME) flashrom would not work yet. i am working on this problem within the scope of my google summer of code project which should be completed by the end of summer. dont hold your breath though please ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [flashrom] SST25VF064C on GE Intelligent Platforms CR12/VR12/EC12 board family
by Stefan Tauner 29 May '11

29 May '11

On Sat, 28 May 2011 17:50:28 +0200 "Wagner, Helge (GE Intelligent Platforms)" <Helge.Wagner(a)ge.com> wrote: > the SST25VF064C is still marked as untested for WRITE in r1320. hello thanks for your report! i have marked the SST49LF020 as fully supported and will commit it later. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [flashrom] [PATCH 00/11] ichspi patches 4.0 - logs showing the new output
by Stefan Tauner 29 May '11

29 May '11

the two logs appended show the differences in the output between current head (r1322) and after all of these have been applied. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 2

Re: [flashrom] [PATCH 01/11] improve macros for SSFS and SSFC bits
by Carl-Daniel Hailfinger 29 May '11

29 May '11

Am 28.05.2011 05:38 schrieb Stefan Tauner: > - introduce offset macros and use them to (re)define the existing mask macros > - add comments > - rename SSFS_CDS to SSFS_FDONE (abbr. used in datasheet not in SSFS but HSFS) > - use those for refactoring and magic number elemination. > - following patch uses them for pretty printing > > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > --- > ichspi.c | 48 ++++++++++++++++++++++++++++++------------------ > 1 files changed, 30 insertions(+), 18 deletions(-) > > diff --git a/ichspi.c b/ichspi.c > index 299cbf3..676b93a 100644 > --- a/ichspi.c > +++ b/ichspi.c > @@ -47,24 +47,36 @@ > #define ICH9_REG_FDATA0 0x10 /* 64 Bytes */ > > #define ICH9_REG_SSFS 0x90 /* 08 Bits */ > -#define SSFS_SCIP 0x00000001 > -#define SSFS_CDS 0x00000004 > -#define SSFS_FCERR 0x00000008 > -#define SSFS_AEL 0x00000010 > +#define SSFS_SCIP_OFF 0 /* SPI Cycle In Progress */ > +#define SSFS_SCIP (0x1 << SSFS_SCIP_OFF) > This is probably a philosophical question, but should we use #define SSFS_SCIP (0x1 << 0) instead and skip definition of all *_OFF #defines? I don't have a good answer, so I'm hoping you can tell me which one is better. > +#define SSFS_FDONE_OFF 2 /* Cycle Done Status */ > +#define SSFS_FDONE (0x1 << SSFS_FDONE_OFF) > +#define SSFS_FCERR_OFF 3 /* Flash Cycle Error */ > +#define SSFS_FCERR (0x1 << SSFS_FCERR_OFF) > +#define SSFS_AEL_OFF 4 /* Access Error Log */ > +#define SSFS_AEL (0x1 << SSFS_AEL_OFF) > /* The following bits are reserved in SSFS: 1,5-7. */ > #define SSFS_RESERVED_MASK 0x000000e2 > > #define ICH9_REG_SSFC 0x91 /* 24 Bits */ > -#define SSFC_SCGO 0x00000200 > -#define SSFC_ACS 0x00000400 > -#define SSFC_SPOP 0x00000800 > -#define SSFC_COP 0x00001000 > -#define SSFC_DBC 0x00010000 > -#define SSFC_DS 0x00400000 > -#define SSFC_SME 0x00800000 > -#define SSFC_SCF 0x01000000 > -#define SSFC_SCF_20MHZ 0x00000000 > -#define SSFC_SCF_33MHZ 0x01000000 > +#define SSFC_SCGO_OFF (1 + 8) /* 1: SPI Cycle Go */ > +#define SSFC_SCGO (0x1 << SSFC_SCGO_OFF) > +#define SSFC_ACS_OFF (2 + 8) /* 2: Atomic Cycle Sequence */ > +#define SSFC_ACS (0x1 << SSFC_ACS_OFF) > +#define SSFC_SPOP_OFF (3 + 8) /* 3: Sequence Prefix Opcode Pointer */ > +#define SSFC_SPOP (0x1 << SSFC_SPOP_OFF) > +#define SSFC_COP_OFF (4 + 8) /* 4-6: Cycle Opcode Pointer */ > +#define SSFC_COP (0x7 << SSFC_COP_OFF) > +#define SSFC_DBC_OFF (8 + 8) /* 8-13: Data Byte Count */ > +#define SSFC_DBC (0x3f << SSFC_DBC_OFF) > +#define SSFC_DS_OFF (14 + 8) /* 14: Data Cycle */ > +#define SSFC_DS (0x1 << SSFC_DS_OFF) > +#define SSFC_SME_OFF (15 + 8) /* 15: SPI SMI# Enable */ > +#define SSFC_SME (0x1 << SSFC_SME_OFF) > +#define SSFC_SCF_OFF (16 + 8) /* 16-18: SPI Cycle Frequency */ > +#define SSFC_SCF (0x7 << SSFC_SCF_OFF) > +#define SSFC_SCF_20MHZ 0x00000000 > +#define SSFC_SCF_33MHZ 0x01000000 > /* We combine SSFS and SSFC to one 32-bit word, > * therefore SSFC bits are off by 8. > * The following bits are reserved in SSFC: 23-19,7,0. */ > @@ -709,8 +721,8 @@ static int ich9_run_opcode(OPCODE op, uint32_t offset, > temp32 = REGREAD32(ICH9_REG_SSFS); > /* Keep reserved bits only */ > temp32 &= SSFS_RESERVED_MASK | SSFC_RESERVED_MASK; > - /* clear error status registers */ > - temp32 |= (SSFS_CDS + SSFS_FCERR); > + /* Clear cycle done and cycle error status registers */ > + temp32 |= (SSFS_FDONE + SSFS_FCERR); > Odd. Did we really have + instead of | here? That looks wrong (yes, technically it is correct, but still, it suggests that the values are numeric instead of individual bits). Now that you're touching that code, could you fix it to use | instead? And please fix an earlier occurence of temp16 |= (SPIS_CDS + SPIS_FCERR) as well. Thanks! > REGWRITE32(ICH9_REG_SSFS, temp32); > > /* Use 20 MHz */ > @@ -720,7 +732,7 @@ static int ich9_run_opcode(OPCODE op, uint32_t offset, > if (datalength != 0) { > uint32_t datatemp; > temp32 |= SSFC_DS; > - datatemp = ((uint32_t) ((datalength - 1) & 0x3f)) << (8 + 8); > + datatemp = (uint32_t) (((datalength - 1) << SSFC_DBC_OFF) & SSFC_DBC); > Are you really 100% sure that integer promotion rules allow that? datalength is uint8_t, and shifting it directly by 8 bits or more may result in undefined behaviour. Need to check that with a C guru. > temp32 |= datatemp; > } > > Rest looks good. Once the _OFF stuff is decided and once we are 100% sure that the integer promotion rules are applied correctly, this is Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Regards, Carl-Daniel -- http://www.hailfinger.org/

2 2

Re: [flashrom] [PATCH 06/11] add missing ICH9 register macros and use them to eliminate magic numbers
by Carl-Daniel Hailfinger 29 May '11

29 May '11

Am 28.05.2011 05:38 schrieb Stefan Tauner: > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> > --- > ichspi.c | 63 ++++++++++++++++++++++++++++++++++++------------------------- > 1 files changed, 37 insertions(+), 26 deletions(-) > > diff --git a/ichspi.c b/ichspi.c > index dff6f32..584cab4 100644 > --- a/ichspi.c > +++ b/ichspi.c > @@ -77,6 +77,15 @@ > #define ICH9_REG_FADDR 0x08 /* 32 Bits */ > #define ICH9_REG_FDATA0 0x10 /* 64 Bytes */ > > +#define ICH9_REG_FRAP 0x50 /* 32 Bytes Flash Region Access Permissions */ > +#define ICH9_REG_FREG0 0x54 /* 32 Bytes Flash Region 0 */ > + > +#define ICH9_REG_PR0 0x74 /* 32 Bytes Protected Range 0 */ > +#define ICH9_REG_PR1 0x78 /* 32 Bytes Protected Range 1 */ > +#define ICH9_REG_PR2 0x7c /* 32 Bytes Protected Range 2 */ > +#define ICH9_REG_PR3 0x80 /* 32 Bytes Protected Range 3 */ > +#define ICH9_REG_PR4 0x84 /* 32 Bytes Protected Range 4 */ > + > #define ICH9_REG_SSFS 0x90 /* 08 Bits */ > #define SSFS_SCIP_OFF 0 /* SPI Cycle In Progress */ > #define SSFS_SCIP (0x1 << SSFS_SCIP_OFF) > @@ -117,6 +126,9 @@ > #define ICH9_REG_OPTYPE 0x96 /* 16 Bits */ > #define ICH9_REG_OPMENU 0x98 /* 64 Bits */ > > +#define ICH9_REG_BBAR 0xA0 /* 32 Bits BIOS Base Address Configuration */ > +#define BBAR_MASK 0x00ffff00 /* 8-23: Bottom of System Flash */ > + > // ICH9R SPI commands > #define SPI_OPCODE_TYPE_READ_NO_ADDRESS 0 > #define SPI_OPCODE_TYPE_WRITE_NO_ADDRESS 1 > @@ -537,15 +549,15 @@ static int program_opcodes(OPCODES *op, int enable_undo) > */ > void ich_set_bbar(uint32_t minaddr) > { > -#define BBAR_MASK 0x00ffff00 > minaddr &= BBAR_MASK; > switch (spi_programmer->type) { > case SPI_CONTROLLER_ICH7: > case SPI_CONTROLLER_VIA: > ichspi_bbar = mmio_readl(ich_spibar + 0x50) & ~BBAR_MASK; > - if (ichspi_bbar) > + if (ichspi_bbar) { > msg_pdbg("Reserved bits in BBAR not zero: 0x%04x", > ichspi_bbar); > + } > Was that hunk intentional? We usually avoid {} for single-command if blocks. > ichspi_bbar |= minaddr; > rmmio_writel(ichspi_bbar, ich_spibar + 0x50); > ichspi_bbar = mmio_readl(ich_spibar + 0x50); > @@ -556,13 +568,14 @@ void ich_set_bbar(uint32_t minaddr) > msg_perr("Setting BBAR failed!\n"); > break; > case SPI_CONTROLLER_ICH9: > - ichspi_bbar = mmio_readl(ich_spibar + 0xA0) & ~BBAR_MASK; > - if (ichspi_bbar) > + ichspi_bbar = mmio_readl(ich_spibar + ICH9_REG_BBAR) & ~BBAR_MASK; > + if (ichspi_bbar) { > msg_pdbg("Reserved bits in BBAR not zero: 0x%04x", > ichspi_bbar); > + } > Same here. > ichspi_bbar |= minaddr; > - rmmio_writel(ichspi_bbar, ich_spibar + 0xA0); > - ichspi_bbar = mmio_readl(ich_spibar + 0xA0); > + rmmio_writel(ichspi_bbar, ich_spibar + ICH9_REG_BBAR); > + ichspi_bbar = mmio_readl(ich_spibar + ICH9_REG_BBAR); > /* We don't have any option except complaining. And if the write > * failed, the restore will fail as well, so no problem there. > */ > @@ -1138,7 +1151,7 @@ static void do_ich9_spi_frap(uint32_t frap, int i) > uint32_t base, limit; > int rwperms = (((ICH_BRWA(frap) >> i) & 1) << 1) | > (((ICH_BRRA(frap) >> i) & 1) << 0); > - int offset = 0x54 + i * 4; > + int offset = ICH9_REG_FREG0 + i * 4; > uint32_t freg = mmio_readl(ich_spibar + offset); > > msg_pdbg("0x%02X: 0x%08x (FREG%i: %s)\n", > @@ -1248,19 +1261,19 @@ int ich_init_spi(struct pci_dev *dev, uint32_t base, void *rcrb, > ich_init_opcodes(); > break; > case SPI_CONTROLLER_ICH9: > - tmp2 = mmio_readw(ich_spibar + 4); > + tmp2 = mmio_readw(ich_spibar + ICH9_REG_HSFS); > msg_pdbg("0x04: 0x%04x (HSFS)\n", tmp2); > prettyprint_ich9_reg_hsfs(tmp2); > - if (tmp2 & (1 << 15)) { > + if (tmp2 & HSFS_FLOCKDN) { > msg_pinfo("WARNING: SPI Configuration Lockdown activated.\n"); > ichspi_lock = 1; > } > > - tmp2 = mmio_readw(ich_spibar + 6); > + tmp2 = mmio_readw(ich_spibar + ICH9_REG_HSFC); > msg_pdbg("0x06: 0x%04x (HSFC)\n", tmp2); > prettyprint_ich9_reg_hsfc(tmp2); > > - tmp = mmio_readl(ich_spibar + 0x50); > + tmp = mmio_readl(ich_spibar + ICH9_REG_FRAP); > msg_pdbg("0x50: 0x%08x (FRAP)\n", tmp); > msg_pdbg("BMWAG 0x%02x, ", ICH_BMWAG(tmp)); > msg_pdbg("BMRAG 0x%02x, ", ICH_BMRAG(tmp)); > @@ -1272,39 +1285,37 @@ int ich_init_spi(struct pci_dev *dev, uint32_t base, void *rcrb, > do_ich9_spi_frap(tmp, i); > > msg_pdbg("0x74: 0x%08x (PR0)\n", > - mmio_readl(ich_spibar + 0x74)); > + mmio_readl(ich_spibar + ICH9_REG_PR0)); > msg_pdbg("0x78: 0x%08x (PR1)\n", > - mmio_readl(ich_spibar + 0x78)); > + mmio_readl(ich_spibar + ICH9_REG_PR1)); > msg_pdbg("0x7C: 0x%08x (PR2)\n", > - mmio_readl(ich_spibar + 0x7C)); > + mmio_readl(ich_spibar + ICH9_REG_PR2)); > msg_pdbg("0x80: 0x%08x (PR3)\n", > - mmio_readl(ich_spibar + 0x80)); > + mmio_readl(ich_spibar + ICH9_REG_PR3)); > msg_pdbg("0x84: 0x%08x (PR4)\n", > - mmio_readl(ich_spibar + 0x84)); > + mmio_readl(ich_spibar + ICH9_REG_PR4)); > > - tmp = mmio_readl(ich_spibar + 0x90); > + tmp = mmio_readl(ich_spibar + ICH9_REG_SSFS); > msg_pdbg("0x90: 0x%02x (SSFS)\n", tmp & 0xff); > prettyprint_ich9_reg_ssfs(tmp); > - if (tmp & (1 << 3)) { > + if (tmp & SSFS_FCERR) { > msg_pdbg("Clearing SSFS.FCERR\n"); > - mmio_writeb(1 << 3, ich_spibar + 0x90); > + mmio_writeb(SSFS_FCERR, ich_spibar + ICH9_REG_SSFS); > } > msg_pdbg("0x91: 0x%06x (SSFC)\n", tmp >> 8); > prettyprint_ich9_reg_ssfc(tmp); > > msg_pdbg("0x94: 0x%04x (PREOP)\n", > - mmio_readw(ich_spibar + 0x94)); > + mmio_readw(ich_spibar + ICH9_REG_PREOP)); > msg_pdbg("0x96: 0x%04x (OPTYPE)\n", > - mmio_readw(ich_spibar + 0x96)); > + mmio_readw(ich_spibar + ICH9_REG_OPTYPE)); > msg_pdbg("0x98: 0x%08x (OPMENU)\n", > - mmio_readl(ich_spibar + 0x98)); > + mmio_readl(ich_spibar + ICH9_REG_OPMENU)); > msg_pdbg("0x9C: 0x%08x (OPMENU+4)\n", > - mmio_readl(ich_spibar + 0x9C)); > - ichspi_bbar = mmio_readl(ich_spibar + 0xA0); > + mmio_readl(ich_spibar + ICH9_REG_OPMENU + 4)); > + ichspi_bbar = mmio_readl(ich_spibar + ICH9_REG_BBAR); > msg_pdbg("0xA0: 0x%08x (BBAR)\n", > ichspi_bbar); > - msg_pdbg("0xB0: 0x%08x (FDOC)\n", > - mmio_readl(ich_spibar + 0xB0)); > Why did FDOC disappear? > ich_init_opcodes(); > break; > default: > Regards, Carl-Daniel -- http://www.hailfinger.org/

2 1

← Newer
1
...
6
7
8
9
10
11
12
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom May 2011