mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Alexey Galakhov <agalakhov@gmail.com>
To: Juergen Beisert <jbe@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 2/4] Fine split S3C arch dependencies from generic code
Date: Fri, 04 May 2012 16:50:59 +0600	[thread overview]
Message-ID: <4FA3B493.7030002@gmail.com> (raw)
In-Reply-To: <201205041158.25104.jbe@pengutronix.de>

On 04.05.2012 15:58, Juergen Beisert wrote:
> Alexey Galakhov wrote:
>> On 03.05.2012 23:41, Juergen Beisert wrote:
>>>> create mode 100644 arch/arm/mach-samsung/include/mach/s3c-nand.h
>>>> delete mode 100644 arch/arm/mach-samsung/include/mach/s3c24xx-nand.h
>>>
>>> That is a really bad idea. I just renamed these files at January 2012 to
>>> reflect their CPU (refer b29b8f43d56b62e406349a5cf1ed56f17454c1f7). Why
>>> do you revert this change again? The NAND controller in the S3C24XX CPU
>>> is unique to this CPU. The NAND controller in the S3C6410 differs from
>>> it, and I guess the same is true in the S5 CPU. So, the newer CPUs need
>>> their own NAND drivers.
>>>
>>> What is the sense of renaming these files?
>>
>> In fact, exactly the opposite is true. The NAND controller in S5PV210 is
>> almost exactly the same as in S3C24xx. The only difference is the
>> numbering of registers. Also S5P suports 1-bit and 4-bit HW ECC while
>> S3C has only 1-bit. 
> 
> Does the S5P not support 8 bit ECC? That would be a step backwards and would 
> make it useless for recent MLC NAND devices.

It has two ECC modes, SLC and MLC.

The SLC mode is exactly the same as S3C2440. The MLC mode has "4-8-16-32
bit support". Looks like this is achieved by using the same 4-bit
hardware calculator.

>> The algorithm is the same, even s3c2440_nand_read_buf() works correctly.
> 
> These routines are useless for NANDs of type MLC which are the standard today.

According to the datasheet, the only difference between SLC and MLC
handling from the software point of view is ECC calculation. The block
reading is exactly the same, just reading the data register multiple
times. The ECC engine in both SLC and MLC modes works just like S3C2440.
The only differnce is that one has to set ECC data direction bit prior
to operation.

>> S3C6410 has the same controller as well.
> 
> No it hasn't. Believe me. Using the old 1 bit ECC (and also the 4 bit ECC) 
> makes no sense any more. Even the built-in iROM forces the 8 bit ECC mode if 
> you want to boot it from NAND. And I guess it is the same on the S5P CPU.

Hm, looks like my board is not the case. Anyway, this seems to be just
adding one more HW specific ECC function and not a complete rewrite.

There is a Linux driver from Samsung, named "s3c_nand.c", found in
S5PVxx kernel patches here and there (not in mainstream). It works for
S3C2416 and up and supports SLC and MLC. I use it for reference.

I.e., here:
https://e60-open.googlecode.com/svn/patches/kernel/samsung-e60-kernel-mtd.patch

Its ECC function looks like that:

static int s3c_nand_calculate_ecc(struct mtd_info *mtd,
                        const u_char *dat, u_char *ecc_code)
{
        u_long nfcont, nfmecc0, nfmecc1;
        void __iomem *regs = s3c_nand.regs;

        /* Lock */
        nfcont = readl(regs + S3C_NFCONT);
        nfcont |= S3C_NFCONT_MECCLOCK;  // <---- this is recommended for
S3C2440 too - Alex
        writel(nfcont, regs + S3C_NFCONT);

        if (nand_type == S3C_NAND_TYPE_SLC) {
                nfmecc0 = readl(regs + S3C_NFMECC0);

                ecc_code[0] = nfmecc0 & 0xff;
                ecc_code[1] = (nfmecc0 >> 8) & 0xff;
                ecc_code[2] = (nfmecc0 >> 16) & 0xff;
                ecc_code[3] = (nfmecc0 >> 24) & 0xff;
        } else {
                if (cur_ecc_mode == NAND_ECC_READ)
                        s3c_nand_wait_dec(); // <--- another difference,
MLC needs "wait ready"< SLC doesn't - Alex
                else {
                        s3c_nand_wait_enc();

                        nfmecc0 = readl(regs + S3C_NFMECC0);
                        nfmecc1 = readl(regs + S3C_NFMECC1);

                        ecc_code[0] = nfmecc0 & 0xff;
                        ecc_code[1] = (nfmecc0 >> 8) & 0xff;
                        ecc_code[2] = (nfmecc0 >> 16) & 0xff;
                        ecc_code[3] = (nfmecc0 >> 24) & 0xff;
                        ecc_code[4] = nfmecc1 & 0xff;
                        ecc_code[5] = (nfmecc1 >> 8) & 0xff;
                        ecc_code[6] = (nfmecc1 >> 16) & 0xff;
                        ecc_code[7] = (nfmecc1 >> 24) & 0xff;
                }
        }

        return 0;
}

I suggest to support both new and old hardware in the same code. Why
not? It is 95% the same.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2012-05-04 10:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03 13:14 [PATCH 0/4] Support Samsung S5PV210 CPU Alexey Galakhov
2012-05-03 13:14 ` [PATCH 1/4] Support most Samsung SoCs in S3C serial driver Alexey Galakhov
2012-05-03 13:14 ` [PATCH 2/4] Fine split S3C arch dependencies from generic code Alexey Galakhov
2012-05-03 17:41   ` Juergen Beisert
2012-05-04  9:39     ` Alexey Galakhov
2012-05-04  9:58       ` Juergen Beisert
2012-05-04 10:50         ` Alexey Galakhov [this message]
2012-05-04 11:13           ` Juergen Beisert
2012-05-04 11:26             ` missing sscanf christian.buettner
2012-05-04 11:40             ` [PATCH 2/4] Fine split S3C arch dependencies from generic code Alexey Galakhov
2012-05-04 12:00               ` Juergen Beisert
2012-05-04 12:34                 ` Alexey Galakhov
2012-05-04 10:52         ` Alexey Galakhov
2012-05-03 13:14 ` [PATCH 3/4] Minimal S5PV210 + Tiny210 support (2nd stage only) Alexey Galakhov
2012-05-03 17:49   ` Juergen Beisert
2012-05-04  9:41     ` Alexey Galakhov
2012-05-03 13:14 ` [PATCH 4/4] S5PV210 iROM magic boot code Alexey Galakhov
2012-05-03 17:59   ` Juergen Beisert
2012-05-04  9:47     ` Alexey Galakhov

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=4FA3B493.7030002@gmail.com \
    --to=agalakhov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=jbe@pengutronix.de \
    /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