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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
