public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Shane Nay <shane@agendacomputing.com>
To: Shane Nay <shane@agendacomputing.com>
Cc: mtd@infradead.org
Subject: Re: Problems with cfi_cmdset_0001 && XIP kernel w/MTD working
Date: Sat, 2 Dec 2000 07:29:29 +0000	[thread overview]
Message-ID: <20001202072929.D4457@www.easysolutions.net> (raw)
In-Reply-To: <20001202050132.B4457@www.easysolutions.net>; from shane@agendacomputing.com on Sat, Dec 02, 2000 at 05:01:32 +0000

Problem solved, and MTD write, read, and erase is now functioning with an
XIP kernel.  Now come my questions..., I realized that it was trying to
fill the write buffer, but wasn't signaling the right size to the flash
chip now.  I traced where it was doing that, and have come to a conclusion
about a particular line of code.  But it might be a special case, and if so
we'll need some logic to deal with it, but I think it might just be a
mistake.  Okay, here it is:

In cfi_cmdset_001.c, in the do_write_buffer code, when it is sending the
size to the cmd_adr after putting the flash chip in write mode.  The
calculation for size there seems to be wrong for interleaved chips.  The
old code reads:
cfi_write(map,CMD((len/(cfi->device_type + CFIDEV_INTERLEAVE))-1),cmd_adr);

However, in my case, when it used this calculation, it undershot the number
of "words" it was going to write.  I think this is really confusing,
because the flash chip I'm working with percieves the number you send there
as "The number of times you will fill the bus".  But in the PDF it says
that that is the number of "words" that you will send it.  I suppose their
definition of word in this case is the present used buswidth of the chip. 
In any event, the correct code in my situation is:
cfi_write(map,CMD((len/(cfi->device_type)-1),cmd_adr);

The interleave should not factor into the division of the number of "words"
you are going to send.  I don't know if this is "generally true", but I
imagine it to be.  Anyone else out there with interleaved intel flashchips?

Thanks,
Shane.

(Ugh, replied to my own thread, bad juju)




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

  reply	other threads:[~2000-12-02 14:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-02  5:01 Problems with cfi_cmdset_0001 Shane Nay
2000-12-02  7:29 ` Shane Nay [this message]
2000-12-02 15:23 ` Nicolas Pitre
2000-12-02  8:54   ` Shane Nay
2000-12-03  3:42     ` including doc2001 and docprobe into the kernel Adam Agnew
2000-12-03  5:52       ` Levi Khatskevitch
2000-12-03 16:32         ` David Woodhouse
2000-12-03 17:19           ` Levi Khatskevitch
2000-12-03 18:13             ` 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=20001202072929.D4457@www.easysolutions.net \
    --to=shane@agendacomputing.com \
    --cc=mtd@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