supporting stupid chips

supporting stupid chips

[Ian Molton]

Hi.

I've come to the conclusion that my controller only supports word reads from its data register.

the question is, what to do?

My choice would be to provide a read_id function and facility to indicate that read_byte is not available (NULL ptr?). IIRC we can already provide bulk transfer functions anyhow.

If this is OK I can make these changes and submit a patch.

if not, suggestions ?

Re: supporting stupid chips part II

[Ian Molton]

Hi.

I've hacked some new read/write functions and a new command function
too, and I can now get to the 24th block before it complains that every
subsequent block is a bad erase block.

The controller is a pest. for writes of commands, it needs bytes. for
the address it needs a word.

for everything else? god only knows. I think probably words for data
transfers.

having never used MTD before, Im not sure how to go about testing it.

Does it require userspace tools?
Should I see anything in /proc/mtd (or anywhere else) ?
What should I expect it to do, given the disk probably has a SSFDC DOS
filesystem on it (winCE handheld device)?

Re: supporting stupid chips part III

[Ian Molton]

Hi.

so, we can read the chip... progress!

this isnt sitting very well with me though.

this controllers read accesses to the data register are odd in that it
*requires* word reads for some accesses but not others, which doesnt
mesh well with the generic code.

Currently in the generic code, we call this->read_byte in the functions:

nand_scan
nand_block_bad
nand_check_wp
nand_command
nand_command_lp
nand_wait

in nand_scan(), we use it to read the id and extended id attributes.
in nand_block_bad(), its used to read a single byte of the OOB
in nand_check_wp() its used to read the chips status.
in nand_wait() its used to read the chips status also.

I havent been able to test this, but based on what I know, the usage in
nand_block_bad(), nand_check_wp(), and nand_wait() will probably work on
this chip. nand_scan() does not as it attempts two consecutive reads
when the chip demands a word read.

Im also unclear as to what on earth nand_command() is up to when given a
SEQIN comand - heres the code...

        if (command == NAND_CMD_SEQIN) {
                int readcmd;

                if (column >= mtd->oobblock) {
                        /* OOB area */
                        column -= mtd->oobblock;
                        readcmd = NAND_CMD_READOOB;
                } else if (column < 256) {
                        /* First 256 bytes --> READ0 */
                        readcmd = NAND_CMD_READ0;
                } else {
                        column -= 256;
                        readcmd = NAND_CMD_READ1;
                }
                this->write_byte(mtd, readcmd);
        }
        this->write_byte(mtd, command);

SEQIN is 0x80, and according to both my spec and my disassemblies, you
dont send additional data with it. AFAICT, every time we send SEQIN we
send readcmd first. why?

Re: supporting stupid chips part IV

[Ian Molton]

This gets worse...

So, now we have the chip reading OK with soft ECC, albeit using a *bizarre* layout for the ECC data.

but it appears the hardware ECC doesnt work! the little bugger.

Re: supporting stupid chips part IV

[Ian Molton]

On Mon, 23 Aug 2004 00:38:35 +0100
Ian Molton <spyro@f2s.com> wrote:

Hit ctrl-enter, oops... try again...

> This gets worse...
> 
> So, now we have the chip reading OK with soft ECC, albeit using a
> *bizarre* layout for the ECC data.
> 
> but it appears the hardware ECC doesnt work! the little bugger.

looking at winCE code more closely, I now see that winCE only uses hw
ECC when *writing*, although it actually seems to reset and enable hw
ECC when reading - just discards the results, bah!

oh well. I guess its back ot soft ECC for now... I'll send an email to
toshiba and see if they have anything to say...