public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Daniel Laird <danieljlaird@hotmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Booting from NAND Flash Problems
Date: Tue, 23 May 2006 00:47:16 -0700 (PDT)	[thread overview]
Message-ID: <4518601.post@talk.nabble.com> (raw)
In-Reply-To: <20060522093800.C761C3525D9@atlas.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.

  reply	other threads:[~2006-05-23  7:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-17 18:32 [U-Boot-Users] Booting from NAND Flash Problems Daniel Laird
2006-05-17 22:48 ` Wolfgang Denk
2006-05-22  7:35   ` Daniel Laird
2006-05-22  9:38     ` Wolfgang Denk
2006-05-23  7:47       ` Daniel Laird [this message]
2006-05-18  4:28 ` Frank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4518601.post@talk.nabble.com \
    --to=danieljlaird@hotmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox