• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 3264 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM3352: LED control in U-boot

Angel Falcon
Expert 1160 points
Part Number: AM3352

Hello,

We are using am3352 in our design with kernel 4.14.67 and U-Boot version 2019.01 from TI SDK.

We have four leds we can control from linux system and we are using "gpio-leds" driver.

Now we also want to control these leds from U-boot and we are trying to use the same "gpio-leds" driver. For this we added to "our_board.dts"

    leds {
        pinctrl-names = "default";
        pinctrl-0 = <&user_leds_sw>;
        compatible = "gpio-leds";

        yellow {
            label = "ledsw0:yellow";
            gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
            default-state = "off";
        };
        green {
            label = "ledsw1:green";
            gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
            default-state = "off";
        };
        red {
            label = "ledsw2:red";
            gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
            default-state = "off";
        };
        orange {
            label = "ledsw3:orange";
            gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
            default-state = "off";
        };
    };

    user_leds_sw: user_leds_sw {
        pinctrl-single,pins = <
            0x03c (PIN_INPUT_PULLUP | MUX_MODE7)    /* (U13) gpmc_ad15.gpio1_4 */
            0x1e4 (PIN_INPUT_PULLUP | MUX_MODE7)    /* (C14) emu0.gpio3_7 */
            0x13c (PIN_INPUT_PULLUP | MUX_MODE7)    /* (L15) gmii1_rxd1.gpio2_20 */
            0x034 (PIN_INPUT_PULLUP | MUX_MODE7)    /* (R12) gpmc_ad13.gpio1_13 */
        >;
    };

And also to "our_ defconfig_file"

CONFIG_CMD_LED=y
CONFIG_LED=y
CONFIG_LED_GPIO=y

After this, leds seem to be defined:

=> led list
ledsw0:yellow   <inactive>
ledsw1:green    <inactive>
ledsw2:red      <inactive>
ledsw3:orange   <inactive>

But when I try to set/reset/toggle any of these LEDs none of them change the status:

=> led ledsw0:yellow on
ledsw0:yellow   <inactive>
ledsw1:green    <inactive>
ledsw2:red      <inactive>
ledsw3:orange   <inactive>
=> led ledsw0:yellow off
ledsw0:yellow   <inactive>
ledsw1:green    <inactive>
ledsw2:red      <inactive>
ledsw3:orange   <inactive>
=> led ledsw0:yellow toggle
ledsw0:yellow   <inactive>
ledsw1:green    <inactive>
ledsw2:red      <inactive>
ledsw3:orange   <inactive>

Could you please help us to solve this issue?

Best regards

Angel

  • 0
    TI__Guru 69542 points

    Angel,

    I've never used that LED driver/command, but it seems like you would be relying on the pinmux to be done via device tree. This can only happen if you have the proper drivers enabled (CONFIG_PINCTRL=y and CONFIG_PINCTRL_SINGLE=y), or if you do the pinmux in your platform/board files. You can use the U-Boot md command at U-Boot prompt in conjunction with the AM335x TRM to check the peripheral registers of both pinmux and GPIO modules while issuing "led" commands to see what might be missing.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Expert 1160 points

    Hello Andreas,

    Thank you for your response.

    I do pinmux of these PINs in our platform/board files and I have added CONFIG_PINCTRL=y and CONFIG_PINCTRL_SINGLE=y, but still have the same problem.

    I can use "gpio" command at U-Boot prompt to set/clear/toggle PINs, so I think PIN access configuration is correct.

    The problem seems to be that the driver is <inactive>, as shown when I want to change any led status.

    I have checked led.c the source code and when calling "if (device_active(dev)" it returns FALSE because DM_FLAG_ACTIVATED is not set, but I can not find the reason for this.

    Best regards and thank you

    Angel

  • 0 in reply to Angel Falcon
    TI__Guru 69542 points

    Angel,

    it looks like in order to get the LEDs probed and into a usable state you need to manually call led_default_state() during a suitable place in your initialization sequence such as during board_init() which gets invoked shortly after when DM will be up after U-Boot self-relocated. That function will then execute a device_probe() call on each LED which should get things going and ready for you to use the command. There are a few platforms in U-Boot doing that like this (just search for led_default_state):

    $ git grep -C 4 led_default_state board/sandbox
board/sandbox/sandbox.c-
board/sandbox/sandbox.c-int board_init(void)
board/sandbox/sandbox.c-{
board/sandbox/sandbox.c-        if (IS_ENABLED(CONFIG_LED))
board/sandbox/sandbox.c:                led_default_state();
board/sandbox/sandbox.c-
board/sandbox/sandbox.c-        return 0;
board/sandbox/sandbox.c-}
board/sandbox/sandbox.c-

    Please let me know if that helps.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Expert 1160 points

    Hello Andreas,

    Thank you very much for your help. That was the issue!!!!

    Now it is working fine.

    Best regards

    Angel

  • 0 in reply to Angel Falcon
    TI__Guru 69542 points

    Angel,

    Angel Falcon said:

    That was the issue!!!!

    Now it is working fine.

    Thanks for closing the loop here and good to know it can be made work. Now I may try this myself sometime to add LED control to some U-Boot boot scripts...

    Regards, Andreas