[U-Boot] mx25pdk does not boot with 3ff46cc42b9d7

[U-Boot] mx25pdk does not boot with 3ff46cc42b9d7

[Fabio Estevam]

Hi,

I noticed that mx25pdk (ARM926) does not boot anymore with top of tree U-boot.

Doing a git bisect resulted in the following commit as being the guilty one:

commit 3ff46cc42b9d73d01c86df904425704410958470
Author: Georges Savoundararadj <savoundg@gmail.com>
Date:   Tue Oct 28 23:16:11 2014 +0100

    arm: relocate the exception vectors

    This commit relocates the exception vectors.
    As ARM1176 and ARMv7 have the security extensions, it uses VBAR.  For
    the other ARM processors, it copies the relocated exception vectors to
    the correct address: 0x00000000 or 0xFFFF0000.

    Signed-off-by: Georges Savoundararadj <savoundg@gmail.com>
    Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
    Cc: Tom Warren <twarren@nvidia.com>

Any ideas?

Thanks

[U-Boot] mx25pdk does not boot with 3ff46cc42b9d7

[Bill Pringlemeir]

On  5 Jan 2015, festevam at gmail.com wrote:

> I noticed that mx25pdk (ARM926) does not boot anymore with top of tree
> U-boot.
>
> Doing a git bisect resulted in the following commit as being the
> guilty one:
>
> commit 3ff46cc42b9d73d01c86df904425704410958470
> Author: Georges Savoundararadj <savoundg@gmail.com>
> Date:   Tue Oct 28 23:16:11 2014 +0100
>
> arm: relocate the exception vectors
>
> This commit relocates the exception vectors.
> As ARM1176 and ARMv7 have the security extensions, it uses VBAR.  For
> the other ARM processors, it copies the relocated exception vectors to
> the correct address: 0x00000000 or 0xFFFF0000.
>
> Signed-off-by: Georges Savoundararadj <savoundg@gmail.com>
> Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
> Cc: Tom Warren <twarren@nvidia.com>
>
> Any ideas?

$ git show 3ff46cc42b9d73d01c86df9044257

/*
 * Default/weak exception vectors relocation routine
 *
 * This routine covers the standard ARM cases: normal (0x00000000),
 * high (0xffff0000) and VBAR. SoCs which do not comply with any of
 * the standard cases must provide their own, strong, version.
 */

The code looks correct.  However, the imx25 has the HAB and some default
vectors set up.  Do you assume they overwrite the HAB vectors?  For the
imx25, the 'V bit = 0' for the physical HAB ROM location, but it can be
remapped to 0xffff0000.  However, there is nothing there (0xffff0000)
initially and this only makes sense with the MMU enabled.

I am not sure what happened before; why it worked.  Maybe you could
define an empty relocate_vectors() in the imx25 board file and see if
everything is ok?  I don't think that a write to the ROM code will BUS
error?  If a write BUS errors, then the empty routine will work/boot.
However, u-boot will not be handling the vectors unless we hook in the
IRAM at 0x7801FFFF, where I guess the ROM code (at address zero)
branches too.

Fwiw,
Bill Pringlemeir.

[U-Boot] mx25pdk does not boot with 3ff46cc42b9d7

[Fabio Estevam]

Hi Bill,

On Mon, Jan 5, 2015 at 8:25 PM, Bill Pringlemeir <bpringlemeir@nbsps.com> wrote:

> $ git show 3ff46cc42b9d73d01c86df9044257
>
> /*
>  * Default/weak exception vectors relocation routine
>  *
>  * This routine covers the standard ARM cases: normal (0x00000000),
>  * high (0xffff0000) and VBAR. SoCs which do not comply with any of
>  * the standard cases must provide their own, strong, version.
>  */
>
> The code looks correct.  However, the imx25 has the HAB and some default
> vectors set up.  Do you assume they overwrite the HAB vectors?  For the
> imx25, the 'V bit = 0' for the physical HAB ROM location, but it can be
> remapped to 0xffff0000.  However, there is nothing there (0xffff0000)
> initially and this only makes sense with the MMU enabled.
>
> I am not sure what happened before; why it worked.  Maybe you could
> define an empty relocate_vectors() in the imx25 board file and see if
> everything is ok?  I don't think that a write to the ROM code will BUS
> error?  If a write BUS errors, then the empty routine will work/boot.
> However, u-boot will not be handling the vectors unless we hook in the
> IRAM at 0x7801FFFF, where I guess the ROM code (at address zero)
> branches too.

I have just fixed by using the same approach done on mx27 with its own
relocate.S:
arch/arm/cpu/arm926ejs/mx27/relocate.S

Will submit the patch shortly.

Thanks