From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 29 Apr 2013 15:46:17 -0500 Subject: [U-Boot] [PATCH v3 07/11] mtd: nand: add Faraday FTNANDC021 NAND controller support In-Reply-To: (from dantesu@gmail.com on Sun Apr 28 22:28:14 2013) Message-ID: <1367268377.32182.16@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 04/28/2013 10:28:14 PM, Kuo-Jung Su wrote: > 2013/4/27 Scott Wood : > > Shouldn't .eccpos depend on HWECC? > > > > > > Actually it means nothing here, the ECC function is designed to be > some kind of > a blackbox to users (i.e softwares), the actual position of ECC codes > are not documented > in the datasheet, I have to dig it out from RTL which I do not have > permission to access. Maybe get rid of .eccpos altogether, and supply your own (much simpler) hwecc read/write_page functions -- similar to what fsl_elbc_nand, which also has transparent (but not hidden) ECC, does? This would also let you get rid of hwctl/calculate/correct. > > Is it really all in one step, regardless of page size? > > > > Theoretical, NO. > It uses R-S or BCH for Forwarding Error Correction, which is selected > at RTL level. > Which means it actually 522 bytes per step at RS and 528 bytes per > step at BCH. > > However it's all blackbox to software, the FTNANDC021 simply supports > only > page read, so looks like everything is done at 1 step. It would matter if you could detect correctable errors, but since you can't, it doesn't. -Scott