From: Greg Ungerer <gerg@snapgear.com>
To: angainor@evo.evopolska.com
Cc: linux-mtd@lists.infradead.org
Cc: David Woodhouse <dwmw2@infradead.org>
Subject: Re: MTD drivers for DoC Millenium Plus
Date: Fri, 20 Jun 2003 15:48:27 +1000 [thread overview]
Message-ID: <3EF2A02B.1000002@snapgear.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0306120922280.29227-100000@evo.evopolska.com>
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
prev parent reply other threads:[~2003-06-20 5:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-04 10:56 MTD drivers for DoC Millenium Plus angainor
2003-06-11 9:53 ` David Woodhouse
2003-06-11 11:18 ` angainor
2003-06-11 13:13 ` angainor
2003-06-11 13:28 ` David Woodhouse
2003-06-12 1:22 ` Greg Ungerer
2003-06-12 10:10 ` angainor
2003-06-12 14:42 ` Greg Ungerer
2003-06-20 5:48 ` Greg Ungerer [this message]
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=3EF2A02B.1000002@snapgear.com \
--to=gerg@snapgear.com \
--cc=angainor@evo.evopolska.com \
--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