Re: [PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60
Hello, just a short supplement … Am Wed, Aug 09, 2023 at 09:40:15AM +0200 schrieb Alexander Dahl: > Hello everyone, > > I had a closer look into the SAMA5D2 Series Datasheet and the SAM9X60 > Data Sheet again. See below. > > Am Tue, Aug 08, 2023 at 05:00:48PM +0200 schrieb Alexander Dahl: > > Hello Mihai, > > > > Am Tue, Aug 08, 2023 at 01:40:26PM + schrieb mihai.s...@microchip.com: > > > 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. > > > > Maybe I should add: currently there are two different drivers for > > atmel raw nand controllers in U-Boot, the old non-DM driver used by > > sam9g20 or sama5 based boards for example and a new driver used by > > sam9x60 based boards. We are talking about sam9x60 and the new driver > > in 'drivers/mtd/nand/raw/atmel/nand-controller.c' here. > > The old one is enabled by CONFIG_NAND_ATMEL, the new one by > CONFIG_DM_NAND_ATMEL instead. > > > > > 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> > > > > Although the new U-Boot driver tests for that, it is not documented in > > U-Boot devicetree bindings. According to Linux kernel (v6.4) device > > tree binding documentation it is only meaningful for sama5. Those > > binding documentation was added to Linux back in 2019 by Boris > > Brezillon. And that line is not present in the dts file for > > sam9x60-curiosity in Linux, so access is fast on Linux without that > > line (this is the part I don't understand yet). > > > > From what I saw in datasheets sam9x60 and sama5d2 have different > > controllers (named 'SMC' and 'HSMC') and the U-Boot driver reflects > > that. That's why I did not add 'atmel,rb' to dts before, I though SMC > > is the older one which does not support native R/B line handling? > > (And because I took it from U-Boot sam9x60ek.dts which also does not have > > it.) > > > > Nevertheless, I tried to add it now in U-Boot as you suggested > > (although without adapting pinctrl), and to my suprise it works … o.O > > > > Trying the same in Linux leads to not finding a
Re: [PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60
Hello everyone, I had a closer look into the SAMA5D2 Series Datasheet and the SAM9X60 Data Sheet again. See below. Am Tue, Aug 08, 2023 at 05:00:48PM +0200 schrieb Alexander Dahl: > Hello Mihai, > > Am Tue, Aug 08, 2023 at 01:40:26PM + schrieb mihai.s...@microchip.com: > > 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. > > Maybe I should add: currently there are two different drivers for > atmel raw nand controllers in U-Boot, the old non-DM driver used by > sam9g20 or sama5 based boards for example and a new driver used by > sam9x60 based boards. We are talking about sam9x60 and the new driver > in 'drivers/mtd/nand/raw/atmel/nand-controller.c' here. The old one is enabled by CONFIG_NAND_ATMEL, the new one by CONFIG_DM_NAND_ATMEL instead. > > > 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> > > Although the new U-Boot driver tests for that, it is not documented in > U-Boot devicetree bindings. According to Linux kernel (v6.4) device > tree binding documentation it is only meaningful for sama5. Those > binding documentation was added to Linux back in 2019 by Boris > Brezillon. And that line is not present in the dts file for > sam9x60-curiosity in Linux, so access is fast on Linux without that > line (this is the part I don't understand yet). > > From what I saw in datasheets sam9x60 and sama5d2 have different > controllers (named 'SMC' and 'HSMC') and the U-Boot driver reflects > that. That's why I did not add 'atmel,rb' to dts before, I though SMC > is the older one which does not support native R/B line handling? > (And because I took it from U-Boot sam9x60ek.dts which also does not have > it.) > > Nevertheless, I tried to add it now in U-Boot as you suggested > (although without adapting pinctrl), and to my suprise it works … o.O > > Trying the same in Linux leads to not finding a NAND device and thus > failing of the atmel-nand-controller driver probe. >From datasheet POV this all makes sense. The HSMC on SAMA5D2 has a native NANDRDY signal/peripheral function to handle the R/B pin of the flash and can do the low level communication by itself with an embedded Nand Flash
Re: [PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60
Hello Mihai,
Am Tue, Aug 08, 2023 at 01:40:26PM + schrieb mihai.s...@microchip.com:
> 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.
Maybe I should add: currently there are two different drivers for
atmel raw nand controllers in U-Boot, the old non-DM driver used by
sam9g20 or sama5 based boards for example and a new driver used by
sam9x60 based boards. We are talking about sam9x60 and the new driver
in 'drivers/mtd/nand/raw/atmel/nand-controller.c' here.
> >
> > 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>
Although the new U-Boot driver tests for that, it is not documented in
U-Boot devicetree bindings. According to Linux kernel (v6.4) device
tree binding documentation it is only meaningful for sama5. Those
binding documentation was added to Linux back in 2019 by Boris
Brezillon. And that line is not present in the dts file for
sam9x60-curiosity in Linux, so access is fast on Linux without that
line (this is the part I don't understand yet).
>From what I saw in datasheets sam9x60 and sama5d2 have different
controllers (named 'SMC' and 'HSMC') and the U-Boot driver reflects
that. That's why I did not add 'atmel,rb' to dts before, I though SMC
is the older one which does not support native R/B line handling?
(And because I took it from U-Boot sam9x60ek.dts which also does not have
it.)
Nevertheless, I tried to add it now in U-Boot as you suggested
(although without adapting pinctrl), and to my suprise it works … o.O
Trying the same in Linux leads to not finding a NAND device and thus
failing of the atmel-nand-controller driver probe.
(Note: all this while booting from SD card, so at91bootstrap should
not interfere, because it does not touch nand.)
What I did not test yet:
- How it behaves in U-Boot when also adapting pinctrl
- How other combinations of adaptions to dts behave in Linux
Sending this mail now anyway, it's too long already and office time is
up for today. Will do more systematic tests tomorrow. Any more
insights welcome.
Greets
Alex
> # nand@3 {
> # reg = <0x3 0x0 0x80>;
> # atmel,rb = <0>;
> # cs-gpios = < 4 GPIO_ACTIVE_HIGH>;
> # rb-gpios = < 5 GPIO_ACTIVE_HIGH>;
> #
RE: [PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60
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 0x80>;
# atmel,rb = <0>;
# cs-gpios = < 4 GPIO_ACTIVE_HIGH>;
# rb-gpios = < 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
Re: [PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60
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? 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
