From: Nicolas Pouillon <nipo@ssji.net>
To: linux-mtd@lists.infradead.org
Subject: Issues with a Doc Milplus
Date: Fri, 1 Oct 2004 15:46:17 +0200 [thread overview]
Message-ID: <20041001154617.163cc484.nipo@ssji.net> (raw)
[-- 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 --]
next reply other threads:[~2004-10-01 13:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-01 13:46 Nicolas Pouillon [this message]
2004-10-01 13:57 ` Issues with a Doc Milplus David Woodhouse
2004-10-01 14:27 ` Nicolas Pouillon
2004-10-02 13:55 ` Patch ! Nicolas Pouillon
2004-10-02 20:42 ` Thomas Gleixner
2004-10-03 1:11 ` Nicolas Pouillon
[not found] ` <20041003030653.2e0452a7.nipo@ssji.net>
[not found] ` <1096768161.21297.129.camel@thomas>
2004-10-03 20:18 ` Nicolas Pouillon
2004-10-04 8:05 ` Thomas Gleixner
2004-10-04 16:38 ` Nicolas Pouillon
2004-10-04 17:59 ` Thomas Gleixner
2004-10-04 20:47 ` Nicolas Pouillon
2004-10-04 21:04 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041001154617.163cc484.nipo@ssji.net \
--to=nipo@ssji.net \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox