Re: [Xen-devel] Bringing up sequence for non-boot CPU fails

[Andrii Anisov <andrii.anisov@xxxxxxxxxxxxxxx>]

> +GLOBAL(enter_hyp_mode)
> +enter_hyp_mode:
> +        adr   r0, save
> +        stmea r0, {r4-r13,lr}
> +        ldr   r12, =0x102
> +        adr   r0, hyp_return
> +        dsb
> +        isb
> +        dmb
> +        smc   #0

Who/what implements this handler?

Ian, this handler is implemented by ROM code, and this is the common OMAP sequence to switch to HYP mode. On our side we decided to leave switch to hyp in XEN for now.

Do you have any hardware debugging tools which could give some insight?

 

Yep, we have one (TI's Code Composer Studio with STM560v2 JTAG) but it has no proper HYP mode debug support yet, TI says it will have in 6 months or so :( So we the only thing we can do with it is stop CPU at some moment and see some registers, no breakpoints or stepping.

What we discovered yet is that the last command executed by CPU1 before hang is 

mcr   CP32(r0, HSCTLR)       /* now paging is enabled */

After this PC contains 0x00000004, CPSR.M is b11010 what is HYP mode, not abort.

It looks like we have broken MMU translation.

Usually these things are down to either missing cache flushes or barriers, but tracking them down has historically been a total pain.

I suspected missing flushes during CPU1 MMU tables preparation but that code looks correct, I do not see any issues there.

Andrii Anisov | Software Engineer
GlobalLogic

Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664  M +380505738852  S andriyanisov
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

On Tue, Feb 18, 2014 at 2:14 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

On Tue, 2014-02-18 at 13:44 +0200, Oleksandr Tyshchenko wrote:

> +GLOBAL(enter_hyp_mode)
> +enter_hyp_mode:
> +        adr   r0, save
> +        stmea r0, {r4-r13,lr}
> +        ldr   r12, =0x102
> +        adr   r0, hyp_return
> +        dsb
> +        isb
> +        dmb
> +        smc   #0

Who/what implements this handler?

> +hyp_return:
> +        adr   r0, save
> +        ldmfd r0, {r4-r13,pc}
> +save:
> +        .rept 11
> +        .word 0
> +        .endr
> +
>  /*
>   * Local variables:
>   * mode: ASM
>
>
> Please, could anyone give me advice about this issue?

Do you have any hardware debugging tools which could give some insight?

Usually these things are down to either missing cache flushes or
barriers, but tracking them down has historically been a total pain.

>  And what do you
> think about solution to exit from busy loop by timeout and restart
> CPU1 bringing up sequence in this case?

A timeout isn't a bad idea, although I would not be inclined to try
again with the CPU in an indeterminate state.

Either we should carry on without it or we should panic (which is more
obvious than a hang). I think carrying on would be surprising (you'd
only get half the processing power you expected).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel