AVR32 / ATNGW100 FLASH adressing issues

Hello,

currently the actual u-Boot (U-Boot 2010.03-00351-g40792d6-dirty) for AVR32/ATNGW100 defines FLASH to be at 0x00000000 (which is the true physical address):
#define CONFIG_SYS_FLASH_BASE 0x00000000
#define CONFIG_SYS_FLASH_SIZE 0x800000
#define CONFIG_SYS_MAX_FLASH_BANKS 1
#define CONFIG_SYS_MAX_FLASH_SECT 135
and
TEXT_BASE = 0x00000000

however the "flinfo" command show FLASH to be at 0xa0000000 (which is translated to 0x00000000 by default)

any commands using FLASH (protect, copy, ...) must therefore use addresses at 0xa0000000 otherwise it will be denied not being in the FLASH address range.

To make "saveenv" work, the definition had to be changed to:
/*#define CONFIG_ENV_ADDR (CONFIG_SYS_FLASH_BASE +
CONFIG_SYS_FLASH_SIZE - CONFIG_ENV_SIZE)*/
#define CONFIG_ENV_ADDR (0xA07F0000)

So far I could be happy, BUT
1. this seems like a bad hack
2. u-Boot is not aware of its sectors in the FLASH

I would like to fix this in a better way, but would like suggestions of where to attack the issue.
I think that the issue should be fixed by making sure FLASH is detected at 0x00000000 and NOT at 0xa0000000, correct?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reinhard_meyer.vcf
Type: text/x-vcard
Size: 370 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100531/6107e388/attachment.vcf

Dear Reinhard Meyer,

...

...

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/66904

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The only thing necessary for the triumph of evil is for good  men  to
do nothing.                                            - Edmund Burke

Right...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.

Haavard

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

Thanks.

Correct.

Any address accessed by the CPU is by definition virtual.

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.

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

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.

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.

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.

I don't know.

Haavard