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

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

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

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?

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?

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

Hoping someone can shed some light on this topic.

Greets
Alex