AM623: GPIO in M4FSS MCU can not be accessed from A53

Hi SI,

Sung-IL said:

My customer has a trouble to access GPIO in M4FSS from A53 core in their custom board when linux boot-up.

Can you please describe what the trouble is?

Sung-IL said:

GPIO in M4SS can be accessed from A53 core after R5 core of device manager was un-loaded in remote proc.

I am not sure I understand this case in which GPIO is accessible, can you please elaborate?

Sung-IL said:

Do you think this issue caused by default setting for HSFS device in Linux SDKv8.6.0 and this issue can be resolved when below patch will be applied?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1210443/faq-am625-generating-sitara-am62x-am62ax-am64x-gp-device-bootable-mmc-sd-card-images-using-sdk-v8-6-and-yocto?tisearch=e2e-sitesearch&keymatch=am62x%20AND%20gp%20AND%20sdk#

I doubt it. The description in the link is about R5 SPL in U-Boot, it is unlikely related to Linux.

Hi Bin,

I meant all GPIOs of M4FSS can not be accessed by A53 core in Linux SDK v8.6.0 after booting and kernel loading, and then the same GPIO of M4FSS can be accessed by A53 core after un-loading R5 core of device manager in remote proc.

it looks R5 core of device manager own all GPIOs of M4FSS after boot-up and I'm curious why R5 core of device manager own M4FSS resources.

Is there any relations between R5 core and M4F SS after boot-up in linux SDK?

Thanks and Best Regards,

SI.

Hi SI,

Sung-IL said:

I meant all GPIOs of M4FSS can not be accessed by A53 core in Linux SDK v8.6.0 after booting and kernel loading,

I still don't understand what the failure is. Please provide the procedure of the access and log showing the issue.

Sung-IL said:

after un-loading R5 core of device manager in remote proc.

Please provide the procedure and log showing how the "un-loading" has been done.

Hi Bin,

When they run their below test code in driver level, 

errors were occurred as below.

~~~~~

[    0.689685] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#0

[    0.696370] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#1

[    0.703046] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#2

[    0.709721] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#3

[    0.716401] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#4

:

:

[    4.154176] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#507

[    4.161028] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#508

[    4.167880] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#509

[    4.174732] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#510

[    4.181583] [kisan_gpio_intr.c: 235:TestGpio] Failed to request gpio#511

~~~~~

When they unload R5 core of device manager  as below, they found above errors were removed.

Thanks and Best Regards,

SI.

Hello SI,

Bin is out today, so I will be commenting from the remoteproc side (not the GPIO side).

First off, please note what AM62x R5F core is doing: it is running the device manager software for the processor. That means the A53 cannot actually shut down the R5F core. So when you do "echo detach", that does not actually change anything from the R5F side - it just means that Linux is no longer aware of whether the R5F core is running.

And when I check the default Linux board config settings for AM62x, the MCU GPIO interrupts are not even allocated for R5F core.

Here is WKUP MCU GPIO Interrupt router outputs allocated to Linux A53:

And the same section, but with 0 outputs allocated for R5F:

So I would not expect that Linux remoteproc driver detaching from the still-running R5F would change anything with regards to GPIO.

Do you have a way for us to see in a single terminal capture, the GPIO requests not working, then the remoteproc driver detaching, and then the working GPIO requests? Maybe that could help with debug.

Regards,

Nick

Hi, 

It seems below gpio API were not worked properly in U-Boot/Kernel code environments. Could you please let them know how they can use these gpio API?

- gpio_request, gpio_direction_output, gpio_set_value, gpio_get_value, etc.

When they tried to control gpio directly in low-level without using above APIs, they succeed to control gpio well. this is not related with attaching/detaching R5 core.

When they tried to built-in below gpio probe function in kernel, they faced fails for all GPIOs.

But, when they tried to implement gpio probe function in kernel module, they succeeded as below.

Could you please check below boot log?

7080.bootlog.txt

Their gpio_probe() function used in their test is as below.

static int gpio_handler_probe(struct platform_device *pdev)
{
    struct StructGpioHandlerData *pdata = NULL;
    int nErr = 0;

    int nIrq = 0;
    int i = 0;

    pdata = devm_kzalloc(&pdev->dev, sizeof(struct StructGpioHandlerData), GFP_KERNEL);
    if(!pdata) {
        printk(KERN_ERR "[%s:%4d] Failed to devm_kzalloc...\n", __FILENAME__, __LINE__);
        return -ENOMEM;
    }

    pdata->pdev = pdev;
    pdata->mdev.minor = MISC_DYNAMIC_MINOR;
    pdata->mdev.name = "gpio_handler";
    pdata->mdev.fops = &gpio_handler_fops;

    nErr = misc_register(&pdata->mdev);
    if(nErr) {
        dev_err(&pdev->dev,"failed to register misc device\n");
        devm_kfree(&pdev->dev, pdata);
        return nErr;
    }
    
    platform_set_drvdata(pdev, pdata);

    for(i = 0 ; i < 512 ; i++)
    {
        if(gpio_is_valid(i))
        {
            //gpio_request_one(i, GPIOF_IN, "TEST");
            if(devm_gpio_request(&pdev->dev, i, "TEST") < 0)
            {
                printk(KERN_ERR "[%s:%4d] Failed to gpio(%d)_request...\n", __FILENAME__, __LINE__, i);
                continue;
            }

            nIrq = gpio_to_irq(i);
            if (nIrq < 0)
            {
                printk(KERN_ERR "[%s:%4d] Failed to gpio(%d)_to_irq(%d).\n", __FILENAME__, __LINE__, i, nIrq);
            }
            else
            {
                printk(KERN_ERR "[%s:%4d] ***********************************gpio(%d)_to_irq(%d).\n", __FILENAME__, __LINE__, i, nIrq);
            }   
        }
        else
        {
            printk(KERN_ERR "[%s:%4d] Failed to gpio(%d)_is_valid.\n", __FILENAME__, __LINE__, i);
        }
    }

   printk(KERN_DEBUG "[%s:%4d] Registered gpio_handler char driver. \n", __FILENAME__, __LINE__);

    return 0;
}

Thanks and Best Regards,

SI.