From: Zhang Wei <wei.zhang@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug.
Date: Mon, 25 Dec 2006 15:03:44 +0800 [thread overview]
Message-ID: <458F77D0.10203@freescale.com> (raw)
In-Reply-To: <20061222171728.E3333353BD9@atlas.denx.de>
Hi, Wolfgang,
Merry X'mas!
I want to explain two key points. I also take the x16 connection flash
example.
1. Reading 16bit data in flash_read_uchar() will not cause an error.
We can get an example from the CFI specification. We run the CFI
Query-unique ACSII string "QRY" command on x16 device with x16 mode
connection. From the word address 0x10, 0x11, 0x12, we could get "Q",
"R", "Y". If using byte address, we should get them like below: byte
address 0x20 got "Q", 0x21 got 0x0, 0x22 got "R", 0x23 got 0x0, 0x24 got
"Y", 0x25 got 0x0. In the u-boot, The word address offset '0x10' in
flash_read_uchar() will be translated to byte address '0x20' by
flash_make_addr(). I get the high 8-bit in flash_read_uchar(), which is
just a NULL and discarded.
2. Reading 16bit data in flash_read_uchar() is a safety operation, which
will avoid the potential problem.
In the Linux kernel, the cfi driver using the similar
implementation. I think reading the full width bit data from the flash
port may clear the flash data buffer. I've tested to add 'volatile'
keyword to the flash_get_size() and flash_read_jedec_ids() functions'
declaration. The flash can not work also. From Chris' work, the
compiler's optimizing causes some flash to get the error.
Thanks!
Best Regards,
Zhang Wei
Wolfgang Denk wrote:
> In message <2176B872C0407E44887F07CCAA869293832458@zch01exm21.fsl.freescale.net> you wrote:
>
>> Yes, the memcpy() is just a byte copy. But a x16 read can be emulated by
>> two x8 read. And in fact, the flash_read_ushort(), flash_read_long() in
>> cfi_flash.c are using the same implementation.
>>
>
> But these are supposed to read more than one byte.
>
>
>> In addition, the original code only reads 8bit, not the full 16bit. My
>> patch ensures the full 16bit data are read completely.
>>
>
> I still don't understand why flash_read_uchar() should read more than
> one byte? If you need a 16 bit read operation I would expect you to
> use flash_read_ushort() instead.
>
> Best regards,
>
> Wolfgang Denk
>
>
next prev parent reply other threads:[~2006-12-25 7:03 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-22 7:27 [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug wei.zhang at freescale.com
2006-12-22 10:00 ` Wolfgang Denk
2006-12-22 11:02 ` Zhang Wei
2006-12-22 14:11 ` Wolfgang Denk
2006-12-22 16:34 ` [U-Boot-Users] 答复: " Zhang Wei-r63237
2006-12-22 17:17 ` Wolfgang Denk
2006-12-25 7:03 ` Zhang Wei [this message]
2006-12-25 23:24 ` Wolfgang Denk
2006-12-26 6:04 ` Zhang Wei
2007-01-04 2:07 ` Zhang Wei-r63237
2007-01-04 8:17 ` Wolfgang Denk
2007-01-04 8:36 ` Zhang Wei-r63237
2007-01-04 9:23 ` Wolfgang Denk
2007-01-04 11:19 ` Stefan Roese
2007-01-05 13:27 ` Stefan Roese
2007-01-07 10:12 ` Tolunay Orkun
2007-01-07 10:40 ` Wolfgang Denk
2007-01-13 7:11 ` Tolunay Orkun
2007-01-13 17:53 ` Håvard Skinnemoen
2007-01-16 6:52 ` Stefan Roese
2007-01-25 4:38 ` Zhang Wei-r63237
2007-01-25 16:10 ` Timur Tabi
2007-01-25 20:33 ` Wolfgang Denk
2007-01-26 2:13 ` Zhang Wei-r63237
2007-01-29 11:29 ` Tolunay Orkun
2007-01-30 3:36 ` Wang Haiying-r54964
2007-01-31 9:01 ` Tolunay Orkun
2007-01-31 19:25 ` Haiying Wang
2007-02-01 5:26 ` Tolunay Orkun
2007-02-01 22:06 ` Haiying Wang
2007-02-01 22:52 ` Chris Fester
2007-02-09 17:47 ` [U-Boot-Users] [PATCH0/2] Re-do the patch for adding DO_SYNC in flash_write_cmd Haiying Wang
2007-02-09 19:42 ` Wolfgang Denk
2007-02-09 19:48 ` Haiying Wang
2007-02-10 1:04 ` Wolfgang Denk
2007-02-10 7:23 ` Tolunay Orkun
2007-02-10 7:40 ` Stefan Roese
2007-02-10 7:57 ` Tolunay Orkun
2007-02-10 8:07 ` Stefan Roese
2007-02-10 21:55 ` Wolfgang Denk
2007-02-10 21:54 ` Wolfgang Denk
2007-02-11 2:34 ` Timur Tabi
2007-02-11 10:23 ` Wolfgang Denk
2007-02-09 19:59 ` Haavard Skinnemoen
2007-02-10 1:02 ` Wolfgang Denk
2007-02-09 17:47 ` [U-Boot-Users] [PATCH 1/2] Add DO_SYNC at the end of flash_write_cmd Haiying Wang
2007-02-09 19:45 ` Wolfgang Denk
2007-02-09 17:47 ` [U-Boot-Users] [PATCH 2/2] Define DO_SYNC in each CPU's header file Haiying Wang
2007-02-09 19:46 ` Wolfgang Denk
2007-02-10 7:17 ` Tolunay Orkun
2007-01-08 2:41 ` [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug Zhang Wei-r63237
2006-12-22 17:07 ` Chris Fester
2006-12-22 17:24 ` Wolfgang Denk
2006-12-22 17:42 ` Chris Fester
2006-12-22 21:33 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=458F77D0.10203@freescale.com \
--to=wei.zhang@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.