[U-Boot-Users] Booting from NAND Flash Problems

Daniel Laird danieljlaird at hotmail.com
Mon May 22 09:35:57 CEST 2006


In message <4436349.post at 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.





More information about the U-Boot mailing list