• State
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 155 views
  • Users 0 members are here
Support feedback
Options
Options
Related

PROCESSOR-SDK-AM62P: SELinux Policy Issue with GPIO Control on TI AM62P Android 15

Jack
Mastermind 9265 points
Part Number: PROCESSOR-SDK-AM62P
Other Parts Discussed in Thread: AM62P

Tool/software:

Hi AM62P Android Champ !

This report details a problem encountered while trying to control a GPIO pin on a TI AM62P EVM board running Android 15.

The gpioset command, which works correctly from the console, fails to execute when called from the init.am62x.rc script.

It's suspected that this issue is due to a SELinux policy violation, as the hal_gpio_default domain is unable to access the GPIO device.

Problem Description

The libgiiod library is present in the Android 15 source for the TI AM62P, and standard GPIO commands like gpioinfo, gpioget, and gpioset function as expected from the command line.

Working Command:

gpioset gpiochip2 49=1

This command successfully controls an LED on the EVM board.

Failing Implementation:

A line was added to device/ti/init.am62x.rc to execute this command at boot:

exec u:r:hal_gpio_default:s0 -- /system/bin/gpioset gpiochip2 49=1

However, this command fails to control the LED, indicating a permission issue.

Analysis

The failure is likely due to an SELinux access control violation. The hal_gpio_default domain, which is the context under which the command is executed, does not have the necessary permissions to access and manipulate the /dev/gpiochip2 device.

Attempts to resolve this by adding an SELinux policy in /system/sepolicy/private have resulted in errors, suggesting that the policy rule is either incorrectly formatted or placed.

Request for Assistance

We require guidance on the correct method for creating an SELinux policy that allows the hal_gpio_default domain to execute the gpioset command and control GPIO pins.

Please provide the correct SELinux policy rule and the proper location for it to be integrated into the build system. Additionally, any insights into the specific permissions required for GPIO device access would be greatly appreciated.

Thanks.
Best Regards, 

Jack

  • 0
    TI__Mastermind 18985 points

    Hello,

    Let me re-assign this thread to the android expert. Please allow some time for a response.

    Thanks,

    Anshu

  • 0 in reply to Anshu Madwesh
    TI__Prodigy 210 points

    Hello, I will look at this and get back to you. Thank you.

  • 0
    TI__Prodigy 210 points

    Hi Jack, sorry for the delay,

    The approach of calling gpioset from the vendor init (am62x init rc) is not recommended. vendor code should not exec system partition binaries

    I would need to see your complete hal_gpio_default implementation to verify what has been done to provide better guidance.

    The way I would recommend to set the gpio pin would be to implement an AIDL HAL that exposes a function through a vendor binary which issues ioctl commands to the proper endpoint.

    In that case hal_gpio_default  would be a vendor domain needing access to something like gpio_device:chr_file.

    here is an example of aidl interface:

      @VintfStability
      interface IGpio {
          /**
           * Set GPIO pin value
           * 
           * @param chip GPIO chip device path (e.g., "/dev/gpiochip2")
           * @param line GPIO line number
           * @param value Pin value (0 = LOW, 1 = HIGH)
           */
          void setGpio(in String chip, in int line, in int value);
      }

    The gpio binary program would expose 

    ndk::ScopedAStatus Gpio::setGpio(const std::string& chip, int32_t line, int32_t value) 

    Please share your sepolicies and implementation. gpioset command should not be called directly from the vendor init.