JEDEC / CFI questions & remarks
Hi All,
We had some troubles with the MTD driver lately, when our taiwanese hardware factory decided to use another flash chip in our devices. We had a EN29LV400BB, now it has become the EN29LV400A. It should be functionally compatible, but with the new chip we suddenly detect an extra CFI device.
Now, I want to do some more debugging on this, but the new hardware is in Taiwan and being shipped to us atm, perhaps this sounds familiar to some.
Second point: the EON clones of the original AMD chipsets have small incompatibility in the method for reading out the manufacturer id. First of all, a small fragment of jedec_probe.c:
static inline u32 jedec_read_mfr(struct map_info *map, __u32 base,
struct cfi_private *cfi)
{
map_word result;
unsigned long mask;
u32 ofs = cfi_build_cmd_addr(0, cfi_interleave(cfi),
cfi->device_type);
mask = (1 << (cfi->device_type * 8)) -1;
result = map_read(map, base + ofs);
return result.x[0] & mask;
}Basically, it reads some info from offset 0 relative to the start of the flash memory. This is fine for AMD chips, which specify x00 as the (hex) address to read out the manufacturer ID. The EON chips we use, however, specify 100 (hex) as the offset of the manufacturer id. So what we did here is change that first argument to cfi_build_cmd_addr from 0 to 0x100 , which should thus work on both AMD and EON chips. But who knows what this breaks on other chip types.... So, I wonder if this should be submitted as a patch (along with the EON chip definitions),
More general questions that come up when spending more than casual time in the mtd driver source, is how well mantained is the jedec bit of the mtd driver? Is anyone using this?? I do get the impression we are alone in using this bit of the MTD driver, but i can't really believe that..
We now have several quick hacks to make it all work for our specific case (eg. return 0; as body for cfi_probe, forcing the chip type in jedec_probe effectivelly skipping detection), but i am one of those idealist types that wants to fix it the right way and submit back to the community, but a bit unsure about what course to follow.
Koen
Quoted 17 lines · Koen Martens
Second point: the EON clones of the original AMD chipsets have small incompatibility in the method for reading out the manufacturer id. First of all, a small fragment of
jedec_probe.c:static inline u32 jedec_read_mfr(struct
map_info*map,__u32base,
structcfi_private*cfi){ map_word result; unsigned long mask; u32 ofs = cfi_build_cmd_addr(0, cfi_interleave(cfi), cfi->device_type); mask = (1 << (cfi->device_type * 8)) -1; result = map_read(map, base + ofs); return result.x[0] & mask; }
Quoted 8 lines
Basically, it reads some info from offset 0 relative to the start of the flash memory. This is fine for AMD chips, which specify x00 as the (hex) address to read out the manufacturer ID. The EON chips we use, however, specify 100 (hex) as the offset of the manufacturer id. So what we did here is change that first argument to
cfi_build_cmd_addrfrom 0 to0x100, which should thus work on both AMD and EON chips. But who knows what this breaks on other chip types.... So, I wonder if this should be submitted as a patch (along with the EON chip definitions),
Actually, wouldn't it be better to put this address in the struct that defines the chip, just as the unlock addresses are..??
koen
Signature · 5 lines
K.F.J. Martens, Sonologic, http://www.sonologic.nl/ Networking, hosting, embedded systems, unix, artificial intelligence. Public PGP key: http://www.metro.cx/pubkey-gmc.asc Wondering about the funny attachment your mail program can't read? Visit http://www.openpgp.org/