Add support for ST M25P05-A, M25P10-A, M25P20, M25P40, M25P16, M25P32, M25P64, M25P128 to flashrom. ST M25P80 support is already there. Not tested, but conforming to data sheets. Pretty-print the chip status register (including block lock information) for ST M25P family chips on erase. Print the chip status register for all SPI chips on erase.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: flashrom-m25p/flash.h =================================================================== --- flashrom-m25p/flash.h (Revision 3009) +++ flashrom-m25p/flash.h (Arbeitskopie) @@ -172,7 +172,15 @@ * byte of device ID is related to log(bitsize) at least for some chips. */ #define ST_ID 0x20 /* ST */ +#define ST_M25P05A 0x2010 +#define ST_M25P10A 0x2011 +#define ST_M25P20 0x2012 +#define ST_M25P40 0x2013 #define ST_M25P80 0x2014 +#define ST_M25P16 0x2015 +#define ST_M25P32 0x2016 +#define ST_M25P64 0x2017 +#define ST_M25P128 0x2018 #define ST_M50FLW040A 0x08 #define ST_M50FLW040B 0x28 #define ST_M50FLW080A 0x80 Index: flashrom-m25p/flashchips.c =================================================================== --- flashrom-m25p/flashchips.c (Revision 3009) +++ flashrom-m25p/flashchips.c (Arbeitskopie) @@ -140,8 +140,24 @@ probe_jedec, erase_chip_jedec, write_jedec}, {"M29F040B", ST_ID, ST_M29F040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, + {"M25P05-A", ST_ID, ST_M25P05A, 64, 32 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P10-A", ST_ID, ST_M25P10A, 128, 32 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P20", ST_ID, ST_M25P20, 256, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P40", ST_ID, ST_M25P40, 512, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"M25P80", ST_ID, ST_M25P80, 1024, 64 * 1024, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P16", ST_ID, ST_M25P16, 2048, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P32", ST_ID, ST_M25P32, 4096, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P64", ST_ID, ST_M25P64, 8192, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P128", ST_ID, ST_M25P128, 16384, 256 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"82802ab", 137, 173, 512, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, {"82802ac", 137, 172, 1024, 64 * 1024, Index: flashrom-m25p/spi.c =================================================================== --- flashrom-m25p/spi.c (Revision 3009) +++ flashrom-m25p/spi.c (Arbeitskopie) @@ -277,14 +277,45 @@ return readarr[0]; }
+void generic_spi_prettyprint_status_register_st_m25p(uint8_t status) +{ + printf("Chip status register: Status Register Write Disable (SRWD) is " + "%sset\n", (status & (1 << 7)) ? "" : "not "); + printf("Chip status register: Block Protect 2 (BP2) is " + "%sset\n", (status & (1 << 4)) ? "" : "not "); + printf("Chip status register: Block Protect 1 (BP1) is " + "%sset\n", (status & (1 << 3)) ? "" : "not "); + printf("Chip status register: Block Protect 0 (BP0) is " + "%sset\n", (status & (1 << 2)) ? "" : "not "); + printf("Chip status register: Write Enable Latch (WEL) is " + "%sset\n", (status & (1 << 1)) ? "" : "not "); + printf("Chip status register: Write In Progress (WIP) is " + "%sset\n", (status & (1 << 7)) ? "" : "not "); +} + +void generic_spi_prettyprint_status_register(struct flashchip *flash) +{ + uint8_t status; + + status = generic_spi_read_status_register(); + printf("Chip status register is %02x\n", status); + switch (flash->manufacture_id) { + case ST_ID: + if ((flash->model_id & 0xff00) == 0x2000) + generic_spi_prettyprint_status_register_st_m25p(status); + break; + } +} + int generic_spi_chip_erase_c7(struct flashchip *flash) { const unsigned char cmd[] = JEDEC_CE_C7; - uint8_t statusreg; + + /* Print the status register before erase to tell the user about + * possible write protection. + */ + generic_spi_prettyprint_status_register(flash);
- statusreg = generic_spi_read_status_register(); - printf("chip status register before erase is %02x\n", statusreg); - generic_spi_write_enable(); /* Send CE (Chip Erase) */ generic_spi_command(JEDEC_CE_C7_OUTSIZE, JEDEC_CE_C7_INSIZE, cmd, NULL);
Add support for ST M25P05-A, M25P10-A, M25P20, M25P40, M25P16, M25P32, M25P64, M25P128 to flashrom. ST M25P80 support is already there. Not tested, but conforming to data sheets and double checked.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: flashrom-m25p/flash.h =================================================================== --- flashrom-m25p/flash.h (Revision 3009) +++ flashrom-m25p/flash.h (Arbeitskopie) @@ -172,7 +172,15 @@ * byte of device ID is related to log(bitsize) at least for some chips. */ #define ST_ID 0x20 /* ST */ +#define ST_M25P05A 0x2010 +#define ST_M25P10A 0x2011 +#define ST_M25P20 0x2012 +#define ST_M25P40 0x2013 #define ST_M25P80 0x2014 +#define ST_M25P16 0x2015 +#define ST_M25P32 0x2016 +#define ST_M25P64 0x2017 +#define ST_M25P128 0x2018 #define ST_M50FLW040A 0x08 #define ST_M50FLW040B 0x28 #define ST_M50FLW080A 0x80 Index: flashrom-m25p/flashchips.c =================================================================== --- flashrom-m25p/flashchips.c (Revision 3009) +++ flashrom-m25p/flashchips.c (Arbeitskopie) @@ -140,8 +140,24 @@ probe_jedec, erase_chip_jedec, write_jedec}, {"M29F040B", ST_ID, ST_M29F040B, 512, 64 * 1024, probe_29f040b, erase_29f040b, write_29f040b}, + {"M25P05-A", ST_ID, ST_M25P05A, 64, 32 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P10-A", ST_ID, ST_M25P10A, 128, 32 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P20", ST_ID, ST_M25P20, 256, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P40", ST_ID, ST_M25P40, 512, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"M25P80", ST_ID, ST_M25P80, 1024, 64 * 1024, probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P16", ST_ID, ST_M25P16, 2048, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P32", ST_ID, ST_M25P32, 4096, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P64", ST_ID, ST_M25P64, 8192, 64 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, + {"M25P128", ST_ID, ST_M25P128, 16384, 256 * 1024, + probe_spi, generic_spi_chip_erase_c7, generic_spi_chip_write}, {"82802ab", 137, 173, 512, 64 * 1024, probe_82802ab, erase_82802ab, write_82802ab}, {"82802ac", 137, 172, 1024, 64 * 1024,
On Mon, Dec 17, 2007 at 09:26:31PM +0100, Carl-Daniel Hailfinger wrote:
Add support for ST M25P05-A, M25P10-A, M25P20, M25P40, M25P16, M25P32, M25P64, M25P128 to flashrom. ST M25P80 support is already there. Not tested, but conforming to data sheets and double checked.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Acked-by: Uwe Hermann uwe@hermann-uwe.de
Uwe.
On 17.12.2007 23:19, Uwe Hermann wrote:
On Mon, Dec 17, 2007 at 09:26:31PM +0100, Carl-Daniel Hailfinger wrote:
Add support for ST M25P05-A, M25P10-A, M25P20, M25P40, M25P16, M25P32, M25P64, M25P128 to flashrom. ST M25P80 support is already there. Not tested, but conforming to data sheets and double checked.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Acked-by: Uwe Hermann uwe@hermann-uwe.de
Thanks, r3012.
Regards, Carl-Daniel
Print the chip status register for all SPI chips on probe if verbose output is specified. Pretty-print the chip status register (including block lock information) for ST M25P family and Macronix MX25L family chips.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: flashrom-prettyprint/spi.c =================================================================== --- flashrom-prettyprint/spi.c (Revision 3009) +++ flashrom-prettyprint/spi.c (Arbeitskopie) @@ -78,6 +78,8 @@
uint16_t it8716f_flashport = 0;
+void generic_spi_prettyprint_status_register(struct flashchip *flash); + /* Generic Super I/O helper functions */ uint8_t regval(uint16_t port, uint8_t reg) { @@ -220,7 +222,7 @@ { if (it8716f_flashport) return it8716f_spi_command(it8716f_flashport, writecnt, readcnt, writearr, readarr); - printf("%s called, but no SPI chipset detected\n", __FUNCTION__); + printf_debug("%s called, but no SPI chipset detected\n", __FUNCTION__); return 1; }
@@ -230,7 +232,7 @@
if (generic_spi_command(JEDEC_RDID_OUTSIZE, JEDEC_RDID_INSIZE, cmd, readarr)) return 1; - printf("RDID returned %02x %02x %02x.\n", readarr[0], readarr[1], readarr[2]); + printf_debug("RDID returned %02x %02x %02x.\n", readarr[0], readarr[1], readarr[2]); return 0; }
@@ -260,8 +262,14 @@ manuf_id = readarr[0]; model_id = (readarr[1] << 8) | readarr[2]; printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); - if (manuf_id == flash->manufacture_id && model_id == flash->model_id) + if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { + /* Print the status register before erase to tell the + * user about possible write protection. + */ + generic_spi_prettyprint_status_register(flash); + return 1; + } }
return 0; @@ -277,13 +285,48 @@ return readarr[0]; }
+/* Prettyprint the status register. Works for + * ST M25P series + * MX MX25L series + */ +void generic_spi_prettyprint_status_register_st_m25p(uint8_t status) +{ + printf_debug("Chip status register: Status Register Write Disable " + "(SRWD) is %sset\n", (status & (1 << 7)) ? "" : "not "); + printf_debug("Chip status register: Bit 6 is " + "%sset\n", (status & (1 << 6)) ? "" : "not "); + printf_debug("Chip status register: Bit 5 is " + "%sset\n", (status & (1 << 5)) ? "" : "not "); + printf_debug("Chip status register: Block Protect 2 (BP2) is " + "%sset\n", (status & (1 << 4)) ? "" : "not "); + printf_debug("Chip status register: Block Protect 1 (BP1) is " + "%sset\n", (status & (1 << 3)) ? "" : "not "); + printf_debug("Chip status register: Block Protect 0 (BP0) is " + "%sset\n", (status & (1 << 2)) ? "" : "not "); + printf_debug("Chip status register: Write Enable Latch (WEL) is " + "%sset\n", (status & (1 << 1)) ? "" : "not "); + printf_debug("Chip status register: Write In Progress (WIP) is " + "%sset\n", (status & (1 << 0)) ? "" : "not "); +} + +void generic_spi_prettyprint_status_register(struct flashchip *flash) +{ + uint8_t status; + + status = generic_spi_read_status_register(); + printf_debug("Chip status register is %02x\n", status); + switch (flash->manufacture_id) { + case ST_ID: + case MX_ID: + if ((flash->model_id & 0xff00) == 0x2000) + generic_spi_prettyprint_status_register_st_m25p(status); + break; + } +} + int generic_spi_chip_erase_c7(struct flashchip *flash) { const unsigned char cmd[] = JEDEC_CE_C7; - uint8_t statusreg; - - statusreg = generic_spi_read_status_register(); - printf("chip status register before erase is %02x\n", statusreg); generic_spi_write_enable(); /* Send CE (Chip Erase) */
On 17.12.2007 21:33, Carl-Daniel Hailfinger wrote:
Print the chip status register for all SPI chips on probe if verbose output is specified. Pretty-print the chip status register (including block lock information) for ST M25P family and Macronix MX25L family chips.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Anyone able to review?
Regards, Carl-Daniel
Looks good here:
Acked-by: Corey Osgood corey.osgood@gmail.com
On Dec 28, 2007 7:30 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 17.12.2007 21:33, Carl-Daniel Hailfinger wrote:
Print the chip status register for all SPI chips on probe if verbose output is specified. Pretty-print the chip status register (including block lock information) for ST M25P family and Macronix MX25L family chips.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
Anyone able to review?
Regards, Carl-Daniel
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On 29.12.2007 06:23, Corey Osgood wrote:
Looks good here:
Acked-by: Corey Osgood corey.osgood@gmail.com
On Dec 28, 2007 7:30 AM, Carl-Daniel Hailfinger wrote:
On 17.12.2007 21:33, Carl-Daniel Hailfinger wrote:
Print the chip status register for all SPI chips on probe if verbose output is specified. Pretty-print the chip status register (including block lock information) for ST M25P family and Macronix MX25L family chips.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
Anyone able to review?
Thanks, r3026.
Regards, Carl-Daniel
Hi all,
I started working on this problem this week and there are some strange things I have found so far. First, the behaviour I noticed when starting flashrom after booting whith LB : 1) flashrom needs to be given the board type in command line parameter (-m gigabyte:m57sli) otherwise it is unable to recognize this board. On the other hand it seems to correctly recognize the SB type (mcp55) and the SIO too (it8716). It seems that it succeeds in reading and writting the configuration registers of the SIO (those accesible through the 0x2e - 0x2f pair of IO ports) at least.. 2) the real problem is that it hangs when trying to access the SPI interface of the SIO, more precisely when pooling the "busy flag" of the configuration register of the SPI interface before sending a SPI command, normally mapped at the 0x820 IO address. Indeed when dumping the value which is read @ this address, one get a value 0xff! It doesn't seem to me that this register should have normally this value, there seem to be a problem with the decoding of this IO address range into the mcp55 SB very probably.. 3) the most strange thing is that when probing with an oscilloscope the SPI signals, there _IS_ indeed a burst of activity on the CLK line when executing flashrom. Some code into flashrom seems to generate this activity, but I haven't found so far where it is triggerd. But from the flashrom point of view there is no reponse from the spi interface so it hangs..
Rudolf Marek suggested after an irc discussion that there could be problems with the GPIO configuration, but I don't think so, because if that would be the case then we couldn't access the SIO at all and the platform wouldn't boot at all with LB. But who knows? Rudolf, can you be more specific about this GPIO hypothesis?.. For my part I continue to think that there is a problem with the IO address decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help please?
Regards, Florentin
On 10.01.2008 12:14, Florentin Demetrescu wrote:
Hi all,
I started working on this problem this week and there are some strange things I have found so far.
Thanks for trying to figure this out!
First, the behaviour I noticed when starting flashrom after booting whith LB :
- flashrom needs to be given the board type in command line parameter (-m
gigabyte:m57sli) otherwise it is unable to recognize this board. On the other hand it seems to correctly recognize the SB type (mcp55) and the SIO too (it8716). It seems that it succeeds in reading and writting the configuration registers of the SIO (those accesible through the 0x2e - 0x2f pair of IO ports) at least..
It seems the board identifiers used inside LB and inside flashrom differ.
- the real problem is that it hangs when trying to access the SPI interface of
the SIO, more precisely when pooling the "busy flag" of the configuration register of the SPI interface before sending a SPI command, normally mapped at the 0x820 IO address. Indeed when dumping the value which is read @ this address, one get a value 0xff! It doesn't seem to me that this register should have normally this value, there seem to be a problem with the decoding of this IO address range into the mcp55 SB very probably..
Yes indeed.
- the most strange thing is that when probing with an oscilloscope the SPI
signals, there _IS_ indeed a burst of activity on the CLK line when executing flashrom. Some code into flashrom seems to generate this activity, but I haven't
That's the classic parallel flash probing which reads from and writes to the memory area of the chip.
found so far where it is triggerd. But from the flashrom point of view there is no reponse from the spi interface so it hangs..
Yes, that's the SPI probing which waits on the status register as you said.
Rudolf Marek suggested after an irc discussion that there could be problems with the GPIO configuration, but I don't think so, because if that would be the case then we couldn't access the SIO at all and the platform wouldn't boot at all with LB. But who knows? Rudolf, can you be more specific about this GPIO hypothesis?.. For my part I continue to think that there is a problem with the IO address decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help please?
Yinghai? Is there some mcp55 conf we need to change?
Regards, Carl-Daniel
On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 10.01.2008 12:14, Florentin Demetrescu wrote:
Hi all, For my part I continue to think that there is a problem with the IO address decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help please?
Yinghai? Is there some mcp55 conf we need to change?
that range is already decoded to LPC bridge ( enable_rom, or cache_as_rom_auto, or mcp55_lpc.c)
YH
Okay I will check this with my oscilloscope.. The most difficult would be to identify the LPC signals on the IT8716 chip, given that the package really installed onto the board doesn't match the publically available datasheet.. But with some effort this can be done.. I hope to be able to give some result after this WE.. Florentin
Quoting yhlu yinghailu@gmail.com:
On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 10.01.2008 12:14, Florentin Demetrescu wrote:
Hi all, For my part I continue to think that there is a problem with the IO
address
decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help
please?
Yinghai? Is there some mcp55 conf we need to change?
that range is already decoded to LPC bridge ( enable_rom, or cache_as_rom_auto, or mcp55_lpc.c)
YH
Hi,
I think we are close to fix the pb. of the flashrom under LB on the m57sli mobo
There was indeed a problem with the IO address decoding into the PCI->LPC bridge..
Facts: 1) after booting with LB : when reading @ the IO address 0x820 (where the SPI IF of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c after booting with the factory bios) 2) when probing the LPC bus with an oscilloscope, one can notice that a IO read @ 0x820 produces: - under factory bios : a corect IO read cycle as expected with the address 0x820 and the SIO answers with the correct value; - under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is what is seen on the bus (I tested many times..), even if the software operation really was a IO read; 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds the value: - 0xc1100001 under factory bios; - 0x30000001 under LB; 4) the IO range 0x0800->0x085f can be seen with the factory bios into the pci register 0xb4 of the same pci device; it don't appear with the actual version of LB 5) after booting with LB, and forcing the following registers of the lpc bridge with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming)
So a workaround is now possible as suggested in point (5).
For a full coreboot patch, unfortunatelly I don't master the software architecture of coreboot enough to make a proposal.. Can someone help please?
I would like to thank Yinghai for his advice (-> mcp55_lpc.c where I found the very interesting procedure "mcp55_lpc_enable_childrens_resources") which permited me to do this work..
Florentin
Quoting yhlu yinghailu@gmail.com:
On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 10.01.2008 12:14, Florentin Demetrescu wrote:
Hi all, For my part I continue to think that there is a problem with the IO
address
decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help
please?
Yinghai? Is there some mcp55 conf we need to change?
that range is already decoded to LPC bridge ( enable_rom, or cache_as_rom_auto, or mcp55_lpc.c)
YH
By the way the LPC interface of the IT8716 version used by this mobo is not as described into the DS. The LPC pads are as follows: - LCLK (PCICLK?) : 78 - nLFRAME : 71 - nLRST : 68 - SERIRQ : 70 - LAD[0] : 72 - LAD[1] : 73 - LAD[2] : 74 - LAD[3] : 75 Lastly on can use the unpopulated TPM connector to solder a sniffer on the LPC bus (where we see that at least sometimes the Trusted Computing can be usefull at something.. ;-))
Quoting Florentin Demetrescu echelon@free.fr:
Hi,
I think we are close to fix the pb. of the flashrom under LB on the m57sli mobo
There was indeed a problem with the IO address decoding into the PCI->LPC bridge..
Facts:
- after booting with LB : when reading @ the IO address 0x820 (where the SPI
IF of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c after booting with the factory bios) 2) when probing the LPC bus with an oscilloscope, one can notice that a IO read @ 0x820 produces:
- under factory bios : a corect IO read cycle as expected with the address
0x820 and the SIO answers with the correct value;
- under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is
what is seen on the bus (I tested many times..), even if the software operation really was a IO read; 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds the value:
- 0xc1100001 under factory bios;
- 0x30000001 under LB;
- the IO range 0x0800->0x085f can be seen with the factory bios into the pci
register 0xb4 of the same pci device; it don't appear with the actual version of LB 5) after booting with LB, and forcing the following registers of the lpc bridge with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming)
So a workaround is now possible as suggested in point (5).
For a full coreboot patch, unfortunatelly I don't master the software architecture of coreboot enough to make a proposal.. Can someone help please?
I would like to thank Yinghai for his advice (-> mcp55_lpc.c where I found the very interesting procedure "mcp55_lpc_enable_childrens_resources") which permited me to do this work..
Florentin
Quoting yhlu yinghailu@gmail.com:
On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 10.01.2008 12:14, Florentin Demetrescu wrote:
Hi all, For my part I continue to think that there is a problem with the IO
address
decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help
please?
Yinghai? Is there some mcp55 conf we need to change?
that range is already decoded to LPC bridge ( enable_rom, or cache_as_rom_auto, or mcp55_lpc.c)
YH
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi Florentin,
you did a great job debugging this. Congratulations!
On 13.01.2008 23:32, Florentin Demetrescu wrote:
I think we are close to fix the pb. of the flashrom under LB on the m57sli mobo
There was indeed a problem with the IO address decoding into the PCI->LPC bridge..
Facts:
- after booting with LB : when reading @ the IO address 0x820 (where the SPI IF
of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c after booting with the factory bios) 2) when probing the LPC bus with an oscilloscope, one can notice that a IO read @ 0x820 produces:
- under factory bios : a corect IO read cycle as expected with the address
0x820 and the SIO answers with the correct value;
- under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is what
is seen on the bus (I tested many times..), even if the software operation really was a IO read; 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds the value:
- 0xc1100001 under factory bios;
- 0x30000001 under LB;
- the IO range 0x0800->0x085f can be seen with the factory bios into the pci
register 0xb4 of the same pci device; it don't appear with the actual version of LB 5) after booting with LB, and forcing the following registers of the lpc bridge with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming)
So a workaround is now possible as suggested in point (5).
For a full coreboot patch, unfortunatelly I don't master the software architecture of coreboot enough to make a proposal.. Can someone help please?
I would like to thank Yinghai for his advice (-> mcp55_lpc.c where I found the very interesting procedure "mcp55_lpc_enable_childrens_resources") which permited me to do this work..
Regards, Carl-Daniel
Some additional details:
1) the "setpci" workaround is fully functional => it enables a successful reprogramming of flash chip with flashrom after booting with coreboot. 2) about the pci register 0xa0 of the lpc bridge (which seems to me to be a sort of "enable child device register" inside the lpc bridge) : it seems than only the bit 30 needs to be set (mask 0x40000000) to activate the spi if. 3) moreover the io address range for the spi if. (0x0800->0x085f) needs to be put into the 0xb0 register and do not work when put in the 0xac register! Btw coreboot seems to program the 0xac register with the value 0x07ff0800 which makes little sense since it corresponds to an "inverted" io range (0x0800->0x07ff) if I follow the logic of the "mcp55_lpc_enable_childrens_resources()" procedure..
Voila.. This is what I found so far.. I will be back soon with a patch proposal..
Florentin
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
Hi Florentin,
you did a great job debugging this. Congratulations!
On 13.01.2008 23:32, Florentin Demetrescu wrote:
I think we are close to fix the pb. of the flashrom under LB on the m57sli
mobo
There was indeed a problem with the IO address decoding into the PCI->LPC bridge..
Facts:
- after booting with LB : when reading @ the IO address 0x820 (where the
SPI IF
of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c
after
booting with the factory bios) 2) when probing the LPC bus with an oscilloscope, one can notice that a IO
read
@ 0x820 produces:
- under factory bios : a corect IO read cycle as expected with the address
0x820 and the SIO answers with the correct value;
- under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is
what
is seen on the bus (I tested many times..), even if the software operation really was a IO read; 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds
the
value:
- 0xc1100001 under factory bios;
- 0x30000001 under LB;
- the IO range 0x0800->0x085f can be seen with the factory bios into the
pci
register 0xb4 of the same pci device; it don't appear with the actual
version of
LB 5) after booting with LB, and forcing the following registers of the lpc
bridge
with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming)
So a workaround is now possible as suggested in point (5).
For a full coreboot patch, unfortunatelly I don't master the software architecture of coreboot enough to make a proposal.. Can someone help
please?
I would like to thank Yinghai for his advice (-> mcp55_lpc.c where I found
the
very interesting procedure "mcp55_lpc_enable_childrens_resources") which permited me to do this work..
Regards, Carl-Daniel
OK, this is an important point for v2. The right way to do this is to add these variables to the mcp55 chip.h: add the lines u32 a0, a4, a8, ac, b0, b4;
Then, in the Config.lb for the mainboard, you do something like this in the section for the southbridge:
register "a0" = "c1100001" register "a4" = "0" register "a8" = "0" register "ac" = "0" register "b0" = "02f40295" register "b4" = "085f0800"
Then you add code to the mcp55 support to check these options and set them.
If you have better names in mind go for it :-)
It should look something like this, let me know if I missed something or this makes no sense.
The existing use of register in mainboard/gigabyte/m57sli for the ide0_enable etc. can be used as a model.
thanks
ron
ron minnich wrote:
OK, this is an important point for v2. The right way to do this is to add these variables to the mcp55 chip.h: add the lines u32 a0, a4, a8, ac, b0, b4;
Then, in the Config.lb for the mainboard, you do something like this in the section for the southbridge:
register "a0" = "c1100001" register "a4" = "0" register "a8" = "0" register "ac" = "0" register "b0" = "02f40295" register "b4" = "085f0800"
Is this something the user is supposed to understand? Are these properties of the device tree?
What do those values mean? GPIOs?
How will we do this in v3? Something like
gpio { num=32, direction=output, value=1 } # Disable write protection
On Jan 15, 2008 2:12 PM, Stefan Reinauer stepan@coresystems.de wrote:
Is this something the user is supposed to understand? Are these properties of the device tree?
What do those values mean? GPIOs?
How will we do this in v3? Something like
gpio { num=32, direction=output, value=1 } # Disable write protection
yes, I think in v3 this sort of thing goes in the dts.
ron
On Tue, Jan 15, 2008 at 11:12:01PM +0100, Stefan Reinauer wrote:
register "a0" = "c1100001" register "a4" = "0" register "a8" = "0" register "ac" = "0" register "b0" = "02f40295" register "b4" = "085f0800"
Is this something the user is supposed to understand?
I say no.
Are these properties of the device tree?
No need I think.
What do those values mean? GPIOs?
This is the key question.
How will we do this in v3? Something like
gpio { num=32, direction=output, value=1 } # Disable write protection
If the values control something that _could_ be used differently, ie. not for the SPI flash interface like on m57sli, it should indeed be parameterized in the dts.
But if it's static configuration that won't change across different boards then I think it belongs in the code.
gpio direction would only make sense if we also allowed implementatino of logic between pins. I don't want to go that far, I hope we don't have to.
I think for v3 we'll have to look at more boards in order to find the best abstraction. This is really virgin territory.
//Peter
Hello,
I propose this patch :
Index: LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/mcp55_lpc.c =================================================================== --- LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/mcp55_lpc.c (revision 3050) +++ LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/mcp55_lpc.c (working copy) @@ -161,11 +161,15 @@
static void lpc_init(device_t dev) { + struct southbridge_nvidia_mcp55_config *conf; + uint32_t dword; uint8_t byte; uint8_t byte_old; int on; int nmi_option;
+ conf = dev->chip_info; + lpc_common_init(dev);
#if 0 @@ -238,6 +242,18 @@ /* Initialize the High Precision Event Timers */ // enable_hpet(dev);
+ /* Enables the decoding of the IO addresses to the flash SPI interface + (if present into the SIO) */ + if (conf->spi_sio_enable) { + dword = pci_read_config32(dev, 0xa0); + dword |= (1<<30); + pci_write_config32(dev, 0xa0, dword); + + /* FIXME : really dirty! It seems that the IO addr range for the SPI IF. + HAS to be set into the 0xb0 or 0xb4 reg which conflicts strongly with + mcp55_lpc_enable_childrens_resources() */ + pci_write_config32(dev, conf->spi_sio_pcireg, conf->spi_sio_iorange); + } }
static void mcp55_lpc_read_resources(device_t dev) Index: LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/chip.h =================================================================== --- LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/chip.h (revision 3050) +++ LinuxBIOSv2_spi_debug/src/southbridge/nvidia/mcp55/chip.h (working copy) @@ -28,8 +28,11 @@ unsigned int ide1_enable : 1; unsigned int sata0_enable : 1; unsigned int sata1_enable : 1; + unsigned int spi_sio_enable : 1; unsigned int mac_eeprom_smbus; unsigned int mac_eeprom_addr; + unsigned int spi_sio_pcireg; + unsigned int spi_sio_iorange; }; struct chip_operations; extern struct chip_operations southbridge_nvidia_mcp55_ops; Index: LinuxBIOSv2_spi_debug/src/mainboard/gigabyte/m57sli/Config.lb =================================================================== --- LinuxBIOSv2_spi_debug/src/mainboard/gigabyte/m57sli/Config.lb (revision 3050) +++ LinuxBIOSv2_spi_debug/src/mainboard/gigabyte/m57sli/Config.lb (working copy) @@ -403,6 +403,9 @@ register "sata1_enable" = "1" register "mac_eeprom_smbus" = "3" # 1: smbus under 2e.8, 2: SM0 3: SM1 register "mac_eeprom_addr" = "0x51" + register "spi_sio_enable" = "1" + register "spi_sio_pcireg" = "0xb0" + register "spi_sio_iorange" = "0x085f0800" end end # device pci 18.0 device pci 18.0 on end # Link 1
Btw is this related to the issue #87 in Issuetracker? (should a new ticket be created especially for this issue?)
Thanks a lot for the help in resolving this issue to all the coreboot team! Florentin
Hi Florentin,
On Wed, Jan 16, 2008 at 04:28:15PM +0100, Florentin Demetrescu wrote:
Btw is this related to the issue #87 in Issuetracker? (should a new ticket be created especially for this issue?)
This is the SPI part of issue #87. For v1(.1) of the board with parallel flash, the problem was resolved in r2955 by Carl-Daniel.
Thanks! Ward.
On Jan 13, 2008 2:32 PM, Florentin Demetrescu echelon@free.fr wrote:
- after booting with LB, and forcing the following registers of the lpc bridge
with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming)
Do you think these values would be the same for all mainboards using this part? That answer will determine how we incorporate this fix.
thanks
ron
On Tuesday 15 January 2008, ron minnich wrote:
On Jan 13, 2008 2:32 PM, Florentin Demetrescu echelon@free.fr wrote:
- after booting with LB, and forcing the following registers of the lpc
bridge with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios)
On my v1.0, booted with legacy bios, these values are exactly the same.
Torsten
Quoting ron minnich rminnich@gmail.com:
On Jan 13, 2008 2:32 PM, Florentin Demetrescu echelon@free.fr wrote:
- after booting with LB, and forcing the following registers of the lpc
bridge
with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming)
Do you think these values would be the same for all mainboards using this part? That answer will determine how we incorporate this fix.
No. On my main computer which uses a mcp55 SB too, these values are definately not the same.. These are board specific values and, as Yinghai suggests in a later post, they should be fixed in the m57sli specific files (on the other hand I agree with Torsten that there are no differences btw the v1.0 & v2.0 versions of the boards regarding these values)
Hi Florentin,
Sorry for jumping into this thread so late! I finally modded one of our m57sli v2 boards today, so now I'm running into the flashrom-under-coreboot problem you've been working so hard on debugging!
On Tue, Jan 15, 2008 at 11:01:12AM +0100, Florentin Demetrescu wrote:
setpci -s 00:01.0 a0.l=c1100001
On one of our other boards with the proprietary bios, this value reads
c0300001
setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios)
All these values match.
Thanks, Ward.
On Jan 13, 2008 2:32 PM, Florentin Demetrescu echelon@free.fr wrote:
Hi,
I think we are close to fix the pb. of the flashrom under LB on the m57sli mobo
There was indeed a problem with the IO address decoding into the PCI->LPC bridge..
Facts:
- after booting with LB : when reading @ the IO address 0x820 (where the SPI IF
of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c after booting with the factory bios) 2) when probing the LPC bus with an oscilloscope, one can notice that a IO read @ 0x820 produces:
- under factory bios : a corect IO read cycle as expected with the address
0x820 and the SIO answers with the correct value;
- under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is what
is seen on the bus (I tested many times..), even if the software operation really was a IO read; 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds the value:
- 0xc1100001 under factory bios;
- 0x30000001 under LB;
- the IO range 0x0800->0x085f can be seen with the factory bios into the pci
register 0xb4 of the same pci device; it don't appear with the actual version of LB 5) after booting with LB, and forcing the following registers of the lpc bridge with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming)
So a workaround is now possible as suggested in point (5).
For a full coreboot patch, unfortunatelly I don't master the software architecture of coreboot enough to make a proposal.. Can someone help please?
Good.
we need to update superio it8715 code to make the spi? to get assigned resource in MB Config.lb
then mcp55_lpc.c will enable that automatically.
Or you can do sth in cache_as_ram_auto.c sio_setup().. this one could be easier
YH
Quoting yhlu yinghailu@gmail.com:
On Jan 13, 2008 2:32 PM, Florentin Demetrescu echelon@free.fr wrote:
Hi,
I think we are close to fix the pb. of the flashrom under LB on the m57sli
mobo
There was indeed a problem with the IO address decoding into the PCI->LPC bridge..
Facts:
- after booting with LB : when reading @ the IO address 0x820 (where the
SPI IF
of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c
after
booting with the factory bios) 2) when probing the LPC bus with an oscilloscope, one can notice that a IO
read
@ 0x820 produces:
- under factory bios : a corect IO read cycle as expected with the address
0x820 and the SIO answers with the correct value;
- under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is
what
is seen on the bus (I tested many times..), even if the software operation really was a IO read; 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds
the
value:
- 0xc1100001 under factory bios;
- 0x30000001 under LB;
- the IO range 0x0800->0x085f can be seen with the factory bios into the
pci
register 0xb4 of the same pci device; it don't appear with the actual
version of
LB 5) after booting with LB, and forcing the following registers of the lpc
bridge
with the following comands: setpci -s 00:01.0 a0.l=c1100001 setpci -s 00:01.0 a4.l=0 setpci -s 00:01.0 a8.l=0 setpci -s 00:01.0 ac.l=0 setpci -s 00:01.0 b0.l=02f40295 setpci -s 00:01.0 b4.l=085f0800 (force them at same values as in proprietary bios) the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly identifies the flash chip (I haven't tested yet a full flash programming)
So a workaround is now possible as suggested in point (5).
For a full coreboot patch, unfortunatelly I don't master the software architecture of coreboot enough to make a proposal.. Can someone help
please?
Good.
we need to update superio it8715 code to make the spi? to get assigned resource in MB Config.lb
then mcp55_lpc.c will enable that automatically.
Or you can do sth in cache_as_ram_auto.c sio_setup().. this one could be easier
YH
Ok, I will do some tests this evening.. (As a side note, I don't know how to hack Config.lb very well yet .. maybe someone will be able to give me some advice on irc, this evening ..)
Thank you for help anyway, Yinghai
Florentin
-
Carl-Daniel Hailfinger -
Corey Osgood -
Florentin Demetrescu -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Torsten Duwe -
Uwe Hermann -
Ward Vandewege -
yhlu