[Qemu-devel] Re: Commit 9c9bb6c89d4 breaks code execution from flash

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]