Hi Alex,
Please find bellow my answer:
------------------------------
Added Mihai who tested this a lot at some point in time
Eugen
On 8/8/23 16:02, Alexander Dahl wrote:
> Hello everyone,
>
> this is a patch series wtih some real fixes _and_ a question or some
> kind of support request in the cover letter. I would be happy if
> anyone could read the cover letter carefully and answer to that one
> what might be the problem I see. O:-)
>
> I'm currently working on the sam9x60-curiosity board and especially
> trying to get it booting from onboard raw NAND flash. As reported in
> my last series I got the flash recognized already. However
> interacting with it was terribly slow, because nand_wait_ready()
> calling
> atmel_nand_dev_ready() ran into a 400ms timeout in several occasions,
> especially when reading from the device. Reading a single block
> triggered that timeout two times per page, which summed up to over 50
> seconds for 64 × 4096 = 256k Bytes!
>
> (You can have U-Boot print that warning from nand_wait_ready() by
> increasing the console log level to at least "warn".)
>
> Note: the dts from atmel/next seems correct to me, I double checked
> that again. My own debug log messages showed the GPIO is accessed,
> and if you add enough debug messages sometimes the timeout is not
> reached, so I'm sure the NAND chip eventually switches that R/B line
> and the code correctly sees that, that line level change however takes
> ages, something between 400ms and 500ms most of the times.
>
> I vaguely remembered on SAMA5D2 the old atmel raw nand driver is used
> which does not support reading the R/B signal, but nevertheless works.
> I'm not familiar in detail with those raw NAND flash chips, but as far
> as I can understand, there are other ways to determine if the chip is
> ready or busy. So after I removed that rb-gpio parameter from
> 'at91-sam9x60_curiosity.dts' I ran into the bug fixed by patch 2.
>
> With that patch applied _and_ rb-gpio still removed from dts, raw NAND
> access is reasonably fast on sam9x60-curiosity board. (You might want
> to rebase to atmel/next for testing this.) Not sure if I should send
> a patch for that dts change, because I suppose it's a workaround only
> and not addressing the actual cause?
>
> I think the fix is correct in itself, I tested different combinations
> and compared with the driver in Linux, however …
>
> Can anyone explain to me, why flash access is sooo slow if the R/B
> gpio is used? Especially in comparision to Linux, where I don't need
> to remove that thing from dts and it works reasonably fast?
// I'm sorry for quoting (email is sent from Outlook)
# Please add in your board dts: atmel,rb = <0>
# nand@3 {
# reg = <0x3 0x0 0x800000>;
# atmel,rb = <0>;
# cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
# rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
# nand-bus-width = <8>;
# nand-ecc-mode = "hw";
# nand-ecc-strength = <8>;
# nand-ecc-step-size = <512>;
# nand-on-flash-bbt;>
> The actual flash chip is a Macronix MX30LF4G28AD, 512 MiB, SLC, erase
> size: 256 KiB, page size: 4096, OOB size: 256.
>
> Greets
> Alex
>
> P.S.: although not returned by get_maintainer.pl I added Eugen to Cc
> because he is maintainer of the at91 and might have some insight if it
> is a general problem of the nand controller in at91 socs?
>
> Alexander Dahl (2):
> mtd: nand: raw: atmel: Remove duplicate line
> mtd: nand: raw: atmel: Add error handling when rb-gpios missing
>
> drivers/mtd/nand/raw/atmel/nand-controller.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
>
> base-commit: a169438411f9277cc689c14078151aa1d1caae3c
