MTD drivers for DoC Millenium Plus

MTD drivers for DoC Millenium Plus

[angainor]

Hi all,
I'm trying to set up a single boot solution based
on DiscOnChip Millenium Plus and Linux (yeah, I
know... I should use a flash chip instead ;)
not up to me.) No real problems when doing that 
with M-Systems binary linux driver, still my boss 
would rather use a GPLd driver. 
I have experienced some problems with doc2001plus 
and inftl drivers and I hoped you could help me out. 
And yes, I know that the inftl driver is quite new...
I could work on it for some time, if it wouldn't be
too much time and if I knew where to start.

First of all, docprobe successfuly identifies DOCMP,
but total size of the DoC is only half of its actual
size (64MiB chip is identified as 32MiB).
I have studied the "DiskOnChip 2000 128Mb problem"
thread here on list and tried to change the
MAX_CHIPS_MPLUS define to something else than 1.
Well, this way I got an 128MiB disk, then a
256MiB one, and so on... :). way too many chips found.
I am able to correctly read the /dev/mtd0 device
(char) with doc2001plus driver. However, 
insmod inftl has no effect. Looking into the code
and little debugging showed that:

1. inftlcore.c

        if (mtd->ecctype != MTD_ECC_RS_DiskOnChip)
                return;

   does indeed return. I guess it shouldn't...
   I don't yet understand the full architecture
   of linux MTD driver, but a quick grep showed,
   that mtd->ecctype is never actually set, except
   for mtd->ecctype = MTD_ECC_SW; in nand.c.
   Is this value acquired from the chip directly?
   If so, there must be something wrong there.
   I commented out that part to see what's next ;)

	Jun  4 13:36:43 (none) syslog.warn klogd: INFTL: Media Header ->
	Jun  4 13:36:43 (none) syslog.warn klogd:     bootRecordID          = BNAND
	Jun  4 13:36:43 (none) syslog.warn klogd:     NoOfBootImageBlocks   = -1
	Jun  4 13:36:43 (none) syslog.warn klogd:     NoOfBinaryPartitions  = 1
	Jun  4 13:36:43 (none) syslog.warn klogd:     NoOfBDTLPartitions    = 1
	Jun  4 13:36:43 (none) syslog.warn klogd:     BlockMultiplerBits    = 0
	Jun  4 13:36:43 (none) syslog.warn klogd:     FormatFlgs            = 1
	Jun  4 13:36:43 (none) syslog.warn klogd:     OsakVersion           = 0x30343135
	Jun  4 13:36:43 (none) syslog.warn klogd:     PercentUsed           = 98
	Jun  4 13:36:43 (none) syslog.warn klogd:     PARTITION[0] ->
	Jun  4 13:36:43 (none) syslog.warn klogd:         virtualUnits    = 10
	Jun  4 13:36:43 (none) syslog.warn klogd:         firstUnit       = 0
	Jun  4 13:36:43 (none) syslog.warn klogd:         lastUnit        = 0
	Jun  4 13:36:43 (none) syslog.warn klogd:         flags           = 0x20000000
	Jun  4 13:36:43 (none) syslog.warn klogd:         spareUnits      = 0
	Jun  4 13:36:43 (none) syslog.warn klogd: INFTL: Media Header Parition 0 
sanity check failed
	Jun  4 13:36:43 (none) syslog.warn klogd:     firstUnit 0 : lastUnit 0  >  
virtualUnits 0
	Jun  4 13:36:43 (none) syslog.warn klogd: INFTL: could not find valid boot record?
	Jun  4 13:36:43 (none) syslog.warn klogd: INFTL: could not mount device	
   
   Basically, the start is ok and does reflect the
   reality. So what goes wrong afterwards?

2. doc2000.h
   
   I found the following definition:

	#define DoC_Mplus_OutputControl         0x1002

   Shouldn't this be rather:

	#define DoC_Mplus_OutputControl         0x100c

   This is what I found in DOC_Millennium_Plus_DS_Rev1.7.pdf.
   0x1002 is actually NOP. I don't think this will help me
   much though ;)

Re: MTD drivers for DoC Millenium Plus

[David Woodhouse]

