From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Johan Jonker <jbx6244@gmail.com>
Cc: richard@nod.at, vigneshr@ti.com, heiko@sntech.de,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, yifeng.zhao@rock-chips.com
Subject: Re: [PATCH v2 1/5] mtd: nand: raw: rockchip-nand-controller: copy hwecc PA data to oob_poi buffer
Date: Mon, 12 Jun 2023 19:40:56 +0200 [thread overview]
Message-ID: <20230612194056.7b27edc5@xps-13> (raw)
In-Reply-To: <b4e73d0f-d3de-b3e1-26a4-cce5337fe07e@gmail.com>
Hi Johan,
jbx6244@gmail.com wrote on Mon, 12 Jun 2023 17:02:40 +0200:
> Rockchip boot blocks are written per 4 x 512 byte sectors per page.
> Each page must have a page address (PA) pointer in OOB to the next page.
> Pages are written in a pattern depending on the NAND chip ID.
> This logic used to build a page pattern table is not fully disclosed and
> is not easy to fit in the MTD framework.
> The formula in rk_nfc_write_page_hwecc() function is not correct.
> Make hwecc and raw behavior identical.
> Generate boot block page address and pattern for hwecc in user space
> and copy PA data to/from the last 4 bytes in the
> chip->oob_poi data layout.
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
> .../mtd/nand/raw/rockchip-nand-controller.c | 34 ++++++++++++-------
> 1 file changed, 21 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c
> index 2312e2736..cafccc324 100644
> --- a/drivers/mtd/nand/raw/rockchip-nand-controller.c
> +++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c
> @@ -597,7 +597,7 @@ static int rk_nfc_write_page_hwecc(struct nand_chip *chip, const u8 *buf,
> int pages_per_blk = mtd->erasesize / mtd->writesize;
> int ret = 0, i, boot_rom_mode = 0;
> dma_addr_t dma_data, dma_oob;
> - u32 reg;
> + u32 tmp;
> u8 *oob;
>
> nand_prog_page_begin_op(chip, page, 0, NULL, 0);
> @@ -624,6 +624,13 @@ static int rk_nfc_write_page_hwecc(struct nand_chip *chip, const u8 *buf,
> *
> * 0xFF 0xFF 0xFF 0xFF | BBM OOB1 OOB2 OOB3 | ...
> *
> + * The code here just swaps the first 4 bytes with the last
> + * 4 bytes without losing any data.
Maybe you don't loose any data, but you basically break all existing
jffs2 users, right? Is this page address only useful on your rk SoC or
are all the SoCs using the same logic?
I think it would be best to flag where this is required and avoid a
massive incompatible change like this one (and the previous one). BTW,
any reason not to merge the two first patches? It seems like the series
would not be bisectable between the two first commits.
Patches 4 and 5 look good as they are not directly related, I'll queue
them, you can avoid re-sending them.
> + *
> + * The chip->oob_poi data layout:
> + *
> + * BBM OOB1 OOB2 OOB3 |......| PA0 PA1 PA2 PA3
> + *
> * Configure the ECC algorithm supported by the boot ROM.
> */
> if ((page < (pages_per_blk * rknand->boot_blks)) &&
> @@ -634,21 +641,17 @@ static int rk_nfc_write_page_hwecc(struct nand_chip *chip, const u8 *buf,
> }
>
> for (i = 0; i < ecc->steps; i++) {
> - if (!i) {
> - reg = 0xFFFFFFFF;
> - } else {
> + if (!i)
> + oob = chip->oob_poi + (ecc->steps - 1) * NFC_SYS_DATA_SIZE;
> + else
> oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE;
> - reg = oob[0] | oob[1] << 8 | oob[2] << 16 |
> - oob[3] << 24;
> - }
>
> - if (!i && boot_rom_mode)
> - reg = (page & (pages_per_blk - 1)) * 4;
> + tmp = oob[0] | oob[1] << 8 | oob[2] << 16 | oob[3] << 24;
>
> if (nfc->cfg->type == NFC_V9)
> - nfc->oob_buf[i] = reg;
> + nfc->oob_buf[i] = tmp;
> else
> - nfc->oob_buf[i * (oob_step / 4)] = reg;
> + nfc->oob_buf[i * (oob_step / 4)] = tmp;
> }
>
> dma_data = dma_map_single(nfc->dev, (void *)nfc->page_buf,
> @@ -811,12 +814,17 @@ static int rk_nfc_read_page_hwecc(struct nand_chip *chip, u8 *buf, int oob_on,
> goto timeout_err;
> }
>
> - for (i = 1; i < ecc->steps; i++) {
> - oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE;
> + for (i = 0; i < ecc->steps; i++) {
> + if (!i)
> + oob = chip->oob_poi + (ecc->steps - 1) * NFC_SYS_DATA_SIZE;
> + else
> + oob = chip->oob_poi + (i - 1) * NFC_SYS_DATA_SIZE;
> +
> if (nfc->cfg->type == NFC_V9)
> tmp = nfc->oob_buf[i];
> else
> tmp = nfc->oob_buf[i * (oob_step / 4)];
> +
> *oob++ = (u8)tmp;
> *oob++ = (u8)(tmp >> 8);
> *oob++ = (u8)(tmp >> 16);
> --
> 2.30.2
>
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2023-06-12 17:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 15:00 [PATCH v2 0/5] Fixes for Rockchip NAND controller driver Johan Jonker
2023-06-12 15:02 ` [PATCH v2 1/5] mtd: nand: raw: rockchip-nand-controller: copy hwecc PA data to oob_poi buffer Johan Jonker
2023-06-12 17:40 ` Miquel Raynal [this message]
2023-06-12 15:02 ` [PATCH v2 2/5] mtd: nand: raw: rockchip-nand-controller: add skipbbt option Johan Jonker
2023-06-12 15:03 ` [PATCH v2 3/5] mtd: nand: raw: rockchip-nand-controller: fix oobfree offset and description Johan Jonker
2023-06-12 17:26 ` Miquel Raynal
2023-06-14 9:23 ` Johan Jonker
2023-06-14 16:01 ` Miquel Raynal
2023-06-12 15:03 ` [PATCH v2 4/5] mtd: nand: raw: add basic sandisk manufacturer ops Johan Jonker
2023-06-12 17:41 ` Miquel Raynal
2023-06-12 15:03 ` [PATCH v2 5/5] mtd: nand: add support for the Sandisk SDTNQGAMA chip Johan Jonker
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=20230612194056.7b27edc5@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=heiko@sntech.de \
--cc=jbx6244@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
--cc=yifeng.zhao@rock-chips.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox