Issues with a Doc Milplus

Issues with a Doc Milplus

[Nicolas Pouillon]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

Hello list !

I'm porting Linux to my PDA (Asus A620).
It has a DocMilPlus inside.
I'm running handhelds.org kernel, which has a non-up-to-date mtd part.
http://cvs.handhelds.org/cgi-bin/viewcvs.cgi/linux/kernel26/drivers/mtd/
(It still has Self-contained drivers)

When trying to make MTD part work, I bumped in different problems:


1/ Doc is mapped to mem address 0x0, in docprobe.c there is an
expression like: 
if (doc_config_location) {
	[probe at specified address]
} else {
	[probe hardlisted addresses]
}

So it never probes for my chip at 0. I noticed the same construct is
present in newer probing routines.
Is there a special way of declaring a chip at 0x0 ?


2/ It was not known by nan_ids, I had to add the following line:
{"NAND 64MiB 3,3V", 0xa5, 26, 0x4000, 0},

Then the chip is detected as:

INFTL: inftlcore.c $Revision: 1.14 $, inftlmount.c $Revision: 1.12 $
Using configured DiskOnChip probe address 0x0
DiskOnChip Millennium Plus found at address 0x0
Flash chip found: Manufacturer ID: 98, Chip ID: A5 (Toshiba:MyNAND 64MiB
3,3V) 
Flash chip found: Manufacturer ID: 98, Chip ID: A5 (Toshiba:MyNAND64MiB
3,3V) 
2 flash chips found. Total DiskOnChip size: 128 MiB
INFTL: could not find valid boot record?
INFTL: could not mount device
slram: not enough parameters.


3/ It seems to be detected twice, it should be 64MiB total, and there is
physically one chip on the board.
Could one chip be virtually two 32MiB chips ?
Is there some special tweaking I missed ?


4/ Using arm part in doc2000.h which is:
#define ReadDOC_(adr, reg)      ((unsigned char)(*(volatile __u32
*)(((unsigned long)adr)+((reg)<<2)))) 
#define WriteDOC_(d, adr, reg) do{ *(volatile __u32 *)(((unsigned
#long)adr)+((reg)<<2)) = (__u32)d; wmb();} while(0)

makes the machine crash, I have to use readb/writeb in order to make the
device work.



I'm sorry for this so-long mail, dont hesitate to flame me with some
RTFMs if I need them, but I've not found similar solved entries ;)

Thanks !

-- 
Nipo <nipo@ssji.net>
Gnu-PGP: 1024D/1DBF658F
http://nipo.ssji.net/nipo.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Issues with a Doc Milplus

[David Woodhouse]

On Fri, 2004-10-01 at 15:46 +0200, Nicolas Pouillon wrote:
> 1/ Doc is mapped to mem address 0x0, in docprobe.c there is an
> expression like: 
> if (doc_config_location) {
> 	[probe at specified address]
> } else {
> 	[probe hardlisted addresses]
> }
> 
> So it never probes for my chip at 0. I noticed the same construct is
> present in newer probing routines.
> Is there a special way of declaring a chip at 0x0 ?

Hmmm. We should probably use -1 for 'unconfigured' instead of zero. Want
to provide a patch accordingly?

> 2/ It was not known by nan_ids, I had to add the following line:
> {"NAND 64MiB 3,3V", 0xa5, 26, 0x4000, 0},

Are you sure that's a 64MiB chip?

> 3/ It seems to be detected twice, it should be 64MiB total, and there is
> physically one chip on the board.
> Could one chip be virtually two 32MiB chips ?

I think that might actually be the case for the 64MiB DiskOnChip M+,
yes.

> 4/ Using arm part in doc2000.h which is:
> #define ReadDOC_(adr, reg)      ((unsigned char)(*(volatile __u32
> *)(((unsigned long)adr)+((reg)<<2)))) 
> #define WriteDOC_(d, adr, reg) do{ *(volatile __u32 *)(((unsigned
> #long)adr)+((reg)<<2)) = (__u32)d; wmb();} while(0)
> 
> makes the machine crash, I have to use readb/writeb in order to make the
> device work.

If provide that in 'diff -u' form we can change that too.

-- 
dwmw2

Re: Issues with a Doc Milplus

[Nicolas Pouillon]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

[Fri, 01 Oct 2004 14:57:45 +0100]
David Woodhouse <dwmw2@infradead.org> eut le bonheur d'écrire:

> Hmmm. We should probably use -1 for 'unconfigured' instead of zero.
> Want to provide a patch accordingly?

