[PATCH]Probing at 0x0

[PATCH]Probing at 0x0

[Nicolas Pouillon]

Hi again

I updated to last CVS snapshot.
After tweaking necessary declarations to interface with 2.6.7, I remade
some modifications in order to be able to probe at 0x0.
I made a patch for this (I hope that way is not too bad):
http://nipo.ssji.net/patches/mtd/nulladdress.diff

I still need to use readb and writeb, but this is not in the patch.

This time, chip is probed as a DoC-Mil+ 32MB, driver complains about it
not being supported. It seems ok, and as mtd are much like rocket
science to me, I'll wait a little until it is (i hope) supported...

I'll try to understand the mmio vs readb/writeb issue as a time
holder. ;)

Thanks again for the support.

-- 
Nipo <nipo@ssji.net>

Re: [PATCH]Probing at 0x0

[Thomas Gleixner]

On Mon, 2004-10-04 at 21:50, Nicolas Pouillon wrote:
> I updated to last CVS snapshot.
> After tweaking necessary declarations to interface with 2.6.7, I remade
> some modifications in order to be able to probe at 0x0.
> I made a patch for this (I hope that way is not too bad):
> http://nipo.ssji.net/patches/mtd/nulladdress.diff

Please add the patches to your mail. I'm not interested in collecting
outdated http references. Providing patches by http reference makes
sense for large modification which would either be rejected by the ML or
annoying the majority of readers.

> I still need to use readb and writeb, but this is not in the patch.

WTF did say you should not use readb/writeb ? 

> This time, chip is probed as a DoC-Mil+ 32MB, driver complains about it
> not being supported. It seems ok, and as mtd are much like rocket
> science to me, I'll wait a little until it is (i hope) supported...

It might be rocket science for you, but it still relies on simple
straight forward facts.

The DoC, which you pointed out, has Doc-chip-ID 0x41 according to the
datasheet.

from include/linux/mtd/doc2000.h
#define DOC_ChipID_DocMilPlus32	0x40
#define DOC_ChipID_DocMilPlus16	0x41

So how is it identified as a Mil+32 ? 
Same magic as the NAND-ID is 0x85 instead of 0x75 ? 
Same quick solution, by adding some magic code / hope ?

> I'll try to understand the mmio vs readb/writeb issue as a time
> holder. ;)

He, time holder. Did you mean placeholder ? 
It's neither nore. mmio is a technology. readb is a macro. writeb too.

mmio == Memory Mapped Input Output. That means you have no seperate IO
port instruction crap which was introduced by the worst CPU architecture
on this planet. Everything, even your Line Printer Port is accessible in
the memory space via a plain pointer without an extra IO-related
instruction like outb/inb.

see http://dri.sourceforge.net/cgi-bin/moin.cgi/MMIO 

and http://dri.sourceforge.net/cgi-bin/moin.cgi/PIO

possibly http://www.c-for-dummies.com

in any case see http://lxr.linux.no/ident?v=2.6.8.1;a=arm;i=readb
where you can find out following the refrences that readb resolves at
the end to
(*(volatile unsigned char  *)(a))

google for "volatile" yourself.


Sorry for being cynical, but I'm too old to believe in IT-witchcrafts.

tglx

Re: [PATCH]Probing at 0x0

[Kalev Lember]

Hi,

On Mon, 4 Oct 2004, Nicolas Pouillon wrote:

> This time, chip is probed as a DoC-Mil+ 32MB, driver complains about it

I believe it is detected correctly. The Diskonchip Millennium Plus 64MB is 
actually two 32 MB devices stacked up.

> not being supported. It seems ok, and as mtd are much like rocket
> science to me, I'll wait a little until it is (i hope) supported...

I reimplemented the Diskonchip Millennium Plus support in the new driver, 
but unfortunately I have only 16MB pieces at hand.

-- 
Best regards,
Kalev Lember

Re: [PATCH]Probing at 0x0

[Nicolas Pouillon]

[Tue, 5 Oct 2004 11:59:19 +0300 (EEST)]
Kalev Lember <kalev@colleduc.ee> eut le bonheur d'écrire:

Hi

> I reimplemented the Diskonchip Millennium Plus support in the new
> driver, but unfortunately I have only 16MB pieces at hand.

