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@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#a450113... Sent from the Uboot - Users forum at Nabble.com.