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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox