Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1995192imm; Fri, 7 Sep 2018 09:13:25 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZHo58WQdd6iBuVNDeEpLJnepuyMYyAj0tdcp5GKwVlmaCvjn3/hmLB4prLHlUllYT7dW24 X-Received: by 2002:a62:fc5:: with SMTP id 66-v6mr9207746pfp.237.1536336805122; Fri, 07 Sep 2018 09:13:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536336805; cv=none; d=google.com; s=arc-20160816; b=BjdjdNLhK2nOkmxmhSb4ZfyoQ/5Jq8tniZ5Wign/MpCeQ/F3RWwox5bQ5Ev0p3nwTl oFGmAMaRERJwATH3KjL2JWKSkMl4tT2ha/XffnSKq5Rspa4jyMS+na+J1CSbj2f/xqIS jyhP9BIzPjcXhW3if36mXO6nX6xWwhgZluCluf0V/rPVtno70AQkDpJzxFXwPrVnDb8y THLR7Bpt82lwqwmUFM3+B9/Z6YL6qGCLqNi440CxQfNQHOvvGl3q/KjJL3jpwR1tVznD unTd9qVXzY88PS8Ki2KgXeI8lBzaFW0rsma9tawwPLb/yrvXYF3+0bT5vE/D5XBe8U+h jJzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-filter; bh=q7/yCKOhBeSEL9bhKekNDITWl0Ds4HNUQsleotDM+Zs=; b=anOnT5irCac17s5anphWw3Alm3Cnncd8x39k224FNpVRr6JxywVq9ZbQhMqqSaX6nQ yHbIzNzBJbmzkPEOWS6/7afeK0MU7jkvLgtP/Hooa2/mVvIqT9XzegkF51VltOlcPYS9 +rB9nTHAg6pOBLMgRmHU16jKvFSlI0R8x+blc3aaeUdh5rJ8NxKj+JxSuDQDO5HkGktn 9T1Tbp1eH0nqdhNKITMMNDvTm13HcQOYXGlljXMmiVMdW5ZEy0o5+wjYa6TGmNG7KoXn JZSP7wAz0lpTZO0hZWqNpe37YN0JScnVuCW3FaO3NEHVgI/uXIkIGw8f1iMZmUyMjr9/ 8eQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=KKECg1Bb; 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 bb7-v6si7984349plb.359.2018.09.07.09.13.08; Fri, 07 Sep 2018 09:13:25 -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; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=KKECg1Bb; 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 S1727939AbeIGUxF (ORCPT + 99 others); Fri, 7 Sep 2018 16:53:05 -0400 Received: from conssluserg-02.nifty.com ([210.131.2.81]:32291 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727598AbeIGUxF (ORCPT ); Fri, 7 Sep 2018 16:53:05 -0400 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (authenticated) by conssluserg-02.nifty.com with ESMTP id w87GB7OR027198; Sat, 8 Sep 2018 01:11:07 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com w87GB7OR027198 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1536336668; bh=q7/yCKOhBeSEL9bhKekNDITWl0Ds4HNUQsleotDM+Zs=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=KKECg1Bbi4cbkZO9Wbj9hfHA+RvzYLihN+R7sRHQa6Y4NUJNz2iS1sQSx/eCoag3b eCFI4k2CzLvp2FLOT/uHIbbR7hzkl7ZN05lEib5uK2f7YHpdKxu8YwNDmH2YCUwlna MSbfuDVhY1Ba9i8mPgqJcPNTjFcQchLFcBJsBxD4bvM17NKLjvYv1wmeweeND1MoY2 diw+QsfC/EuafNmFfeSWjByPxfF9muqKC7NaruLXbedr6/RhL1fk/Qr3CEjZWF8+3X 0nxhvZs5AGAvBDbvWnGOo76vboXJxUfxF5Wh2L4rg+CqyaGVxJilLErvS0gLDmfp7m H8/8oO7VaUggw== X-Nifty-SrcIP: [209.85.221.176] Received: by mail-vk1-f176.google.com with SMTP id l143-v6so1033883vke.1; Fri, 07 Sep 2018 09:11:07 -0700 (PDT) X-Gm-Message-State: APzg51B5qe4PlPNUu+BaUtfWFL4j5TouX04aW2rsaepY55+pfTurk2LQ xBQt6oUV0QqwMAimqlhnS/uDhxkuEDyI1DNqqZ4= X-Received: by 2002:a1f:f8c2:: with SMTP id w185-v6mr3010667vkh.135.1536336666295; Fri, 07 Sep 2018 09:11:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:7111:0:0:0:0:0 with HTTP; Fri, 7 Sep 2018 09:10:25 -0700 (PDT) In-Reply-To: <20180907165348.3e0027ee@bbrezillon> References: <1536317783-4942-1-git-send-email-yamada.masahiro@socionext.com> <20180907160822.319047c8@bbrezillon> <20180907165348.3e0027ee@bbrezillon> From: Masahiro Yamada Date: Sat, 8 Sep 2018 01:10:25 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mtd: rawnand: denali: add DT property to specify skipped bytes in OOB To: Boris Brezillon Cc: Dinh Nguyen , Rob Herring , linux-mtd , Mark Rutland , DTML , Richard Weinberger , Linux Kernel Mailing List , Marek Vasut , Miquel Raynal , Brian Norris , David Woodhouse Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Boris, 2018-09-07 23:53 GMT+09:00 Boris Brezillon : > 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. FPGA is unrelated here. Neither the boot ROM nor the Denali core is re-programmable. I hesitate to associate the number of skipped bytes with the compatible string because it is not a parameter of the Denali IP. Rather, it is the matter of "how we use the OOB", so I want to leave room for customization like nand-ecc-strength etc. even if the boot ROM happens to expect a particular value. If you prefer a per-compatible value, I can do that, but I believe the NAND core and the boot ROM are orthogonal. > I'd really prefer not having a generic property that > allows you to put anything you want. -- Best Regards Masahiro Yamada