[PATCH v3 3/4] spi-nor: Adapt soft reset to XTX25F32B in Rock Pi 4 rev 1.4

[Pratyush Yadav]

On 26/07/22 10:27AM, Xavier Drudis Ferran wrote:
> 
> Thank you for your time looking at the patch. 
> 
> El Tue, Jul 26, 2022 at 12:43:06PM +0530, Pratyush Yadav deia:
> > 
> > Please don't put the changelog in the commit message. Put it below the 3 
> > dashed lines below.
> >
> 
> Sorry. Will try to remember it next time. Not sure there's a next version of
> this patch, though. 
>  
> > 
> > This only tells if the _controller_ supports the op. There is no way to 
> > find out if the flash supports the op without reading SFDP, which would 
> > need you to either reset the flash or know which mode it is in.
> 
> Correct. But you can't always read the SFDP if you get the flash in 
> some wrong state and try to reset it through a mode that the controller
> doesn't support. 
> 
> >  So this patch is all wrong.
> 
> Then I won't send a 4th version unless someone else thinks it's worth
> it and I have more time for it.
>  
> > The only way to find out what the flash supports is to read its ID or 
> > SFDP.
> > 
> 
> Chicken and egg ? The soft_reset is done before reading SFDP. 
> It was done always in octal mode before my patch ("always" means
> whenever CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT was enabled). My
> patch tries to do it in a mode that the controller supports. 

Yes, this is indeed a chicken and egg problem of sorts. The octal mode 
soft reset I added is a hack that gets _some_ flashes working but not 
all. I see 3 possible ways to solve this:

  1. Encode soft reset type in device tree. Read DT to issue the correct 
     type of reset. But if a flash supports multiple stateful modes like 
     4D-4D-4D and 8D-8D-8D, this might not work so well.
  2. Do a hardware reset. This needs the RESET# line to be connected on 
     the board and some way to toggle it. Does not work for boards that 
     do not have this.
  3. Discover the mode the flash is in. The SFDP spec (JESD216D-01) does 
     recommend a way to do this in section "4.5 Command Modes". This can 
     let us find out which type of soft reset command the flash takes by 
     reading SFDP. Of course, this needs the flash to implement the read 
     SFDP command in all modes, which is not mandatory as per spec (at 
     least as per xSPI spec (JESD251), which documents 8D-8D-8D 
     flashes).

There is no one size fits all solution that I can see, so I think we 
need to do all 3 to get full coverage of all cases. But start with the 
one that fixes your use case and is easiest for you. I would guess that 
is point 2.

And all this does not even fix the problem of flashes that do not 
support 1S-1S-1S mode at all. There are some flashes out there that 
simply only support 8D-8D-8D mode. For those flashes, a reset would 
still put them in 8D-8D-8D mode. To support those you need to discover 
the flash mode and then initialize the flash in that mode itself, 
without resetting.

I would recommending working with the Linux SPI NOR subsystem first. 
That has more eyes looking at it so it would be easier to come up with a 
good solution. Then you can backport it to U-Boot.

> 
> In my experiments this helps being able to program /dev/mtd0 from
> linux with flashrom. If that is working in mainstream U-Boot on a Rock
> Pi 4B version 1.4 or later (with XTX flash) for the rest of people,
> then I must be testing wrong, what do I know?
> 
> Thanks. Have a nice day.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.