linux-kernel - Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EDFBA6D.9080500@freescale.com>
Date:	Wed, 7 Dec 2011 13:11:41 -0600
From:	Scott Wood <scottwood@...escale.com>
To:	LiuShuo <b35362@...escale.com>
CC:	<shuo.liu@...escale.com>, <dwmw2@...radead.org>,
	<Artem.Bityutskiy@...ia.com>, <linux-mtd@...ts.infradead.org>,
	<linuxppc-dev@...ts.ozlabs.org>, <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <leoli@...escale.com>
Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
 large-page Nand chip

On 12/06/2011 09:55 PM, LiuShuo wrote:
> 于 2011年12月07日 08:09, Scott Wood 写道:
>> On 12/03/2011 10:31 PM, shuo.liu@...escale.com wrote:
>>> From: Liu Shuo<shuo.liu@...escale.com>
>>>
>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In
>>> order
>>> to support the Nand flash chip whose page size is larger than 2K bytes,
>>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
>>> them to a large buffer.
>>>
>>> Signed-off-by: Liu Shuo<shuo.liu@...escale.com>
>>> ---
>>> v3:
>>>      -remove page_size of struct fsl_elbc_mtd.
>>>      -do a oob write by NAND_CMD_RNDIN.
>>>
>>>   drivers/mtd/nand/fsl_elbc_nand.c |  243
>>> ++++++++++++++++++++++++++++++++++----
>>>   1 files changed, 218 insertions(+), 25 deletions(-)
>> What is the plan for bad block marker migration?
> This patch has been ported to uboot now, I think we can make a special
> uboot image for bad
> block marker migration when first use the chip.

It should not be a special image, and there should be some way to mark
that the migration has happened.  Even if we do the migration in U-Boot,
Linux could check for the marker and if absent, disallow access and tell
the user to run the migration tool.

>>> @@ -473,13 +568,72 @@ static void fsl_elbc_cmdfunc(struct mtd_info
>>> *mtd, unsigned int command,
>>>            * write so the HW generates the ECC.
>>>            */
>>>           if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column != 0 ||
>>> -            elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize)
>>> -            out_be32(&lbc->fbcr,
>>> -                elbc_fcm_ctrl->index - elbc_fcm_ctrl->column);
>>> -        else
>>> +            elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize) {
>>> +            if (elbc_fcm_ctrl->oob&&  mtd->writesize>  2048) {
>>> +                out_be32(&lbc->fbcr, 64);
>>> +            } else {
>>> +                out_be32(&lbc->fbcr, elbc_fcm_ctrl->index
>>> +                        - elbc_fcm_ctrl->column);
>>> +            }
>> We need to limit ourselves to the regions that have actually been
>> written to in the buffer.  fbcr needs to be set separately for first and
>> last subpages, with intermediate subpages having 0, 64, or 2112 as
>> appropriate.  Subpages that are entirely before column or entirely after
>> column + index should be skipped.
> 
> I have considered this case, but I don't think it is useful.
>     1.There isn't a 'length' parameter in driver interface, although we
> can get it from 'index - column'.

Right.  column is start, and index is end + 1.  We have the bounds of
what has been written.

>     2.To see nand_do_write_oob() in nand_base.c, it fill '0xff' to
> entire oob area first and write the user data by nand_fill_oob(), then
> call ecc.write_oob (default is nand_write_oob_std()).

Do we really want to assume that that's what it will always do?

And if we do want to make such assumptions, we could rip out all usage
of index/column here, and just handle "oob" and "full page" cases.

-Scott

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/