On Wed, 2003-06-04 at 11:56, angainor@evo.evopolska.com wrote:
> First of all, docprobe successfuly identifies DOCMP,
> but total size of the DoC is only half of its actual
> size (64MiB chip is identified as 32MiB).

Hmmm. Sounds like a bug in the hardware driver. Greg?

> I have studied the "DiskOnChip 2000 128Mb problem"
> thread here on list and tried to change the
> MAX_CHIPS_MPLUS define to something else than 1.
> Well, this way I got an 128MiB disk, then a
> 256MiB one, and so on... :). way too many chips found.

> 1. inftlcore.c
> 
>         if (mtd->ecctype != MTD_ECC_RS_DiskOnChip)
>                 return;
> 
>    does indeed return. I guess it shouldn't...

Mea Culpa. I've fixed that in CVS now.

> 
> INFTL: Media Header ->
>      bootRecordID          = BNAND
>      NoOfBootImageBlocks   = -1
>      NoOfBinaryPartitions  = 1
>      NoOfBDTLPartitions    = 1
>      BlockMultiplerBits    = 0
>      FormatFlgs            = 1
>      OsakVersion           = 0x30343135
>      PercentUsed           = 98
>      PARTITION[0] ->
>          virtualUnits    = 10
>          firstUnit       = 0
>          lastUnit        = 0
>          flags           = 0x20000000
>          spareUnits      = 0
>  INFTL: Media Header Parition 0  sanity check failed
>      firstUnit 0 : lastUnit 0  >   virtualUnits 0
> 
>    Basically, the start is ok and does reflect the
>    reality. So what goes wrong afterwards?

Can you dump the contents of the media header using the DOS tools? How
big is the 'binary' partition? If you comment out that sanity check does
it actually work? 


> 2. doc2000.h
>    
>    I found the following definition:
> 
> 	#define DoC_Mplus_OutputControl         0x1002
> 
>    Shouldn't this be rather:
> 
> 	#define DoC_Mplus_OutputControl         0x100c
> 
>    This is what I found in DOC_Millennium_Plus_DS_Rev1.7.pdf.
>    0x1002 is actually NOP. I don't think this will help me
>    much though ;)

I haven't seen that documentation. Greg?

-- 
dwmw2

Re: MTD drivers for DoC Millenium Plus

[angainor]

> 
> Can you dump the contents of the media header using the DOS tools? How
> big is the 'binary' partition? If you comment out that sanity check does
> it actually work? 

thie chip has been formated with

./dformat -win:e000 -y -ipl:IPL0508.BIN -s:DOC514.EXB -bdkf0:VT6027D.018  -first

where VT6027D.018 is 262144 bytes large. That's a BIOS. With your current
CVS updates I get the following. I suspect this behaviour results from the
fact that my DoC is still recognized as 32MiB, where in fact it is a 64MiB 
one. That's why the real number of units does not match the expected one.
And bypassing sanity checks cleared my DoC, including BIOS. nice :))


