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

[Jan Kiszka]

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