[resending because the mailing list was accidentally dropped from Cc]

Reinhard Meyer reinhard.meyer@emk-elektronik.de wrote:

I would be willing to help solve the issue/dispute.

Thanks.

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?

Correct.

2. CFI Driver for parallel flash uses virtual adresses why?

Any address accessed by the CPU is by definition virtual.

To be compatible with serial flash? Or to generally avoid caching problems - assuming every hardware can disable cache using the mmu?

Various architectures provide different ways of managing the cache. Some (e.g. AVR32) do it via the MMU, others provide other mechanisms.

This is why I added a generic function for mapping a physical address to a virtual address given a set of desired cache properties, and changed the CFI driver to use it. This worked very well, until the CFI driver was changed to do address calculations on virtual addresses instead of physical addresses.

The proposed solution by Wolfgang is to toss that interface and instead introduce a "cache control" interface which is basically identical except that it doesn't return a virtual address. Since AVR32 uses the MMU to control caching properties, such an interface would be utterly useless.

3. The default translation on AP700x is a0000000->00000000, non cached.

The default translations are as follows: - 00000000 -> 00000000, cached - 80000000 -> 00000000, cached - a0000000 -> 00000000, uncached - e0000000 -> e0000000, uncached

4. With some effort that could be changed to 00000000->00000000? The

effort would be to setup page tables in RAM?

With some effort, anything is possible. However, adding full-blown paging support to a boot loader seems just wrong.

For a generic solution, it's not enough to just load the necessary pages into the TLB; you'll have to implement a TLB miss exception handler to support the case where the TLB isn't large enough to hold all the mappings at once.

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.

Yes, but ironically enough, this used to work in terms of physical addresses. The problems with exposing virtual addresses through the user interface is that they might change in the future.

6. That can be achieved by defining the ENV_ADDR accordingly OR by

changing the load/saveenv functionality to have the address translated first

Yes, but the translation used to be localized in the CFI driver. Introducing physical-to-virtual mappings into all parts of the system _except_ the CFI driver seems like a huge step backwards.

7. What issues do exist with the jffs2 file system in that context?

I don't know.

Haavard