This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6548: AARCH32 mode of Cortex-A53

Part Number: AM6548

Hi,

I need to use the AARCH32 execution mode for Cortex-A53. I have modified the SBL source like below (RED color indicates modifications) and able to switch the execution mode from default AARCH64 to required AARCH32.

File: sbl_slave_core_boot.c
Function: SBL_SlaveCoreBoot()
---

proc_set_config_req.processor_id = sblSlaveCoreInfoPtr->tisci_proc_id;
proc_set_config_req.bootvector_lo = pAppEntry->CpuEntryPoint[core_id];
proc_set_config_req.bootvector_hi = 0x0;
proc_set_config_req.config_flags_1_set = 0;
proc_set_config_req.config_flags_1_clear = 0;

/* For Cortex-A53 CPUs, set the execution mode to AARCH32 */
if ( (core_id == MPU1_CPU0_ID) || (core_id == MPU1_CPU1_ID) || (core_id == MPU2_CPU0_ID) || (core_id == MPU1_CPU1_ID) )
{
    proc_set_config_req.config_flags_1_set |= TISCI_MSG_VAL_PROC_BOOT_CFG_FLAG_ARMV8_AARCH32;
}

if (pAppEntry->CpuEntryPoint[core_id] < SBL_INVALID_ENTRY_ADDR) /* Set entry point only is valid */

---

My questions are:
Q1)  Do I need to consider any other modification to boot the Cortex-A53 cores in AARCH32 mode?
Q2)  Is there any example app (like k3MulticoreApp) for AARCH32 mode instead of AARCH64?
Q3)  After connecting to the Cortex-A53_cluster0_core0 via JTAG, I am not being able to set the GIC's ICC_SRE to enable access to the CPU interface of GIC. I have used the following code in my reset vector e.g.

---

mov   r0, #7
mcr  p15, 0, r0, c12, c12, 5  /* Write r0 to ICC_SRE */

---

The above statements are not being able to set concerned bits in ICC_SRE. Any idea? Any help is highly appreciated.

Regards,

Hasan 

 

  • Hasan,

    For clarity can you give some guidance on the need for AARCH32 specifically? Are you looking to run legacy binaries?

    We have not verified in the default Processor SDK software. The initialization should get the cores properly in the AARCH32 mode, however, the code snippet you provided does seem to have a typo “(core_id == MPU1_CPU0_ID) || (core_id == MPU1_CPU1_ID) || (core_id == MPU2_CPU0_ID) || (core_id == MPU1_CPU1_ID)”, has MPU1_CPU1_ID twice. This may have simply been an error in the post, but please check.

    We will look further into any dependencies that we are aware of.

    Best regards,

    Dave

  • Hi Dave,

    Thanks a lot for your reply.

    > For clarity can you give some guidance on the need for AARCH32 specifically? Are you looking to run legacy binaries?
    Yes. The kernel I need to run on A53 cores, does not support AARCH64. I must run on AARCH32 mode.

    > has MPU1_CPU1_ID twice.
    Yeah. Thanks to the correction.

    Any example application for CA53 in AARCH32 mode can help me to verify the operation of CA53 in AARCH32 (like k3MulticoreApp).

    Best regards,

    Hasan

  • Hi Dave,

    I have solved the GIC's ICC_IRE read issue.

    >>Q3)  After connecting to the Cortex-A53_cluster0_core0 via JTAG, I am not being able to set the GIC's ICC_SRE to enable access to the CPU interface of GIC. I have used the following code in my reset vector e.g.

    >> mov   r0, #7

    >> mcr  p15, 0, r0, c12, c12, 5  /* Write r0 to ICC_SRE */

    Basically, I needed to enable ICC_MSRE first before accessing ICC_SRE register. I did it in the following way and everything is working. And I would like to inform you that I am able run my proprietary RTOS on AM65x IDK board.

    /* GIC-500 */
    /* Set system register enable (SRE) for all relevant exception levels */

    /* Switch to Monitor mode to access ICC_MCRE.
    When booting in AArch32 mode, processors
    enter secure Supervisor mode after reset */

    cps #0x16

    /* Enable system register access for EL3 and
    allow lower exception levels to configure
    the same for themselves */

    mov r0, #0xf

    mcr p15, 6, r0, c12, c12, 5 /* ICC_MSRE */
    isb
    mcr p15, 0, r0, c12, c12, 5 /* ICC_SRE(S) */

    Thanks,

    Hasan 

  • Hasan,

    Thank you for your update and confirmation. I'm glad to see you have it now working.

    Best regards,

    Dave

  • Dave Bell said:

    Hasan,

    Thank you for your update and confirmation. I'm glad to see you have it now working.

    Best regards,

    Dave

    Thanks, Dave. Now I am closing this thread.