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. But this still leaves us with the 8-bit entries of the cfi_table. Jan
signature.asc
Description: OpenPGP digital signature
