Horrible Bug? AMD29LV400BB with mtd in 2.6.10rc2

Horrible Bug? AMD29LV400BB with mtd in 2.6.10rc2

[K.F.J. Martens]

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/

Re: Horrible Bug? AMD29LV400BB with mtd in 2.6.10rc2

[Ben Dooks]

On Thu, Dec 02, 2004 at 11:56:07PM +0100, K.F.J. Martens wrote:
> 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 */
> 

There has been some fixing in the jedec and similar probe code
to fix the use of the fields of device width / overlap due to
incorrect addressing being used for the chip commands. 

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

Re: Horrible Bug? AMD29LV400BB with mtd in 2.6.10rc2

[K.F.J. Martens]

Hi Ben,

You are everywhere :)

On Fri, Dec 03, 2004 at 12:46:01AM +0000, Ben Dooks wrote:
> On Thu, Dec 02, 2004 at 11:56:07PM +0100, K.F.J. Martens wrote:
> > If I reverse them like so:
> > 
> > 
> >                         [0] = MTD_UADDR_0x0555_0x02AA,  /* x8 */
> >                         [1] = MTD_UADDR_0x0AAA_0x0555,  /* x16 */
> > 
> 
> There has been some fixing in the jedec and similar probe code
> to fix the use of the fields of device width / overlap due to
> incorrect addressing being used for the chip commands. 

Meaning that a patch is indeed being submitted right now? It can be
confusing though, how the terms x8 and x16 are used in the datasheets et
al. 

Kind regards,

Koen


-- 
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/