From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Laird Date: Mon, 22 May 2006 00:35:57 -0700 (PDT) Subject: [U-Boot-Users] Booting from NAND Flash Problems In-Reply-To: References: <4436349.post@talk.nabble.com> Message-ID: <4501134.post@talk.nabble.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.