
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... 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#a451860... Sent from the Uboot - Users forum at Nabble.com.