linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: Javier Martinez Canillas <javier@dowhile0.org>
Cc: "Gupta, Pekon" <pekon@ti.com>,
	"Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>,
	"Enric Balletbo Serra" <eballetbo@gmail.com>,
	"Benoît Cousson" <bcousson@baylibre.com>,
	"Tony Lindgren" <tony@atomide.com>,
	"Javier Martinez Canillas" <martinez.javier@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"Ezequiel Garcia" <ezequiel.garcia@free-electrons.com>,
	"Scott Wood (scottwood@freescale.com)" <scottwood@freescale.com>
Subject: Re: [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility.
Date: Mon, 2 Dec 2013 11:24:45 -0500	[thread overview]
Message-ID: <529CB44D.5020800@ti.com> (raw)
In-Reply-To: <CABxcv=nTQOW7JvCKqHwaX0CXPN6USs66jWUFthW=3CoajsHbPw@mail.gmail.com>

On 12/02/2013 11:21 AM, Javier Martinez Canillas wrote:
> Hi Pekon,
> 
> On Mon, Dec 2, 2013 at 5:13 PM, Gupta, Pekon <pekon@ti.com> wrote:
>>> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
>>>> On Mon, 2 Dec 2013 11:00:35 -0500, Tom Rini wrote:
>>>
>>>>>> Although the new ECC schema breaks the compatibility between the board
>>>>>> files and new DT based kernel, I think we should use BCH8 scheme.
>>>>>> Sorry, because I had not realized that this was configurable in
>>>>>> u-boot, so I think, if Thomas is also agree, the better fix in that
>>>>>> case is change CONFIG_NAND_OMAP_ECCSCHEME to
>>>>>> OMAP_ECC_BCH8_CODE_HW_DETECTION_SW in u-boot. If this works we can
>>>>>> discard this patch.
>>>>>
>>>>> I theoretically don't have anything against that, but if I do this
>>>>> change in U-Boot, and then use U-Boot to reflash to NAND the SPL and
>>>>> U-Boot itself, will the OMAP ROM code still be able to read the SPL
>>>>> from NAND ? I'm not sure which ECC scheme does the OMAP ROM code
>>>>> support, and how it detects (or not) which ECC scheme to use to read
>>>>> the SPL.
>>>>
>>>> Yes, this brings us back to one of the old and long-standing problems.
>>>> The ROM on these devices will generally speak one format and that means
>>>> using NAND chips that say for the first block (or N blocks or whatever)
>>>> you only need 1bit ECC but for the rest 4/8/16/whatever.  And then
>>>> informing the kernel (and anything else) that "partitions" N need this
>>>> format and the rest need that.
>>>
>>> As long as U-Boot provides separate commands, or a "nandecc" command
>>> that allows to switch between ECC scheme, and select the ECC scheme
>>> expected by the ROM code when flashing the SPL, and then the ECC scheme
>>> expected by the SPL and the kernel to flash U-Boot itself, the kernel
>>> image, and the various filesystem images, then it's all fine, we can
>>> leave with different ECC schemes used for different things on the NAND
>>> flash.
>>>
> 
> Yes, we used nandecc to write data on different mtd partitions for SPL
> (nandecc hw) and the rootfs (nandecc hw bch8).
> 
>> Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'.
>> The infrastructure is still in place, however the command 'nandecc' is
>> deprecated in newer versions.
>> References in mainline u-boot:
>> arch/arm/cpu/armv7/omap3/board.c  @@do_switch_ecc()
>> driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc()
>>
> 
> Why nandecc is being deprecated from u-boot? How are you supposed to
> use a different ECC scheme then?

We (I) had killed off all of the mainline users of the nandecc command,
once everyone was using the same 1bit scheme layout.  None of the people
that had mixed HAM1/BCH4 at the time wanted to work upstream on it.

-- 
Tom

  reply	other threads:[~2013-12-02 16:24 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-01 11:23 [PATCH] ARM: dts: omap3-igep00x0: Fix nand ECC to maintain backward compatibility Enric Balletbo i Serra
2013-12-01 12:27 ` Javier Martinez Canillas
2013-12-02 10:54   ` Thomas Petazzoni
2013-12-02 14:16     ` Enric Balletbo Serra
2013-12-02 14:56       ` Gupta, Pekon
2013-12-02 15:02         ` Thomas Petazzoni
2013-12-02 15:19           ` Gupta, Pekon
2013-12-02 15:39             ` Enric Balletbo Serra
2013-12-02 15:51               ` Thomas Petazzoni
2013-12-02 16:00                 ` Tom Rini
2013-12-02 16:06                   ` Thomas Petazzoni
2013-12-02 16:13                     ` Gupta, Pekon
2013-12-02 16:19                       ` Thomas Petazzoni
2013-12-02 17:05                         ` Gupta, Pekon
2013-12-02 17:16                           ` Michael Trimarchi
2013-12-02 17:46                             ` Gupta, Pekon
2013-12-02 18:09                               ` Tom Rini
2013-12-02 17:25                           ` Tom Rini
2013-12-06 19:52                           ` Scott Wood
2013-12-02 16:19                       ` Tom Rini
2013-12-02 16:21                       ` Javier Martinez Canillas
2013-12-02 16:24                         ` Tom Rini [this message]
2013-12-02 16:46                           ` Javier Martinez Canillas
2013-12-02 16:57                             ` Tom Rini

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=529CB44D.5020800@ti.com \
    --to=trini@ti.com \
    --cc=bcousson@baylibre.com \
    --cc=eballetbo@gmail.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=javier@dowhile0.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=martinez.javier@gmail.com \
    --cc=pekon@ti.com \
    --cc=scottwood@freescale.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=tony@atomide.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;
as well as URLs for NNTP newsgroup(s).