From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tolunay Orkun Date: Sun, 07 Jan 2007 04:12:07 -0600 Subject: [U-Boot-Users] [PATCH] Fixed cfi flash read uchar bug. In-Reply-To: <200701051428.21262.sr@denx.de> References: <20070104092331.EC2C4353C96@atlas.denx.de> <200701051428.21262.sr@denx.de> Message-ID: <45A0C777.1000508@orkun.us> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Stefan Roese wrote: > On Thursday 04 January 2007 10:23, Wolfgang Denk wrote: >>> Wolfgang Denk wrote: >>>> Now this is what I want to understand. What exactly is the "potential >>>> problem"? >>> That's the issue in the flash 'Spinsion S29GL064M90TFIR6' with x16 >>> connection. After running flash_read_jedec_ids(), any follow CFI query >>> command will get the data with high 8bit = 0xff, but the low 8bit is >>> valid. And if we only read low 8bit, we'll get the 0xff too. In >>> addition, the second follow CFI query command has no that issue. So, I >>> read the full 16bit date and only take the valid low 8bit. >> etc. etc. >> >> I didn't see any new facts in your current posting. My position has >> not changed either: I don't see how your character-wise copy using >> memcpy() would be different from accessing the flash through a uchar >> pointer; also I still think that if the compiler version changes >> behaviour then we don't really understand what's going on here. >> >> Maybe Tolunay or Stefan can comment now that both are back from their >> Xmas breaks; they both know the CFI driver much better than me. > > What I noticed after looking at the flash access functions like > flash_read_uchar() is that no access macros and even no volatile pointer > access is used to read from the flash. This looks like a potential problem, > that can show when using different compiler versions. > > Please find attached a small patch that adds fixes this potential problem for > the 3 functions flash_read_uchar/ushort/long. Please give it a try and let me > know if this changed the behavior somehow. I think this is a good idea given GCC 4.x is agressive in optimizations. I do not think converting these to use memcpy() is a good idea. I am with Wolfgang on this. I think we should commit Stefan's patch even if it might or might not solve the problem Zhang is experiencing. Best regards, Tolunay