Jun 11 13:59:17 (none) syslog.warn klogd: INFTL: Media Header ->
Jun 11 13:59:17 (none) syslog.warn klogd:     bootRecordID          = BNAND
Jun 11 13:59:17 (none) syslog.warn klogd:     NoOfBootImageBlocks   = -1
Jun 11 13:59:17 (none) syslog.warn klogd:     NoOfBinaryPartitions  = 1
Jun 11 13:59:17 (none) syslog.warn klogd:     NoOfBDTLPartitions    = 1
Jun 11 13:59:17 (none) syslog.warn klogd:     BlockMultiplerBits    = 0
Jun 11 13:59:17 (none) syslog.warn klogd:     FormatFlgs            = 1
Jun 11 13:59:17 (none) syslog.warn klogd:     OsakVersion           = 0x30343135
Jun 11 13:59:17 (none) syslog.warn klogd:     PercentUsed           = 98
Jun 11 13:59:17 (none) syslog.warn klogd:     PARTITION[0] ->
Jun 11 13:59:17 (none) syslog.warn klogd:         virtualUnits    = 10
Jun 11 13:59:17 (none) syslog.warn klogd:         firstUnit       = 4
Jun 11 13:59:17 (none) syslog.warn klogd:         lastUnit        = 13
Jun 11 13:59:17 (none) syslog.warn klogd:         flags           = 0x20000000
Jun 11 13:59:17 (none) syslog.warn klogd:         spareUnits      = 0
Jun 11 13:59:17 (none) syslog.warn klogd:     PARTITION[1] ->
Jun 11 13:59:17 (none) syslog.warn klogd:         virtualUnits    = 1991
Jun 11 13:59:17 (none) syslog.warn klogd:         firstUnit       = 15
Jun 11 13:59:17 (none) syslog.warn klogd:         lastUnit        = 2047
Jun 11 13:59:17 (none) syslog.warn klogd:         flags           = 0xc0000000
Jun 11 13:59:17 (none) syslog.warn klogd:         spareUnits      = 2
Jun 11 13:59:17 (none) syslog.err klogd: _DoC_WaitReady called for out-of-line wait
Jun 11 13:59:17 (none) syslog.warn klogd: INFTL: Media Header sanity check failed:
Jun 11 13:59:17 (none) syslog.warn klogd:         numvunits (1991) > 
				nb_blocks (1024) - nb_boot_blocks(15) - 2

Re: MTD drivers for DoC Millenium Plus

[angainor]

After delving a little more into the code...

I have managed to cheat a little through the INFTL_mount,
so now I'm back in inftlcode.c/inftl_add_mtd().
Discovered inftl->mbd.size is correct, M-Systems 
driver did discover same size. Next, calculation of
cylinders/heads/sectors fails, but never mind that.
Below is the code that worries me a lot:

	...
        if (add_mtd_blktrans_dev) {
                if (inftl->PUtable)
	...

Guys, really, has nobody even run this code once
to see if it works? add_mtd_blktrans_dev is a function.
It needs arguments. Specifically, it needs to feed on
&inftl->mbd. So this should actually be:

	...
        if (add_mtd_blktrans_dev(&inftl->mdb)) {
                if (inftl->PUtable)
	...

Checking if a pointer to a function is not zero will 
in most cases return true under linux. This COULD NOT 
possibly work, not once. What's more scary, exactly the 
same code is present in nftlcore.c. And that driver must 
have been tested. What's going on? I've checked out CVS today. 
Am I missing something? 

Regards

Marcin

Re: MTD drivers for DoC Millenium Plus

[David Woodhouse]

On Wed, 2003-06-11 at 14:13, angainor@evo.evopolska.com wrote:

> Guys, really, has nobody even run this code once
> to see if it works? add_mtd_blktrans_dev is a function.
> It needs arguments. Specifically, it needs to feed on
> &inftl->mbd. So this should actually be:

Oops. Sorry. No -- it wasn't tested. I tested FTL and mtdblock when
converting to the new mtd_blktrans stuff but not NFTL and INFTL. Barring
stupid typos, I expected it to 'just work'.

-- 
dwmw2

Re: MTD drivers for DoC Millenium Plus

[Greg Ungerer]

David Woodhouse wrote:
> On Wed, 2003-06-04 at 11:56, angainor@evo.evopolska.com wrote:
>>First of all, docprobe successfuly identifies DOCMP,
>>but total size of the DoC is only half of its actual
>>size (64MiB chip is identified as 32MiB).
> 
> Hmmm. Sounds like a bug in the hardware driver. Greg?

Sure does. I didn't know there was a 64MiB Plus part.
I'll see what I can find out about it.


>>I have studied the "DiskOnChip 2000 128Mb problem"
>>thread here on list and tried to change the
>>MAX_CHIPS_MPLUS define to something else than 1.
>>Well, this way I got an 128MiB disk, then a
>>256MiB one, and so on... :). way too many chips found.

We will need to find out a little bit more about this
part. The Millennium Plus family originally had 2 memebers,
each with their own high level ID. Easy to tell them
apart. There internal flash organization is quite different
though, the larger (32MiB) part has dual interleaved
flash.


>>INFTL: Media Header ->
>>     bootRecordID          = BNAND
>>     NoOfBootImageBlocks   = -1
>>     NoOfBinaryPartitions  = 1
>>     NoOfBDTLPartitions    = 1
>>     BlockMultiplerBits    = 0
>>     FormatFlgs            = 1
>>     OsakVersion           = 0x30343135
>>     PercentUsed           = 98
>>     PARTITION[0] ->
>>         virtualUnits    = 10
>>         firstUnit       = 0
>>         lastUnit        = 0
>>         flags           = 0x20000000
>>         spareUnits      = 0
>> INFTL: Media Header Parition 0  sanity check failed
>>     firstUnit 0 : lastUnit 0  >   virtualUnits 0
>>
>>   Basically, the start is ok and does reflect the
>>   reality. So what goes wrong afterwards?
> 
> 
> Can you dump the contents of the media header using the DOS tools? How
> big is the 'binary' partition? If you comment out that sanity check does
> it actually work? 

This sure does look odd. The doc I have states that the firstUnit
and lastUnit should be valid even for binary partitions.


>>2. doc2000.h
>>   
>>   I found the following definition:
>>
>>	#define DoC_Mplus_OutputControl         0x1002
>>
>>   Shouldn't this be rather:
>>
>>	#define DoC_Mplus_OutputControl         0x100c
>>
>>   This is what I found in DOC_Millennium_Plus_DS_Rev1.7.pdf.
>>   0x1002 is actually NOP. I don't think this will help me
>>   much though ;)
> 
> I haven't seen that documentation. Greg?

