Is remap safe on AT91 (slightly OT)?

I do not think the usual way is to first copy ROM to RAM. The way we do it, and most examples (atmel) I've seen as well, Do it like this:

Boot from rom and at a certain point the remap is executed. This maps the rom at a different location. The next instruction, which is already in the pipeline, will jump to an address in the new location of the rom. So execution will continue from the same rom, but now mapped at a different location. No copy to RAM required.

This method depends on the pipeline as you effectivly remove the code from the location it is running from.

on

from

BL

half-baked

Load the target address into a register and do a bx. The bl pretty probably does not get as far as you would like, as the easiest-to-use chip selects will be farther away from each other that the direct branch is able to handle.

My setup code does it:

adr r12,initbl @ point to initialisation table ldmia r12,{r0-r11} @ get chip select settings stmia r11,{r0-r10} @ set up chip selects and remap bx r10 @ go to remapped space

initbl: .word CS_0_VALUE @ value to load to chip select 0 .word CS_1_VALUE @ value to load to chip select 0 .word CS_2_VALUE @ value to load to chip select 0 .word CS_3_VALUE @ value to load to chip select 0 .word CS_4_VALUE @ value to load to chip select 0 .word CS_5_VALUE @ value to load to chip select 0 .word CS_6_VALUE @ value to load to chip select 0 .word CS_7_VALUE @ value to load to chip select 0 .word CANCEL_MAP @ remap cancel bit .word ADDR_RANGE @ address range and read protocol setup .word the_start @ start address after remap .word AT91EBI @ external bus controller base address

The remap cancellation is actually performed after fetching the bx instruction, so it will get executed.

The adr pseudo-op is position-independent, so this code can be located to the final ROM location after remap cancellation (i.e. where CS0 will point after loading).

HTH

Tauno Voipio tauno voipio @ iki fi

"Andras Tantos" wrote in news:3f8c1d96$ snipped-for-privacy@news.microsoft.com:

No, the remap switches on a shadow of the ROM over the RAM, this means that the ROM is always present in the memory map at the high address. The recommended course of actioin is to branch to the real ROM address, and then switch off remap.

ADR r0, mylabel MOV pc, r0 mylabel: LDR r0, =REMAP_CONTROL_REG MOV r1, #1 STR r1, [r0]

It will work*, but it is not 'safe' - try step debugging that code for instance. You might know why it falls in a heap, but will your successor?

Will

Sigh, I should have thought about that. I will implement it in that way. Thanks!

There's no cache in that particular device, and in my case IRQs are off. But you're right, the first solution is the way to go.

Thanks, Andras Tantos

Now, it seems I make kind of a thread on my own :-). Anyway, I've looked at the datasheet and I'm not at all that sure any more that the external ROM is present at a high address, before remap. It is present at the low address only (normal external memory access range generates an abort). After remap it is present at a high address only. So there's no safe address range where I can jump to to do the remap. Or did I miss something?

Thanks, Andras Tantos

at

is

where

It's not, AFAIK. The datasheet is pretty clear in this respect.

The trick may be OK for other ARM's, but for AT91, the RAM is at 0x00300000 till remap and the CS0 chip (hopefully FLASH / ROM) at zero.

My code is tested in tens of units - try it.

Tauno Voipio tauno voipio @ iki fi

PS. If you're interested, I can send the whole startup module. It's written for GNU assembler and it starts the hardware for GNU C (gcc) run environment.

Just correct the email address in the sig in the obvious way.

TV

probably

Thanks to all of you who answered. I wrote my program and it works as expected, the branch gets executed after the remap.

Andras Tantos