[U-Boot] Resigning as the AVR32 custodian (was Re: AVR32 / ATNGW100 FLASH adressing issues)

[Haavard Skinnemoen]

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

Reinhard Meyer <reinhard.meyer at 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