Horrible Bug? AMD29LV400BB with mtd in 2.6.10rc2

["K.F.J. Martens" <gmc@metro.cx>]

Hi All,

I'm currently developing a flash file system for the TomTom GO, a car
navigation system that employs an ARM processor.

In it is an EON29LV400BB flash chip, which is entirely compatible with
AMD's AM29LV400BB.

Now, what I did was copy the AM29LV400BB definition in
mtd/chips/jedec_probe.c to a new definition in the struct amd_flash_info
array jedec_table like so:


        },{
                .mfr_id         = MANUFACTURER_EON, 
                .dev_id         = EON29LV400BB,
                .name           = "EON AM29LV400BB",
                .uaddr          = {
                        [0] = MTD_UADDR_0x0AAA_0x0555,  /* x8 */
                        [1] = MTD_UADDR_0x0555_0x02AA,  /* x16 */
                },
                .DevSize        = SIZE_512KiB,
                .CmdSet         = P_ID_AMD_STD,
                .NumEraseRegions= 4,
                .regions        = {
                        ERASEINFO(0x04000,1),
                        ERASEINFO(0x02000,2),
                        ERASEINFO(0x08000,1),
                        ERASEINFO(0x10000,7),
                }
        }, {



Now, here comes. This does not work, and the reason is that the x8 and
x16 addresses are swapped. It's a bit late now to hook up one of those
devices and paste the exact error message, but it was something along
the line of 'MTD jedec_match(): 0x0555 0x0aaa did not match'

If I reverse them like so:


                        [0] = MTD_UADDR_0x0555_0x02AA,  /* x8 */
                        [1] = MTD_UADDR_0x0AAA_0x0555,  /* x16 */



It works fine. So, am I crazy, or is there something wrong indeed with
the 2.6 code. A quick check against 2.4 (where I had the chip working
first) revealed that indeed the 2.4 code has the addresses the right
way. So unless someone can show me that i am indeed crazy, I suggest i
will come up with a patch one of these days that fixes these definitions
(and at the same time perhaps adds all the EON chips i know about).

If this is indeed wrong, I guess it is wrong for all the amd chips too,
as well as the compatible chips from fujitsu.

Am I the first to run this code?? Can't imagine this... 

Kind regards,

Koen Martens


-- 
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, 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/