From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wang Haiying-r54964 Date: Mon, 29 Jan 2007 20:36:30 -0700 Subject: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug. In-Reply-To: <45BDDA91.3070303@orkun.us> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >The current code works because most CPU Bus Interface Unit >will execute >buswide cycles and discard the unused byte(s). > >I understand that you would like to convert this code to use memcpy() >and pick various bytes from local ram instead of directly from flash. >Right? What exactly you are experiencing when you use current code. >Could you refresh my memory? The problem we experienced here is that the flash(am29lv641d) could not get the correct size during boot up(the error message like "FLASH: ....255 erase regions found, only 4 used...0kB" is printed out), could not be read correctly by flinfo, could not erased or written etc. It is because the num_erase_regions got a wrong value by flash_read_uchar(info, FLASH_OFFSET_NUM_ERASE_REGIONS)in line 1204. It happened only after the latest update of cfi_flash driver after u-boot 1.1.6 released. This update added a flash_read_jedec_ids before reading num_erase_resions. We suspect that reset command in flash_read_jedec_ids()may cause the problem. After the last reset in this function, a flash_write_cmd() follows it, then the flash_read_uchar is executed directly after. This flash_read_uchar returns a wrong number(124, 255 for num_erase_regions etc.). If this flash_read_uchar here reads some other flash info other than FLASH_OFFSET_NUM_ERASE_REGIONS by uchar, it also returns wrong value. >I do not like memcpy() as it is a black box. It could be >implemented at >low level using string instructions, it could do various things for >different cpu architectures and various sizes so it could lead to very >hard to find issues. I agree. >My proposal for you to try: Do not depend on bus interface unit doing >buswide reads, explicitly read buswide chunks after doing the bus-wide >read into a temporary variable, pick the usable bytes from that >temporary variable. This should eliminate the bus interface unit >dependency of the CPU and possible board designer interfacing gimmicks. Thanks a lot. :) >Let us know how it goes (can you post your patch too so I can >verify it). Zhang Wei is on vacation this week, he had generated a new patch to implement it with the similar idea last week. He will post his new patch after he is back. Thanks. Haiying