rockpi4 - 5.1.0-rockchip64 - leds


dolphs
 Share

0

Recommended Posts

Hi,

I am running " Linux server 5.1.0-rockchip64 #5.89 SMP Fri Jun 21 13:42:34 CEST 2019 aarch64 GNU/Linux "

and trying to switch off the green light somewhere at " /sys/class/leds/power ", but was unable to find the proper setting to switch it off.

Anyone can give me a hand please? cheers

 

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

I didnt got a rockchip64, so I will show it for you on a Orange Pi One :)

 

root@opi-one(192.168.6.114):~# cd /sys/class/leds
root@opi-one(192.168.6.114):/sys/class/leds# ls -l
total 0
lrwxrwxrwx 1 root root 0 Jul 16 20:52 orangepi:green:pwr -> ../../devices/platform/leds/leds/orangepi:green:pwr
lrwxrwxrwx 1 root root 0 Jul 16 20:52 orangepi:red:status -> ../../devices/platform/leds/leds/orangepi:red:status

Find out the current triger setting - showing in [] = here [mmc0]:
more /sys/class/leds/orangepi:green:pwr/trigger
none rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd
-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport [mmc0] disk-activity disk-read disk-wri
te ide-disk mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 default-on panic 0.1:01:link 0.1:01:100Mbps 0.1:01:10M
bps

Power off the green LED:
echo 'none' > /sys/class/leds/orangepi:green:pwr/trigger

Power on the green LED:
echo 'default-on' > /sys/class/leds/orangepi:green:pwr/trigger

Now you only have to check the name of your green LED and replace that in the commands :)

Link to post
Share on other sites

47 minutes ago, dolphs said:

Anyone can give me a hand please?

On RockPi4B schematic, the green led is permanently connected to +5V thru R12.

To make is controllable from SoC, that R12 needs to be unsoldered and a new R13 with 1K value should be added.

If you just wish to get rid of it, the leds can easily be broken ...

Link to post
Share on other sites

1 hour ago, martinayotte said:

On RockPi4B schematic, the green led is permanently connected to +5V thru R12.

To make is controllable from SoC, that R12 needs to be unsoldered and a new R13 with 1K value should be added.

If you just wish to get rid of it, the leds can easily be broken ...

The green light is way to bright, how do you brake it?

Link to post
Share on other sites

they should probably use a higher resistor for this one.. I never got why they didn't made it controllable especially when everything was there to make it. @hipboi any plans to fix it in the next revision of the board? I happily adjust the DT patch (which is gone anyway). ;)Btw. the current RockPi dts has no LEDs configured at all if I see this correctly..

Link to post
Share on other sites

wow - it seems this was not such a strange question after all, cheers for your response !

 

11 hours ago, guidol said:

I didnt got a rockchip64, so I will show it for you on a Orange Pi One :)

 

Based on that I was trying to find my way on this board, but yet it appears it is a feature request which will be sorted in one of the next revisions.

I assume upgrading to dev image to 5.2 will be mandatory to benefit from this. This won't be an issue , but next three weeks I am unable to test so I will check back in August.

cheers!

Link to post
Share on other sites

Instead of breaking the (bright) onboard LED's it might be a good idea to use some small piece of black tape.
 

This topic is interesting because I'm also currently working on LEDs on the RockPi. The very bright green LED is very well suited to make the logo appear in a 3d-printed case. But it can only light up in one colour.

RockPi_LogoLED.png.85314347d3c5f64cd50d51ec825c1d0e.png


A first problem arises when the M.2 NVME adapter board is screwed on top and hides the green light. 
I could connect an RGB LED (cathode) to the GPIOs. But it would need 3 digital (PWM) pins.  

So I looked at the small WS2812 LED modules.
WS2812_RGB_Led.png.dc6b218fb9b62b8a804862a809389662.png

The existing libraries are made for RPi boards with either PWM, PCM or SPI-MISO

As SPI1 on RockPi is used for the SPI-Flash and boot functionality, I tried to enable SPI2 and use Pin 29 (TXD) to generate the serial bit sequence for the WS2812 chips.

 

With the Help of @martinayotte 

...I was able to activate I2C (which in newer releases now is enabled by default) and fill the OLED devices with the LUMA library.

 

But whatever I tried - by using the current stable or nightly Armbian Bionic build - I wasn't able to se /dev/spi* devices or use them in any other way.

TBH I'm not an expert and have no clear idea what of the following things should or must play together and what are different approaches that shouldn't be mixed.

First I tried to enable SPI in the decompiled .dts file like I did with the I2C port

status = "okay";

compatible = "spidev";

spi-max-frequency = <1000000>;


then I also tried to install libmraa and turn on SPI switches in /boot/hw_intfc.conf as described in https://wiki.radxa.com/Rockpi4/dev/libmraa
 

I guess many other approaches like a layer acting as an universal SBC GPIO library like 

or also https://github.com/rahul-thakoor/rust_gpiozero still require the SPI* devices enabled and working at OS level.

 