I could do so, but it could break current configs where 0 meant "probing
at prelisted addresses"... (but users should read docs anyway ;))

> > 2/ It was not known by nan_ids, I had to add the following line:
> > {"NAND 64MiB 3,3V", 0xa5, 26, 0x4000, 0},
> 
> Are you sure that's a 64MiB chip?

In CE, there are 32Mib for system rom, and 32Mib for user, and chip is
alone on the board, so yes it is 64. I have chip ref somewhere if it can
help...

> > Could one chip be virtually two 32MiB chips ?
> 
> I think that might actually be the case for the 64MiB DiskOnChip M+,
> yes.

Right then, it explains both points. I'll declare it as a 32Mib chip in
list.

[mmio - readb/writeb]
> If provide that in 'diff -u' form we can change that too.

Hm, there is already #ifdef-ing using
-32bit mmio for __arm__
-16bit mmio for __ppc__
-readb/writeb else.
I read other PDA's config based on the same arch (Xscale), where it
seems to work. This issue seems quite "local" to my works, could this be
a side effect of something else ?

I'll submit a patch for these.

-- 
Nipo <nipo@ssji.net>
Gnu-PGP: 1024D/1DBF658F
http://nipo.ssji.net/nipo.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Patch !

[Nicolas Pouillon]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

[Fri, 1 Oct 2004 16:27:05 +0200]
Nicolas Pouillon <nipo@ssji.net> eut le bonheur d'écrire:

> I'll submit a patch for these.

