[U-Boot-Users] Booting from NAND Flash Problems

Daniel Laird danieljlaird at hotmail.com
Tue May 23 09:47:16 CEST 2006


> 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.





More information about the U-Boot mailing list