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

[Xavier Drudis Ferran]

El Tue, Jul 26, 2022 at 02:39:09PM +0530, Pratyush Yadav deia:
> 
> 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:
> 

But it was a hack that solved a problem. We still have hunger, war and
disease, but we have some more flashes working. That's some good,
isn't it?

>   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.

So must flash chips always be listed in dts ?
Can some boards have a socket and users plug different flashes to it ? 
Might it then not work so well also ?
My idea was try what you can with the controller you have because you 
know more what controller you have than what flash you have (until you
can ask your flash who it is and what it looks like). This is only active when 
a nondefault kconfig is enabled, anyway.

>   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.

ACK.
Unfortunately not in my case[1]. 

>   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).
>

I think my XTX supports the soft reset according to the manual
(commands 66 and 99), but the SFDP info does not include info about
soft reset. I might misremember though.
 
> 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.
>

My XT25F32B-S has no hardware reset pin. The manual[2] says so in a sentence, 
in page 49 (out of context) and the pinout is : 
   
   - Chip Select Input (CS#)
   - Data Output(SO)  or I/O 1 (IO1)
   - Write Protect Input (WP#), or I/O2 (IO2)
   - Ground (VSS)
   - Data Input (SI), or I/O 0 (IO0)
   - Serial Clock Input (SCLK)
   - Hold Input (HOLD#)
   - Power Supply (VCC)
    
And of course the board does not have a line for the nonexistent pin,
so no, the closest to hardware reset would be board poweroff.  SI, SO,
CS and SCLK are connected to a 40 pin connector though, so I can
ground them or pull them up or something. But no use.

> 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.
> 

Well, maybe we can limit ourselves to solve solvable problems... That
should keep us busy for a while...

> 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.
>

Thanks for the advice. Makes sense I guess. I'll see if I have the time and
motivation. 

[1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4b_plus_v16_sch_20200628.pdf
[2] https://www.xtxtech.com/download/?AId=157