From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] MTD/SPI/FLASH: add support for Ramtron FRAMs using SPI
Date: Thu, 26 Aug 2010 22:00:50 +0200 [thread overview]
Message-ID: <4C76C7F2.3020005@emk-elektronik.de> (raw)
In-Reply-To: <201008260511.17530.vapier@gentoo.org>
Dear Mike,
I have been looking at the possible solutions quite some time now,
the issue is rather complex:
1. according to Ramtron, 0x7f is a continuation byte defined in a
JEDEC standard (I could not find a spec for that), and shall be
ignored until a non-0x7f shows. That shall be Manufacturer Id (0xc2
for Ramtron), followed by the 2 device id bytes. Following that
method, the spi_flash.c should do that and use the first non-0x7f
value for the switch statement. The switch would then have a
case 0xc2 to call the ramtron-specific code.
about like (rough sketch):
for (index=0; index < IDLENGTH-3 && idcode[index] == 0x7f; index++)
;
/*
* here we are on the first non-0x7f byte or still on one,
* the switch will sort that out...
*/
switch (idcode[index]) {
case 0xc2: flash = spi_fram_probe_ramtron(spi, idcode+index);
/* the function will only access its parameter idcode with index 1 and 2 */
etc...
default: /* covers the 0x7f case as well */
2. the switch case 0xff would occur twice, if someone had defined
STMICRO and RAMTRON. I would postulate here that it is not allowed
to define both and issue an #error.
3. If someone decided to put the env into FRAM, the env-var describing
the nonstandard type would not be there (yet). So this should have
another solution. Since because of 2. another non-standard SPI device
should not be expected - I would, after accessing the status register to
verify something FRAM-like is there, use a CONFIG_FRAM_DEVICE to
define the chip to be assumed. That would work for us, since there
is only one non-standard FRAM in the list anyway.
Your thoughts?
Best Regards
Reinhard
next prev parent reply other threads:[~2010-08-26 20:00 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 [this message]
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
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=4C76C7F2.3020005@emk-elektronik.de \
--to=u-boot@emk-elektronik.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.