Re: [U-Boot] mtd: cfi: Add support for status register polling
On 09/12/2017 10:09 AM, Marek Vasut wrote: > The status register is optional in the AMD command sets, but it's > presence can be checked by reading out CFI table entry 0xc bit 0. > If the register is present, prefer using it's bit 7 to determine > if the flash is busy over reading the flash ; this is needed ie. > on Hyperflash memories. > > Signed-off-by: Marek Vasut > --- Marek, Some of our boards failed. I traced to this commit. Reverting this commit fixes the issue. I happen to have two boards with slightly different flash chip. One works and the other doesn't. The working board has => fli Bank # 1: CFI conformant flash (16 x 16) Size: 128 MB in 1024 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2801 Erase timeout: 2048 ms, write timeout: 1 ms Buffer write timeout: 3 ms, buffer size: 512 bytes The failing board has => fli Bank # 1: CFI conformant flash (16 x 16) Size: 128 MB in 1024 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2801 Erase timeout: 4096 ms, write timeout: 1 ms Buffer write timeout: 3 ms, buffer size: 64 bytes Can you investigate? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: cfi: Add support for status register polling
On 11/17/2017 05:43 PM, York Sun wrote: > On 09/12/2017 10:09 AM, Marek Vasut wrote: >> The status register is optional in the AMD command sets, but it's >> presence can be checked by reading out CFI table entry 0xc bit 0. >> If the register is present, prefer using it's bit 7 to determine >> if the flash is busy over reading the flash ; this is needed ie. >> on Hyperflash memories. >> >> Signed-off-by: Marek Vasut >> --- > > Marek, > > Some of our boards failed. I traced to this commit. Reverting this > commit fixes the issue. I happen to have two boards with slightly > different flash chip. One works and the other doesn't. I can't since I don't have the board with such a chip ... Which chip is that ? Mine is Spansion S25KL256 hyperflash. > The working board has > > => fli > > Bank # 1: CFI conformant flash (16 x 16) Size: 128 MB in 1024 Sectors > AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2801 > Erase timeout: 2048 ms, write timeout: 1 ms > Buffer write timeout: 3 ms, buffer size: 512 bytes > > The failing board has > > => fli > > Bank # 1: CFI conformant flash (16 x 16) Size: 128 MB in 1024 Sectors > AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2801 > Erase timeout: 4096 ms, write timeout: 1 ms > Buffer write timeout: 3 ms, buffer size: 64 bytes > > Can you investigate? > > York > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: cfi: Add support for status register polling
On 11/17/2017 08:02 PM, Marek Vasut wrote: > On 11/17/2017 05:43 PM, York Sun wrote: >> On 09/12/2017 10:09 AM, Marek Vasut wrote: >>> The status register is optional in the AMD command sets, but it's >>> presence can be checked by reading out CFI table entry 0xc bit 0. >>> If the register is present, prefer using it's bit 7 to determine >>> if the flash is busy over reading the flash ; this is needed ie. >>> on Hyperflash memories. >>> >>> Signed-off-by: Marek Vasut >>> --- >> >> Marek, >> >> Some of our boards failed. I traced to this commit. Reverting this >> commit fixes the issue. I happen to have two boards with slightly >> different flash chip. One works and the other doesn't. > > I can't since I don't have the board with such a chip ... > Which chip is that ? Mine is Spansion S25KL256 hyperflash. S26KL256S (26 instead of 25), sorry. > >> The working board has >> >> => fli >> >> Bank # 1: CFI conformant flash (16 x 16) Size: 128 MB in 1024 Sectors >> AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2801 >> Erase timeout: 2048 ms, write timeout: 1 ms >> Buffer write timeout: 3 ms, buffer size: 512 bytes >> >> The failing board has >> >> => fli >> >> Bank # 1: CFI conformant flash (16 x 16) Size: 128 MB in 1024 Sectors >> AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E2801 >> Erase timeout: 4096 ms, write timeout: 1 ms >> Buffer write timeout: 3 ms, buffer size: 64 bytes >> >> Can you investigate? >> >> York >> > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: cfi: Add support for status register polling
On Nov 17, 2017, at 11:04, Marek Vasut mailto:marek.va...@gmail.com>> wrote: On 11/17/2017 08:02 PM, Marek Vasut wrote: On 11/17/2017 05:43 PM, York Sun wrote: On 09/12/2017 10:09 AM, Marek Vasut wrote: The status register is optional in the AMD command sets, but it's presence can be checked by reading out CFI table entry 0xc bit 0. If the register is present, prefer using it's bit 7 to determine if the flash is busy over reading the flash ; this is needed ie. on Hyperflash memories. Signed-off-by: Marek Vasut mailto:marek.vasut+rene...@gmail.com>> --- Marek, Some of our boards failed. I traced to this commit. Reverting this commit fixes the issue. I happen to have two boards with slightly different flash chip. One works and the other doesn't. I can't since I don't have the board with such a chip ... Which chip is that ? Mine is Spansion S25KL256 hyperflash. S26KL256S (26 instead of 25), sorry. I have to wait for the team to confirm. The board is remote to me. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: cfi: Add support for status register polling
On 11/17/2017 11:04 AM, Marek Vasut wrote: > On 11/17/2017 08:02 PM, Marek Vasut wrote: >> On 11/17/2017 05:43 PM, York Sun wrote: >>> On 09/12/2017 10:09 AM, Marek Vasut wrote: The status register is optional in the AMD command sets, but it's presence can be checked by reading out CFI table entry 0xc bit 0. If the register is present, prefer using it's bit 7 to determine if the flash is busy over reading the flash ; this is needed ie. on Hyperflash memories. Signed-off-by: Marek Vasut --- >>> >>> Marek, >>> >>> Some of our boards failed. I traced to this commit. Reverting this >>> commit fixes the issue. I happen to have two boards with slightly >>> different flash chip. One works and the other doesn't. >> >> I can't since I don't have the board with such a chip ... >> Which chip is that ? Mine is Spansion S25KL256 hyperflash. > > S26KL256S (26 instead of 25), sorry. > My local board has chip S29GL01GS11TFIV1. The remote board has identical manufacture ID and device ID. I guess they are the same part (maybe different speed grade though). I haven't heard from the team who can visually check the part number for me. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: cfi: Add support for status register polling
On 11/17/2017 12:59 PM, York Sun wrote: > On 11/17/2017 11:04 AM, Marek Vasut wrote: >> On 11/17/2017 08:02 PM, Marek Vasut wrote: >>> On 11/17/2017 05:43 PM, York Sun wrote: On 09/12/2017 10:09 AM, Marek Vasut wrote: > The status register is optional in the AMD command sets, but it's > presence can be checked by reading out CFI table entry 0xc bit 0. > If the register is present, prefer using it's bit 7 to determine > if the flash is busy over reading the flash ; this is needed ie. > on Hyperflash memories. > > Signed-off-by: Marek Vasut > --- Marek, Some of our boards failed. I traced to this commit. Reverting this commit fixes the issue. I happen to have two boards with slightly different flash chip. One works and the other doesn't. >>> >>> I can't since I don't have the board with such a chip ... >>> Which chip is that ? Mine is Spansion S25KL256 hyperflash. >> >> S26KL256S (26 instead of 25), sorry. >> > > My local board has chip S29GL01GS11TFIV1. The remote board has identical > manufacture ID and device ID. I guess they are the same part (maybe > different speed grade though). I haven't heard from the team who can > visually check the part number for me. > Marek, I got an email from our hardware team. At some point, our vendor had two parts with the same device ID. The other one is S29GL01GP13TFIV1. According to Cypress migration document, the old part doesn't support status register feature. I understand you already check lower software bits. But I am afraid this register is not valid for old parts which don't support this feature. I checked the datasheet of S29GL01GP. It has no description of offset 0xC. Reading from the hardware, I got 0xFF. If there is no "valid" bit to indicate we can use lower software bit regsiter, it is useless. Comparing the logs Failing board Flash: York debug: manuId = 0x1 York debug: lsbits = 0xff York debug: read offset 0xE as 0x28 York debug: read offset 0xF as 0x1 128 MiB Working board Flash: York debug: manuId = 0x1 York debug: lsbits = 0x3 York debug: read offset 0xE as 0x28 York debug: read offset 0xF as 0x1 128 MiB If there is no other way to know the "lower software bits" register is valid, then we have to abandon this feature. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: cfi: Add support for status register polling
On 11/17/2017 10:48 PM, York Sun wrote: > On 11/17/2017 12:59 PM, York Sun wrote: >> On 11/17/2017 11:04 AM, Marek Vasut wrote: >>> On 11/17/2017 08:02 PM, Marek Vasut wrote: On 11/17/2017 05:43 PM, York Sun wrote: > On 09/12/2017 10:09 AM, Marek Vasut wrote: >> The status register is optional in the AMD command sets, but it's >> presence can be checked by reading out CFI table entry 0xc bit 0. >> If the register is present, prefer using it's bit 7 to determine >> if the flash is busy over reading the flash ; this is needed ie. >> on Hyperflash memories. >> >> Signed-off-by: Marek Vasut >> --- > > Marek, > > Some of our boards failed. I traced to this commit. Reverting this > commit fixes the issue. I happen to have two boards with slightly > different flash chip. One works and the other doesn't. I can't since I don't have the board with such a chip ... Which chip is that ? Mine is Spansion S25KL256 hyperflash. >>> >>> S26KL256S (26 instead of 25), sorry. >>> >> >> My local board has chip S29GL01GS11TFIV1. The remote board has identical >> manufacture ID and device ID. I guess they are the same part (maybe >> different speed grade though). I haven't heard from the team who can >> visually check the part number for me. >> > > Marek, > > I got an email from our hardware team. At some point, our vendor had two > parts with the same device ID. The other one is S29GL01GP13TFIV1. > According to Cypress migration document, the old part doesn't support > status register feature. I understand you already check lower software > bits. Which lower software bits ? > But I am afraid this register is not valid for old parts which > don't support this feature. I checked the datasheet of S29GL01GP. It has > no description of offset 0xC. Reading from the hardware, I got 0xFF. If > there is no "valid" bit to indicate we can use lower software bit > regsiter, it is useless. I am happy to dump you whatever you need from the hyperflash (which is in fact a CFI NOR flash with different interface), if that helps us identify how to improve the condition to discern flashes which do and do not support this polling feature. Since CFI is a standard, there must be a way to do it. > Comparing the logs > > Failing board > > Flash: York debug: manuId = 0x1 > York debug: lsbits = 0xff > York debug: read offset 0xE as 0x28 > York debug: read offset 0xF as 0x1 > 128 MiB > > > Working board > > Flash: York debug: manuId = 0x1 > York debug: lsbits = 0x3 > York debug: read offset 0xE as 0x28 > York debug: read offset 0xF as 0x1 > 128 MiB > > If there is no other way to know the "lower software bits" register is > valid, then we have to abandon this feature. We cannot because then that breaks hyperflash support, so we need to figure out how to improve the condition to discern the flashes. > York > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: cfi: Add support for status register polling
On 11/18/2017 02:24 AM, Marek Vasut wrote: > On 11/17/2017 10:48 PM, York Sun wrote: >> On 11/17/2017 12:59 PM, York Sun wrote: >>> On 11/17/2017 11:04 AM, Marek Vasut wrote: On 11/17/2017 08:02 PM, Marek Vasut wrote: > On 11/17/2017 05:43 PM, York Sun wrote: >> On 09/12/2017 10:09 AM, Marek Vasut wrote: >>> The status register is optional in the AMD command sets, but it's >>> presence can be checked by reading out CFI table entry 0xc bit 0. >>> If the register is present, prefer using it's bit 7 to determine >>> if the flash is busy over reading the flash ; this is needed ie. >>> on Hyperflash memories. >>> >>> Signed-off-by: Marek Vasut >>> --- >> >> Marek, >> >> Some of our boards failed. I traced to this commit. Reverting this >> commit fixes the issue. I happen to have two boards with slightly >> different flash chip. One works and the other doesn't. > > I can't since I don't have the board with such a chip ... > Which chip is that ? Mine is Spansion S25KL256 hyperflash. S26KL256S (26 instead of 25), sorry. >>> >>> My local board has chip S29GL01GS11TFIV1. The remote board has identical >>> manufacture ID and device ID. I guess they are the same part (maybe >>> different speed grade though). I haven't heard from the team who can >>> visually check the part number for me. >>> >> >> Marek, >> >> I got an email from our hardware team. At some point, our vendor had two >> parts with the same device ID. The other one is S29GL01GP13TFIV1. >> According to Cypress migration document, the old part doesn't support >> status register feature. I understand you already check lower software >> bits. > > Which lower software bits ? Register at offset 0xC. This register is not part of CFI. But there is CFI extention, explained below. > >> But I am afraid this register is not valid for old parts which >> don't support this feature. I checked the datasheet of S29GL01GP. It has >> no description of offset 0xC. Reading from the hardware, I got 0xFF. If >> there is no "valid" bit to indicate we can use lower software bit >> regsiter, it is useless. > > I am happy to dump you whatever you need from the hyperflash (which is > in fact a CFI NOR flash with different interface), if that helps us > identify how to improve the condition to discern flashes which do and do > not support this polling feature. > > Since CFI is a standard, there must be a way to do it. In vendor specific extended query, it has a register at address 53h in this document http://www.cypress.com/file/213771/download. > >> Comparing the logs >> >> Failing board >> >> Flash: York debug: manuId = 0x1 >> York debug: lsbits = 0xff >> York debug: read offset 0xE as 0x28 >> York debug: read offset 0xF as 0x1 >> 128 MiB >> >> >> Working board >> >> Flash: York debug: manuId = 0x1 >> York debug: lsbits = 0x3 >> York debug: read offset 0xE as 0x28 >> York debug: read offset 0xF as 0x1 >> 128 MiB >> >> If there is no other way to know the "lower software bits" register is >> valid, then we have to abandon this feature. > > We cannot because then that breaks hyperflash support, so we need to > figure out how to improve the condition to discern the flashes. > I sent you a patch. Please review. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mtd: cfi: Add support for status register polling
On 11/18/2017 08:11 PM, York Sun wrote: > On 11/18/2017 02:24 AM, Marek Vasut wrote: >> On 11/17/2017 10:48 PM, York Sun wrote: >>> On 11/17/2017 12:59 PM, York Sun wrote: On 11/17/2017 11:04 AM, Marek Vasut wrote: > On 11/17/2017 08:02 PM, Marek Vasut wrote: >> On 11/17/2017 05:43 PM, York Sun wrote: >>> On 09/12/2017 10:09 AM, Marek Vasut wrote: The status register is optional in the AMD command sets, but it's presence can be checked by reading out CFI table entry 0xc bit 0. If the register is present, prefer using it's bit 7 to determine if the flash is busy over reading the flash ; this is needed ie. on Hyperflash memories. Signed-off-by: Marek Vasut --- >>> >>> Marek, >>> >>> Some of our boards failed. I traced to this commit. Reverting this >>> commit fixes the issue. I happen to have two boards with slightly >>> different flash chip. One works and the other doesn't. >> >> I can't since I don't have the board with such a chip ... >> Which chip is that ? Mine is Spansion S25KL256 hyperflash. > > S26KL256S (26 instead of 25), sorry. > My local board has chip S29GL01GS11TFIV1. The remote board has identical manufacture ID and device ID. I guess they are the same part (maybe different speed grade though). I haven't heard from the team who can visually check the part number for me. >>> >>> Marek, >>> >>> I got an email from our hardware team. At some point, our vendor had two >>> parts with the same device ID. The other one is S29GL01GP13TFIV1. >>> According to Cypress migration document, the old part doesn't support >>> status register feature. I understand you already check lower software >>> bits. >> >> Which lower software bits ? > > Register at offset 0xC. This register is not part of CFI. But there is > CFI extention, explained below. > >> >>> But I am afraid this register is not valid for old parts which >>> don't support this feature. I checked the datasheet of S29GL01GP. It has >>> no description of offset 0xC. Reading from the hardware, I got 0xFF. If >>> there is no "valid" bit to indicate we can use lower software bit >>> regsiter, it is useless. >> >> I am happy to dump you whatever you need from the hyperflash (which is >> in fact a CFI NOR flash with different interface), if that helps us >> identify how to improve the condition to discern flashes which do and do >> not support this polling feature. >> >> Since CFI is a standard, there must be a way to do it. > > In vendor specific extended query, it has a register at address 53h in > this document http://www.cypress.com/file/213771/download. Cool, that works! >> >>> Comparing the logs >>> >>> Failing board >>> >>> Flash: York debug: manuId = 0x1 >>> York debug: lsbits = 0xff >>> York debug: read offset 0xE as 0x28 >>> York debug: read offset 0xF as 0x1 >>> 128 MiB >>> >>> >>> Working board >>> >>> Flash: York debug: manuId = 0x1 >>> York debug: lsbits = 0x3 >>> York debug: read offset 0xE as 0x28 >>> York debug: read offset 0xF as 0x1 >>> 128 MiB >>> >>> If there is no other way to know the "lower software bits" register is >>> valid, then we have to abandon this feature. >> >> We cannot because then that breaks hyperflash support, so we need to >> figure out how to improve the condition to discern the flashes. >> > > I sent you a patch. Please review. Done, thanks > York > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
