From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Laird Date: Tue, 23 May 2006 00:47:16 -0700 (PDT) Subject: [U-Boot-Users] Booting from NAND Flash Problems In-Reply-To: <20060522093800.C761C3525D9@atlas.denx.de> References: <4436349.post@talk.nabble.com> <4501134.post@talk.nabble.com> <20060522093800.C761C3525D9@atlas.denx.de> Message-ID: <4518601.post@talk.nabble.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > Why don't you use the existing NAND flash code in U-boot? >Please note that "runs perfectly under linux" doesn't mean anything >here. U-Boot is not Linux. Unfortunately the chip I am using has a Flash Interface Chip that handles the access to flash, this means that the standard u-boot flash code will not access the flash properly(my problem I know). This is why a custom MTD driver that plugs into the linux MTD infrastructure was written and is used succesfully. U-Boot then took the really good decision to use the same infrastructure hence I use the same driver code. I agree that u-boot is not linux but a driver that works using the same infrastructure is always a good starting point. >> It loads the environment but always rejects it based on the CRC check. >> If I cache flush after reading the environment from flash the CRC check >> completes ok and it uses this environment. >You probably should make sure to use proper cache policies and/or >flushing troughout your port. As indicated I am using the standard cpu/mips code with a custom serial port driver. This was done to minimise the probability of bugs being introduced by myself. There is obviously an issue in my port regarding cache flushing. I had also seen this discussion http://sourceforge.net/mailarchive/forum.php?thread_id=10170097&forum_id=12898 And was wondering if i might be suffereing with a similar issue hence I asked the community for there wider experience and advice. No point solving a fixed problem! >> problem is all the code that follows (device init, eth_initialise, etc >> fail) >> Without a cache flush these work. > >That's what I said: fix your port of U-Boot. Obviously a true statement I was just seeing if others has seen anything similar, using the standard cpu/mips code should minimise the bugs I should have introduced >> I think that you need to initialise the NAND flash and env_relocate >> before >> the calls to eth_initialise etc so I do not feel my order is incorrect. > >Why don't you just use the existing code? In the current lib_mips/board.c nand_init is not actually called. Hence I questioned if anyone had used the new Linux based NAND driver infrastructure with a mips cpu. >If you think you know beter and come up with your >own implementation then you will have to debug it yourself. Fair point, I am sure i do not know better however the chip I am using dictates using a different NAND driver, the current lib_mips does not seem to initialise NAND flash and I am using the cpu/mips code to minimise the bugs i will have introduced. >All I can say is that the exsiting code in U-Boot works fine on a couple of >boards. Cool, I never questioned that I only asked if a mips processor was using the new NAND infrastructure and if anyone had had any issue regarding caching etc. When looking throught the code it seems that 3 boards use ENV_IS_IN_NAND and these are 2 XScales and one PPC. Thanks for all the comments i will see if i can fix my port and feed back the changes Dan -- View this message in context: http://www.nabble.com/Booting+from+NAND+Flash+Problems-t1637982.html#a4518601 Sent from the Uboot - Users forum at Nabble.com.