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.

Why don't you use the existing NAND flash code in U-boot? Please note that "runs perfectly under linux" doesn't mean anything here. U-Boot is not Linux.

Unfortunately the chip I am using has a Flash Interface Chip that handles the access to flash, this means that the standard u-boot flash code will not access the flash properly(my problem I know). This is why a custom MTD driver that plugs into the linux MTD infrastructure was written and is used succesfully. U-Boot then took the really good decision to use the same infrastructure hence I use the same driver code. I agree that u-boot is not linux but a driver that works using the same infrastructure is always a good starting point.

...

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.

You probably should make sure to use proper cache policies and/or flushing troughout your port.

As indicated I am using the standard cpu/mips code with a custom serial port driver. This was done to minimise the probability of bugs being introduced by myself. There is obviously an issue in my port regarding cache flushing. I had also seen this discussion http://sourceforge.net/mailarchive/forum.php?thread_id=10170097&forum_id... And was wondering if i might be suffereing with a similar issue hence I asked the community for there wider experience and advice. No point solving a fixed problem!

...

problem is all the code that follows (device init, eth_initialise, etc fail) Without a cache flush these work.

That's what I said: fix your port of U-Boot.

Obviously a true statement I was just seeing if others has seen anything similar, using the standard cpu/mips code should minimise the bugs I should have introduced

...

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.

Why don't you just use the existing code?

In the current lib_mips/board.c nand_init is not actually called. Hence I questioned if anyone had used the new Linux based NAND driver infrastructure with a mips cpu.

If you think you know beter and come up with your own implementation then you will have to debug it yourself.

Fair point, I am sure i do not know better however the chip I am using dictates using a different NAND driver, the current lib_mips does not seem to initialise NAND flash and I am using the cpu/mips code to minimise the bugs i will have introduced.

All I can say is that the exsiting code in U-Boot works fine on a couple

of

boards.

Cool, I never questioned that I only asked if a mips processor was using the new NAND infrastructure and if anyone had had any issue regarding caching etc. When looking throught the code it seems that 3 boards use ENV_IS_IN_NAND and these are 2 XScales and one PPC.

Thanks for all the comments i will see if i can fix my port and feed back the changes Dan -- View this message in context: http://www.nabble.com/Booting+from+NAND+Flash+Problems-t1637982.html#a451860... Sent from the Uboot - Users forum at Nabble.com.