Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp29413334rwd; Wed, 5 Jul 2023 11:26:03 -0700 (PDT) X-Google-Smtp-Source: APBJJlHD8HkgoLeeKOqZUzbT9fMW4EnUlIRABEsHrYgYuYR3VKXes8S0m2I9dPQrjKWHeG72izUG X-Received: by 2002:a05:6a00:2355:b0:681:415d:ba2c with SMTP id j21-20020a056a00235500b00681415dba2cmr21093471pfj.31.1688581562965; Wed, 05 Jul 2023 11:26:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688581562; cv=none; d=google.com; s=arc-20160816; b=0PfwYhA+6uO/A/Irqzra1AR+gkCam5JJqmYeGQiMT5FjL2gNHI0AZrrQdvOtM5FlyY 1lwqHcSOjEOZ+LBwTbmdC0EqYZefNyJRIpVg/Y0mOgTkeUZHz5nGG4y3jq1sDYzNBaMu BS5YlQUo7kNNv/JbJBzwybPJwMb8TiIA6NEoDV3+i3MbKiMAZiYWr3gpqa4wWRolBWJb hn8RBAX/OH90YgLTdrbcNvdZuPTm//y/xsNohoXXfet13xMZmhTS+MMWCNeYEqexH9Yl bH19LAGAumtMRWTwVsG1r3DAPtIdiniPxeVwUI+mDptHOLhNa4kN/EXv7kjkmsC7tHuj eUww== 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:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=w7iqWni3eK8x3dTleEGq98e3HnfEpiof9+EFvCVfJeA=; fh=I88AE4wjkR+qlr1nXzcwTrGI9xaGTfEDs+o47AcGY9U=; b=NeOpPz225IKZ2Hu8dTx6rsnBjwdkgYTuHVBuQLa+eTSE+czBMZuiWZmZ0i9XBNRl3G vVDBK2dpJoLnUy8iQlFVaikaTfTycUzKWE0efegZIVTZN1L/vrwbEAjwPTf15hk9+YEu w3jkQKB1dfjrFqUjH7MWV+L1dIgfFEjD9j43wKhGqxF3Y3gb7q/OE3u4VI44iE1Ic7Hw VkmHadddMJWZJ+nIiVSgiEKe2iHI4EDFUDbLLlWxW+aqA3hk9MQuOqIPAESWCuxUwvyE GxZiEXPl2nufYki+eUVYufJitWw5hrECY8ZEa7JD09hbj0BOs+h/4k15hjnwx5X+04uI HaFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=lcHhhZJ6; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ca9-20020a056a00418900b0066cc86468c5si22366532pfb.26.2023.07.05.11.25.47; Wed, 05 Jul 2023 11:26:02 -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=lcHhhZJ6; 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 S232365AbjGESWp (ORCPT + 99 others); Wed, 5 Jul 2023 14:22:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233633AbjGESW1 (ORCPT ); Wed, 5 Jul 2023 14:22:27 -0400 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90A0C2694 for ; Wed, 5 Jul 2023 11:21:56 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2b6f9edac8dso31270011fa.3 for ; Wed, 05 Jul 2023 11:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688581256; x=1691173256; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=w7iqWni3eK8x3dTleEGq98e3HnfEpiof9+EFvCVfJeA=; b=lcHhhZJ6UA3AaQGfvUqt/v6qgzBe4qjRli/ZwMNWbWFNKRJuoYH/PNcBNy64/kkQ77 Qm1aUvHQGPebLCfWmTrgGclckRL2j19Cu2XFej0v1AWuWlpg0Si8hgXauI9+QgK0gBQ4 2MADHn/a+BIrH8jeGN7OEyfb+N9fAyIYgNd2xBcalXN+8RPMcM2a35wdI0zJXiMPwKMd /kUxQVqpOykM6keZP7tPcp38JOnNiK8oCzYQ6kxbs5u9KFU9m9mOTc+5HAp7T4Nk5P8v 4a0fQVoWHivgC2jfuBLVJ6m6YiErJ+3/lvX7+B3NqNSiaUrdb7D6NwEJGuMciykXo8Mj /SlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688581256; x=1691173256; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=w7iqWni3eK8x3dTleEGq98e3HnfEpiof9+EFvCVfJeA=; b=J/wchp5Y9QyoCBB9OO50lFZDfiPTrloGqFnj9eQ7gqWmmyJsoO5krInRrrIlzTaIwZ KVU+p6tJD63/mXz6aPZ8l35UJsntAB+1QJChPWIy9z/FymzbOR2NvQYkW5L1EYknRWxV /elysYGDqqzTjZWQvI5C6B4TTyICNhva4aAAKoh+FcS7m577LVs7qnzBkrfEjiQrX/l9 9XDRgPfymyWbmRWD1vu6KbGXTu00gGYt8TobX/JFHqOHDl/oU8fQczKGWdNE2DKh2BwI XcSsNhVeHnjP+EXpMoBY0rUxfzIyl/HM1e0NWz+eHk+XkkHnkzLYsZhK223V9lWvsrBD qDSg== X-Gm-Message-State: ABy/qLYoTAz5xwj1wMBtlqpm55e31YuH6s+6seAJ3Q8AEhofPFfLKg9a P8uGlYMdaUwDB0OXns4kwqw= X-Received: by 2002:a19:7418:0:b0:4f9:5d2a:e0f6 with SMTP id v24-20020a197418000000b004f95d2ae0f6mr11255992lfe.14.1688581255815; Wed, 05 Jul 2023 11:20:55 -0700 (PDT) Received: from [192.168.2.1] (81-204-249-205.fixed.kpn.net. [81.204.249.205]) by smtp.gmail.com with ESMTPSA id qx22-20020a170906fcd600b009931baa0d44sm6553278ejb.140.2023.07.05.11.20.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jul 2023 11:20:55 -0700 (PDT) Message-ID: Date: Wed, 5 Jul 2023 20:20:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v3 2/3] mtd: rawnand: rockchip-nand-controller: copy hwecc PA data to oob_poi buffer To: Miquel Raynal 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: <0047fc52-bc45-a768-8bdd-c0f12cddc17e@gmail.com> <539cfba7-dd6f-015e-b990-a2335cb3aac9@gmail.com> <20230704170858.2a64c181@xps-13> Content-Language: en-US From: Johan Jonker In-Reply-To: <20230704170858.2a64c181@xps-13> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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,NICE_REPLY_A,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: X-Mailing-List: linux-kernel@vger.kernel.org On 7/4/23 17:08, Miquel Raynal wrote: > Hi Johan, > > jbx6244@gmail.com wrote on Thu, 15 Jun 2023 19:34:13 +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. > > Only when used as boot device I guess? It's a BootROM limitation. Yes, required by the BootROM. > >> 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. > > So this is a fix as well, deserves a tag. Whatever the reason why you > need this, the issue you are solving is: write_page_hwecc and > write_page_raw are not aligned. Fixes: 058e0e847d54 ("mtd: rawnand: rockchip: NFC driver for RK3308, RK2928 and others") > >> Generate boot block page address and pattern for hwecc in user space >> and copy PA data to/from the already reserved last 4 bytes before EEC > > ECC OK > >> in the chip->oob_poi data layout. >> >> This patch breaks all existing jffs2 users that have free OOB overlap >> with the reserved space for PA data. >> >> Signed-off-by: Johan Jonker >> --- >> >> Changed V3: >> Change prefixes >> Reword >> --- >> .../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 37fc07ba5..5a0468034 100644 >> --- a/drivers/mtd/nand/raw/rockchip-nand-controller.c >> +++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c >> @@ -598,7 +598,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); >> @@ -625,6 +625,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. >> + * >> + * 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)) && >> @@ -635,21 +642,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) > > So we no longer need boot_rom_mode? Or do we? boot_rom_mode is still in use for ecc switching. > >> - 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, >> @@ -812,12 +815,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