[U-Boot] 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?

Dear Reinhard Meyer,
In message 4C03C0CA.50504@emk-elektronik.de you wrote:
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):
...
however the "flinfo" command show FLASH to be at 0xa0000000 (which is translated to 0x00000000 by default)
...
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/66904
Best regards,
Wolfgang Denk

Wolfgang Denk wd@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/66904
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
participants (3)
-
Haavard Skinnemoen
-
Reinhard Meyer
-
Wolfgang Denk