From: "Gaëtan Carlier" <gcembed@gmail.com> To: Sascha Hauer <s.hauer@pengutronix.de> Cc: Artem Bityutskiy <dedekind1@gmail.com>, J.Lambrecht@televic.com, Juergen Beisert <jbe@pengutronix.de>, linux-mtd@lists.infradead.org, Sascha Hauer <kernel@pengutronix.de>, David Woodhouse <dwmw2@infradead.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 1/1] mxc_nand : allow swapping the Bad block Indicator for NFC v1. Date: Wed, 26 Mar 2014 14:53:33 +0100 [thread overview] Message-ID: <5332DBDD.4090802@gmail.com> (raw) In-Reply-To: <20120911071715.GB18243@pengutronix.de> Hi, On 09/11/2012 09:17 AM, Sascha Hauer wrote: > On Mon, Sep 10, 2012 at 04:31:23PM +0200, Gaëtan Carlier wrote: >> Hi Juergen, >> On 09/06/2012 10:56 AM, Juergen Beisert wrote: >>> Hi Gaëtan, >>> >>> Gaëtan Carlier wrote: >>>> Any comments for this patch ? >>> >>> Sorry, a little bit late. >>> >>>> Swap the BI-byte on position 0x7D0 with a data byte at 0x835. To fix a bug >>>> in Freescale imx NFC v1 SoC's for 2K page NAND flashes: imx27 and imx31. >>>> Warning: The same solution needs to be applied to the boot loader and the >>>> flash programmer. >>> >>> What sense does it make to swap the bytes at offset 0x7D0 and 0x835? >>> >>> Background: the NFC in the i.MX27/i.MX31 (NFCv1) and i.MX25/i.MX35 (NFCv2) can >>> only handle 512 byte pages with 16 bit OOB at once. To get them work with 2 k >>> page NANDs they only do the 512 + 16 step four times. The result is, a 2 k >>> page NAND is not handled as 2 k data and 64 bytes OOB, its handled instead as >>> a stream of 2112 bytes: >>> >>> |<-------- 2112 bytes --------->| >>> 512+16 | 512+16 | 512+16 | 512+16 >>> >>> Which means the NFC mixes data and OOB/checksums into its internal SRAM. But >>> all upper routines still use this SRAM content with a 2048 (data) + 64 (OOB) >>> bytes layout (to be more precise also the NFC hardware uses this layout). >>> Result is, the factory bad block markers are lost, because the NFC stores the >>> first 48 bytes from each OOB into the SRAM's data area (beginning with offset >>> 2000 (= 0x7D0) in the data area). >>> >>> So, the main goal of this swap patch should be to keep the factory bad block >>> markers _and_ to make use of them. >>> >>> But the i.MX driver does not register its own bad block pattern description, >>> so the default one is used with the BBM at position NAND_LARGE_BADBLOCK_POS >>> (which means offset 0 in the OOB area). >>> >>> So, I think, all upper layers still search for the BBM at offset 0 of the OOB >>> area, which results to SRAM's offset 0x800 (for NFCv1) and not 0x835. This >>> means this patch keeps the factory bad block markers, but they won't still be >>> used as expected. >>> >>> IMHO the bytes at SRAM's offset 0x7D0 and 0x800 for the NFCv1 must be swapped >>> (and 0x7D0 and 0x1000 for the NFCv2) to keep the factory bad block markers >>> _and_ to make use of them. Or am I wrong? >>> >>> Regards, >>> Juergen >>> >> The point is not the necessity of swapping bytes if factory bad >> block markers are not used. >> In my case, the bytes must be swapped because all previous >> operations on flash swapped these bytes : >> * Flashes redboot (bootloader) via JTAG using OpenOCD which swaps bytes; >> * Writes kernel and rootfs via TFTP using redboot which swaps bytes; >> So to be able to read rootfs partition, mxc-nand driver have to swap >> bytes otherwise, JFFS2 detects error on partition and is unable to >> mount it. > > I am all in favour to be able to swap the factory bad block marker with > the position the mtd framework expects it. > > That according to our understanding are bytes 0x7d0 in the main area > and byte 0x0 in the spare area. > >> >> I have not chosen to swap these bytes. In a training, I received >> redboot and kernel 2.6.22 with set of patches to support i.MX27 and >> these patches included swap of bytes in nand driver. So I start my >> development with this workaround and it is now impossible to get >> back because boards are already in production. > > So you are swapping the factory bad block marker with some position > where the mtd layer does not expect the bad block marker. With this > you preserve the factor bad block marker, but do not use it to detect > bad blocks. I don't see where the problem is. The fact that bad block marker are used or not, is not related to "my" patch. This patch just places data where they should be. If I take the Nand and connect it to a not-bugged NFC controller, all data will be read correctly with data is main area and OOB is spare area. > > In this form the patch is simply not correct and should be dropped. > Now I want to adapt and publish my platform file to latest kernel version and I am still stopped with this biswap patch that is not applied. As I said before, I must not be the only that have used this damned original patch from Freescale that swaps byte in their ATK programming soft, redboot and Kernel and it is impossible to fallback to current NAND handling (without swapping). Is there any chance that if I send this patch against linux-next/master branch, it will be finally accepted. Only people that needs it will use it. There is so much option in menuconfig with so little explaination and mark as "Only say Yes if you known what you do". > Sascha > Thank you. Best regards, Gaëtan Carlier.
WARNING: multiple messages have this Message-ID (diff)
From: gcembed@gmail.com (Gaëtan Carlier) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/1] mxc_nand : allow swapping the Bad block Indicator for NFC v1. Date: Wed, 26 Mar 2014 14:53:33 +0100 [thread overview] Message-ID: <5332DBDD.4090802@gmail.com> (raw) In-Reply-To: <20120911071715.GB18243@pengutronix.de> Hi, On 09/11/2012 09:17 AM, Sascha Hauer wrote: > On Mon, Sep 10, 2012 at 04:31:23PM +0200, Ga?tan Carlier wrote: >> Hi Juergen, >> On 09/06/2012 10:56 AM, Juergen Beisert wrote: >>> Hi Ga?tan, >>> >>> Ga?tan Carlier wrote: >>>> Any comments for this patch ? >>> >>> Sorry, a little bit late. >>> >>>> Swap the BI-byte on position 0x7D0 with a data byte at 0x835. To fix a bug >>>> in Freescale imx NFC v1 SoC's for 2K page NAND flashes: imx27 and imx31. >>>> Warning: The same solution needs to be applied to the boot loader and the >>>> flash programmer. >>> >>> What sense does it make to swap the bytes at offset 0x7D0 and 0x835? >>> >>> Background: the NFC in the i.MX27/i.MX31 (NFCv1) and i.MX25/i.MX35 (NFCv2) can >>> only handle 512 byte pages with 16 bit OOB at once. To get them work with 2 k >>> page NANDs they only do the 512 + 16 step four times. The result is, a 2 k >>> page NAND is not handled as 2 k data and 64 bytes OOB, its handled instead as >>> a stream of 2112 bytes: >>> >>> |<-------- 2112 bytes --------->| >>> 512+16 | 512+16 | 512+16 | 512+16 >>> >>> Which means the NFC mixes data and OOB/checksums into its internal SRAM. But >>> all upper routines still use this SRAM content with a 2048 (data) + 64 (OOB) >>> bytes layout (to be more precise also the NFC hardware uses this layout). >>> Result is, the factory bad block markers are lost, because the NFC stores the >>> first 48 bytes from each OOB into the SRAM's data area (beginning with offset >>> 2000 (= 0x7D0) in the data area). >>> >>> So, the main goal of this swap patch should be to keep the factory bad block >>> markers _and_ to make use of them. >>> >>> But the i.MX driver does not register its own bad block pattern description, >>> so the default one is used with the BBM at position NAND_LARGE_BADBLOCK_POS >>> (which means offset 0 in the OOB area). >>> >>> So, I think, all upper layers still search for the BBM at offset 0 of the OOB >>> area, which results to SRAM's offset 0x800 (for NFCv1) and not 0x835. This >>> means this patch keeps the factory bad block markers, but they won't still be >>> used as expected. >>> >>> IMHO the bytes at SRAM's offset 0x7D0 and 0x800 for the NFCv1 must be swapped >>> (and 0x7D0 and 0x1000 for the NFCv2) to keep the factory bad block markers >>> _and_ to make use of them. Or am I wrong? >>> >>> Regards, >>> Juergen >>> >> The point is not the necessity of swapping bytes if factory bad >> block markers are not used. >> In my case, the bytes must be swapped because all previous >> operations on flash swapped these bytes : >> * Flashes redboot (bootloader) via JTAG using OpenOCD which swaps bytes; >> * Writes kernel and rootfs via TFTP using redboot which swaps bytes; >> So to be able to read rootfs partition, mxc-nand driver have to swap >> bytes otherwise, JFFS2 detects error on partition and is unable to >> mount it. > > I am all in favour to be able to swap the factory bad block marker with > the position the mtd framework expects it. > > That according to our understanding are bytes 0x7d0 in the main area > and byte 0x0 in the spare area. > >> >> I have not chosen to swap these bytes. In a training, I received >> redboot and kernel 2.6.22 with set of patches to support i.MX27 and >> these patches included swap of bytes in nand driver. So I start my >> development with this workaround and it is now impossible to get >> back because boards are already in production. > > So you are swapping the factory bad block marker with some position > where the mtd layer does not expect the bad block marker. With this > you preserve the factor bad block marker, but do not use it to detect > bad blocks. I don't see where the problem is. The fact that bad block marker are used or not, is not related to "my" patch. This patch just places data where they should be. If I take the Nand and connect it to a not-bugged NFC controller, all data will be read correctly with data is main area and OOB is spare area. > > In this form the patch is simply not correct and should be dropped. > Now I want to adapt and publish my platform file to latest kernel version and I am still stopped with this biswap patch that is not applied. As I said before, I must not be the only that have used this damned original patch from Freescale that swaps byte in their ATK programming soft, redboot and Kernel and it is impossible to fallback to current NAND handling (without swapping). Is there any chance that if I send this patch against linux-next/master branch, it will be finally accepted. Only people that needs it will use it. There is so much option in menuconfig with so little explaination and mark as "Only say Yes if you known what you do". > Sascha > Thank you. Best regards, Ga?tan Carlier.
next prev parent reply other threads:[~2014-03-26 13:53 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-08-15 13:04 [PATCH v2] mxc_nand : allow swapping the Bad block Indicator for NFC v1 Gaëtan Carlier 2012-08-15 13:04 ` Gaëtan Carlier 2012-08-24 12:28 ` Artem Bityutskiy 2012-08-24 12:28 ` Artem Bityutskiy 2012-08-24 16:17 ` [PATCH 1/1] " Gaëtan Carlier 2012-08-24 16:17 ` Gaëtan Carlier 2012-08-28 10:33 ` Gaëtan Carlier 2012-08-28 10:33 ` Gaëtan Carlier 2012-08-29 7:56 ` Artem Bityutskiy 2012-08-29 7:56 ` Artem Bityutskiy 2012-09-06 8:56 ` Juergen Beisert 2012-09-06 8:56 ` Juergen Beisert 2012-09-10 14:31 ` Gaëtan Carlier 2012-09-10 14:31 ` Gaëtan Carlier 2012-09-11 7:17 ` Sascha Hauer 2012-09-11 7:17 ` Sascha Hauer 2012-09-11 8:03 ` Gaëtan Carlier 2012-09-11 8:03 ` Gaëtan Carlier 2012-09-11 8:47 ` Sascha Hauer 2012-09-11 8:47 ` Sascha Hauer 2012-09-23 13:00 ` Artem Bityutskiy 2012-09-23 13:00 ` Artem Bityutskiy 2014-03-26 13:53 ` Gaëtan Carlier [this message] 2014-03-26 13:53 ` Gaëtan Carlier 2014-03-28 9:11 ` Sascha Hauer 2014-03-28 9:11 ` Sascha Hauer 2014-03-28 9:52 ` Gaëtan Carlier 2014-03-28 9:52 ` Gaëtan Carlier 2012-09-06 13:03 ` Juergen Beisert 2012-09-06 13:03 ` Juergen Beisert
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=5332DBDD.4090802@gmail.com \ --to=gcembed@gmail.com \ --cc=J.Lambrecht@televic.com \ --cc=dedekind1@gmail.com \ --cc=dwmw2@infradead.org \ --cc=jbe@pengutronix.de \ --cc=kernel@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mtd@lists.infradead.org \ --cc=s.hauer@pengutronix.de \ /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.