raw nand: Accessing R/B# through GPIO never used

[Alexander Dahl]

Hei hei,

meanwhile we made a custom board with SAM9X60 and a Spansion S34ML02G1 SLC 
flash, and I learned some more things here.

Am Freitag, 11. August 2023, 08:40:23 CET schrieb Alexander Dahl:
> Hello flash developers,
> 
> I'm currently evaluating the nice Microchip SAM9X60-Curiosity board
> for booting from NAND flash.  Is has a at91 SAM9X60 SoC, a Macronix
> MX30LF4G28AD 4Gbit flash chip and uses the new atmel raw nand driver
> contributed by Boris Brezillon back in 2017 based on different older
> drivers.  NAND flash access in Linux works fine and out of the box
> with current mainline, I did not expect anything else.

All things observed and mentioned here happen with the curiosity board, too.

> When trying to get the NAND flash access working in U-Boot I noticed a
> strange behaviour.  You can see the whole thread here:
> 
> https://lore.kernel.org/u-boot/20230809-marvelous-number-8e973a3bb5e0@ifak-s
> ystem.com/T/#t
> 
> What got me wondering is the behaviour with regard to the R/B# line of
> the flash chip.  According to the chips datasheet (and datasheet of
> other raw NAND flash chips we used before, e.g. a Spansion® S34ML02G1
> 2Gbit chip) that pin is somewhat optional to use, right?  You can get
> the same information through an access of bit 6 in the status register
> of the flash chip.  We learned this a few years ago when trying to
> make raw nand work with an at91 sama5d2 in U-Boot, where U-Boot had
> only an old driver for the atmel nand controller which did not work
> with the pio4 GPIO controller of the SoC, so accessing R/B# through
> GPIO was not possible, but thanks to the other way (status bit) you
> could get it to run.
> 
> Note: the SoC's nand flash controller we are talking about here (SMC
> in SAM9X60) has no native R/B# line support and the SAM9X60 datasheet
> explicitly recommends to connect that pin to a GPIO.
> 
> Now the problem in recent U-Boot with proper GPIO access is: it takes
> ages for some flash operations to complete.  The gpio signal stays 0
> for several hundrets (!) of milliseconds until the read from the pin
> gets 1 (confirmed by debug print in modified U-Boot source).  My
> workaround for now is removing the 'rb-gpios' property from U-Boot
> dts, that way flash access is reasonably fast.

I tried again with recent U-Boot 2024.01 and the behaviour is still the same, 
you should be able to reproduce this with mainline U-Boot and the sam9x60-
curiosity board.

> So I wondered what the Linux driver makes different.
> 
> Turns out: if I am not mistaken, the Linux driver does not consider
> that R/B# line at all.  Why?  The GPIO is determined in DTS through
> the property 'rb-gpios' which is well documented in device tree
> bindings docs, and used in numerous dts files over different vendors.
> However that property is not evaluated in a single driver?!  My
> conclusion is: no driver ever accesses that pin and everything just
> works through status bit register access, right?
> 
> Can anyone confirm that?

I was mistaken.  See this call:

https://elixir.bootlin.com/linux/v6.8-rc7/source/drivers/mtd/nand/raw/atmel/
nand-controller.c#L1688

Following the function devm_fwnode_gpiod_get_index() the parameter "con_id" is 
passed along through several functions down to of_find_gpio() and when passed 
"foo" that says:

    /* Try GPIO property "foo-gpios" and "foo-gpio" */

So it tries several suffixes for "foo", that is why a simple grep does not 
find anything.  In the particular case passing "rb" to 
devm_fwnode_gpiod_get_index() would find the "rb-gpios" which is described in 
dt bindings.  

Thanks to frieder in IRC for pointing me.  This mail is to have that wisdom 
archived.

> Bonus questions:
> 
> Has anyone tried to really access that line through GPIO if the SoC
> requires that and how does that R/B# line behave over different flash
> chips then?  Can this be a problem of the NAND flash chip itself?  Is it
> safe to go with "soft wait" through status bit access only?

Fun findings: unlike U-Boot where using that GPIO does _not_ work for me, the 
NAND flash access on SAM9X60 in Linux _only_ works with that dts property 
present and thus the linux driver using nand_gpio_waitrdy() instead of 
nand_soft_waitrdy() (which it would use if that dts property would be 
missing).  In the latter case I only get zeros as data, making it impossible 
to read anything useful from the flash.

> (Note: it's not easily possible to analyse this with an oscilloscope
> or logic analyzer on the sam9x60-curiosity board, because the line in
> question is a direct pcb trace from a ball of one chip to a ball of
> the other chip.  Similar for other connections from NAND to SoC.)

Well on our custom board the flash comes in TSOP package, so we might be able 
to investigate that in depth later.  Of course any other insights welcome. :-)

Greets
Alex

> 
> Hoping someone can shed some light on this topic.
> 
> Greets
> Alex
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/