[U-Boot] [PATCH] NAND: Add nand read.raw and write.raw commands
These commands should work around various "hardware" ECC and BCH methods. This is important for example in case where the user needs to write precisely what's in a buffer to a NAND page, with no interference of hardware ECC engine or such.
Signed-off-by: Marek Vasut marek.vasut@gmail.com --- common/cmd_nand.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c index b767cd2..ca510ae 100644 --- a/common/cmd_nand.c +++ b/common/cmd_nand.c @@ -606,6 +606,20 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) ret = nand->read_oob(nand, off, &ops); else ret = nand->write_oob(nand, off, &ops); + } else if (!strcmp(s, ".raw")) { + /* Raw access */ + mtd_oob_ops_t ops = { + .datbuf = (u8 *)addr, + .oobbuf = ((u8 *)addr) + nand->writesize, + .len = nand->writesize, + .ooblen = nand->oobsize, + .mode = MTD_OOB_RAW + }; + + if (read) + ret = nand->read_oob(nand, off, &ops); + else + ret = nand->write_oob(nand, off, &ops); } else { printf("Unknown nand command suffix '%s'.\n", s); return 1;
Dear Marek,
On 08/26/2011 12:04 AM, Marek Vasut wrote:
These commands should work around various "hardware" ECC and BCH methods. This is important for example in case where the user needs to write precisely what's in a buffer to a NAND page, with no interference of hardware ECC engine or such.
I think I don't get it :)
Where is the problem with writing this stuff to NAND now? If the ECC interferes there was a problem with the NAND Flash therefore the data is corrupted.
Regards Simon
On Friday, August 26, 2011 09:57:17 AM Simon Schwarz wrote:
Dear Marek,
On 08/26/2011 12:04 AM, Marek Vasut wrote:
These commands should work around various "hardware" ECC and BCH methods. This is important for example in case where the user needs to write precisely what's in a buffer to a NAND page, with no interference of hardware ECC engine or such.
I think I don't get it :)
Where is the problem with writing this stuff to NAND now? If the ECC interferes there was a problem with the NAND Flash therefore the data is corrupted.
It's not an issue with data corruption. For example in my case, if nand_write_skip_bad() is called, HW ECC writes the ECC information in various places in the page. But if done this way, exactly what's in the buffer is written to the page.
Cheers
Regards Simon
On 08/26/2011 04:49 PM, Marek Vasut wrote:
On Friday, August 26, 2011 09:57:17 AM Simon Schwarz wrote:
Dear Marek,
On 08/26/2011 12:04 AM, Marek Vasut wrote:
These commands should work around various "hardware" ECC and BCH methods. This is important for example in case where the user needs to write precisely what's in a buffer to a NAND page, with no interference of hardware ECC engine or such.
I think I don't get it :)
Where is the problem with writing this stuff to NAND now? If the ECC interferes there was a problem with the NAND Flash therefore the data is corrupted.
It's not an issue with data corruption. For example in my case, if nand_write_skip_bad() is called, HW ECC writes the ECC information in various places in the page. But if done this way, exactly what's in the buffer is written to the page.
But isn't then the HW ECC misconfigured? AFAIK ECC information should be written only to the OOB never into the normal page.
I'am really not sure if I understand the patch - it seems to me that you are writing/reading the oob while this collides with the description that you want to write data. Could you explain further what exactly the patch is supposed to do?
Regards Simon
Dear Simon Schwarz,
In message 4E57CB52.5000302@gmail.com you wrote:
But isn't then the HW ECC misconfigured? AFAIK ECC information should be written only to the OOB never into the normal page.
I'am really not sure if I understand the patch - it seems to me that you are writing/reading the oob while this collides with the description that you want to write data. Could you explain further what exactly the patch is supposed to do?
There are some SoCs with quite funny requiremnts regarding the organization of NAND they expect for their ROM boot loader. The Freescale (or rather SigmaTel) i.MX28 is one of them.
I think Marek needs this feature to format the NAND in such a way that booting from NAND works on i.MX28
Best regards,
Wolfgang Denk
participants (3)
-
Marek Vasut -
Simon Schwarz -
Wolfgang Denk