I also tried to look into documentations like http://linux-sunxi.org/SPIdev and adopt it to the RockPi specs, but no luck.

So for now it looks more like I must consider to keep my project simple (static green LED and no covering NVME) or I try to get some hints here in this forum...

 

Link to post
Share on other sites

12 hours ago, gufmar said:

As SPI1 on RockPi is used for the SPI-Flash and boot functionality, I tried to enable SPI2

I've committed fixes for Rockchip SPI overlays in DEV branch, I've got SPI2 working on my RockPi4B ...

 

EDIT: Tested also on my OPi-RK3399 and RockPro64 ...

EDIT2: beware, it seems that any speed lower than 10MHz is not allowed ...

Link to post
Share on other sites

22 hours ago, martinayotte said:

I've committed fixes for Rockchip SPI overlays in DEV branch, I've got SPI2 working on my RockPi4B ...

 

This sounds great! So I while waiting the setup of my new armbuilder vm, I read through the https://docs.armbian.com/Developer-Guide_Build-Process/ and https://docs.armbian.com/Developer-Guide_Build-Options/ and wonder if I need some special options set or if I can just go with defaults?

(I checked out the build repo after your two commits, but as far as I can see it's master, not DEV branch)

 

Link to post
Share on other sites

56 minutes ago, martinayotte said:

Did you build a new image with my latest fixes ?

yes. First kernel compilation in my life, worked fine, with expert mode (at least afaik for now ;- )

 

56 minutes ago, martinayotte said:

Did you enabled spi-spidev overlay in /boot/armbianEnv.txt ?

no, will do this evening. I wasn't sure if I need to do this as for I2C in the dts/dtb file (okay) or somewhere else.
Thanks.

Link to post
Share on other sites

On 7/24/2019 at 11:53 PM, martinayotte said:

EDIT2: beware, it seems that any speed lower than 10MHz is not allowed ...

Is this something related to the overlay file, or where do I have the chance to play with this value?


By using the python spidev library I can set something like spi.max_speed_hz=10000000
But I can't see any effect.

Also spi.xfer has some factor and it looks like it depends a bit on the HW, wiring and CPU components

 

    spi.xfer(tx.tolist(), int(4/1.25e-6)) #works, on Zero (initially didn't?)
    #spi.xfer(tx.tolist(), int(4/1.20e-6))  #works, no flashes on Zero, Works on Raspberry 3
    #spi.xfer(tx.tolist(), int(4/1.15e-6))  #works, no flashes on Zero
    #spi.xfer(tx.tolist(), int(4/1.05e-6))  #works, no flashes on Zero
    #spi.xfer(tx.tolist(), int(4/.95e-6))  #works, no flashes on Zero
    #spi.xfer(tx.tolist(), int(4/.90e-6))  #works, no flashes on Zero
    #spi.xfer(tx.tolist(), int(4/.85e-6))  #doesn't work (first 4 LEDS work, others have flashing colors)
    #spi.xfer(tx.tolist(), int(4/.65e-6))  #doesn't work on Zero; Works on Raspberry 3
    #spi.xfer(tx.tolist(), int(4/.55e-6))  #doesn't work on Zero; Works on Raspberry 3
    #spi.xfer(tx.tolist(), int(4/.50e-6))  #doesn't work on Zero; Doesn't work on Raspberry 3 (bright colors)
    #spi.xfer(tx.tolist(), int(4/.45e-6))  #doesn't work on Zero; Doesn't work on Raspberry 3

when I change the timing I can see best (but not perfect) results with 4/.70e-6

As this code example also mentions (first 4 LEDS work) I can only drive the first two LEDs - whatever value I try.

 

So I wonder if the "base frequency" is set to the optimal value and how I can cange it (without having at hand a singal analyzer to verify)
 

 

 

 

Link to post
Share on other sites

1 hour ago, gufmar said:

I can set something like spi.max_speed_hz=10000000

The limitation I saw was using spi_text.c, where any speed lower than 10000000 was returning a timeout error on RK3399, which doesn't on AllWinner such A64 or H3.

1 hour ago, gufmar said:

spi.xfer(tx.tolist(), int(4/1.25e-6))

I'm not following you here : the second argument of spi.xfer is the data buffer size, not the speed ...

Link to post
Share on other sites

On 7/24/2019 at 12:16 PM, gufmar said:

Instead of breaking the (bright) onboard LED's it might be a good idea to use some small piece of black tape.

 

How far are things atm, is it possible to " switch off "

or should I go to one of the DIY chains and grab some black tape instead ;)

Link to post
Share on other sites

11 minutes ago, dolphs said:

 

How far are things atm, is it possible to " switch off "

or should I go to one of the DIY chains and grab some black tape instead

 

 

on the available versions there won't be a off switch. See the third answer you got when the thread started.

On 7/18/2019 at 10:08 PM, martinayotte said:

On RockPi4B schematic, the green led is permanently connected to +5V thru R12.

To make is controllable from SoC, that R12 needs to be unsoldered and a new R13 with 1K value should be added.

If you just wish to get rid of it, the leds can easily be broken ...

 

 

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

0