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: 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.

  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