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.