DiskOn Chip Millennium Plus 32MB + INFTL

Husam husamsenussi at gmail.com
Sat Jun 10 08:21:37 EDT 2006

On Friday 09 June 2006 01:18, you wrote:
> On Fri, 2006-06-09 at 01:04 +0100, Husam wrote:
> > I have device with  DiskOnChip Millennium Plus 64M "2x 32M", so I start
> > making changes to nand based driver using the old one but I found the
> > following problems:
> >
> > 1. The NAND layer use lookup table to set the size of the page, erase
> > block .. etc, but this does work will 32/64M because of interleave.
> I thought the 64MiB device was two separate 'floors' of 32MiB? So it's
> two chips of the same size... what exactly is the problem?
Yes thats correct but the 32MiB consist of two "NAND 16MiB, 8-bit" Chip, 
providing 16 bit access using interleave, and that double size the page "Page 
= 1024 + 32 OOB".

But does NAND layer need to be abee to handle Multi floor device?

> > 2. When I set bus width to 16 in diskonchip level nand_scan return an
> > error because that doesn't match with table.
> Doesn't match with which table? What chip ID is detected?
Yes the ID exist on the table "mfr = 0x98 (Toshiba) , id = 0x75" which match 
the id I get from trueffs driver for wince, so I would expect "NAND 16MiB, 
8-bit". However as I said before the driver should double the size of the 
page because of interleave.

> > 3. Reading and writing has to be done in 16 bit otherwise you lose data,
> > because MDOC+ 32/64M moves the pointer 2 bytes even if you read one byte.
> That's OK though, isn't it? Writing has to be done in chunks much larger
> than that anyway, and for ECC reasons so does reading.
> > 4. I found that read_buff terminate the read each time, and because of
> > that nand_read_ecc skip bytes when read across sections.
> I think the new code probably fixed this, didn't it? If not, we can make
> sure it does.
No  you are still terminating the read at the end of read_buf function, you 
wold need to

1. Send READ command
2. Read date "e.g. 512 bytes" 
3. Read ECC 6 bytes
4. terminate read stream

My be diskonchip layer should implement read_page !!!

> > 5. Layout of the data on the page is different form 16M, but I'm not sure
> > if this is specific  to INTFL.
> I _think_ it's specific to INFTL -- it's weird, though. I don't actually
> know why M-Systems did that interleaving. There are guys from M-Systems
> on the list though -- perhaps they can enlighten us?
But would be able to use the same layout with jffs?

> > I had look at the changes you guys made recently and I found that some of
> > these change would fix some of the above problems but not all of them,.
> Now is a good time to get the remaining issues fixed. I'd very much like
> to have the 32MiB and 64MiB DiskOnChip Millennium Plus devices working.

Thats good ... because from what I see 64MiB is not even supported by INTFL 
layer, in 64MiB each device has separate boot records but information for 
some of the partitions into the two boot records.


Partition 1


        virtualUnits    = 1184
        firstUnit       = 17
        lastUnit        = 0 				====> Disk 2
        flags           = 0x4000000d
        spareUnits      = 2
        Reserved0       = 16
        Reserved1       = 0

Disk 2

        virtualUnits    = 1184
        firstUnit       = 0					===> in Disk 1
        lastUnit        = 1224
        flags           = 0x4000000d
        spareUnits      = 2
        Reserved0       = 0
        Reserved1       = 0

More information about the linux-mtd mailing list