| Message ID | 20200424184410.8578-1-p.yadav@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mtd: spi-nor: add xSPI Octal DTR support | expand |
Hi, Pratyush, Boris,
On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote:
> This series adds support for octal DTR flashes in the spi-nor framework,
I'm still learning about this, but I can give you my 2 cents as of now, to
open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous
because the flash may not recover from unexpected resets. Entering one of
these modes can be:
1/ volatile selectable, the device return to the 1-1-1 protocol after the next
power-on. I guess this is conditioned by the optional RESET pin, but I'll have
to check. Also the flash can return to the 1-1-1 mode using the software reset
or through writing to its Configuration Register, without power-on or power-
off.
2/ non-volatile selectable in which RESET# and software reset are useless, the
flash defaults to the mode selected in the non volatile Configuration Register
bits. The only way to get back to 1-1-1 is to write to the Configuration
Register.
Not recovering from unexpected resets is unacceptable. One should always
prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with the
presence of the optional RESET pin.
For the unfortunate flashes that support just option 2/, we should not enter
these modes on our own, just by discovering the capabilities from the SFDP
tables or by the flags in the flash_info struct. The best we can do for them
is to move the responsibility to the user. Maybe to add a Kconfig option that
is disabled by default with which we condition the entering in 2-2-2, 4-4-4 or
8-8-8 modes. Once entered in one of these modes, if an unexpected reset comes,
you most likely are doomed, because early stage bootloaders may not work in
these modes and you'll not be able to boot the board. Assuming that one uses
other environment to boot the board, we should at least make sure that the
flash works in linux after an unexpected reset. We should try to determine in
which mode we are at init, so maybe an extension of the default_init hook is
needed. But all this looks like a BIG compromise, I'm not yet sure if we
should adress 2/. Thoughts?
I'm still looking into this.
Cheers,
ta
On Mon, 11 May 2020 09:00:35 +0000 <Tudor.Ambarus@microchip.com> wrote: > Hi, Pratyush, Boris, > > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: > > This series adds support for octal DTR flashes in the spi-nor framework, > > I'm still learning about this, but I can give you my 2 cents as of now, to > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous > because the flash may not recover from unexpected resets. Entering one of > these modes can be: > 1/ volatile selectable, the device return to the 1-1-1 protocol after the next > power-on. I guess this is conditioned by the optional RESET pin, but I'll have > to check. Also the flash can return to the 1-1-1 mode using the software reset > or through writing to its Configuration Register, without power-on or power- > off. My understanding is that there's no standard software reset procedure that guarantees no conflict with existing 1S commands, so even the software reset approach doesn't work here. > 2/ non-volatile selectable in which RESET# and software reset are useless, the > flash defaults to the mode selected in the non volatile Configuration Register > bits. The only way to get back to 1-1-1 is to write to the Configuration > Register. I'm less worried about this case though, since I'd expect the ROM code and bootloaders to be able to deal with xD-xD-xD modes when the flash is set in this mode by default. That implies letting Linux know about this default mode of course, maybe through an extra DT property/cmdline param. > > Not recovering from unexpected resets is unacceptable. One should always > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with the > presence of the optional RESET pin. Totally agree with you on that one, but we know what happens in practice... > > For the unfortunate flashes that support just option 2/, we should not enter > these modes on our own, just by discovering the capabilities from the SFDP > tables or by the flags in the flash_info struct. The best we can do for them > is to move the responsibility to the user. Maybe to add a Kconfig option that > is disabled by default with which we condition the entering in 2-2-2, 4-4-4 or > 8-8-8 modes. Hm, a Kconfig option doesn't sound like the right solution to the problem, since it should be a per-flash decision, not something you set system-wise. > Once entered in one of these modes, if an unexpected reset comes, > you most likely are doomed, because early stage bootloaders may not work in > these modes and you'll not be able to boot the board. Assuming that one uses > other environment to boot the board, we should at least make sure that the > flash works in linux after an unexpected reset. We should try to determine in > which mode we are at init, so maybe an extension of the default_init hook is > needed. But all this looks like a BIG compromise, I'm not yet sure if we > should adress 2/. Thoughts? We should definitely not write non-volatile regs on our own, but instead use the mode that's been chosen there. I doubt anyone setting the non-volative conf to 8D-8D-8D will ever want to go back to 1S-1S-1S anyway, so 8D -> 1S transitions are not really an issue, right? Of course, that still leaves us with the 'mode detection' issue, and I have no solution other than flagging it through the DT/cmdline for that one...
On 11/05/20 2:30 pm, Tudor.Ambarus@microchip.com wrote: > Hi, Pratyush, Boris, > > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: >> This series adds support for octal DTR flashes in the spi-nor framework, > > I'm still learning about this, but I can give you my 2 cents as of now, to > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous > because the flash may not recover from unexpected resets. Unfortunately, xSPI compliant flashes need to support 1S-1S-1S and 8D-8D-8D (or 4S-4D-4D) mode only. So we have to start supporting state-full modes > Entering one of these modes can be: > 1/ volatile selectable, the device return to the 1-1-1 protocol after the next > power-on. I guess this is conditioned by the optional RESET pin, but I'll have > to check. Also the flash can return to the 1-1-1 mode using the software reset > or through writing to its Configuration Register, without power-on or power- > off. Right, I guess switching to octal mode be made conditional based upon SNOR_F_BROKEN_RESET? > 2/ non-volatile selectable in which RESET# and software reset are useless, the > flash defaults to the mode selected in the non volatile Configuration Register > bits. The only way to get back to 1-1-1 is to write to the Configuration > Register. > In addition to reset issue, supporting flash that boot up in Octal DDR mode (due to non-volatile setting) is still pretty difficult. Commands like Read ID and READ SFDP (that are used for flash discovery at runtime) follow different protocols across different vendors in Octal DDR mode. So its almost impossible to support such flashes w/o a hint about device type from DT (or somewhere else). I would really stick to option 1 for now until someone makes a compelling case to support option 2. > Not recovering from unexpected resets is unacceptable. One should always > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with the > presence of the optional RESET pin. > > For the unfortunate flashes that support just option 2/, we should not enter > these modes on our own, just by discovering the capabilities from the SFDP > tables or by the flags in the flash_info struct. The best we can do for them > is to move the responsibility to the user. Maybe to add a Kconfig option that > is disabled by default with which we condition the entering in 2-2-2, 4-4-4 or > 8-8-8 modes. Once entered in one of these modes, if an unexpected reset comes, > you most likely are doomed, because early stage bootloaders may not work in > these modes and you'll not be able to boot the board. Assuming that one uses > other environment to boot the board, we should at least make sure that the > flash works in linux after an unexpected reset. We should try to determine in > which mode we are at init, so maybe an extension of the default_init hook is > needed. But all this looks like a BIG compromise, I'm not yet sure if we > should adress 2/. Thoughts? > Agree, lets not worry about option 2 for now... Regards Vignesh
On 11/05/20 11:27AM, Boris Brezillon wrote: > On Mon, 11 May 2020 09:00:35 +0000 > <Tudor.Ambarus@microchip.com> wrote: > > > Hi, Pratyush, Boris, > > > > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: > > > This series adds support for octal DTR flashes in the spi-nor framework, > > > > I'm still learning about this, but I can give you my 2 cents as of now, to > > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous > > because the flash may not recover from unexpected resets. Entering one of > > these modes can be: > > 1/ volatile selectable, the device return to the 1-1-1 protocol after the next > > power-on. I guess this is conditioned by the optional RESET pin, but I'll have > > to check. Also the flash can return to the 1-1-1 mode using the software reset > > or through writing to its Configuration Register, without power-on or power- > > off. > > My understanding is that there's no standard software reset procedure > that guarantees no conflict with existing 1S commands, so even the > software reset approach doesn't work here. > > > 2/ non-volatile selectable in which RESET# and software reset are useless, the > > flash defaults to the mode selected in the non volatile Configuration Register > > bits. The only way to get back to 1-1-1 is to write to the Configuration > > Register. > > I'm less worried about this case though, since I'd expect the ROM > code and bootloaders to be able to deal with xD-xD-xD modes when the > flash is set in this mode by default. That implies letting Linux know > about this default mode of course, maybe through an extra DT > property/cmdline param. > > > > > Not recovering from unexpected resets is unacceptable. One should always > > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with the > > presence of the optional RESET pin. > > Totally agree with you on that one, but we know what happens in > practice... > > > > > For the unfortunate flashes that support just option 2/, we should not enter > > these modes on our own, just by discovering the capabilities from the SFDP > > tables or by the flags in the flash_info struct. The best we can do for them > > is to move the responsibility to the user. Maybe to add a Kconfig option that > > is disabled by default with which we condition the entering in 2-2-2, 4-4-4 or > > 8-8-8 modes. > > Hm, a Kconfig option doesn't sound like the right solution to the > problem, since it should be a per-flash decision, not something you set > system-wise. Agreed. Is there any such flash in use today? The two flashes the series adds support for both have volatile configuration for 8D mode. Unless we have to support a flash like this in practice, I think such a change is out of the scope of this series. > > Once entered in one of these modes, if an unexpected reset comes, > > you most likely are doomed, because early stage bootloaders may not work in > > these modes and you'll not be able to boot the board. Assuming that one uses > > other environment to boot the board, we should at least make sure that the > > flash works in linux after an unexpected reset. We should try to determine in > > which mode we are at init, so maybe an extension of the default_init hook is > > needed. But all this looks like a BIG compromise, I'm not yet sure if we > > should adress 2/. Thoughts? > > We should definitely not write non-volatile regs on our own, but > instead use the mode that's been chosen there. I doubt anyone > setting the non-volative conf to 8D-8D-8D will ever want to go back to > 1S-1S-1S anyway, so 8D -> 1S transitions are not really an issue, right? > > Of course, that still leaves us with the 'mode detection' issue, and I > have no solution other than flagging it through the DT/cmdline for that > one... Correct. I tried doing it, and the best way I could figure out was to try reading the SFDP signature in 1S and 8D mode, and see where we get the correct value. But unfortunately, because the Read ID command is different in 8D mode for different flashes, we can't then figure out which flash it actually is.
Hi, Boris, Pratyush, I stripped case 2/, we'll not treat it for now. On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Mon, 11 May 2020 09:00:35 +0000 > > <Tudor.Ambarus@microchip.com> wrote: > > Hi, Pratyush, Boris, > > > > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: > > > This series adds support for octal DTR flashes in the spi-nor framework, > > > > I'm still learning about this, but I can give you my 2 cents as of now, to > > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous > > because the flash may not recover from unexpected resets. Entering one of > > these modes can be: > > 1/ volatile selectable, the device return to the 1-1-1 protocol after the > > next power-on. I guess this is conditioned by the optional RESET pin, but > > I'll have to check. Also the flash can return to the 1-1-1 mode using the > > software reset or through writing to its Configuration Register, without > > power-on or power- off. > > My understanding is that there's no standard software reset procedure > that guarantees no conflict with existing 1S commands, so even the > software reset approach doesn't work here. > The software reset procedure can't protect you from unexpected resets, but the hardware with its optional reset pin can. Pratyush to confirm. cut > > > Not recovering from unexpected resets is unacceptable. One should always > > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with > > the presence of the optional RESET pin. > > Totally agree with you on that one, but we know what happens in > practice... What I proposed is to condition the entering in the state-full modes with the presence of the optional RESET pin. We would introduce an optional device tree property for the RESET pin. If hardware doesn't implement the optional RESET# signal, then we will not enter in the state-full modes. Cheers, ta
On 12/05/20 11:46 am, Tudor.Ambarus@microchip.com wrote: > Hi, Boris, Pratyush, > > I stripped case 2/, we'll not treat it for now. > > On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >> content is safe >> >> On Mon, 11 May 2020 09:00:35 +0000 >> >> <Tudor.Ambarus@microchip.com> wrote: >>> Hi, Pratyush, Boris, >>> >>> On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: >>>> This series adds support for octal DTR flashes in the spi-nor framework, >>> >>> I'm still learning about this, but I can give you my 2 cents as of now, to >>> open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous >>> because the flash may not recover from unexpected resets. Entering one of >>> these modes can be: >>> 1/ volatile selectable, the device return to the 1-1-1 protocol after the >>> next power-on. I guess this is conditioned by the optional RESET pin, but >>> I'll have to check. Also the flash can return to the 1-1-1 mode using the >>> software reset or through writing to its Configuration Register, without >>> power-on or power- off. >> >> My understanding is that there's no standard software reset procedure >> that guarantees no conflict with existing 1S commands, so even the >> software reset approach doesn't work here. >> > > The software reset procedure can't protect you from unexpected resets, but the > hardware with its optional reset pin can. Pratyush to confirm. > > cut > >> >>> Not recovering from unexpected resets is unacceptable. One should always >>> prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with >>> the presence of the optional RESET pin. >> >> Totally agree with you on that one, but we know what happens in >> practice... > > What I proposed is to condition the entering in the state-full modes with the > presence of the optional RESET pin. We would introduce an optional device tree > property for the RESET pin. If hardware doesn't implement the optional RESET# > signal, then we will not enter in the state-full modes. > Are you asking for dedicated SW controllable reset line or just an indication from DT that OSPI reset line is connected to board level soft/hard reset lines? Mandating SW controllable RESET line is bit of a stretch IMO... Board design may not allow wasting dedicated pin due to lack of GPIOs perhaps.. For eg.: TI EVM has OSPI reset line connected to board level reset out. This ensures any soft/warm/hard CPU reset will trigger OSPI Flash reset, but there is no SW control that allows OSPI flash alone to be reset. Isn't such a reset mechanism sufficient? Regards Vignesh
Hi, Vignesh, On Tuesday, May 12, 2020 12:49:07 PM EEST Vignesh Raghavendra wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > On 12/05/20 11:46 am, Tudor.Ambarus@microchip.com wrote: > > Hi, Boris, Pratyush, > > > > I stripped case 2/, we'll not treat it for now. > > > > On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote: > >> EXTERNAL EMAIL: Do not click links or open attachments unless you know > >> the > >> content is safe > >> > >> On Mon, 11 May 2020 09:00:35 +0000 > >> > >> <Tudor.Ambarus@microchip.com> wrote: > >>> Hi, Pratyush, Boris, > >>> > >>> On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote: > >>>> This series adds support for octal DTR flashes in the spi-nor > >>>> framework, > >>> > >>> I'm still learning about this, but I can give you my 2 cents as of now, > >>> to > >>> open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous > >>> because the flash may not recover from unexpected resets. Entering one > >>> of > >>> these modes can be: > >>> 1/ volatile selectable, the device return to the 1-1-1 protocol after > >>> the > >>> next power-on. I guess this is conditioned by the optional RESET pin, > >>> but > >>> I'll have to check. Also the flash can return to the 1-1-1 mode using > >>> the > >>> software reset or through writing to its Configuration Register, without > >>> power-on or power- off. > >> > >> My understanding is that there's no standard software reset procedure > >> that guarantees no conflict with existing 1S commands, so even the > >> software reset approach doesn't work here. > > > > The software reset procedure can't protect you from unexpected resets, but > > the hardware with its optional reset pin can. Pratyush to confirm. > > > > cut > > > >>> Not recovering from unexpected resets is unacceptable. One should always > >>> prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 > >>> with > >>> the presence of the optional RESET pin. > >> > >> Totally agree with you on that one, but we know what happens in > >> practice... > > > > What I proposed is to condition the entering in the state-full modes with > > the presence of the optional RESET pin. We would introduce an optional > > device tree property for the RESET pin. If hardware doesn't implement the > > optional RESET# signal, then we will not enter in the state-full modes. > > Are you asking for dedicated SW controllable reset line or just an > indication from DT that OSPI reset line is connected to board level > soft/hard reset lines? I don't see a need for the reset line to be SW controllable, a simple indication from the device tree should be enough. > > Mandating SW controllable RESET line is bit of a stretch IMO... Board > design may not allow wasting dedicated pin due to lack of GPIOs perhaps.. > > For eg.: TI EVM has OSPI reset line connected to board level reset out. > This ensures any soft/warm/hard CPU reset will trigger OSPI Flash reset, > but there is no SW control that allows OSPI flash alone to be reset. > Isn't such a reset mechanism sufficient? > I think it is, yes. Cheers, ta
On 12/05/20 11:29AM, Tudor.Ambarus@microchip.com wrote: > Hi, Vignesh, > > > > The software reset procedure can't protect you from unexpected > > > resets, but > > > the hardware with its optional reset pin can. Pratyush to confirm. > > > > > > cut > > > > > >>> Not recovering from unexpected resets is unacceptable. One should always > > >>> prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 > > >>> with > > >>> the presence of the optional RESET pin. > > >> > > >> Totally agree with you on that one, but we know what happens in > > >> practice... > > > > > > What I proposed is to condition the entering in the state-full modes with > > > the presence of the optional RESET pin. We would introduce an optional > > > device tree property for the RESET pin. If hardware doesn't implement the > > > optional RESET# signal, then we will not enter in the state-full modes. > > > > Are you asking for dedicated SW controllable reset line or just an > > indication from DT that OSPI reset line is connected to board level > > soft/hard reset lines? > > I don't see a need for the reset line to be SW controllable, a simple > indication from the device tree should be enough. We already have the property "broken-flash-reset". Should we re-use it or should we have a opt-in property instead of an opt-out one? > > > > Mandating SW controllable RESET line is bit of a stretch IMO... Board > > design may not allow wasting dedicated pin due to lack of GPIOs perhaps.. > > > > For eg.: TI EVM has OSPI reset line connected to board level reset out. > > This ensures any soft/warm/hard CPU reset will trigger OSPI Flash reset, > > but there is no SW control that allows OSPI flash alone to be reset. > > Isn't such a reset mechanism sufficient? > > > > I think it is, yes.