PROCESSOR-SDK-AM437X: PRU hardware spinlock issue

Hello Kang,

1) What is your PRU code for accessing the Spinlock register?

2) Why are you adding the Spinlock to the PRU Resource table? As long as your PRU code enables the OCP master port, I would expect you to be able to write to the spinlock registers. In your Linux Processor SDK, see example-applications/pru-icss-x.x/examples/am437x/PRU_RPMsg_... examples for an example of how to enable the OCP master port.

Regards,

Nick

Hi Nick, 

Thanks for your reply.

Nick Saulnier said:

1) What is your PRU code for accessing the Spinlock register?

typedef struct {
    volatile uint32_t rev;
    volatile uint32_t reserved0[(0x10-0x04)/4];
    volatile uint32_t sysconfig;
    volatile uint32_t status;
    volatile uint32_t reserved1[(0x800-0x18)/4];
    volatile uint32_t lock[LOCK_REG_NUM];
} sys_hwspinlock_t;

static sys_hwspinlock_t *hwspinlock = ((sys_hwspinlock_t *)0x480CA000);
void hwspinlock_init(void)
{
    hwspinlock->sysconfig |= SPINLOCK_SYSCONFIG_SOFTRESET;  
    while (!(hwspinlock->status & SPINLOCK_SYSSTATUS_RESETDONE));
}

int hwspinlock_trylock(uint32_t id)
{
    return hwspinlock->lock[id];
}

int hwspinlock_unlock(uint32_t id)
{
    hwspinlock->lock[id] = SPINLOCK_NOTTAKEN ;
    return 0;
}
...

Nick Saulnier said:

2) Why are you adding the Spinlock to the PRU Resource table?

I think the reason of the kernel warning is PRU tries to access L4_PER_1 but kernel blocks it, so it is needed to tell the kernel to grant the right by resource table. 

Nick Saulnier said:

As long as your PRU code enables the OCP master port, I would expect you to be able to write to the spinlock registers. In your Linux Processor SDK, see example-applications/pru-icss-x.x/examples/am437x/PRU_RPMsg_... examples for an example of how to enable the OCP master port.

Is it correct to enable the OCP master by " CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;"?

If it is right, I have done it. 

Regards,

George Kang

Hello George,

Yes, that should enable the OCP master port.

"L3 Custom Error: MASTER ICSS1 TARGET L4_PER_1 (Read): Data Access in User mode during Functional access" - This error does not necessarily mean that Linux is blocking the PRU from reading something. I have seen that error before if a peripheral's clock sources have not been properly initialized.

Try using a resource table where L4_PERIPHERAL_L4PER1 is not defined. If you are still running into errors, try reading the spinlock from the command line with devmem2 to see if you get the same issues when reading/writing from Linux.

Regards,

Nick

Hi Nick, 

Which type of fw_rsc shall be used?

Here is the header about the resource table but it does not work.

struct my_resource_table {
        struct resource_table base;

        uint32_t offset[1]; /* Should match 'num' in actual definition */
        struct fw_rsc_devmem l4_perp1;
};

#pragma DATA_SECTION(pru_remoteproc_ResourceTable, ".resource_table")
#pragma RETAIN(pru_remoteproc_ResourceTable)
struct my_resource_table pru_remoteproc_ResourceTable = {
        1,      /* we're the first version that implements this */
        1,      /* number of entries in the table */
        0, 0,   /* reserved, must be zero */
        {
            offsetof(struct my_resource_table, l4_perp1),
        },
        {
                TYPE_DEVMEM,
                L4_PERIPHERAL_L4PER1, L4_PERIPHERAL_L4PER1,
                SZ_2M, 0, 0, "PRU_PERIPHERAL_L4PER1",
        },
};

Hello George,

I would start by copying the empty resource table in your Linux Processor SDK, see example-applications/pru-icss-x.x/examples/am437x/PRU_Halt/resource_table_empty.h

Regards,

Nick