From: angelo <angelo70@gmail.com>
To: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Cc: uClinux development list <uclinux-dev@uclinux.org>
Subject: cfi_cmdset_0002.c SST39VF3201B issue
Date: Thu, 06 Oct 2011 14:29:08 +0200 [thread overview]
Message-ID: <4E8D9F14.4090108@gmail.com> (raw)
Dear all,
like me some other users had issues with this chip and jffs2.
From time to time users asks why they get errors trying to use jffs2
with this chip.
This chip, from the datasheet, allows to erase 4KB "sectors" or 64KB
"blocks", replying to cfi queries with a "setcor" erase size and a
"block" erase size.
I can be wrong of course, but this is what i figured out:
1) fixup decision
Someone of you decided to fix up this SST39VF3201 in this way:
static void fixup_old_sst_eraseregion(struct mtd_info *mtd)
{
struct map_info *map = mtd->priv;
struct cfi_private *cfi = map->fldrv_priv;
/*
* These flashes report two seperate eraseblock regions based on the
* sector_erase-size and block_erase-size, although they both
operate on the
* same memory. This is not allowed according to CFI, so we just
pick the
* sector_erase-size.
*/
cfi->cfiq->NumEraseRegions = 1;
}
Of course, in this way, deciding 0x1000 (sector-size) is the one to use,
jffs2 cannot be used safely, since
minimal data block is 4Kb + some hdr bytes. Wasn't better fixup to
"block" size (64K) ?
2) after fixup decision, when jffs2 asks to erase a block to
cfi_cmdset_0002.c, cfi driver seems to erase wrongly a 64K block.
This is what happen in detail:
jffs erase.c, to erase a block does: mtd->erase(), with a len
mtd->erasesize (4KB).
mtd->erase() is calls cfi_amdstd_erase_varsize ...
finally, do_erase_oneblock is called, where:
cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
cfi->device_type, NULL);
cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
cfi->device_type, NULL);
cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi,
cfi->device_type, NULL);
cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
cfi->device_type, NULL);
cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
cfi->device_type, NULL);
map_write(map, CMD(0x30), adr);
but this chip uses 0x30 cmd to erase a 64 KB block, and 0x50 to erase a
sector.
Please let me know if i am in the right direction, so i can think about
a patch that allows
jffs2 to be used with native hw 64KB block erasesize.
Regards
Angelo Dureghello
next reply other threads:[~2011-10-06 12:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-06 12:29 angelo [this message]
2011-10-06 12:48 ` cfi_cmdset_0002.c SST39VF3201B issue Fabio Giovagnini
2011-10-06 14:23 ` angelo
[not found] ` <4E8DB0A1.5080202@gmail.com>
2011-10-08 9:50 ` Fabio Giovagnini
2011-10-14 9:09 ` Artem Bityutskiy
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=4E8D9F14.4090108@gmail.com \
--to=angelo70@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=uclinux-dev@uclinux.org \
/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