[ECOS] ecos redboot compile problem.

[Doyle, Patrick]

> Thanks for the reply Patrick, 
>   I found the branch at the third location in SRAM. However, 
> what I don't understand is how
> the PC is getting to address 0x20000008 (Third position in 
> SRAM) on a reset. From the comments
> in the source I assume that there is a branch in Flash at 
> 0x00 that goes to SRAM. If it's 
> going to 0x20000000 then why don't the codes at 0x20000000 
> and 0x20000004 get executed since
> they are valid opcodes? 
At reset, the processor starts executing at address 0.  Assuming the DIP
switches are in their default positions, address 0 maps to the AMD boot
flash on the innovator.  

The code at address 0 contains a branch instruction to the initialization
code in RedBoot.

The initialization code examines addresses 0x20000000 and 0x20000004 to see
if they contain 0x12345678 and 0x87654321 respectively.  If they do, the
code zeros those locations and branches to address 0x20000008 (the third
word in SRAM).  So, the opcodes at addresses 0x20000000 and 0x20000004 are
never executed.

> 
>    BTW. I'm running on a X86 Linux Red Hat 9.0. I've tried 
> both the caned and home built
>  cross-compiler. For some reason arm-elf-objdump thinks that 
> the data at 0x20000000 is 
>  data in redboot-SRAM.out from you; and my redboot.img it 
> shows as instructions.
> 
Now I am confused as to what was your original problem...
When I run arm-elf-objdump -D as I described in my previous email, I get the
same results for redboot-SRAM.out as I do for install/bin/redboot.elf.
(Well, they are the same for the 0x20000000 addresses of which we are
speaking -- I've changed other things since then).

So I am confused... what problem are you trying to solve?
--wpd

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss