* [PATCH]Probing at 0x0 @ 2004-10-04 19:50 Nicolas Pouillon 2004-10-04 21:53 ` Thomas Gleixner 2004-10-05 8:59 ` Kalev Lember 0 siblings, 2 replies; 12+ messages in thread From: Nicolas Pouillon @ 2004-10-04 19:50 UTC (permalink / raw) To: linux-mtd 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-04 19:50 [PATCH]Probing at 0x0 Nicolas Pouillon @ 2004-10-04 21:53 ` Thomas Gleixner 2004-10-05 8:59 ` Kalev Lember 1 sibling, 0 replies; 12+ messages in thread From: Thomas Gleixner @ 2004-10-04 21:53 UTC (permalink / raw) To: Nicolas Pouillon; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-04 19:50 [PATCH]Probing at 0x0 Nicolas Pouillon 2004-10-04 21:53 ` Thomas Gleixner @ 2004-10-05 8:59 ` Kalev Lember 2004-10-06 19:34 ` Nicolas Pouillon 1 sibling, 1 reply; 12+ messages in thread From: Kalev Lember @ 2004-10-05 8:59 UTC (permalink / raw) To: Nicolas Pouillon; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-05 8:59 ` Kalev Lember @ 2004-10-06 19:34 ` Nicolas Pouillon 2004-10-08 18:28 ` Kalev Lember 0 siblings, 1 reply; 12+ messages in thread From: Nicolas Pouillon @ 2004-10-06 19:34 UTC (permalink / raw) To: linux-mtd [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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-06 19:34 ` Nicolas Pouillon @ 2004-10-08 18:28 ` Kalev Lember 2004-10-08 19:05 ` Thomas Gleixner 2004-10-08 19:15 ` David Woodhouse 0 siblings, 2 replies; 12+ messages in thread From: Kalev Lember @ 2004-10-08 18:28 UTC (permalink / raw) To: Nicolas Pouillon; +Cc: linux-mtd 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-08 18:28 ` Kalev Lember @ 2004-10-08 19:05 ` Thomas Gleixner 2004-10-11 9:00 ` Kalev Lember 2004-10-08 19:15 ` David Woodhouse 1 sibling, 1 reply; 12+ messages in thread From: Thomas Gleixner @ 2004-10-08 19:05 UTC (permalink / raw) To: Kalev Lember; +Cc: Nicolas Pouillon, linux-mtd 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-08 19:05 ` Thomas Gleixner @ 2004-10-11 9:00 ` Kalev Lember 2004-10-11 12:41 ` Nicolas Pouillon 0 siblings, 1 reply; 12+ messages in thread From: Kalev Lember @ 2004-10-11 9:00 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Nicolas Pouillon, linux-mtd 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-11 9:00 ` Kalev Lember @ 2004-10-11 12:41 ` Nicolas Pouillon 0 siblings, 0 replies; 12+ messages in thread From: Nicolas Pouillon @ 2004-10-11 12:41 UTC (permalink / raw) To: Kalev Lember; +Cc: linux-mtd [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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-08 18:28 ` Kalev Lember 2004-10-08 19:05 ` Thomas Gleixner @ 2004-10-08 19:15 ` David Woodhouse 2004-10-11 12:23 ` Kalev Lember 1 sibling, 1 reply; 12+ messages in thread From: David Woodhouse @ 2004-10-08 19:15 UTC (permalink / raw) To: Kalev Lember; +Cc: Nicolas Pouillon, linux-mtd 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-08 19:15 ` David Woodhouse @ 2004-10-11 12:23 ` Kalev Lember 2004-10-11 12:25 ` David Woodhouse 0 siblings, 1 reply; 12+ messages in thread From: Kalev Lember @ 2004-10-11 12:23 UTC (permalink / raw) To: David Woodhouse; +Cc: Nicolas Pouillon, linux-mtd 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-11 12:23 ` Kalev Lember @ 2004-10-11 12:25 ` David Woodhouse 2004-10-11 13:12 ` Thomas Gleixner 0 siblings, 1 reply; 12+ messages in thread From: David Woodhouse @ 2004-10-11 12:25 UTC (permalink / raw) To: Kalev Lember; +Cc: Nicolas Pouillon, linux-mtd 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH]Probing at 0x0 2004-10-11 12:25 ` David Woodhouse @ 2004-10-11 13:12 ` Thomas Gleixner 0 siblings, 0 replies; 12+ messages in thread From: Thomas Gleixner @ 2004-10-11 13:12 UTC (permalink / raw) To: David Woodhouse; +Cc: linux-mtd, Nicolas Pouillon 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-10-11 13:20 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-10-04 19:50 [PATCH]Probing at 0x0 Nicolas Pouillon 2004-10-04 21:53 ` Thomas Gleixner 2004-10-05 8:59 ` Kalev Lember 2004-10-06 19:34 ` Nicolas Pouillon 2004-10-08 18:28 ` Kalev Lember 2004-10-08 19:05 ` Thomas Gleixner 2004-10-11 9:00 ` Kalev Lember 2004-10-11 12:41 ` Nicolas Pouillon 2004-10-08 19:15 ` David Woodhouse 2004-10-11 12:23 ` Kalev Lember 2004-10-11 12:25 ` David Woodhouse 2004-10-11 13:12 ` Thomas Gleixner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.