From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] MTD/SPI/FLASH: add support for Ramtron FRAMs using SPI
Date: Sat, 28 Aug 2010 20:14:50 -0400 [thread overview]
Message-ID: <201008282014.51577.vapier@gentoo.org> (raw)
In-Reply-To: <4C799FB5.9050506@emk-elektronik.de>
On Saturday, August 28, 2010 19:45:57 Reinhard Meyer wrote:
> On 29.08.2010 01:17, Mike Frysinger wrote:
> > On Saturday, August 28, 2010 17:48:39 Mike Frysinger wrote:
> >> + /* Make sure the ID was jedec extended */
> >> + j = flashes[i].shift - 1;
> >> + while (j>= 0&& idcode[j] == 0x7f)
> >> + continue;
> >
> > thinko ... this loops forever. the tested fix:
> > j = flashes[i].shift;
> > while (--j>= 0)
> >
> > if (idcode[j] != 0x7f)
> >
> > break;
> >
> > this whole change increases code size a bit (20 - 60 bytes on Blackfin
> > depending on how many flashes are supported), but it makes management
> > easier and allows for arbitrarily long manufacturers ids. so i think
> > it's worth it.
>
> arbitrarily long ids unfortunately require an arbitrarily long id_buffer :)
well right, but now the problem has been reduced to simply changing the len of
the idcode buffer
> In that case I think its easier to right after READ_ID count the 0x7f's
> and search the table with count and the id:
hmm, that's true. no point in rescanning the idcode multiple times.
> (n is either a compile time constant or determined by examining the table
> for largest 'shift'+3)
i'd prefer to stick to compile constant for now so we dont have to force the
hardware to keep recomputing a number that gcc isnt capable of optimizing into
a constant for us.
> read-id (n bytes)
> shift=count 7f's (max n-3)
> id=id_buffer[shift]
> search table for shift and id, call function.
> if function returns NULL, continue search in table.
>
> That will allow several shift=0, id=0xff entries in the table, which should
> be ordered such that least likely to false detect probes come first:
> stmicro first since that probe actually has a way to really figure out
> the device, the FM25H20-ramtron has no other way except for a ram size
> test which certainly is not a good idea to do here...
hmm, pushing the non-jedec probes into the const table is attractive indeed
> It is disputable whether the function gets id_buffer or id_buffer+shift
> as parameter. I'd prefer the latter.
since we already need to calculate the value of id_buffer+shift to check the
one byte, i think passing that down is OK for now. i would just make a note
in the code about this behavior.
> I am willing to code and test and submit a patch for that method.
if you want to take the patch i posted and extend that by itself with the
comments here, and then do the ramtron patch separately on top of that, that'd
be great.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100828/14fdc655/attachment.pgp
next prev parent reply other threads:[~2010-08-29 0:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-25 12:47 [U-Boot] [PATCH] MTD/SPI/FLASH: add support for Ramtron FRAMs using SPI Reinhard Meyer
2010-08-26 2:31 ` Mike Frysinger
2010-08-26 5:57 ` Reinhard Meyer
2010-08-26 6:12 ` Mike Frysinger
2010-08-26 6:24 ` Reinhard Meyer
2010-08-26 8:27 ` Reinhard Meyer
2010-08-26 9:11 ` Mike Frysinger
2010-08-26 20:00 ` Reinhard Meyer
2010-08-28 21:48 ` Mike Frysinger
2010-08-28 22:15 ` Reinhard Meyer
2010-08-28 22:26 ` Mike Frysinger
2010-08-28 23:17 ` Mike Frysinger
2010-08-28 23:45 ` Reinhard Meyer
2010-08-29 0:14 ` Mike Frysinger [this message]
2010-08-29 1:59 ` Reinhard Meyer
2010-08-29 2:26 ` Mike Frysinger
2010-08-29 3:35 ` Reinhard Meyer
2010-08-29 4:34 ` Mike Frysinger
2010-08-29 4:52 ` Reinhard Meyer
2010-09-07 20:12 ` Peter Tyser
2010-09-07 19:38 ` Wolfgang Denk
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=201008282014.51577.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=u-boot@lists.denx.de \
/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;
as well as URLs for NNTP newsgroup(s).