Jan Kiszka wrote: > Jan Kiszka wrote: >> Michael Walle wrote: >>> Am Thursday 13 May 2010 09:38:43 schrieb Jan Kiszka: >>>>> But i noticed another minor bug. The cfi02 doesn't handle 'read flash id' >>>>> on 16bit accesses correctly. It always returns 8 bit. I used something >>>>> like >>>>> >>>>> if (width == 2) >>>>> ret = pfl->ident[0] << 8 | pfl->ident[1]; /* rsp. ident[1]/ident[2] >>>>> */ >>>>> >>>>> within the 0x90 reading as a quick workaround. >>>> Are you sure that this is valid? The whole cfi_table is also only >>>> provided byte-wise, same in cfi01. >>> At least the JEDEC ID read returns 16 bit values with x16 devices. Have a >>> look >>> at: >>> http://www.spansion.com/Support/Datasheets/s29gl128_256n_sp_a2_e.pdf >>> Table II on page 51 >>> >>> micromonitor (the program i tested with) and uboot uses 16bit reads to read >>> the flash id. Have a look at >>> http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=drivers/mtd/cfi_flash.c;h=3267c5de36d1b12a190f93f9a3048ded598f84aa;hb=HEAD#l1535 >>> >> Right, I came to the same conclusion based on chip I'm using for the >> Musicpal model. Working on a proper fix - now that I think to have found >> a solution for the XIP vs. mode switch conflict. > > Wait! Access to ident[0..3] is already correct as those fields are > stored and returned as 16-bit values. I guess you just did not pass the > proper IDs when registering your pflash_cfi02 instance.
... or you suffered from a be/le issue. In contrast to data, the ID is not swapped according to the byte order that was specified during init. Does your target byte order differ from your host? > > But this still leaves us with the 8-bit entries of the cfi_table. > The CFI table is only returned byte-wise, even in 16- or 32-bit mode. But I guess it should be properly swapped to the right byte order nevertheless. Jan
signature.asc
Description: OpenPGP digital signature
