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

[Alexander Dahl]

Hei hei,

maybe that whole story was to long to grasp?  But gentle ping if
someone has some spare time to read.  I'm still curious why this
happens and why that device tree property is used all over numerous
device tree files but in no driver?!  See below.

Greets
Alex

Am Fri, Aug 11, 2023 at 08:40:23AM +0200 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.
> 
> 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
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/