Yep, this is a bug. I'll fix that in CVS.
Shouldn't have any effect for you though, the driver
doesn't use that register at all.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear Pty Ltd                            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

Re: MTD drivers for DoC Millenium Plus

[angainor]

> >>I have studied the "DiskOnChip 2000 128Mb problem"
> >>thread here on list and tried to change the
> >>MAX_CHIPS_MPLUS define to something else than 1.
> >>Well, this way I got an 128MiB disk, then a
> >>256MiB one, and so on... :). way too many chips found.
> 
> We will need to find out a little bit more about this
> part. The Millennium Plus family originally had 2 memebers,
> each with their own high level ID. Easy to tell them
> apart. There internal flash organization is quite different
> though, the larger (32MiB) part has dual interleaved
> flash.

> This sure does look odd. The doc I have states that the firstUnit
> and lastUnit should be valid even for binary partitions.

Well, i think i finally got something. As i thought, the
problem was that the driver did not recognize the size of the
DoC correctly. I played with MAX_CHIPS_MPLUS/MAX_FLOORS_MPLUS.
The correct setting seems to be in this case:

	MAX_CHIPS_MPLUS=1
	MAX_FLOORS_MPLUS=2

The detection code does not work here.
Maybe it should be done differently with DoCMP?
Greg, if you point me to proper data sheets, i might
try to figure out.

I get no sanity checks errors and the driver correctly
recognized two linux partitions created earlier with M-Systems
driver. At least the partition table was read correctly.
Dumps of the partitions differed from the actual data
in many places. The only thing the driver said that might
be wrong was this (<X> is in range 1981-2047, so not all blocks
are affected):

	INFTL: formatting chain at block <X>
	INFTL: formatting chain at block <X>
	INFTL: formatting block <X>
	MTD: Error 0xffffffa5 erasing at 0x3f20000
	INFTL: error while formatting block <X>

Any writing causes immediate system death :))

Might my problems result from wrong cylinders/heads/sectors
decided by the driver? I get:

	INFTL: cannot calculate a geometry to match size of 0x1f1c0.
	INFTL: using C:995 H:16 S:8 (== 0x1f180 sects)

Re: MTD drivers for DoC Millenium Plus

[Greg Ungerer]

