[U-Boot] AVR32 / ATNGW100 FLASH adressing issues

[U-Boot] AVR32 / ATNGW100 FLASH adressing issues

[Reinhard Meyer]

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 

[U-Boot] AVR32 / ATNGW100 FLASH adressing issues

[Wolfgang Denk]

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

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

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

[Haavard Skinnemoen]

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

[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@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