[v2,3/5] mtd: nand: raw: rockchip-nand-controller: fix oobfree offset and description
Message ID | f2cebf54-a16c-c849-a988-bfd98c502748@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2666102vqr; Mon, 12 Jun 2023 08:24:59 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4EQ/wxn75iIPdCKZdvULmILbpmULMmvhtDMcW6pWUbVGT99bVxOb8JpmLIjGt4Y9esb3MW X-Received: by 2002:a05:6a00:b42:b0:64c:c5f9:152a with SMTP id p2-20020a056a000b4200b0064cc5f9152amr12399891pfo.23.1686583499720; Mon, 12 Jun 2023 08:24:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686583499; cv=none; d=google.com; s=arc-20160816; b=uZSK4EAPJPr8oUnTZK3ZK+pfvdtq2SGmsK0enl+0IRRjSLLw4kw4bbtsT8/5HZ7LcC PhUw+yZF/2hXatWB8Otv/OAqfIpzE84HbwEMRzOn8APyyTJ2nxxYqjmgk3Hvya7egYlk rPpfh9dMRQMf9EOUTNYvyEUVNNSptEQa74LfCx/IrWxXLY/2kEhYuofL7t9ftd7fclKA cn9Nu0sjhdMqqNCVE0/76vuSXGMIDPGPUdyMiGOurZYNj1PFtuM6DK018pEMXJK7RBVR kT/R/eUQnR9YBOMKEn1QMJ3p6a6GcOL6gaK3hEqaXWx+qIbTgUct/bKQuSGCdNJwpYUX mUuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id:dkim-signature; bh=C6UuLqkfXOKHkrI1ad2tdmANY5TMlVXBKHyBVpKDDNs=; b=lztkdZ4wIXgnu1TQqaeAn65TxmN42hAQjY5ChjY6u//6yomPOP0DVOYSMsGaMEl5OY 5Pur071lJU4Ff6HvHo926GD+S9gNb21fQ9j93fCb5/jElM3r58vpgU+AK4Fl1QJevEF3 wchYyBPGxueKBvbY6kPtv+T4T//N/ndCnOwQ6fnUpJzj7S6y/A3xKX3N5P4ObttTrj3Y XoHjdW3Lg2/CwU1DiD8H1ve5KswUR2uqB4q569xVLsJHazsvbluRzqx8FeCJPREXyO4h GVYhpGKiN5mDlL3mJOgWMcDsG5hf1ec427meUcQNWeLQ2T1bTIgWyNHRzRrjj5wkCkpm MGaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=fQoS3tSG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e9-20020a056a0000c900b0063b1fbbb8c5si7023771pfj.131.2023.06.12.08.24.46; Mon, 12 Jun 2023 08:24:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=fQoS3tSG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239104AbjFLPDh (ORCPT <rfc822;rust.linux@gmail.com> + 99 others); Mon, 12 Jun 2023 11:03:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36634 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239171AbjFLPDW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 12 Jun 2023 11:03:22 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B056E191 for <linux-kernel@vger.kernel.org>; Mon, 12 Jun 2023 08:03:21 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-9786fc23505so656880166b.2 for <linux-kernel@vger.kernel.org>; Mon, 12 Jun 2023 08:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686582200; x=1689174200; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=C6UuLqkfXOKHkrI1ad2tdmANY5TMlVXBKHyBVpKDDNs=; b=fQoS3tSGn8MnsOHfhsD6U5U64Fu3Nmsz50Zwg30oq03i6E9Ezn91hqw2g7JpPIfkYa eMxsDjRIBq9G0jJGBcWaDnePtVmfbNPUTYXkxtjP670BBPDpCwJOCK3L/KPB4zt36UjW kdt6PlviG3u9oMqOmGxqCLIMkk1SKvUtpzyC+hd9ztU8insHBNXyIOokRBp0ctanexIY NJp9NQSsohcxBpxh49DM4vi0azYuVugTJ838AKT94gn1TeK2cUx1267WJIPahLF1PDIo F5UQNY4dJJR83Egpjg+3rjY6RUlKmsbFha9n3Bejl45Oi6Vq1kE4K81JkzKG5nkdhNwm P2ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686582200; x=1689174200; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:from:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=C6UuLqkfXOKHkrI1ad2tdmANY5TMlVXBKHyBVpKDDNs=; b=i4m0hNFu+4eR/d1Dn7tY1IfAgb4t9fBpYt5n38krGaDZrSwxqL5Y+v8MQ67ecBgWzc zpaaPQDH6QJ40KTKV0I/+zSYaVodg+xb7mpVQAZhYNIJJkycSfemLGOLOlGFWeSBhc3N TcRj2BvMUwOpPm2qEz2KTZZP/ngUfzbhr+tr3N2cjS/rAqt3uZ6mGk1qEztzuKaoSIbl 9BjsmEP3UlkxlVD1nf9Z4nqbtzv2R0ogTCtZFWXU8xZAkHhc2rzHOZ93WlefRNp42Rtb HDw4qVaFx89e9kbRrGciroiNPZjynd2r3UsFYZMcdMR1hxNAo1bnPl1rlpbdxZr+IyvV MXsA== X-Gm-Message-State: AC+VfDxRsccjVyuCOv2FvIAu5UGbB8ViJswANctxVDoaJnN4Yz+y4sue fPRu6+BSjujjd0K07pWv3xY= X-Received: by 2002:a17:907:3603:b0:96a:19d8:f082 with SMTP id bk3-20020a170907360300b0096a19d8f082mr9821093ejc.25.1686582199969; Mon, 12 Jun 2023 08:03:19 -0700 (PDT) Received: from [192.168.2.2] (81-204-249-205.fixed.kpn.net. [81.204.249.205]) by smtp.gmail.com with ESMTPSA id k14-20020a1709061c0e00b0096f6e2f4d9esm5264570ejg.83.2023.06.12.08.03.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jun 2023 08:03:19 -0700 (PDT) Message-ID: <f2cebf54-a16c-c849-a988-bfd98c502748@gmail.com> Date: Mon, 12 Jun 2023 17:03:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 From: Johan Jonker <jbx6244@gmail.com> Subject: [PATCH v2 3/5] mtd: nand: raw: rockchip-nand-controller: fix oobfree offset and description To: miquel.raynal@bootlin.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 References: <11e16c3b-6f7b-a6a9-b0ed-b7ac0cd703e3@gmail.com> Content-Language: en-US In-Reply-To: <11e16c3b-6f7b-a6a9-b0ed-b7ac0cd703e3@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768510979602165719?= X-GMAIL-MSGID: =?utf-8?q?1768510979602165719?= |
Series |
Fixes for Rockchip NAND controller driver
|
|
Commit Message
Johan Jonker
June 12, 2023, 3:03 p.m. UTC
The MTD framework reserves 1 or 2 bytes for the bad block marker
depending on the bus size. The rockchip-nand-controller driver
currently only supports a 8 bit bus, but reserves standard 2 bytes
for the BBM. The first free OOB byte is therefore OOB2 at offset 2.
Page address(PA) bytes are moved to the last 4 positions before
ECC. Update the description for Linux.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
---
drivers/mtd/nand/raw/rockchip-nand-controller.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
--
2.30.2
Comments
Hi Johan, jbx6244@gmail.com wrote on Mon, 12 Jun 2023 17:03:18 +0200: > The MTD framework reserves 1 or 2 bytes for the bad block marker > depending on the bus size. The rockchip-nand-controller driver > currently only supports a 8 bit bus, but reserves standard 2 bytes > for the BBM. We always reserve 2 bytes, no? > The first free OOB byte is therefore OOB2 at offset 2. > Page address(PA) bytes are moved to the last 4 positions before > ECC. Update the description for Linux. The description should just be: Move Page Address (PA) bytes to the last 4 positions before ECC. And then you should justify why this is needed. Also, this would break all existing jffs2 users, right? > > Signed-off-by: Johan Jonker <jbx6244@gmail.com> > --- > drivers/mtd/nand/raw/rockchip-nand-controller.c | 11 ++++------- > 1 file changed, 4 insertions(+), 7 deletions(-) > > diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c > index 31d8c7a87..fcda4c760 100644 > --- a/drivers/mtd/nand/raw/rockchip-nand-controller.c > +++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c > @@ -566,9 +566,10 @@ static int rk_nfc_write_page_raw(struct nand_chip *chip, const u8 *buf, > * BBM OOB1 OOB2 OOB3 |......| PA0 PA1 PA2 PA3 > * > * The rk_nfc_ooblayout_free() function already has reserved > - * these 4 bytes with: > + * these 4 bytes together with 2 bytes for BBM > + * by reducing it's length: > * > - * oob_region->offset = NFC_SYS_DATA_SIZE + 2; > + * oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2; > */ > if (!i) > memcpy(rk_nfc_oob_ptr(chip, i), > @@ -945,12 +946,8 @@ static int rk_nfc_ooblayout_free(struct mtd_info *mtd, int section, > if (section) > return -ERANGE; > > - /* > - * The beginning of the OOB area stores the reserved data for the NFC, > - * the size of the reserved data is NFC_SYS_DATA_SIZE bytes. > - */ > oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2; > - oob_region->offset = NFC_SYS_DATA_SIZE + 2; > + oob_region->offset = 2; > > return 0; > } > -- > 2.30.2 > Thanks, Miquèl
On 6/12/23 19:26, Miquel Raynal wrote: > Hi Johan, > > jbx6244@gmail.com wrote on Mon, 12 Jun 2023 17:03:18 +0200: > >> The MTD framework reserves 1 or 2 bytes for the bad block marker >> depending on the bus size. The rockchip-nand-controller driver >> currently only supports a 8 bit bus, but reserves standard 2 bytes >> for the BBM. > > We always reserve 2 bytes, no? Not always used, but for consistency/simplicity the author assumes/reserves 2 bytes. > >> The first free OOB byte is therefore OOB2 at offset 2. >> Page address(PA) bytes are moved to the last 4 positions before >> ECC. Update the description for Linux. > > The description should just be: > > Move Page Address (PA) bytes to the last 4 positions before ECC. Space is already reserved, but overwritten. > > And then you should justify why this is needed. Also, this would break > all existing jffs2 users, right? Hi Miquel, From your comments it seems that the chip->oob_poi buffer layout is still not clear to you. Hope that this text below helps. If existing jffs2 users of free OOB are writing they are corrupting our PA data in RAW mode. So that must be fixed. Please advise how we split pre and post change users. (With a Module parameter like skipbbt renamed to "user_mode" = 0 offset 6, "user_mode" = 1 offset 2) Copying PA data in both RAW and HW mode has already reserved space in the layout. Let me know if I can help to get forward here. Johan === Given: Rockchip rk3066 MK808 with NAND: nand: Hynix H27UCG8T2ATR-BC 64G 3.3V 8-bit nand: 8192 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: 640 === Calulations: #define NFC_SYS_DATA_SIZE (4) /* 4 bytes sys data in oob pre 1024 data.*/ So per step only 4 bytes of OOB can be read. === The NFC can read/write in 1024 data bytes per step. To read/write a full page it needs 8 steps. chip->ecc.size = 1024; chip->ecc.steps = mtd->writesize / chip->ecc.size; = 8192 / 1024 = 8 steps === The total size of usefull OOB before ECC: rknand->metadata_size = NFC_SYS_DATA_SIZE * ecc->steps; = 4 * 8 = 32 === Wrong free OOB offset starts at OOB6: oob_region->offset = NFC_SYS_DATA_SIZE + 2; = 4 + 2 = 6 With a free OOB offset of 6 and a length of 26 ==> 6 + 26 = 32 we corrupt the PA address starting at offset 28. New offset OOB2: oob_region->offset = 2; The full range of free runs from OOB2 till/including OOB27. === The last 4 bytes of metadata are reserved for this Page Address(PA) for the bootrom. Currently only in use in RAW mode. The current PA calculation needed to write boot blocks for all Rockchip SoCs is however useless. The pattern of where the next page is written depends on the chip ID. As the MTD framework doesn't pass this chip ID in it's data structures, we must calculate that in userspace. Therefore both RAW and HW mode must pass the PA bytes. === The NFC hardware is capable for a 16 bit bus, but not implemented yet. Reserved are standard 2 bits for the BBM for a consistantency by the original author. === chip->oob_poi buffer layout for 8 steps: BBM0 BBM1 OOB2 OOB3 | OOB4 OOB5 OOB6 OOB7 OOB8 OOB9 OOB10 OOB11 | OOB12 OOB13 OOB15 OOB15 OOB16 OOB17 OOB18 OOB19 | OOB20 OOB21 OOB22 OOB23 OOB24 OOB25 OOB26 OOB27 | PA0 PA1 PA2 PA3 ECC0 ECC1 ECC2 ECC3 | ... ... ... ... === rk_nfc_ooblayout_free: oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2; = 32 - 4 - 2 = 26 oob_region->offset = 2; Free OOB should start at OOB2 to not overwrite PA data. === rk_nfc_ooblayout_ecc: oob_region->length = mtd->oobsize - rknand->metadata_size; = 640 - 32 = 608 oob_region->offset = rknand->metadata_size; = 32 ECC data starts at offset 32. === > >> >> Signed-off-by: Johan Jonker <jbx6244@gmail.com> >> --- >> drivers/mtd/nand/raw/rockchip-nand-controller.c | 11 ++++------- >> 1 file changed, 4 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c >> index 31d8c7a87..fcda4c760 100644 >> --- a/drivers/mtd/nand/raw/rockchip-nand-controller.c >> +++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c >> @@ -566,9 +566,10 @@ static int rk_nfc_write_page_raw(struct nand_chip *chip, const u8 *buf, >> * BBM OOB1 OOB2 OOB3 |......| PA0 PA1 PA2 PA3 >> * >> * The rk_nfc_ooblayout_free() function already has reserved >> - * these 4 bytes with: >> + * these 4 bytes together with 2 bytes for BBM >> + * by reducing it's length: >> * >> - * oob_region->offset = NFC_SYS_DATA_SIZE + 2; >> + * oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2; >> */ >> if (!i) >> memcpy(rk_nfc_oob_ptr(chip, i), >> @@ -945,12 +946,8 @@ static int rk_nfc_ooblayout_free(struct mtd_info *mtd, int section, >> if (section) >> return -ERANGE; >> >> - /* >> - * The beginning of the OOB area stores the reserved data for the NFC, >> - * the size of the reserved data is NFC_SYS_DATA_SIZE bytes. >> - */ >> oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2; >> - oob_region->offset = NFC_SYS_DATA_SIZE + 2; >> + oob_region->offset = 2; >> >> return 0; >> } >> -- >> 2.30.2 >> > > > Thanks, > Miquèl
Hi Johan, jbx6244@gmail.com wrote on Wed, 14 Jun 2023 11:23:44 +0200: > On 6/12/23 19:26, Miquel Raynal wrote: > > Hi Johan, > > > > jbx6244@gmail.com wrote on Mon, 12 Jun 2023 17:03:18 +0200: > > > >> The MTD framework reserves 1 or 2 bytes for the bad block marker > >> depending on the bus size. The rockchip-nand-controller driver > >> currently only supports a 8 bit bus, but reserves standard 2 bytes > >> for the BBM. > > > > We always reserve 2 bytes, no? > > Not always used, but for consistency/simplicity the author assumes/reserves 2 bytes. It's kind of an implicit rule in the raw NAND subsystem. It's not an author choice. > >> The first free OOB byte is therefore OOB2 at offset 2. > >> Page address(PA) bytes are moved to the last 4 positions before > >> ECC. Update the description for Linux. > > > > The description should just be: > > > > > Move Page Address (PA) bytes to the last 4 positions before ECC. > > Space is already reserved, but overwritten. Well, I don't know, but I'm quoting your commit log "Page address(PA) bytes are moved to the last 4 positions before ECC" and if this sentence is right, I am proposing another way to say this which sounds more declarative. > > > > > And then you should justify why this is needed. Also, this would > > break all existing jffs2 users, right? > > Hi Miquel, > > From your comments it seems that the chip->oob_poi buffer layout is > still not clear to you. Hope that this text below helps. > If existing jffs2 users of free OOB are writing They are, it's the first thing that jjfs2 does: writing cleanmarkers in the free area. > they are corrupting > our PA data in RAW mode. So that must be fixed. I did not yet understand whether corrupting the PA data was an absolute mistake or if it was specific to a given range of ROM codes. But let's assume it must be fixed. > Please advise how we > split pre and post change users. If you change the layout, you break users. There is no question here. But if you do that, we need: - a crystal clear explanation of why this is needed - to say it clearly: this change breaks existing jffs2 users > (With a Module parameter like > skipbbt renamed to "user_mode" = 0 offset 6, "user_mode" = 1 offset I know the cafe driver does that, it is awful IMHO. > 2) Copying PA data in both RAW and HW mode has already reserved space > in the layout. Let me know if I can help to get forward here. > > Johan > > === > > Given: > > Rockchip rk3066 MK808 with NAND: > nand: Hynix H27UCG8T2ATR-BC 64G 3.3V 8-bit > nand: 8192 MiB, MLC, erase size: 2048 KiB, page size: 8192, OOB size: > 640 > > === > > Calulations: > > #define NFC_SYS_DATA_SIZE (4) /* 4 bytes sys data in > oob pre 1024 data.*/ > > So per step only 4 bytes of OOB can be read. I think I get what you mean but the above sentence is wrong. You can always read the full OOB in raw mode. And in general you can as well in host ECC mode. Then what users do with the OOB information is orthogonal. However, if they don't want their data to be smashed, they can request the information about which bytes are free to be used (typically what jffs2 does, while ubi does not care about OOB). The oob layout helpers can then restrain the advertised free area to only share bytes which are not used by the PA. > > === > > The NFC can read/write in 1024 data bytes per step. > To read/write a full page it needs 8 steps. > > chip->ecc.size = 1024; > chip->ecc.steps = mtd->writesize / chip->ecc.size; > = 8192 / 1024 > = 8 steps > === > > The total size of usefull OOB before ECC: > > rknand->metadata_size = NFC_SYS_DATA_SIZE * ecc->steps; > = 4 * 8 > = 32 > === > > Wrong free OOB offset starts at OOB6: > oob_region->offset = NFC_SYS_DATA_SIZE + 2; > = 4 + 2 > = 6 > > With a free OOB offset of 6 and a length of 26 ==> 6 + 26 = 32 we > corrupt the PA address starting at offset 28. > > New offset OOB2: > oob_region->offset = 2; > > The full range of free runs from OOB2 till/including OOB27. > === > > The last 4 bytes of metadata are reserved for this Page Address(PA) > for the bootrom. Currently only in use in RAW mode. I'm not sure to understand what "currently on ly in use in raw mode". In raw mode, the user can overwrite the whole OOB area, it is the user input what should be written in each and every byte. In ECC mode the ECC engine will smash some of this data to write its own ECC bytes. > The current PA calculation needed to write boot blocks for all > Rockchip SoCs is however useless. The pattern of where the next page > is written depends on the chip ID. As the MTD framework doesn't pass > this chip ID in it's data structures, we must calculate that in > userspace. yes, I agree the right approach if you need to write these is to perform raw OOB writes with values calculated manually. > Therefore both RAW and HW mode must pass the PA bytes. Yes, no problem with that. > === > > The NFC hardware is capable for a 16 bit bus, but not implemented yet. > Reserved are standard 2 bits for the BBM for a consistantency by the > original author. > > === > > chip->oob_poi buffer layout for 8 steps: > > BBM0 BBM1 OOB2 OOB3 | OOB4 OOB5 OOB6 OOB7 > > OOB8 OOB9 OOB10 OOB11 | OOB12 OOB13 OOB15 OOB15 > OOB16 OOB17 OOB18 OOB19 | OOB20 OOB21 OOB22 OOB23 > > OOB24 OOB25 OOB26 OOB27 | PA0 PA1 PA2 PA3 > > ECC0 ECC1 ECC2 ECC3 | ... ... ... ... Yes. > > === > > rk_nfc_ooblayout_free: > oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2; > = 32 - 4 - 2 > = 26 > > oob_region->offset = 2; > > Free OOB should start at OOB2 to not overwrite PA data. Yes. > > === > > rk_nfc_ooblayout_ecc: > oob_region->length = mtd->oobsize - rknand->metadata_size; > = 640 - 32 > = 608 > oob_region->offset = rknand->metadata_size; > = 32 > > ECC data starts at offset 32. Yes. > > === > > > > > >> > >> Signed-off-by: Johan Jonker <jbx6244@gmail.com> > >> --- > >> drivers/mtd/nand/raw/rockchip-nand-controller.c | 11 ++++------- > >> 1 file changed, 4 insertions(+), 7 deletions(-) > >> > >> diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c > >> b/drivers/mtd/nand/raw/rockchip-nand-controller.c index > >> 31d8c7a87..fcda4c760 100644 --- > >> a/drivers/mtd/nand/raw/rockchip-nand-controller.c +++ > >> b/drivers/mtd/nand/raw/rockchip-nand-controller.c @@ -566,9 > >> +566,10 @@ static int rk_nfc_write_page_raw(struct nand_chip > >> *chip, const u8 *buf, > >> * BBM OOB1 OOB2 OOB3 |......| PA0 PA1 PA2 > >> PA3 * > >> * The rk_nfc_ooblayout_free() function already > >> has reserved > >> - * these 4 bytes with: > >> + * these 4 bytes together with 2 bytes for BBM > >> + * by reducing it's length: > >> * > >> - * oob_region->offset = NFC_SYS_DATA_SIZE + 2; > >> + * oob_region->length = rknand->metadata_size - > >> NFC_SYS_DATA_SIZE - 2; */ > >> if (!i) > >> memcpy(rk_nfc_oob_ptr(chip, i), > >> @@ -945,12 +946,8 @@ static int rk_nfc_ooblayout_free(struct > >> mtd_info *mtd, int section, if (section) > >> return -ERANGE; > >> > >> - /* > >> - * The beginning of the OOB area stores the reserved data > >> for the NFC, > >> - * the size of the reserved data is NFC_SYS_DATA_SIZE > >> bytes. > >> - */ > >> oob_region->length = rknand->metadata_size - > >> NFC_SYS_DATA_SIZE - 2; > >> - oob_region->offset = NFC_SYS_DATA_SIZE + 2; > >> + oob_region->offset = 2; > >> > >> return 0; > >> } > >> -- > >> 2.30.2 > >> > > > > > > Thanks, > > Miquèl Thanks, Miquèl
diff --git a/drivers/mtd/nand/raw/rockchip-nand-controller.c b/drivers/mtd/nand/raw/rockchip-nand-controller.c index 31d8c7a87..fcda4c760 100644 --- a/drivers/mtd/nand/raw/rockchip-nand-controller.c +++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c @@ -566,9 +566,10 @@ static int rk_nfc_write_page_raw(struct nand_chip *chip, const u8 *buf, * BBM OOB1 OOB2 OOB3 |......| PA0 PA1 PA2 PA3 * * The rk_nfc_ooblayout_free() function already has reserved - * these 4 bytes with: + * these 4 bytes together with 2 bytes for BBM + * by reducing it's length: * - * oob_region->offset = NFC_SYS_DATA_SIZE + 2; + * oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2; */ if (!i) memcpy(rk_nfc_oob_ptr(chip, i), @@ -945,12 +946,8 @@ static int rk_nfc_ooblayout_free(struct mtd_info *mtd, int section, if (section) return -ERANGE; - /* - * The beginning of the OOB area stores the reserved data for the NFC, - * the size of the reserved data is NFC_SYS_DATA_SIZE bytes. - */ oob_region->length = rknand->metadata_size - NFC_SYS_DATA_SIZE - 2; - oob_region->offset = NFC_SYS_DATA_SIZE + 2; + oob_region->offset = 2; return 0; }