SK-AM62B-P1: Android: Modify device tree to test "User LED"

Hello,

I'm not familiar with Android so I'll help where I can.

This would help with understanding the device tree LED node: git.ti.com/.../common.yaml

Alexandre Baptista said:

I want to enable the "USER Test LED 1" I'm still confused on how/where to modify the device tree files.

There is no modification required for this LED. It should be on when the board boots.

Alexandre Baptista said:

Modifying the property "default-state" to "on" is enough to achieve this?

It shouldn't be required as stated before.

Alexandre Baptista said:

What does the "LED_FUNCTION_HEARTBEAT" do here?

'LED_FUNCTION_HEARTBEAT' is just a pre-defined macro. The heartbeat function simply turns on the LED in the pattern of a heart beating.

Alexandre Baptista said:

And finally, do I have to rebuild everything (kernel/bootloader/android) after every change I make?

For just modifying the device tree, you'll only need to re-compile the dtb.

I will get someone else to comment on the Android specifics.

Best Regards,

Anshu

Thanks for the quick response.

The "LD1" LED is not turned on and it's not doing the heartbeat effect, so I think it's not turning on by default.

Will wait for the Android specific help.

So I just need to re-compile the dtb file and then reflash the eMMC with the ./flashall.. command?

Hi Alexandre,

After rebuilding the kernel, make sure to also rebuild the `boot.img` with `make bootimage`

The dtb is part of a dtb.img:
https://git.ti.com/cgit/android/device-ti-am62x/tree/build/tasks/dtimages.mk?h=d-android14-release#n16

This dtb.img is merged into the android boot.img file as controlled by this variable:
https://git.ti.com/cgit/android/device-ti-am62x/tree/BoardConfig-common.mk?h=d-android14-release#n113

So rebuilding the kernel followed by the boot.img should be sufficient.

Hope that helps,
Mattijs

And after rebuilding the kernel I need to rebuild the Android image?

Ok, your solution worked. When I check the device tree files, I see that the changes were applied, however, the LD1 is still turned off.

yes

Can you maybe experiment with the sysfs interface to see which leds you can control?

There should be some leds in `/sys/class/leds` which you could control via standard sysfs interface

Sorry for the wait.

In the /sys/class/leds I only find these entries:

console:/sys/class/leds # ls -l
total 0
lrwxrwxrwx 1 root root 0 2024-03-18 20:10 mmc0:: -> ../../devices/platform/bus@f0000/fa10000.mmc/leds/mmc0::
lrwxrwxrwx 1 root root 0 2024-03-18 20:10 mmc1:: -> ../../devices/platform/bus@f0000/fa00000.mmc/leds/mmc1::
lrwxrwxrwx 1 root root 0 2024-03-18 20:10 mmc2:: -> ../../devices/platform/bus@f0000/fa20000.mmc/leds/mmc2::

And when I try to change some values on any of them like this:

console:/sys/class/leds # echo 255 > mmc0\:\://brightness                      

console:/sys/class/leds # cat mmc0\:\:/brightness                            
255

None of the LEDS light up. Is there a better way to test?

Great, glad you solved your issue and thank you for sharing your experience.