In message 4501134.post@talk.nabble.com you wrote:
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
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.
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.
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.
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?
You mention "our driver", "my code" and "my order" - how should we comment on this? If you think you know beter and come up with your own implementation then you will have to debug it yourself. All I can say is that the exsiting code in U-Boot works fine on a couple of boards.
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
Dump your custome code. Use the existing one.
This is my last comment on this.
Define "run uncached".
Caches disabled.
Instruction cache or data cache or both or what? Yo need to be more specific.
Wolfgang Denk