Does this mean it is actually supported but disabled by lack of tests ?
My chip can be a (read only until i've not dumped it) "guinea pig" ;-)

Cheers

-- 
Nipo <nipo@ssji.net>

Re: [PATCH]Probing at 0x0

[Kalev Lember]

Nicolas Pouillon wrote:

>>I reimplemented the Diskonchip Millennium Plus support in the new
>>driver, but unfortunately I have only 16MB pieces at hand.
>>    
>>
>
>Does this mean it is actually supported but disabled by lack of tests ?
>My chip can be a (read only until i've not dumped it) "guinea pig" ;-)
>  
>
No, it is not supported. According to 
http://www.tri-m.com/products/msystems/files/specs/mddoc_spec.pdf the 32 
MB Millennium Plus has 16 bit data bus while the supported 16 MB Mil+ 
has 8 bit bus.

-- 
Best regards,
Kalev Lember

Re: [PATCH]Probing at 0x0

[Thomas Gleixner]

On Fri, 2004-10-08 at 20:28, Kalev Lember wrote:
> No, it is not supported. According to 
> http://www.tri-m.com/products/msystems/files/specs/mddoc_spec.pdf the 32 
> MB Millennium Plus has 16 bit data bus while the supported 16 MB Mil+ 
> has 8 bit bus.

Hmm, I think you talk about different things.

>> This time, chip is probed as a DoC-Mil+ 32MB, driver complains about 
>> it not being supported. It seems ok, and as mtd are much like rocket
>> science to me, I'll wait a little until it is (i hope) supported...

The DoC has Doc-chip-ID 0x41 according to the datasheet.
http://www.m-systems.com/files/documentation/doc/Mobile_Plus_32_64MB_DS_Rev1.7.pdf

from include/linux/mtd/doc2000.h
#define DOC_ChipID_DocMilPlus32 0x40
#define DOC_ChipID_DocMilPlus16 0x41

So how is it identified as a Mil+32 ? 

The chip can be accessed in 16 bit mode, but it does not need the two
parallel chip magic which are neccecary for the Mil+32.

Please correct me, if I'm wrong or talking about something different :)

tglx

Re: [PATCH]Probing at 0x0

[David Woodhouse]

On Fri, 2004-10-08 at 21:28 +0300, Kalev Lember wrote:
> No, it is not supported. According to 
> http://www.tri-m.com/products/msystems/files/specs/mddoc_spec.pdf the 32 
> MB Millennium Plus has 16 bit data bus while the supported 16 MB Mil+ 
> has 8 bit bus.

I think you can use it in 8-bit mode too though. The old doc2001plus
driver handled them both, didn't it?

-- 
dwmw2

Re: [PATCH]Probing at 0x0

[Kalev Lember]

On Fri, 8 Oct 2004, Thomas Gleixner wrote:

> On Fri, 2004-10-08 at 20:28, Kalev Lember wrote:
> > No, it is not supported. According to 
> > http://www.tri-m.com/products/msystems/files/specs/mddoc_spec.pdf the 32 
> > MB Millennium Plus has 16 bit data bus while the supported 16 MB Mil+ 
> > has 8 bit bus.
> 
> Hmm, I think you talk about different things.
> 
> >> This time, chip is probed as a DoC-Mil+ 32MB, driver complains about 
> >> it not being supported. It seems ok, and as mtd are much like rocket
> >> science to me, I'll wait a little until it is (i hope) supported...
> 
> The DoC has Doc-chip-ID 0x41 according to the datasheet.
> http://www.m-systems.com/files/documentation/doc/Mobile_Plus_32_64MB_DS_Rev1.7.pdf

Why do you think it has 0x41?

Quoting this message: 
http://lists.infradead.org/pipermail/linux-mtd/2004-October/010544.html :
> 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

So I understand this is a 64 MB chip.

Quoting message 
http://lists.infradead.org/pipermail/linux-mtd/2004-October/010552.html :
> 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

I think we have a typo here, the right marking should be MD3331-D64-V3-X. 
This is a Diskonchip Millennium Plus 64 MB according to 
http://www.m-systems.com/files/prodUpd_EOL/doc/PU0103_DOC_Plus_Packaging.pdf 
.


> from include/linux/mtd/doc2000.h
> #define DOC_ChipID_DocMilPlus32 0x40
> #define DOC_ChipID_DocMilPlus16 0x41
> 
> So how is it identified as a Mil+32 ? 

http://lists.infradead.org/pipermail/linux-mtd/2004-October/010584.html :

> This time, chip is probed as a DoC-Mil+ 32MB, driver complains about it
> not being supported. It seems ok, and as mtd are much like rocket

This proves that our chip id is 0x40, because in the diskonchip.c:
> case DOC_ChipID_DocMilPlus32:
> 	printk(KERN_ERR "DiskOnChip Millennium Plus 32MB is not supported, ignoring.\n");

this message is output if the diskonchip's id is DOC_ChipID_DocMilPlus32 
(0x40).


> The chip can be accessed in 16 bit mode, but it does not need the two
> parallel chip magic which are neccecary for the Mil+32.
> 
> Please correct me, if I'm wrong or talking about something different :)

I think you have a misunderstanding about the chip we have here. This is a 
64 MB device that must be accessed it 16 bit mode.

-- 
Best regards,
Kalev Lember

Re: [PATCH]Probing at 0x0

[Kalev Lember]

On Fri, 8 Oct 2004, David Woodhouse wrote:

> On Fri, 2004-10-08 at 21:28 +0300, Kalev Lember wrote:
> > No, it is not supported. According to 
> > http://www.tri-m.com/products/msystems/files/specs/mddoc_spec.pdf the 32 
> > MB Millennium Plus has 16 bit data bus while the supported 16 MB Mil+ 
> > has 8 bit bus.
> 
> I think you can use it in 8-bit mode too though. The old doc2001plus
> driver handled them both, didn't it?

I think you are right. It did handle both of them in 8-bit mode.
I believe that if we are going to use 32 MB devices in 8-bit mode, we must 
deal with the interleaving crap, right?

-- 
Kalev Lember

Re: [PATCH]Probing at 0x0

[David Woodhouse]

On Mon, 2004-10-11 at 15:23 +0300, Kalev Lember wrote:
> On Fri, 8 Oct 2004, David Woodhouse wrote:
> 
> > On Fri, 2004-10-08 at 21:28 +0300, Kalev Lember wrote:
> > > No, it is not supported. According to 
> > > http://www.tri-m.com/products/msystems/files/specs/mddoc_spec.pdf the 32 
> > > MB Millennium Plus has 16 bit data bus while the supported 16 MB Mil+ 
> > > has 8 bit bus.
> > 
> > I think you can use it in 8-bit mode too though. The old doc2001plus
> > driver handled them both, didn't it?
> 
> I think you are right. It did handle both of them in 8-bit mode.
> I believe that if we are going to use 32 MB devices in 8-bit mode, we must 
> deal with the interleaving crap, right?

I think so, yes.

-- 
dwmw2

Re: [PATCH]Probing at 0x0

[Nicolas Pouillon]

[Mon, 11 Oct 2004 12:00:02 +0300 (EEST)]
Kalev Lember <kalev@colleduc.ee> eut le bonheur d'écrire:

> This is a 64 MB device that must be accessed it 16 bit mode.

Indeed, and as I have no control over the hardware configuration, I wont
be able to use it as 8bit.

Forcing some detection code, it finally ends up with something like
"Media Header not found". I did not understand the calling chain which
ended in the corresponding function, and didn't understand what is
"media header"... no ref in datasheets (at least in those I have)

-- 
Nipo <nipo@ssji.net>

Re: [PATCH]Probing at 0x0

[Thomas Gleixner]

On Mon, 2004-10-11 at 14:25, David Woodhouse wrote:
> > I think you are right. It did handle both of them in 8-bit mode.
> > I believe that if we are going to use 32 MB devices in 8-bit mode, we must 
> > deal with the interleaving crap, right?
> 
> I think so, yes.

You mean 16-bit mode ? Then you need the interleave hack.

http://www.m-systems.com/files/documentation/doc/Mobile_Plus_32_64MB_DS_Rev1.7.pdf

A 13-bit wide address bus enables access to the DiskOnChip 8KB memory
window (as shown in Section 6.2). In 32/64MB capacities, the 16-bit data
bus permits full 16-bit wide access to the flash, due to an internal,
dual-bank, interleaved architecture. With both internal and external
16-bit access, DiskOnChip Millennium Plus 32/64MB provides unrivaled
performance. In 16MB capacities, an 8-bit data bus permits 8-bit wide
internal access to the flash but 16-bit external access to the host.

That means, that the 2 chips are accessed in parallel. So each word you
write is split into two bytes. The even goes into chip 0 and the odd
into chip 1.

This increases pagesize to 1024 byte and the bad block table must be
aware of that too.

The only thing I can not figure out, is whether you must duplicate the
commands, address bytes. 
I assume yes. So we need a seperate command function which does 
writeb16 (command | (command << 8)); 
and shifts the address 1 time right and writes the address bytes the
same way as the command.

The remaining stuff should work unchanged including ecc, but we need a
seperate oobinfo though.

tglx