[U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.

Zhang Wei
2006-12-22T11:02:53Z

Hi, Wolfgang,

This cfi-flash issue was found in u-boot 1.1.6 top git tree. On our
board (MPC8641HPCn), sometimes the u-boot will get the wrong
'num_erase_regions' (0xff) when it boots up. It causes the u-boot can
not find and access the flash. If I remove the patch -- '[PATCH] CFI
driver AMD Command Set Top boot geometry reversal, etc.' from Stefan
Roese <sr@denx.de> in Nov. 13, 2006. All of the flash in u-boot are OK.

That patch adds support for reading JEDEC Manufacturer ID and Device ID
causes. -- function flash_read_jedec_ids(). In our board, we have
'Spinsion S29GL064M90TFIR6' flash with 16bit width port connection.
After perform flash_read_jedec_ids(), the cfi query read will get an
'0xff'. From this flash's specification, the read for flash commands in
16bit port connection should perform 16bit read and ignore the high 8bit
data. Although this issue maybe occurs in the special chip, perform the
fully 16bit read is a safety operation.

The modification refers to the cfi flash drivers in Linux kernel (The
cfi_read_query() function in include/linux/mtd/cfi.h file). It's more
easy and clear than making the different type date read for different
portwidth (such as ushort_read() for x16, ulong_read() for x32).

Thanks!

Best Regards,
Zhang Wei

Wolfgang Denk wrote:
> In message <1166772458178-git-send-email-> you wrote:
>
>> For the flash of port width more than 8bit, a completetly read must
>> be performed. For example, 16bit port width flash must perform a
>> ushort read. Otherwise, some flashes will get error data.
>>
>
> Please explain under which circumstances you think this is necessary.
>
>
>> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
>> ---
>> drivers/cfi_flash.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cfi_flash.c b/drivers/cfi_flash.c
>> index 9b10220..f02b047 100644
>> --- a/drivers/cfi_flash.c
>> +++ b/drivers/cfi_flash.c
>> @@ -250,9 +250,9 @@ #endif
>> */
>> inline uchar flash_read_uchar (flash_info_t * info, uint offset)
>> {
>> - uchar *cp;
>> + uchar cp[FLASH_CFI_64BIT];
>>
>> - cp = flash_make_addr (info, 0, offset);
>> + memcpy(cp, flash_make_addr (info, 0, offset), info->portwidth);
>>
>
> This most probably does NOT perform any ushort reads at all, but does
> a simple byte by byte copy, so your patch does not make much sense to
> me.
>
> Please explain in which sort of problems you see that are supposed to
> be fixed by this modification.
>
> Best regards,
>
> Wolfgang Denk
>
>