[U-Boot] [PATCH] MTD/SPI/FLASH: add support for Ramtron FRAMs using SPI

Reinhard Meyer u-boot at emk-elektronik.de
Thu Aug 26 22:00:50 CEST 2010


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


More information about the U-Boot mailing list