This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Bug in arm vectors.S ???
- To: Carl van Schaik <carl at leg dot uct dot ac dot za>
- Subject: RE: [ECOS] Bug in arm vectors.S ???
- From: Gary Thomas <gthomas at redhat dot com>
- Date: Wed, 02 Aug 2000 07:41:02 -0600 (MDT)
- Cc: Ecos Mailing List <ecos-discuss at sourceware dot cygnus dot com>
I'd say the problem is with your LED macro. Either have it use
other registers, or get rid of it.
At this time, the LED macro is only used during initial board
bringup. It's reasonable that the code assume that the macro
does not destroy any registers in use.
On 02-Aug-2000 Carl van Schaik wrote:
> Hi
>
> With refernece to the lines :
>
> str r2,[r0,#0x10]
> ldr r2,[r1,#0x30]
> str r2,[r0,#0x30]
>
> LED 4
>
>#if defined(CYG_HAL_STARTUP_ROM)
> // Set up reset vector
> ldr r2,[r1,#0x00] // reset vector intstruction
> str r2,[r0,#0x00]
> ldr r2,=warm_reset
> str r2,[r0,#0x20]
> // Relocate [copy] data from ROM to RAM
> ldr r3,.__rom_data_start
> ldr r4,.__ram_data_start
> ldr r5,.__ram_data_end
>
> After the "LED" macro, r0 and r1 may have been corrupted, I know in my
> port and in the pid hal_platform_setup.h the LED routines are using r0 and
> not restoring it. Thus an <abort_prefetch> could occur.
>
> Am I correct in this assumption? Should the LED code not use r0 and r1?
> Should the code above be modified? by inserting
> "
> mov r0,#0 // move vectors
> ldr r1,.__exception_handlers
> "
> after the LED 4 macro.
>
> thanks
>
> Carl van Schaik <carl@leg.uct.ac.za>
> -----------------------------------------------------
> Dept. Electrical Engineering, UCT
>
> 621 Menzies Building
> University of Cape Town
> Rondebosch
> Western Cape
> 7700
> South Africa
>
> Tel: +27 21 650-3467
> Fax: +27 21 650-3465
>