Haavard Skinnemoen schrieb:
Wolfgang Denk <w...@denx.de> wrote:I think that the issue should be fixed by making sure FLASH is detected at 0x00000000 and NOT at 0xa0000000, correct?This has been discussed in one of the longer and more heated discussions on that list; see thread starting here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/66904Right...and since we never reached an agreement, and I still have no idea about how to bring the most popular AVR32 board into working shape, it seems kind of pointless for me to continue as the AVR32 custodian. In fact, I should probably have resigned a long time ago, but this kind of failure is not easy to admit. Please remove me from the list. I'm sorry it didn't work out.
Hi, I would be willing to help solve the issue/dispute. Correct me if I am wrong:1. The issue seems to be the requirement/wish by Wolfgang Denk that virtual and physical addresses of flash should be 1:1 mapped?
2. CFI Driver for parallel flash uses virtual adresses why? To be compatible with serial flash? Or to generally avoid caching problems - assuming every hardware can disable cache using the mmu?
3. The default translation on AP700x is a0000000->00000000, non cached.4. With some effort that could be changed to 00000000->00000000? The effort would be to setup page tables in RAM?
5. The current u-Boot works fine with the default translation, provided the environment sector is used with its virtual address AND commands involving the flash (protect, erase, cp) are done using the virtual addresses.
6. That can be achieved by defining the ENV_ADDR accordingly OR by changing the load/saveenv functionality to have the address translated first
7. What issues do exist with the jffs2 file system in that context? With Best Regards Reinhard Meyer
<<attachment: reinhard_meyer.vcf>>
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
