From: Masahiro Yamada <yamada.masahiro@socionext.com> To: Tim Sander <tim@krieglstein.org> Cc: Vignesh Raghavendra <vigneshr@ti.com>, Dinh Nguyen <dinguyen@kernel.org>, Richard Weinberger <richard@nod.at>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marek Vasut <marek.vasut@gmail.com>, linux-mtd <linux-mtd@lists.infradead.org>, Miquel Raynal <miquel.raynal@bootlin.com>, Brian Norris <computersforpeace@gmail.com>, David Woodhouse <dwmw2@infradead.org> Subject: Re: mtd raw nand denali.c broken for Intel/Altera Cyclone V Date: Tue, 10 Sep 2019 16:16:37 +0900 [thread overview] Message-ID: <CAK7LNAR8xtURiCoJC0eWLFw0q+78Eb_axoOzWH+JNugf-24Qig@mail.gmail.com> (raw) In-Reply-To: <5143724.5TqzkYX0oI@dabox> On Fri, Sep 6, 2019 at 9:39 PM Tim Sander <tim@krieglstein.org> wrote: > > Hi > > I have noticed that there multiple breakages piling up for the denali nand > driver on the Intel/Altera Cyclone V. Unfortunately i had no time to track the > mainline kernel closely. So the breakage seems to pile up. I am a little > disapointed that Intel is not on the lookout that the kernel works on the > chips they are selling. I was really happy about the state of the platform > before concerning mainline support. > > The failure starts with kernel 4.19 or stable kernel release 4.18.19. The > commit is ba4a1b62a2d742df9e9c607ac53b3bf33496508f. Just for clarification, this corresponds to 0d55c668b218a1db68b5044bce4de74e1bd0f0c8 upstream. > The problem here is that > our platform works with a zero in the SPARE_AREA_SKIP_BYTES register. Please clarify the scope of "our platform". (Only you, or your company, or every individual using this chip?) First, SPARE_AREA_SKIP_BYTES is not the property of the hardware. Rather, it is about the OOB layout, in other words, this parameter is defined by software. For example, U-Boot supports the Denali NAND driver. The SPARE_AREA_SKIP_BYTES is a user-configurable parameter: https://github.com/u-boot/u-boot/blob/v2019.10-rc3/drivers/mtd/nand/raw/Kconfig#L112 Your platform works with a zero in the SPARE_AREA_SKIP_BYTES register because the NAND chip on the board was initialized with a zero set to the SPARE_AREA_SKIP_BYTES register. If the NAND chip had been initialized with 8 set to the SPARE_AREA_SKIP_BYTES register, it would have been working with 8 to the SPARE_AREA_SKIP_BYTES. The Boot ROM is the only (semi-)software that is unconfigurable by users, so the value of SPARE_AREA_SKIP_BYTES should be aligned with the boot ROM. I recommend you to check the spec of the boot ROM. (The maintainer of the platform, Dihn is CC'ed, so I hope he will jump in) Second, I doubt 0 is a good value for SPARE_AREA_SKIP_BYTES. As explained in commit log, SPARE_AREA_SKIP_BYTES==0 means the OOB is used for ECC without any offset. So, the BBM marked in the factory will be destroyed. > But in > this case the patch assumes the default value 8 which is straight out wrong > on this variant. Without this patch reverted all blocks of the nand flash are > beeing marked bad :-(. > > When reverting the patch ba4a1b62a2d742df9e9c607ac53b3bf33496508f i can boot > 4.19.10 again. > > With 5.0 the it goes further down the drain and i didn't manage to boot it > even with the above patch reverted. > > I also tried 5.3-rc7 with the above patch reverted and the variable t_x dirty hacked to the > value 0x1388 as i got the impression that the timing calculation is off too. I still get an > interrupt error and boot failure: git-bisect is a general solution to pin point the problem. BTW, if you end up with hacking the clock frequency, something is already wrong. denali->clk_rate, denali->clk_x_rate should be 50MHz, 200MHz, respectively. If not, please check the clock driver and your DT. > [ 0.817588] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda > [ 0.823946] nand: Micron MT29F2G08ABAEAWP > [ 0.827965] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > [ 1.887052] denali-nand-dt ff900000.nand: timeout while waiting for irq 0x1000 > [ 2.911056] denali-nand-dt ff900000.nand: timeout while waiting for irq 0x1000 > > I have seen this https://lore.kernel.org/patchwork/patch/983055/ thread and > this might fix at least the 4.19 boot problem. > > I would be really happy for hints how to get the Intel Cyclone V working again. > > Best regards > Tim > > > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- Best Regards Masahiro Yamada
WARNING: multiple messages have this Message-ID (diff)
From: Masahiro Yamada <yamada.masahiro@socionext.com> To: Tim Sander <tim@krieglstein.org> Cc: Vignesh Raghavendra <vigneshr@ti.com>, Marek Vasut <marek.vasut@gmail.com>, Richard Weinberger <richard@nod.at>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Dinh Nguyen <dinguyen@kernel.org>, linux-mtd <linux-mtd@lists.infradead.org>, Miquel Raynal <miquel.raynal@bootlin.com>, Brian Norris <computersforpeace@gmail.com>, David Woodhouse <dwmw2@infradead.org> Subject: Re: mtd raw nand denali.c broken for Intel/Altera Cyclone V Date: Tue, 10 Sep 2019 16:16:37 +0900 [thread overview] Message-ID: <CAK7LNAR8xtURiCoJC0eWLFw0q+78Eb_axoOzWH+JNugf-24Qig@mail.gmail.com> (raw) In-Reply-To: <5143724.5TqzkYX0oI@dabox> On Fri, Sep 6, 2019 at 9:39 PM Tim Sander <tim@krieglstein.org> wrote: > > Hi > > I have noticed that there multiple breakages piling up for the denali nand > driver on the Intel/Altera Cyclone V. Unfortunately i had no time to track the > mainline kernel closely. So the breakage seems to pile up. I am a little > disapointed that Intel is not on the lookout that the kernel works on the > chips they are selling. I was really happy about the state of the platform > before concerning mainline support. > > The failure starts with kernel 4.19 or stable kernel release 4.18.19. The > commit is ba4a1b62a2d742df9e9c607ac53b3bf33496508f. Just for clarification, this corresponds to 0d55c668b218a1db68b5044bce4de74e1bd0f0c8 upstream. > The problem here is that > our platform works with a zero in the SPARE_AREA_SKIP_BYTES register. Please clarify the scope of "our platform". (Only you, or your company, or every individual using this chip?) First, SPARE_AREA_SKIP_BYTES is not the property of the hardware. Rather, it is about the OOB layout, in other words, this parameter is defined by software. For example, U-Boot supports the Denali NAND driver. The SPARE_AREA_SKIP_BYTES is a user-configurable parameter: https://github.com/u-boot/u-boot/blob/v2019.10-rc3/drivers/mtd/nand/raw/Kconfig#L112 Your platform works with a zero in the SPARE_AREA_SKIP_BYTES register because the NAND chip on the board was initialized with a zero set to the SPARE_AREA_SKIP_BYTES register. If the NAND chip had been initialized with 8 set to the SPARE_AREA_SKIP_BYTES register, it would have been working with 8 to the SPARE_AREA_SKIP_BYTES. The Boot ROM is the only (semi-)software that is unconfigurable by users, so the value of SPARE_AREA_SKIP_BYTES should be aligned with the boot ROM. I recommend you to check the spec of the boot ROM. (The maintainer of the platform, Dihn is CC'ed, so I hope he will jump in) Second, I doubt 0 is a good value for SPARE_AREA_SKIP_BYTES. As explained in commit log, SPARE_AREA_SKIP_BYTES==0 means the OOB is used for ECC without any offset. So, the BBM marked in the factory will be destroyed. > But in > this case the patch assumes the default value 8 which is straight out wrong > on this variant. Without this patch reverted all blocks of the nand flash are > beeing marked bad :-(. > > When reverting the patch ba4a1b62a2d742df9e9c607ac53b3bf33496508f i can boot > 4.19.10 again. > > With 5.0 the it goes further down the drain and i didn't manage to boot it > even with the above patch reverted. > > I also tried 5.3-rc7 with the above patch reverted and the variable t_x dirty hacked to the > value 0x1388 as i got the impression that the timing calculation is off too. I still get an > interrupt error and boot failure: git-bisect is a general solution to pin point the problem. BTW, if you end up with hacking the clock frequency, something is already wrong. denali->clk_rate, denali->clk_x_rate should be 50MHz, 200MHz, respectively. If not, please check the clock driver and your DT. > [ 0.817588] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda > [ 0.823946] nand: Micron MT29F2G08ABAEAWP > [ 0.827965] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 > [ 1.887052] denali-nand-dt ff900000.nand: timeout while waiting for irq 0x1000 > [ 2.911056] denali-nand-dt ff900000.nand: timeout while waiting for irq 0x1000 > > I have seen this https://lore.kernel.org/patchwork/patch/983055/ thread and > this might fix at least the 4.19 boot problem. > > I would be really happy for hints how to get the Intel Cyclone V working again. > > Best regards > Tim > > > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- Best Regards Masahiro Yamada ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-09-10 7:17 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-06 12:38 mtd raw nand denali.c broken for Intel/Altera Cyclone V Tim Sander 2019-09-06 12:38 ` Tim Sander 2019-09-10 7:16 ` Masahiro Yamada [this message] 2019-09-10 7:16 ` Masahiro Yamada 2019-09-10 13:48 ` Tim Sander 2019-09-10 13:48 ` Tim Sander 2019-09-10 15:22 ` Dinh Nguyen 2019-09-10 15:22 ` Dinh Nguyen 2019-09-11 2:37 ` Masahiro Yamada 2019-09-11 2:37 ` Masahiro Yamada 2019-09-11 7:27 ` Tim Sander 2019-09-11 7:27 ` Tim Sander 2019-09-26 9:10 ` Tim Sander 2019-09-26 9:10 ` Tim Sander 2019-09-26 17:47 ` Masahiro Yamada 2019-09-26 17:47 ` Masahiro Yamada 2020-01-10 16:46 ` Tim Sander 2020-01-10 16:46 ` Tim Sander 2020-01-10 17:13 ` Marek Vasut 2020-01-10 17:13 ` Marek Vasut 2020-01-10 19:05 ` Masahiro Yamada 2020-01-10 19:05 ` Masahiro Yamada 2020-01-10 22:38 ` Tim Sander 2020-01-10 22:38 ` Tim Sander 2020-01-11 2:38 ` Masahiro Yamada 2020-01-11 2:38 ` Masahiro Yamada 2020-01-13 10:22 ` Tim Sander 2020-01-13 10:22 ` Tim Sander
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAK7LNAR8xtURiCoJC0eWLFw0q+78Eb_axoOzWH+JNugf-24Qig@mail.gmail.com \ --to=yamada.masahiro@socionext.com \ --cc=computersforpeace@gmail.com \ --cc=dinguyen@kernel.org \ --cc=dwmw2@infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=marek.vasut@gmail.com \ --cc=miquel.raynal@bootlin.com \ --cc=richard@nod.at \ --cc=tim@krieglstein.org \ --cc=vigneshr@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.