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.
next prev parent 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