From: Daniel Laird <danieljlaird@hotmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Booting from NAND Flash Problems
Date: Mon, 22 May 2006 00:35:57 -0700 (PDT) [thread overview]
Message-ID: <4501134.post@talk.nabble.com> (raw)
In-Reply-To: <E1FgcvZ-0004Ss-B7@mail.sourceforge.net>
In message <4436349.post@talk.nabble.com> you wrote:
>>
>> This means that a small program has to run first. This small program is
>> <
>> 16K in size and copies U-Boot from Nand Flash into RAM and then executes
>> it.
>>
>> In theory this should work fine.
>
>This works fine in practice for a couple of systems.
Cool!
>> However i am having loads of issues with running u-boot with cache
>> enabled.
>> If cache is enabled then the Nand Driver (I am using the latest Linux MTD
>> based driver)
>> has problems as it uses a DMA copy to copy to the Nand Flash.
>> If I implement cache flushing I break u-boot.
>>
>Then your port of U-Boot is broken.
I appreciate the port of u-boot it broken but let me just elaborate a little
more.
I am using the standard mips code i.e All I have added to cpu/mips is a
serial port driver.
I then create a board and implement the usual functions checkboard,
initdram, low_level_init etc....
I then use an MTD driver that runs perfectly under linux. i.e the same C
file with minor structure name changes is used from our linux port that has
been stable and used for a long time now.
I then indicate that the environment is stored in nand flash.
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.
problem is all the code that follows (device init, eth_initialise, etc fail)
Without a cache flush these work.
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.
So I was wondering what ideas people may have. I feel that the most likely
is that my linux MTD driver use GFP_DMA flag and kmalloc when it is used in
Linux. This may (I am still investigating) result in it using a different
KSEG which the mips has set up to be uncached. (using the MMU) whereas under
u-boot this is mapped to just malloc and as such is still cached. I will
pursue this but any helpful ideas from anyone would be appreciated.
>>I was wondering if anyone has any hints or tips on how u-boot is used in a
>> system with only Nand Flash and a Mips processor.
>
>I don;t see anything in your setup where using NAND flash or a MIPS
>CPU plays a role; all this is pretty similar on all architectures.
Agreed was just asking for hints and tips!
>> I have seen other posts suggesting mips processors should run uncached
>> but
>> this is obviously slower.
>
>Define "run uncached".
Caches disabled.
>> Has the case been consider where relocation is not necessary i.e a small
>>
>Yes.
>>
>> program just loads the executable to a location and runs it. I know
>> relocation can save memory but in my system it means extra copying and
>> currently extra headaches!!
>
>Then don't do it.
agreed but as I have indicated throughout I was trying to limit the changes
to the cpu/mips bit and this does relocate hence i tried this.
>Best regards,
>
>Wolfgang Denk
>
>--
>Software Engineering: Embedded and Realtime Systems, Embedded Linux
>Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>The ultimate barrier is one's viewpoint.
> - Terry Pratchett, _The Dark Side of the Sun_
Cheers
Daniel Laird
--
View this message in context: http://www.nabble.com/Booting+from+NAND+Flash+Problems-t1637982.html#a4501134
Sent from the Uboot - Users forum at Nabble.com.
next prev parent reply other threads:[~2006-05-22 7:35 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 [this message]
2006-05-22 9:38 ` Wolfgang Denk
2006-05-23 7:47 ` Daniel Laird
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=4501134.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.