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?