| Message ID | e47ed0aa3e1a6fdca7689434ce7dea99ff4826e7.1659764848.git.Takahiro.Kuwano@infineon.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Ambarus Tudor |
| Headers | show |
| Series | mtd: spi-nor: Add support for Infineon SEMPER s25hl02gt and s25hs02gt | expand |
On 8/6/22 09:34, tkuw584924@gmail.com wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Hi! > > s25hl02gt and s25hs02gt > > Add ID, flags, and fixup for s25hl02gt and s25hs02gt. > These parts are > - Dual-die package parts > - Not support chip erase > - 4-byte addressing mode by default CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 only the first 128 Mb of die 1 can be accessed." So there are flashes of the same family that are by default in 3 byte address mode. You added support just for a subset of them and used a generic name, which is not accurate, right? Can we instead make an algorithm to determine the current address mode?
On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote: > On 8/6/22 09:34, tkuw584924@gmail.com wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> > > Hi! > >> >> s25hl02gt and s25hs02gt >> >> Add ID, flags, and fixup for s25hl02gt and s25hs02gt. >> These parts are >> - Dual-die package parts >> - Not support chip erase >> - 4-byte addressing mode by default > > CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 > only the first 128 Mb of die 1 can be accessed." > So there are flashes of the same family that are by default in 3 byte address > mode. You added support just for a subset of them and used a generic name, > which is not accurate, right? > We added model #15 (3-byte address mode by default) to address special requirement from a customer who needs to use bootrom with 3-byte addressing. Anyway, I overlooked model # difference. Thanks for pointing out this. > Can we instead make an algorithm to determine the current address mode? > I have just found that we can distinguish model # via BFPT DWORD16. If Hardware reset, Software reset, or Power cycle can exit 4-byte address mode, that means the device is 3-byte address mode by default. The questions is can we implement in spi_nor_parse_bfpt() in sfdp.c or post_bfpt_fixup() in manufacturer code? Thanks, Takahiro
On 8/8/22 08:42, Takahiro Kuwano wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote: >> On 8/6/22 09:34, tkuw584924@gmail.com wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> >> >> Hi! >> >>> >>> s25hl02gt and s25hs02gt >>> >>> Add ID, flags, and fixup for s25hl02gt and s25hs02gt. >>> These parts are >>> - Dual-die package parts >>> - Not support chip erase >>> - 4-byte addressing mode by default >> >> CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 >> only the first 128 Mb of die 1 can be accessed." >> So there are flashes of the same family that are by default in 3 byte address >> mode. You added support just for a subset of them and used a generic name, >> which is not accurate, right? >> > We added model #15 (3-byte address mode by default) to address special > requirement from a customer who needs to use bootrom with 3-byte addressing. > Anyway, I overlooked model # difference. Thanks for pointing out this. > >> Can we instead make an algorithm to determine the current address mode? >> > I have just found that we can distinguish model # via BFPT DWORD16. > If Hardware reset, Software reset, or Power cycle can exit 4-byte address > mode, that means the device is 3-byte address mode by default. I don't think this will help us. It doesn't matter the default mode if you have a non volatile register that can be updated and changes the default mode. Are there any registers/data that can be read successively in 3 byte addr mode and then in 4 byte addr mode? We'll then compare what we receive from the flash with a known value and determine the mode. > The questions is can we implement in spi_nor_parse_bfpt() in sfdp.c or > post_bfpt_fixup() in manufacturer code? >
On 8/8/2022 3:08 PM, Tudor.Ambarus@microchip.com wrote: > On 8/8/22 08:42, Takahiro Kuwano wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote: >>> On 8/6/22 09:34, tkuw584924@gmail.com wrote: >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>> >>>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> >>> >>> Hi! >>> >>>> >>>> s25hl02gt and s25hs02gt >>>> >>>> Add ID, flags, and fixup for s25hl02gt and s25hs02gt. >>>> These parts are >>>> - Dual-die package parts >>>> - Not support chip erase >>>> - 4-byte addressing mode by default >>> >>> CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 >>> only the first 128 Mb of die 1 can be accessed." >>> So there are flashes of the same family that are by default in 3 byte address >>> mode. You added support just for a subset of them and used a generic name, >>> which is not accurate, right? >>> >> We added model #15 (3-byte address mode by default) to address special >> requirement from a customer who needs to use bootrom with 3-byte addressing. >> Anyway, I overlooked model # difference. Thanks for pointing out this. >> >>> Can we instead make an algorithm to determine the current address mode? >>> >> I have just found that we can distinguish model # via BFPT DWORD16. >> If Hardware reset, Software reset, or Power cycle can exit 4-byte address >> mode, that means the device is 3-byte address mode by default. > > I don't think this will help us. It doesn't matter the default mode if you > have a non volatile register that can be updated and changes the default > mode. > > Are there any registers/data that can be read successively in 3 byte addr mode > and then in 4 byte addr mode? We'll then compare what we receive from the flash > with a known value and determine the mode. > As we discussed before [0], if address mode in the controller and device are different, the read data will be undetermined. But if we really want... Compare SR1 data read by RDSR1(05h - No Addr) and RDAR(65h - Addr 0). In most cases (without block protection), SR1=00h. The value of 00h would be awkward to determine if this is 'real' output from Flash or not. So, use WREN(06h) and WRDI(04h) that flips BIT(1) in SR1. Therefore, something like: 1) RDSR1 2) RDAR with 3-byte addr (000000h) 3) If #1 == #2 4) WREN 5) RDAR with 3-byte addr (000000h) 6) BIT(1) is SR1==1? ... Or simply WREN -> RDAR -> WRDI -> RDAR then check if only BIT(1) is toggled. [0] https://lore.kernel.org/all/070bfe6a-00e8-1c59-c9db-52d249dfbcfe@microchip.com/ Thanks, Takahiro
On 8/8/22 09:41, Takahiro Kuwano wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On 8/8/2022 3:08 PM, Tudor.Ambarus@microchip.com wrote: >> On 8/8/22 08:42, Takahiro Kuwano wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote: >>>> On 8/6/22 09:34, tkuw584924@gmail.com wrote: >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>> >>>>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> >>>> >>>> Hi! >>>> >>>>> >>>>> s25hl02gt and s25hs02gt >>>>> >>>>> Add ID, flags, and fixup for s25hl02gt and s25hs02gt. >>>>> These parts are >>>>> - Dual-die package parts >>>>> - Not support chip erase >>>>> - 4-byte addressing mode by default >>>> >>>> CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 >>>> only the first 128 Mb of die 1 can be accessed." >>>> So there are flashes of the same family that are by default in 3 byte address >>>> mode. You added support just for a subset of them and used a generic name, >>>> which is not accurate, right? >>>> >>> We added model #15 (3-byte address mode by default) to address special >>> requirement from a customer who needs to use bootrom with 3-byte addressing. >>> Anyway, I overlooked model # difference. Thanks for pointing out this. >>> >>>> Can we instead make an algorithm to determine the current address mode? >>>> >>> I have just found that we can distinguish model # via BFPT DWORD16. >>> If Hardware reset, Software reset, or Power cycle can exit 4-byte address >>> mode, that means the device is 3-byte address mode by default. >> >> I don't think this will help us. It doesn't matter the default mode if you >> have a non volatile register that can be updated and changes the default >> mode. >> >> Are there any registers/data that can be read successively in 3 byte addr mode >> and then in 4 byte addr mode? We'll then compare what we receive from the flash >> with a known value and determine the mode. >> > As we discussed before [0], if address mode in the controller and device are I remember, yes, but without determining the mode, the driver will work only with flashes that come with the factory settings. The driver will be unusable if someone changes the address mode in a non volatile way, right? > different, the read data will be undetermined. > > But if we really want... > Compare SR1 data read by RDSR1(05h - No Addr) and RDAR(65h - Addr 0). > In most cases (without block protection), SR1=00h. The value of 00h would be > awkward to determine if this is 'real' output from Flash or not. So, use> WREN(06h) and WRDI(04h) that flips BIT(1) in SR1. Would be good to have more fixed/OPT-like bits, or if we could change more bits to increase the chances to not hit just some undetermined data. > > Therefore, something like: > 1) RDSR1 > 2) RDAR with 3-byte addr (000000h) > 3) If #1 == #2 > 4) WREN > 5) RDAR with 3-byte addr (000000h) > 6) BIT(1) is SR1==1? > ... > > Or simply WREN -> RDAR -> WRDI -> RDAR then check if only BIT(1) is toggled. Both may work, yes, but making the assumption on only one bit is fragile. Can we use the Read Any Register Command with 3 and 4 byte address modes and compare the values? Are there any registers with fixed values? > > [0] https://lore.kernel.org/all/070bfe6a-00e8-1c59-c9db-52d249dfbcfe@microchip.com/ > > Thanks, > Takahiro
On 8/8/2022 4:34 PM, Tudor.Ambarus@microchip.com wrote: > On 8/8/22 09:41, Takahiro Kuwano wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> On 8/8/2022 3:08 PM, Tudor.Ambarus@microchip.com wrote: >>> On 8/8/22 08:42, Takahiro Kuwano wrote: >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>> >>>> On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote: >>>>> On 8/6/22 09:34, tkuw584924@gmail.com wrote: >>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>>> >>>>>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> >>>>> >>>>> Hi! >>>>> >>>>>> >>>>>> s25hl02gt and s25hs02gt >>>>>> >>>>>> Add ID, flags, and fixup for s25hl02gt and s25hs02gt. >>>>>> These parts are >>>>>> - Dual-die package parts >>>>>> - Not support chip erase >>>>>> - 4-byte addressing mode by default >>>>> >>>>> CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 >>>>> only the first 128 Mb of die 1 can be accessed." >>>>> So there are flashes of the same family that are by default in 3 byte address >>>>> mode. You added support just for a subset of them and used a generic name, >>>>> which is not accurate, right? >>>>> >>>> We added model #15 (3-byte address mode by default) to address special >>>> requirement from a customer who needs to use bootrom with 3-byte addressing. >>>> Anyway, I overlooked model # difference. Thanks for pointing out this. >>>> >>>>> Can we instead make an algorithm to determine the current address mode? >>>>> >>>> I have just found that we can distinguish model # via BFPT DWORD16. >>>> If Hardware reset, Software reset, or Power cycle can exit 4-byte address >>>> mode, that means the device is 3-byte address mode by default. >>> >>> I don't think this will help us. It doesn't matter the default mode if you >>> have a non volatile register that can be updated and changes the default >>> mode. >>> >>> Are there any registers/data that can be read successively in 3 byte addr mode >>> and then in 4 byte addr mode? We'll then compare what we receive from the flash >>> with a known value and determine the mode. >>> >> As we discussed before [0], if address mode in the controller and device are > > I remember, yes, but without determining the mode, the driver will work only > with flashes that come with the factory settings. The driver will be unusable > if someone changes the address mode in a non volatile way, right? > Yes, right. >> different, the read data will be undetermined. >> >> But if we really want... >> Compare SR1 data read by RDSR1(05h - No Addr) and RDAR(65h - Addr 0). >> In most cases (without block protection), SR1=00h. The value of 00h would be >> awkward to determine if this is 'real' output from Flash or not. So, use> WREN(06h) and WRDI(04h) that flips BIT(1) in SR1. > > Would be good to have more fixed/OPT-like bits, or if we could change more bits > to increase the chances to not hit just some undetermined data. >> >> Therefore, something like: >> 1) RDSR1 >> 2) RDAR with 3-byte addr (000000h) >> 3) If #1 == #2 >> 4) WREN >> 5) RDAR with 3-byte addr (000000h) >> 6) BIT(1) is SR1==1? >> ... >> >> Or simply WREN -> RDAR -> WRDI -> RDAR then check if only BIT(1) is toggled. > > Both may work, yes, but making the assumption on only one bit is fragile. > Can we use the Read Any Register Command with 3 and 4 byte address modes and > compare the values? Are there any registers with fixed values? > Register values can vary because it's register:) So... let's use Data Integrity Check CRC registers. These registers do not have fixed values but we can calculate expected values by offline. Read several bytes (>=4) from Flash array with Read(03h) then calculate CRC by crc32(). Issue Data integrity Check command (5Bh) followed by start and end address (4-byte for each), wait till ready. Read calculated CRC by Read Any Register in 3 and 4 byte address (00800095h~0080098h) then compare the crc32() result and register read result.
On 8/8/22 11:09, Takahiro Kuwano wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On 8/8/2022 4:34 PM, Tudor.Ambarus@microchip.com wrote: >> On 8/8/22 09:41, Takahiro Kuwano wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> On 8/8/2022 3:08 PM, Tudor.Ambarus@microchip.com wrote: >>>> On 8/8/22 08:42, Takahiro Kuwano wrote: >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>> >>>>> On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote: >>>>>> On 8/6/22 09:34, tkuw584924@gmail.com wrote: >>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>>>> >>>>>>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> >>>>>> >>>>>> Hi! >>>>>> >>>>>>> >>>>>>> s25hl02gt and s25hs02gt >>>>>>> >>>>>>> Add ID, flags, and fixup for s25hl02gt and s25hs02gt. >>>>>>> These parts are >>>>>>> - Dual-die package parts >>>>>>> - Not support chip erase >>>>>>> - 4-byte addressing mode by default >>>>>> >>>>>> CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 >>>>>> only the first 128 Mb of die 1 can be accessed." >>>>>> So there are flashes of the same family that are by default in 3 byte address >>>>>> mode. You added support just for a subset of them and used a generic name, >>>>>> which is not accurate, right? >>>>>> >>>>> We added model #15 (3-byte address mode by default) to address special >>>>> requirement from a customer who needs to use bootrom with 3-byte addressing. >>>>> Anyway, I overlooked model # difference. Thanks for pointing out this. >>>>> >>>>>> Can we instead make an algorithm to determine the current address mode? >>>>>> >>>>> I have just found that we can distinguish model # via BFPT DWORD16. >>>>> If Hardware reset, Software reset, or Power cycle can exit 4-byte address >>>>> mode, that means the device is 3-byte address mode by default. >>>> >>>> I don't think this will help us. It doesn't matter the default mode if you >>>> have a non volatile register that can be updated and changes the default >>>> mode. >>>> >>>> Are there any registers/data that can be read successively in 3 byte addr mode >>>> and then in 4 byte addr mode? We'll then compare what we receive from the flash >>>> with a known value and determine the mode. >>>> >>> As we discussed before [0], if address mode in the controller and device are >> >> I remember, yes, but without determining the mode, the driver will work only >> with flashes that come with the factory settings. The driver will be unusable >> if someone changes the address mode in a non volatile way, right? >> > Yes, right. > >>> different, the read data will be undetermined. >>> >>> But if we really want... >>> Compare SR1 data read by RDSR1(05h - No Addr) and RDAR(65h - Addr 0). >>> In most cases (without block protection), SR1=00h. The value of 00h would be >>> awkward to determine if this is 'real' output from Flash or not. So, use> WREN(06h) and WRDI(04h) that flips BIT(1) in SR1. >> >> Would be good to have more fixed/OPT-like bits, or if we could change more bits >> to increase the chances to not hit just some undetermined data. >>> >>> Therefore, something like: >>> 1) RDSR1 >>> 2) RDAR with 3-byte addr (000000h) >>> 3) If #1 == #2 >>> 4) WREN >>> 5) RDAR with 3-byte addr (000000h) >>> 6) BIT(1) is SR1==1? >>> ... >>> >>> Or simply WREN -> RDAR -> WRDI -> RDAR then check if only BIT(1) is toggled. >> >> Both may work, yes, but making the assumption on only one bit is fragile. >> Can we use the Read Any Register Command with 3 and 4 byte address modes and >> compare the values? Are there any registers with fixed values? >> > Register values can vary because it's register:) > > So... let's use Data Integrity Check CRC registers. These registers do not > have fixed values but we can calculate expected values by offline. Read > several bytes (>=4) from Flash array with Read(03h) then calculate CRC by > crc32(). Issue Data integrity Check command (5Bh) followed by start and > end address (4-byte for each), wait till ready. Read calculated CRC by > Read Any Register in 3 and 4 byte address (00800095h~0080098h) then compare > the crc32() result and register read result. Much better, yes. I think it is worth it. What's your opinion, Takahiro? Others, Michael, Pratyush?
On 8/8/2022 5:26 PM, Tudor.Ambarus@microchip.com wrote: > On 8/8/22 11:09, Takahiro Kuwano wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >> >> On 8/8/2022 4:34 PM, Tudor.Ambarus@microchip.com wrote: >>> On 8/8/22 09:41, Takahiro Kuwano wrote: >>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>> >>>> On 8/8/2022 3:08 PM, Tudor.Ambarus@microchip.com wrote: >>>>> On 8/8/22 08:42, Takahiro Kuwano wrote: >>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>>> >>>>>> On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote: >>>>>>> On 8/6/22 09:34, tkuw584924@gmail.com wrote: >>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>>>>> >>>>>>>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>>> >>>>>>>> s25hl02gt and s25hs02gt >>>>>>>> >>>>>>>> Add ID, flags, and fixup for s25hl02gt and s25hs02gt. >>>>>>>> These parts are >>>>>>>> - Dual-die package parts >>>>>>>> - Not support chip erase >>>>>>>> - 4-byte addressing mode by default >>>>>>> >>>>>>> CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 >>>>>>> only the first 128 Mb of die 1 can be accessed." >>>>>>> So there are flashes of the same family that are by default in 3 byte address >>>>>>> mode. You added support just for a subset of them and used a generic name, >>>>>>> which is not accurate, right? >>>>>>> >>>>>> We added model #15 (3-byte address mode by default) to address special >>>>>> requirement from a customer who needs to use bootrom with 3-byte addressing. >>>>>> Anyway, I overlooked model # difference. Thanks for pointing out this. >>>>>> >>>>>>> Can we instead make an algorithm to determine the current address mode? >>>>>>> >>>>>> I have just found that we can distinguish model # via BFPT DWORD16. >>>>>> If Hardware reset, Software reset, or Power cycle can exit 4-byte address >>>>>> mode, that means the device is 3-byte address mode by default. >>>>> >>>>> I don't think this will help us. It doesn't matter the default mode if you >>>>> have a non volatile register that can be updated and changes the default >>>>> mode. >>>>> >>>>> Are there any registers/data that can be read successively in 3 byte addr mode >>>>> and then in 4 byte addr mode? We'll then compare what we receive from the flash >>>>> with a known value and determine the mode. >>>>> >>>> As we discussed before [0], if address mode in the controller and device are >>> >>> I remember, yes, but without determining the mode, the driver will work only >>> with flashes that come with the factory settings. The driver will be unusable >>> if someone changes the address mode in a non volatile way, right? >>> >> Yes, right. >> >>>> different, the read data will be undetermined. >>>> >>>> But if we really want... >>>> Compare SR1 data read by RDSR1(05h - No Addr) and RDAR(65h - Addr 0). >>>> In most cases (without block protection), SR1=00h. The value of 00h would be >>>> awkward to determine if this is 'real' output from Flash or not. So, use> WREN(06h) and WRDI(04h) that flips BIT(1) in SR1. >>> >>> Would be good to have more fixed/OPT-like bits, or if we could change more bits >>> to increase the chances to not hit just some undetermined data. >>>> >>>> Therefore, something like: >>>> 1) RDSR1 >>>> 2) RDAR with 3-byte addr (000000h) >>>> 3) If #1 == #2 >>>> 4) WREN >>>> 5) RDAR with 3-byte addr (000000h) >>>> 6) BIT(1) is SR1==1? >>>> ... >>>> >>>> Or simply WREN -> RDAR -> WRDI -> RDAR then check if only BIT(1) is toggled. >>> >>> Both may work, yes, but making the assumption on only one bit is fragile. >>> Can we use the Read Any Register Command with 3 and 4 byte address modes and >>> compare the values? Are there any registers with fixed values? >>> >> Register values can vary because it's register:) >> >> So... let's use Data Integrity Check CRC registers. These registers do not >> have fixed values but we can calculate expected values by offline. Read >> several bytes (>=4) from Flash array with Read(03h) then calculate CRC by >> crc32(). Issue Data integrity Check command (5Bh) followed by start and >> end address (4-byte for each), wait till ready. Read calculated CRC by >> Read Any Register in 3 and 4 byte address (00800095h~0080098h) then compare >> the crc32() result and register read result. > > Much better, yes. I think it is worth it. What's your opinion, Takahiro? > Others, Michael, Pratyush? > OK, I will prototype and test it.
Hi Tudor, I submitted another series about address mode discovery. Please review that. I will revise this series after another one is settled. Thanks, Takahiro On 8/8/2022 5:31 PM, Takahiro Kuwano wrote: > On 8/8/2022 5:26 PM, Tudor.Ambarus@microchip.com wrote: >> On 8/8/22 11:09, Takahiro Kuwano wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>> >>> On 8/8/2022 4:34 PM, Tudor.Ambarus@microchip.com wrote: >>>> On 8/8/22 09:41, Takahiro Kuwano wrote: >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>> >>>>> On 8/8/2022 3:08 PM, Tudor.Ambarus@microchip.com wrote: >>>>>> On 8/8/22 08:42, Takahiro Kuwano wrote: >>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>>>> >>>>>>> On 8/8/2022 1:47 PM, Tudor.Ambarus@microchip.com wrote: >>>>>>>> On 8/6/22 09:34, tkuw584924@gmail.com wrote: >>>>>>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe >>>>>>>>> >>>>>>>>> From: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> >>>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>>> >>>>>>>>> s25hl02gt and s25hs02gt >>>>>>>>> >>>>>>>>> Add ID, flags, and fixup for s25hl02gt and s25hs02gt. >>>>>>>>> These parts are >>>>>>>>> - Dual-die package parts >>>>>>>>> - Not support chip erase >>>>>>>>> - 4-byte addressing mode by default >>>>>>>> >>>>>>>> CFR2N[7] CFR2V[7] says that: "For the DDP or QDP devices, if ADRBYT = 0 >>>>>>>> only the first 128 Mb of die 1 can be accessed." >>>>>>>> So there are flashes of the same family that are by default in 3 byte address >>>>>>>> mode. You added support just for a subset of them and used a generic name, >>>>>>>> which is not accurate, right? >>>>>>>> >>>>>>> We added model #15 (3-byte address mode by default) to address special >>>>>>> requirement from a customer who needs to use bootrom with 3-byte addressing. >>>>>>> Anyway, I overlooked model # difference. Thanks for pointing out this. >>>>>>> >>>>>>>> Can we instead make an algorithm to determine the current address mode? >>>>>>>> >>>>>>> I have just found that we can distinguish model # via BFPT DWORD16. >>>>>>> If Hardware reset, Software reset, or Power cycle can exit 4-byte address >>>>>>> mode, that means the device is 3-byte address mode by default. >>>>>> >>>>>> I don't think this will help us. It doesn't matter the default mode if you >>>>>> have a non volatile register that can be updated and changes the default >>>>>> mode. >>>>>> >>>>>> Are there any registers/data that can be read successively in 3 byte addr mode >>>>>> and then in 4 byte addr mode? We'll then compare what we receive from the flash >>>>>> with a known value and determine the mode. >>>>>> >>>>> As we discussed before [0], if address mode in the controller and device are >>>> >>>> I remember, yes, but without determining the mode, the driver will work only >>>> with flashes that come with the factory settings. The driver will be unusable >>>> if someone changes the address mode in a non volatile way, right? >>>> >>> Yes, right. >>> >>>>> different, the read data will be undetermined. >>>>> >>>>> But if we really want... >>>>> Compare SR1 data read by RDSR1(05h - No Addr) and RDAR(65h - Addr 0). >>>>> In most cases (without block protection), SR1=00h. The value of 00h would be >>>>> awkward to determine if this is 'real' output from Flash or not. So, use> WREN(06h) and WRDI(04h) that flips BIT(1) in SR1. >>>> >>>> Would be good to have more fixed/OPT-like bits, or if we could change more bits >>>> to increase the chances to not hit just some undetermined data. >>>>> >>>>> Therefore, something like: >>>>> 1) RDSR1 >>>>> 2) RDAR with 3-byte addr (000000h) >>>>> 3) If #1 == #2 >>>>> 4) WREN >>>>> 5) RDAR with 3-byte addr (000000h) >>>>> 6) BIT(1) is SR1==1? >>>>> ... >>>>> >>>>> Or simply WREN -> RDAR -> WRDI -> RDAR then check if only BIT(1) is toggled. >>>> >>>> Both may work, yes, but making the assumption on only one bit is fragile. >>>> Can we use the Read Any Register Command with 3 and 4 byte address modes and >>>> compare the values? Are there any registers with fixed values? >>>> >>> Register values can vary because it's register:) >>> >>> So... let's use Data Integrity Check CRC registers. These registers do not >>> have fixed values but we can calculate expected values by offline. Read >>> several bytes (>=4) from Flash array with Read(03h) then calculate CRC by >>> crc32(). Issue Data integrity Check command (5Bh) followed by start and >>> end address (4-byte for each), wait till ready. Read calculated CRC by >>> Read Any Register in 3 and 4 byte address (00800095h~0080098h) then compare >>> the crc32() result and register read result. >> >> Much better, yes. I think it is worth it. What's your opinion, Takahiro? >> Others, Michael, Pratyush? >> > OK, I will prototype and test it.
diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c index 22b0be5d312b..11f0bb509900 100644 --- a/drivers/mtd/spi-nor/spansion.c +++ b/drivers/mtd/spi-nor/spansion.c @@ -325,6 +325,10 @@ static void s25hx_t_post_sfdp_fixup(struct spi_nor *nor) } } + /* Fix the number of dice that is wrongly advertised in 2Gb parts. */ + if (nor->params->size == SZ_256M) + nor->params->num_of_dice = 2; + cypress_nor_set_page_size(nor); } @@ -526,6 +530,11 @@ static const struct flash_info spansion_nor_parts[] = { PARSE_SFDP MFR_FLAGS(USE_CLSR) .fixups = &s25hx_t_fixups }, + { "s25hl02gt", INFO6(0x342a1c, 0x0f0090, 256 * 1024, 1024) + PARSE_SFDP + FLAGS(NO_CHIP_ERASE) + MFR_FLAGS(DEF_4BAM) + .fixups = &s25hx_t_fixups }, { "s25hs512t", INFO6(0x342b1a, 0x0f0390, 256 * 1024, 256) PARSE_SFDP MFR_FLAGS(USE_CLSR) @@ -534,6 +543,11 @@ static const struct flash_info spansion_nor_parts[] = { PARSE_SFDP MFR_FLAGS(USE_CLSR) .fixups = &s25hx_t_fixups }, + { "s25hs02gt", INFO6(0x342b1c, 0x0f0090, 256 * 1024, 1024) + PARSE_SFDP + FLAGS(NO_CHIP_ERASE) + MFR_FLAGS(DEF_4BAM) + .fixups = &s25hx_t_fixups }, { "cy15x104q", INFO6(0x042cc2, 0x7f7f7f, 512 * 1024, 1) FLAGS(SPI_NOR_NO_ERASE) }, { "s28hs512t", INFO(0x345b1a, 0, 256 * 1024, 256)