Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1969462imm; Fri, 7 Sep 2018 08:51:42 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYjD4a7Tw6NncFhkqZ8XCipZs9dVAizDfLZvLcn7G19ANy/7RxtC8w1ap8P2LO9udGBhzPF X-Received: by 2002:a63:3387:: with SMTP id z129-v6mr8972867pgz.104.1536335502833; Fri, 07 Sep 2018 08:51:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536335502; cv=none; d=google.com; s=arc-20160816; b=HPGKrB/qqj4ZXZItDtxnosh0iWKCoEc/ccNEQXwbS5dIIuRHvBKtCtGH5w0y3qQjwQ 9xTFq0tNc9t80CEC+bMS0qTMmmqPkLwBeCjm0FbeAzSVT+Gw9RulZ3tCSJtQhKZMiGE2 7RqWAahG/RUrRTElLODqBDOIdYMTPYFZTSidghWrdgP0aByh6kBXhRAf1FY8UXf6F57O EvrlB+VDOn4pSltcdDusPnBAQGVHIdhM+SOlMVDDNFgZE1n5bcnOFb7Js9x2nRSreueO yxREPFDRNmuCD+xlMglWxtkMqx+IYrccIdaWw3T2oHG1oV9wd3W2k024gajwa85qAmEE RY/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=2OXtpl9vmBFDQnPedALQfb2qm7bGTpbM4QXqbidE1M4=; b=IyfwNG8Dt2/xGZrNyxDKMMk1P/2Ox+DsV8xdIU1nFEJw/2eyDpVEhD1MMK9WCm5t15 wl9XPbqzSmHrQuOH2nyuKFKlTouwbpVc9jBz/Nm30j7PyvjG/x14p6O4aKH1mtvBAEeT YHgKAiLloz35OD2D95NGlpa+OiRgBgD8BvrlFiAFGwtr2kF+TRIcX1OeNjFA9bVU1c7u vxvriW40yRkOVr8Rrmr/QZAeIVZPDIPrykEgeaRkwqwqzf+oNGDq6ADur6Vfn9DhRN53 Fd2a1gIh+tvhviRTqyvNfy8iHe22jfVyYcQrU4Hxi99XMQrHyPYCqDhArVa3tZan6Y+B P7sw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a9-v6si8861708pgj.224.2018.09.07.08.51.27; Fri, 07 Sep 2018 08:51:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729989AbeIGTfH (ORCPT + 99 others); Fri, 7 Sep 2018 15:35:07 -0400 Received: from mail.bootlin.com ([62.4.15.54]:44987 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725944AbeIGTfH (ORCPT ); Fri, 7 Sep 2018 15:35:07 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 9C39720787; Fri, 7 Sep 2018 16:53:49 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (AAubervilliers-681-1-30-219.w90-88.abo.wanadoo.fr [90.88.15.219]) by mail.bootlin.com (Postfix) with ESMTPSA id 3F9A720701; Fri, 7 Sep 2018 16:53:49 +0200 (CEST) Date: Fri, 7 Sep 2018 16:53:48 +0200 From: Boris Brezillon To: Masahiro Yamada , Dinh Nguyen , Rob Herring , linux-mtd Cc: Mark Rutland , DTML , Marek Vasut , Richard Weinberger , Linux Kernel Mailing List , Miquel Raynal , Brian Norris , David Woodhouse Subject: Re: [PATCH] mtd: rawnand: denali: add DT property to specify skipped bytes in OOB Message-ID: <20180907165348.3e0027ee@bbrezillon> In-Reply-To: References: <1536317783-4942-1-git-send-email-yamada.masahiro@socionext.com> <20180907160822.319047c8@bbrezillon> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 7 Sep 2018 23:42:53 +0900 Masahiro Yamada wrote: > Hi Boris, > > 2018-09-07 23:08 GMT+09:00 Boris Brezillon : > > Hi Masahiro, > > > > On Fri, 7 Sep 2018 19:56:23 +0900 > > Masahiro Yamada wrote: > > > >> NAND devices need additional data area (OOB) for error correction, > >> but it is also used for Bad Block Marker (BBM). In many cases, the > >> first byte in OOB is used for BBM, but the location actually depends > >> on chip vendors. The NAND controller should preserve the precious > >> BBM to keep track of bad blocks. > >> > >> In Denali IP, the SPARE_AREA_SKIP_BYTES register is used to specify > >> the number of bytes to skip from the start of OOB. The ECC engine > >> will automatically skip the specified number of bytes when it gets > >> access to OOB area. > >> > >> The same value for SPARE_AREA_SKIP_BYTES should be used between > >> firmware and the operating system if you intend to use the NAND > >> device across the control hand-off. > >> > >> In fact, the current denali.c code expects firmware to have already > >> set the SPARE_AREA_SKIP_BYTES register, then reads the value out. > >> > >> If no firmware (or bootloader) has initialized the controller, the > >> register value is zero, which is the default after power-on-reset. > >> > >> In other words, the Linux driver cannot initialize the controller > >> by itself. You cannot support the reset control either because > >> resetting the controller will get register values lost. > >> > >> This commit adds a way to specify it via DT. If the property > >> "denali,oob-skip-bytes" exists, the value will be set to the register. > > > > Hm, do we really need to make this config customizable? I mean, either > > you have a large-page NAND (page > 512 bytes) and the 2 first bytes > > must be reserved for the BBM or you have a small-page NAND and the BBM > > is at position 4 and 5. Are you sure people configure that differently? > > Don't you always have SPARE_AREA_SKIP_BYTES set to 6 or 2? > > > As I said in the patch description, > I need to use the same SPARE_AREA_SKIP_BYTES value > across firmware, boot-loader, Linux, and whatever. > > I want to set the value to 8 for my platform > because the on-chip boot ROM expects 8. > I cannot change it since the boot ROM is hard-wired. > > > The boot ROM skips 8 bytes in OOB > when it loads images from the on-board NAND device. > > So, when I update the image from U-Boot or Linux, > I need to make sure to set the register to 8. > > If I update the image with a different value, > the Boot ROM fails to boot. > > > > When the system has booted from NAND, > the register is already set to 8. It works. > > However, when the system has booted from eMMC, > the register is not initialized by anyone. > I am searching for a way to set the register to 8 > in this case. > > > The boot ROM in SOCFPGA might expect a different value, > I am not sure. Okay, then why not having a per-compatible value if it's related to the BootROM? Unless the BootROM is part of the FPGA and can be reprogrammed. I'd really prefer not having a generic property that allows you to put anything you want.