All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.