Here it is, but I dont like changing 0 to -1 for undefined.
Maybe adding (another) config option could be better (like "force null
address probing")... thoughts ?

I made two patches, for different handleds.org kernel dates (fall July,
(the one I'm working on): 2.6.7, and now: 2.6.8.1)

http://nipo.ssji.net/mtd/patches/
(I've not tried 2.6.8.1 version)

-- 
Nipo <nipo@ssji.net>
Gnu-PGP: 1024D/1DBF658F
http://nipo.ssji.net/nipo.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Patch !

[Thomas Gleixner]

On Sat, 2004-10-02 at 15:55, Nicolas Pouillon wrote:
> I made two patches, for different handleds.org kernel dates (fall July,
> (the one I'm working on): 2.6.7, and now: 2.6.8.1)
> 
> (I've not tried 2.6.8.1 version)

You should have tried 2.6.8.1 !!

Did you notice the DEPRECATED NOTE in Kconfig ????

INFTL in 2.6.8.1 tells you: 
"INFTL no longer supports the old DiskOnChip drivers loaded via
docprobe.\n"
"Please use the new diskonchip driver under the NAND subsystem.\n");

Please follow this advise. The docxx stuff in mtd/devices will be
removed in the near future and INFTL with the old drivers was missing
some functionality anyway, AFAIK.

The chip ID part of your patch is giving me a bit more headache. The ID
0xA5 is a valid ID for NAND 2GiB 1,8V 8-bit.
Since NAND is available _all_ manufacturers use the same Chip ID codes
for chips with the same specifications. All Cardreaders, MP3-Players and
Digicams rely on those ID's.
I doubt that there are 32 MiB chips around with chip ID 0xA5. The Chip
ID in all Toshiba datasheets of their various 32MiB NAND chips is 0x75. 
I'm not going to put this line into the code without sensible
confirmation that this is the real ID. Please figure out the DoC
partnumber and let M-Sys confirm this. If they confirm that some moron
started to break the ID rules, then we have to figure out a way to make
this work. Putting this line without any further modifications into the
code would break other drivers.

tglx

Re: Patch !

[Nicolas Pouillon]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

[Sat, 02 Oct 2004 22:42:09 +0200]
Thomas Gleixner <tglx@linutronix.de> eut le bonheur d'écrire:

> You should have tried 2.6.8.1 !!

I have.
2.6.8.1 kernel from hh.org just crashes on my device, (MTD in or not),
and I have no time to investigate this issue, so I keep to 2.6.7 (no
interesting changes in 2.6.8.1 to me anyway)

> Did you notice the DEPRECATED NOTE in Kconfig ????
[..]
> "Please use the new diskonchip driver under the NAND subsystem.\n");

Indeed, and the other one is marked experimental ;)

> Please follow this advise. The docxx stuff in mtd/devices will be
> removed in the near future and INFTL with the old drivers was missing
> some functionality anyway, AFAIK.

Yes, sure, I will switch to new drivers ASAP, but we (project people)
have taken 2.6.7 as reference, so we'll use this patch for a few
more weeks.

I've tried to update to newer MTD kernel part, keeping the rest in 2.6.7
state, but some of the API seems to have changed.

> The chip ID part of your patch is giving me a bit more headache. The
> ID 0xA5 is a valid ID for NAND 2GiB 1,8V 8-bit.

Whoops, didn't pay attention to this :(

[...]
> Please figure out the DoC
> partnumber and let M-Sys confirm this. If they confirm that some moron
> started to break the ID rules, then we have to figure out a way to
> make this work. Putting this line without any further modifications
> into the code would break other drivers.

Is there some means to determine chip type by software ?
Things I can read on the chip (hoping i'm correct, it is not very
readable) are:
"M-Systems
Disc-on-chip
MD333-D64-V3-X
Japan 033-----" (dunno what's under "----")

-- 
Nipo <nipo@ssji.net>
Gnu-PGP: 1024D/1DBF658F
http://nipo.ssji.net/nipo.asc


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Patch !

[Nicolas Pouillon]

[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

[Sun, 03 Oct 2004 03:49:21 +0200]
Thomas Gleixner <tglx@linutronix.de> eut le bonheur d'écrire:

>  It's quite stable now. The experimental will go away soon.

;)

> I see. But you will not be able to use the chip really, as the code in
> mtd/devices and the old inftl driver are missing functionality (e.g.
> write support).

Short term I dont care about write support, as I wont have two chances
to rewrite the DoC, if I screw things up, the only thing I will be able
to do is get the device back to service (and they wont want to repair
it, I opened it...)

Unless... Is there some means to access DoC through JTAG ?
I've seens some pages saying it works, but I'm not too sure it actually
was speaking of the case I have : A PXA and a M-Sys DoC.

> The new code supports the usage of NAND aware
> filesystems like JFFS2 too. So you don't even need the INFTL stuff, if
> you must not provide compability with the M-Sys stuff.

Mh, what is "compatibility with M-Sys stuff" ?

> The MTD CVS patch (use patches/patchin.sh) should work with 2.6.7.
> Hmm, the __iomem related changes are not in 2.6.7. Thats just a simple
> #define. The code runs on 2.4 too. See compatmac.h

I'll have a look at it ;)

> > Things I can read on the chip (hoping i'm correct, it is not very
> > readable) are:
> > "M-Systems
> > Disc-on-chip
> > MD333-D64-V3-X
> > Japan 033-----" (dunno what's under "----")
> 
> MD3331-D64-V3-T 64MB/512Mb FBGA 3.3V

64MB, 3.3V, BGA, yes ;)
Picture here, to confirm (I actually forgot the 1 after "333"):
http://a620.zwischenstand.de/Photos/DoC/dscn2499.jpg
(photos I have without the sticker are bad)

> That's the only one I found on the M-Sys webpage which has a similar
> type code.

This is it. Is chip ID 0xa5 ?

Cheers !

-- 
Nipo <nipo@ssji.net>
Gnu-PGP: 1024D/1DBF658F
http://nipo.ssji.net/nipo.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Patch !

[Thomas Gleixner]

On Sun, 2004-10-03 at 22:18, Nicolas Pouillon wrote:
> Unless... Is there some means to access DoC through JTAG ?
> I've seens some pages saying it works, but I'm not too sure it actually
> was speaking of the case I have : A PXA and a M-Sys DoC.

If you can start something like a kernel or a repairtool via JTAG you
should have access.

> > The new code supports the usage of NAND aware
> > filesystems like JFFS2 too. So you don't even need the INFTL stuff, if
> > you must not provide compability with the M-Sys stuff.
> 
> Mh, what is "compatibility with M-Sys stuff" ?

The M-Sys INFTL format.

> > The MTD CVS patch (use patches/patchin.sh) should work with 2.6.7.
> > Hmm, the __iomem related changes are not in 2.6.7. Thats just a simple
> > #define. The code runs on 2.4 too. See compatmac.h
> 
> I'll have a look at it ;)

I really recommend you to use the new code, so ppl. which have such
devices around can help you.

> > > 
> > That's the only one I found on the M-Sys webpage which has a similar
> > type code.
> 
> This is it. Is chip ID 0xa5 ?

Of course not. It's 0x75 :)

Maybe that helps:

> *Interestingly* I got a5ec as the ID for my chip, but this was an 
> incorrect ID.
> the reason I got it was that on the toshiba controller I used, accessing 
> the data register bytewise read every *other* byte, returning ec and 
> garbage (which was  a5 always).
> Using a word access worked as expected and I got the correct id, 75 ec

Is the chip configured for 16-bit interface mode ? 
If yes, there are more tweaks neccecary.

tglx

Re: Patch !

[Nicolas Pouillon]

[Mon, 04 Oct 2004 10:05:11 +0200]
Thomas Gleixner <tglx@linutronix.de> eut le bonheur d'écrire:

> If you can start something like a kernel or a repairtool via JTAG you
> should have access.

Hm, sould document more on JTAG ;)

> > > #define. The code runs on 2.4 too. See compatmac.h
> > 
> > I'll have a look at it ;)

Ok, it does compile.
I still have problems like oops when accessing MTD (same than before).
error is "Unhandled fault: imprecise external abort (0xcf6) at
0x20800014", which seems a blur.
I cant understand why Xscale complains, but I saw this issue has been
addressed some times on arm-linux ML, without fix (at least not in same
threads)

> Is the chip configured for 16-bit interface mode ? 

PXA boots of it and its BOOT_SEL is configured to "Asynchronous 16bit
ROM", elsewhere, in mem controller, it is configured as "16bit fast
flash or rom, non burst read". so I assume it is.

> If yes, there are more tweaks neccecary.

I can see some NAND_BUSWIDTH_16 options, but how can this be enabled at
probe time ?

-- 
Nipo <nipo@ssji.net>
Gnu-PGP: 1024D/1DBF658F
http://nipo.ssji.net/nipo.asc

Re: Patch !

[Thomas Gleixner]

On Mon, 2004-10-04 at 18:38, Nicolas Pouillon wrote:
> > Is the chip configured for 16-bit interface mode ? 
> 
> PXA boots of it and its BOOT_SEL is configured to "Asynchronous 16bit
> ROM", elsewhere, in mem controller, it is configured as "16bit fast
> flash or rom, non burst read". so I assume it is.
> 
> > If yes, there are more tweaks neccecary.
> 
> I can see some NAND_BUSWIDTH_16 options, but how can this be enabled at
> probe time ?

The configuration register reflects the state of the IF_CFG pin.
The NAND_BUSWIDTH_16 option must be set before calling nand_scan, but
AFAICS you must also add 16bit aware read/write... functions for 
doc2001plus.

tglx

Re: Patch !

[Nicolas Pouillon]

[Mon, 04 Oct 2004 19:59:11 +0200]
Thomas Gleixner <tglx@linutronix.de> eut le bonheur d'écrire:

> The configuration register reflects the state of the IF_CFG pin.

I assume this is an hardware configuration.
Would it be possible to change 16bit access to 32bit in MTD chip while
running?

I tried to reconfigure PXA bank mode to 32 bit mode: probing no more
works, and mmio transfers dont crash any more...
So if I understood well, PXA just makes kernel crash if accessing a
16bit mapped zone with 32bits words (quite normal, in fact, but not
straightforward for me as I'm learning at the same time ;)

As I saw different bug reports/issues on MLs with this kind of thing
(PXA kernel crashing while probing mtd), shouldn't a #warning, or a
printk just before probing annoucing the issue could be added ?

Cheers !

-- 
Nipo <nipo@ssji.net>
Gnu-PGP: 1024D/1DBF658F
http://nipo.ssji.net/nipo.asc

Re: Patch !

[Thomas Gleixner]

On Mon, 2004-10-04 at 22:47, Nicolas Pouillon wrote:
> > The configuration register reflects the state of the IF_CFG pin.
> 
> I assume this is an hardware configuration.
> Would it be possible to change 16bit access to 32bit in MTD chip while
> running?

RTFM !!!!

Configuration  Register
Type: Read/Write (except bit 7, which is Read Only)
7 IF_CFG (Interface Configuration). Reflects the state of the IF_CFG
input pin.

That's a bit to read what the hardware is configured for. I doubt that
there is a possibility to reconfigure the PCB by software. :)

> I tried to reconfigure PXA bank mode to 32 bit mode: probing no more
> works, and mmio transfers dont crash any more...

That's really surprising that it works no more.

> So if I understood well, PXA just makes kernel crash if accessing a
> 16bit mapped zone with 32bits words (quite normal, in fact, but not
> straightforward for me as I'm learning at the same time ;)

This is either a configuration problem or a bug/feature of the MTD code.
Which driver / part of the MTD framework is the source of this problem ?

> As I saw different bug reports/issues on MLs with this kind of thing
> (PXA kernel crashing while probing mtd), shouldn't a #warning, or a
> printk just before probing annoucing the issue could be added ?

He ? An Oops or a BUG are warning enough, that something is going wrong.
If we put for everything what can go wrong a warning into the kernel
then the majority of the kernel source will be printk and string
constants instead of functional code.

tglx