Re: [ECOS] Redboot on Assabet, problem with reset_vector and UNMAPPED_PTR in vectors.S

["Chris Lesiak" <clesiak at licor dot com>]

I too had this problem.  It seems as if you have three options:

1. Add the following to your hal_platform_setup.h file:
     #define CYGHWR_HAL_ROM_VADDR 0x50000000
2. Upgrade your binutils.  I tested binutils-011002 and it does not have this
problem .
3. Define CYGSEM_HAL_ROM_RESET_USES_JUMP (I haven't tried this myself.)

Chris Lesiak
clesiak@licor.com


todd.kallam@acterna.com said:
>>Hi,

>>I am trying to get the redboot running out of flash on my assabet/neponset
>>board.
>>I am using a snapshot of the code that I downloaded today.  My board will not
>>start to
>>boot and the problem appears to be with the reset_vector set to the wrong
value.

>>The vectors.S file uses the following lines to set the vector value:

 >>        vectors:
>>          UNMAPPED_PTR(reset_vector)                      // 0x20

>>The UNMAPPED_PTR macro is defined as:

>>          # define UNMAPPED(x) ((x)-CYGHWR_HAL_ROM_VADDR)

>>This expression should equate to   ((0x50000040) - 0x50000000) and equal
>>0x00000040,
>>but the map file shows the value getting set to 0x00000060.   According to the
>>map file,
>>the value should be 0x00000040.

>>It seems that the assembler or linker has added 0x20 to the value which also
>>happens
>>to be the offset for where vectors start.

>>I can manually change 0x00000060 to 0x00000040 in redboot.bin (address
>>0x00000020) and
>>the assabet boots up correctly every time.

>>Here is a partial listing of the objdump on the redboot.img:

>>------ Snip  --------------------------------------------

>>redboot.img:     file format elf32-littlearm

>>Disassembly of section .rom_vectors:

>>50000000 <__exception_handlers>:
>>50000000: e59ff018  ldr  pc, [pc, #18]   ; 50000020 <vectors>
>>50000004: e59ff018  ldr  pc, [pc, #18]   ; 50000024 <.undefined_instruction>
>>50000008: e59ff018  ldr  pc, [pc, #18]   ; 50000028 <.software_interrupt>
>>5000000c: e59ff018  ldr  pc, [pc, #18]   ; 5000002c <.abort_prefetch>
>>50000010: e59ff018  ldr  pc, [pc, #18]   ; 50000030 <.abort_data>
>>50000014: 00000000  andeq     r0, r0, r0
>>50000018: e59ff018  ldr  pc, [pc, #18]   ; 50000038 <.IRQ>
>>5000001c: e59ff018  ldr  pc, [pc, #18]   ; 5000003c <.FIQ>

>>50000020 <vectors>:
>>50000020: 00000060  andeq     r0, r0, r0, rrx

>>50000024 <.undefined_instruction>:
>>50000024: 50000370  andpl     r0, r0, r0, ror r3

>>50000028 <.software_interrupt>:
>>50000028: 500003f4  strpld    r0, [r0], -r4

>>5000002c <.abort_prefetch>:
>>5000002c: 5000042c  andpl     r0, r0, ip, lsr #8

>>50000030 <.abort_data>:
>>50000030: 500004a8  andpl     r0, r0, r8, lsr #9
>>50000034: 00000000  andeq     r0, r0, r0

>>50000038 <.IRQ>:
>>50000038: 500005b0  strplh    r0, [r0], -r0

>>5000003c <.FIQ>:
>>5000003c: 50000578  andpl     r0, r0, r8, ror r5
>>Disassembly of section .text:

>>50000040 <reset_vector>:
>>50000040: e3a01412  mov  r1, #301989888  ; 0x12000000
>>50000044: e59f26bc  ldr  r2, [pc, #6bc]  ; 50000708 <_eCos_id+0x14>
>>50000048: e3822a02  orr  r2, r2, #8192   ; 0x2000
>>5000004c: e3822901  orr  r2, r2, #16384  ; 0x4000
>>50000050: e5812000  str  r2, [r1]
>>50000054: e59f16b0  ldr  r1, [pc, #6b0]  ; 5000070c <_eCos_id+0x18>
>>50000058: e59f26b0  ldr  r2, [pc, #6b0]  ; 50000710 <_eCos_id+0x1c>
>>5000005c: e5812000  str  r2, [r1]
>>50000060: e59f36ac  ldr  r3, [pc, #6ac]  ; 50000714 <_eCos_id+0x20>
>>50000064: e3a02fbf  mov  r2, #764  ; 0x2fc
>>50000068: e5832000  str  r2, [r3]
>>5000006c: e59f26a4  ldr  r2, [pc, #6a4]  ; 50000718 <_eCos_id+0x24>
>>50000070: e5812000  str  r2, [r1]
>>50000074: e59f36a0  ldr  r3, [pc, #6a0]  ; 5000071c <_eCos_id+0x28>
>>50000078: e3a02064  mov  r2, #100  ; 0x64
>>5000007c: e5939000  ldr  r9, [r3]
>>50000080: e2522001  subs r2, r2, #1      ; 0x1
>>50000084: 1afffffc  bne  5000007c <_stext+0x3c>
>>---------------------------------------------------

>>Has anyone else experienced this problem?

>>I am using the 2.95.2 version of the arm-elf tools with ecos-gcc-2952.pat.

>>Any suggestions are welcome.

>>Thanks,

>>Todd