This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Redboot reset must use JUMP ?
- To: Jordi Colomer <jco at ict dot es>
- Subject: RE: [ECOS] Redboot reset must use JUMP ?
- From: Gary Thomas <gthomas at cambridge dot redhat dot com>
- Date: Fri, 08 Jun 2001 07:46:31 -0600 (MDT)
- Cc: jlm at ict dot es, ecos-discuss <ecos-discuss at sources dot redhat dot com>
- Organization: Red Hat, Inc.
On 08-Jun-2001 Jordi Colomer wrote:
>
> Hi,
>
> (Thanks to Gary Thomas for replying my first question
> about this problem).
>
> I have tried redboot for the first time in my Assabet
> (StrongArm) board. After writing it on the flash memory,
> it works great : I can use the network, download a kernel
> image and flash it. Doing a hardware reset also works ok,
> as well.
>
> After recycling power (power off and then on), the CPU
> does not boot. Sampling the logic levels of the pins
> with a boundary-scan utility, reveals that the CPU is
> constantly receiving prefetch aborts. Since the MMU is
> disabled, the CPU cannot handle the *virtual* jump address
> to the prefetch handler, then a new prefetch abort is
> thrown and loops back again.
>
> It seems that the first prefetch abort is raised right
> after the CPU executes the reset vector, which contains
> an indirect jump to the reset routine. This routine never
> executes because the exception is thrown, making the CPU
> to enter the endless loop.
>
> If I define CYGSEM_HAL_ROM_RESET_USES_JUMP in
> hal/arm/arch/src/vectors.S, then a direct jump is used,
> and the prefetch abort is NOT thrown. Redboot boots ok.
>
This is good.
>
> I wonder :
>
> 1. Why the indirect jump causes a prefetch abort, while
> the MMU is disabled ? (a chip bug... ?). It does not
> happen in some other assabets.
I agree, it is odd. Using the jump is completely reasonable
and if it makes it work, so much the better.
>
> 2. Why the code in vectors.S is conditional at this
> point ? which are the benefits of the indirect jump ?
> is it really necessary (although legal) ?
There are some platforms where the reset vector and the
start of the code are too far away for a simple jump to
work. On these platforms, the setup code handles any
translation problems, etc.
>
> This is part of hal/arm/.../vectors.S :
>
> .global __exception_handlers
> __exception_handlers:
>#ifdef CYGSEM_HAL_ROM_RESET_USES_JUMP
> // Assumption: ROM code has these vectors at the hardware reset
> address.
> // A simple jump removes any address-space dependencies [i.e. safer]
> b reset_vector // 0x00
>#else
> ldr pc,.reset_vector // 0x00
>#endif
> ldr pc,.undefined_instruction // 0x04
> ldr pc,.software_interrupt // 0x08 start &&
> software int
> ldr pc,.abort_prefetch // 0x0C
> ldr pc,.abort_data // 0x10
> .word 0 // unused
> ldr pc,.IRQ // 0x18
> ldr pc,.FIQ // 0x1C
>
>
> NOTE: .reset_vector contains a physical address. The other variables
> contain virtual addresses.
>
>
> Jordi Colomer.