From: roger <rogerxxmaillist@san.rr.com>
To: linux-mtd@lists.infradead.org
Subject: Re: Problems with using doc2001 module - 000F0000
Date: 12 Jun 2003 12:50:48 -0700 [thread overview]
Message-ID: <1055447448.3079.8.camel@localhost3.localdomain> (raw)
In-Reply-To: <1055397377.16455.129.camel@imladris.demon.co.uk>
On Wed, 2003-06-11 at 22:56, David Woodhouse wrote:
> On Thu, 2003-06-12 at 00:53, roger wrote:
> > The DiskOnChip (DoC) Shows the following (data doesn't start again until
> > approximately 000F57F0)
> > 000F57F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA 10
> > EB 3C 00 00 28 ................U...<..(
> > 000F5808 43 29 4D 2D 53 79 73 74 65 6D 73 31 39 39 38 00 00 00 21
> > 00 00 04 00 1C C)M-Systems1998...!.....
>
> This is a hexdump from physical memory?
>
> Odd. That 0x55 0xAA ought to be at 0xF0000. Is it possible that your
> address lines to the chip are in the wrong order?
>
> What happens if you now unload the l440gx module and load the DiskOnChip
> driver, with the probe address 0xf5800?
nothing. doc2001 module w/ docprobe still doesn't find it at 0xf5800.
So, in order to get doc2001 to recognize that there is a DoC @
0xfff00000, i still need to induce the kernel panic. and on a second
440BX/VX/ZX (?) the l440gx.o module won't even load.
>
> > It certainly looks like i'm looking at the actual chips through the
> > L440GX memory map and the modules load fine without having to induce the
> > kernel panic. However, the offset of the start & ending of the hardware
> > chip appears incorrect. I'm guessing I only have to modify the l440gx.c
> > code to reflect the proper parameters? On the cosemetic side of things,
> > the module labels the DoC as a "L440GX BIOS" instead of a "DOC
> > MIL"....another small oddity.
>
> It thinks it's ROM, and that's why it's labelled as BIOS. You're only
> loading the l440gx module to make it do the PCI config magic to enable
> writes to that physical address range.
>
> Unless you load the DiskOnChip driver, you won't drive a DiskOnChip
> properly ;)
yup. exactly. I was able to see the DOC and Original bios flash rom chip
at 0xfff00000 using the l440gx module but with diff (incorrect) memory
start/stop offsets.
So, I need to modify the doc2001.c code to reflect a similar chip
recognization that l440gx.c does. Otherwise, the doc2001.c will not
even see the mtd chip(s). looks very close to getting this working.
--
Roger
http://www.eskimo.com/~roger/index.html
next prev parent reply other threads:[~2003-06-12 20:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-09 0:23 Problems with using doc2001 module roger
2003-06-09 9:02 ` David Woodhouse
2003-06-11 9:01 ` roger
2003-06-11 9:14 ` David Woodhouse
2003-06-11 23:53 ` Problems with using doc2001 module - 000F0000 roger
2003-06-12 5:56 ` David Woodhouse
2003-06-12 19:50 ` roger [this message]
2003-06-11 10:01 ` Problems with using doc2001 module roger
2003-06-11 10:09 ` David Woodhouse
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=1055447448.3079.8.camel@localhost3.localdomain \
--to=rogerxxmaillist@san.rr.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