RE: [ECOS] Redboot reset must use JUMP ?

[Gary Thomas <gthomas at cambridge dot redhat dot com>]

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.