angainor@evo.evopolska.com wrote:
>>>>I have studied the "DiskOnChip 2000 128Mb problem"
>>>>thread here on list and tried to change the
>>>>MAX_CHIPS_MPLUS define to something else than 1.
>>>>Well, this way I got an 128MiB disk, then a
>>>>256MiB one, and so on... :). way too many chips found.
>>
>>We will need to find out a little bit more about this
>>part. The Millennium Plus family originally had 2 memebers,
>>each with their own high level ID. Easy to tell them
>>apart. There internal flash organization is quite different
>>though, the larger (32MiB) part has dual interleaved
>>flash.
> 
>>This sure does look odd. The doc I have states that the firstUnit
>>and lastUnit should be valid even for binary partitions.
> 
> Well, i think i finally got something. As i thought, the
> problem was that the driver did not recognize the size of the
> DoC correctly. I played with MAX_CHIPS_MPLUS/MAX_FLOORS_MPLUS.
> The correct setting seems to be in this case:
> 
> 	MAX_CHIPS_MPLUS=1
> 	MAX_FLOORS_MPLUS=2

This would seem to make sense from what I know about
the Millennium Plus 32MiB part. I am talking with the
guys I know at M-Systems to get an understanding of
how to access the 64MiB.


> The detection code does not work here.
> Maybe it should be done differently with DoCMP?
> Greg, if you point me to proper data sheets, i might
> try to figure out.

I don't have anything for the 64MiB part. As fas as I know
the publicly available 32MiB datasheet doesn't give you
much information to go on for programming it.

The doc I have is under restricted access, I can't let it out.


> I get no sanity checks errors and the driver correctly
> recognized two linux partitions created earlier with M-Systems
> driver. At least the partition table was read correctly.

 From what I know so far the first 32MiB shoud look
pretty much like the 32MiB part. The upper 32MiB
is another flash device. So no suprise that you should
be able to read the partition table.


> Dumps of the partitions differed from the actual data
> in many places. The only thing the driver said that might
> be wrong was this (<X> is in range 1981-2047, so not all blocks
> are affected):
> 
> 	INFTL: formatting chain at block <X>
> 	INFTL: formatting chain at block <X>
> 	INFTL: formatting block <X>
> 	MTD: Error 0xffffffa5 erasing at 0x3f20000
> 	INFTL: error while formatting block <X>
> 
> Any writing causes immediate system death :))
> 
> Might my problems result from wrong cylinders/heads/sectors
> decided by the driver? I get:
> 
> 	INFTL: cannot calculate a geometry to match size of 0x1f1c0.
> 	INFTL: using C:995 H:16 S:8 (== 0x1f180 sects)

By my simple calculations that is about right. I think the
problem is that the doc2001plus.c code just doesn't know
how to correctly access the 2nd (upper 32MiB) flash in the
64MiB part. I try and find out exactly how to do that.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude          EMAIL:  gerg@snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com

Re: MTD drivers for DoC Millenium Plus

[Greg Ungerer]

angainor@evo.evopolska.com wrote:
>>>>I have studied the "DiskOnChip 2000 128Mb problem"
>>>>thread here on list and tried to change the
>>>>MAX_CHIPS_MPLUS define to something else than 1.
>>>>Well, this way I got an 128MiB disk, then a
>>>>256MiB one, and so on... :). way too many chips found.
>>
>>We will need to find out a little bit more about this
>>part. The Millennium Plus family originally had 2 memebers,
>>each with their own high level ID. Easy to tell them
>>apart. There internal flash organization is quite different
>>though, the larger (32MiB) part has dual interleaved
>>flash. 
> 
>>This sure does look odd. The doc I have states that the firstUnit
>>and lastUnit should be valid even for binary partitions. 
> 
> Well, i think i finally got something. As i thought, the
> problem was that the driver did not recognize the size of the
> DoC correctly. I played with MAX_CHIPS_MPLUS/MAX_FLOORS_MPLUS.
> The correct setting seems to be in this case:
> 
> 	MAX_CHIPS_MPLUS=1
> 	MAX_FLOORS_MPLUS=2
> 
> The detection code does not work here.
> Maybe it should be done differently with DoCMP?
> Greg, if you point me to proper data sheets, i might
> try to figure out.

According to M-Systems the 2nd flash is just accessed
by setting the DeviceSelect register appropriately.

So your above defines are correct. If this does not
detect the 2nd flash then there must be a problem in
the DoC_IdentChip() code. Reading the code nothing is
immediately obviously wrong to me.

You do need to skip using the 3 reserved blocks at
the front of every flash device inside this thing though.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear Pty Ltd                            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com