dolphs Posted July 18, 2019 Posted July 18, 2019 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
guidol Posted July 18, 2019 Posted July 18, 2019 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
martinayotte Posted July 18, 2019 Posted July 18, 2019 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 ...
soerenderfor Posted July 18, 2019 Posted July 18, 2019 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?
martinayotte Posted July 18, 2019 Posted July 18, 2019 17 minutes ago, soerenderfor said: The green light is way to bright, how do you brake it? Most probably with a knife, pressed right in the middle of the led, it should brake easily...
chwe Posted July 19, 2019 Posted July 19, 2019 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..
hipboi Posted July 19, 2019 Posted July 19, 2019 ok, we will fix in the next revision. Both led should be controllable, the green should be used for power indicator on hardware and after software running can also control it by gpio.
dolphs Posted July 19, 2019 Author Posted July 19, 2019 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!
martinayotte Posted July 19, 2019 Posted July 19, 2019 9 hours ago, hipboi said: Both led should be controllable So, those resistors configs will be reversed ?
gufmar Posted July 24, 2019 Posted July 24, 2019 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. 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. 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...
martinayotte Posted July 24, 2019 Posted July 24, 2019 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 ... 1
gufmar Posted July 25, 2019 Posted July 25, 2019 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)
martinayotte Posted July 25, 2019 Posted July 25, 2019 6 minutes ago, gufmar said: but as far as I can see it's master, not DEV branch When I said DEV branch, I'm talking DEV builds using 5.2.y branch, not a git branch of armbian scripts....
Igor Posted July 25, 2019 Posted July 25, 2019 DEV branches are still hidden by default ... @gufmar You need to add additional parameter EXPERT="yes" (perhaps right to config-default) when building in interactive mode to see (in menu) stuff that is still in development.
gufmar Posted July 25, 2019 Posted July 25, 2019 TIL: there are many branches. thanks. will try my best.
Igor Posted July 25, 2019 Posted July 25, 2019 Always stay on a build script (https://github.com/armbian/build) master branch unless you are a part of some special (usually) builds script feature development which is happening there ... we have more kernel branches per board (family) as well ...
gufmar Posted July 26, 2019 Posted July 26, 2019 ok, whatever I did, the flashed eMMC booted up and run fine. But there is still no /dev/spi* device. Do I need to enable it in the .dts file and recompile to to dtb (similar as with i2c devices) ?
martinayotte Posted July 26, 2019 Posted July 26, 2019 3 hours ago, gufmar said: But there is still no /dev/spi* device. Did you build a new image with my latest fixes ? Did you enabled spi-spidev overlay in /boot/armbianEnv.txt ? overlays=spi-spidev param_spidev_spi_bus=2
gufmar Posted July 26, 2019 Posted July 26, 2019 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.
martinayotte Posted July 26, 2019 Posted July 26, 2019 4 minutes ago, gufmar said: 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. There are I2C7 and I2C8 overlays available ...
gufmar Posted July 28, 2019 Posted July 28, 2019 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)
martinayotte Posted July 28, 2019 Posted July 28, 2019 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 ...
dolphs Posted October 21, 2019 Author Posted October 21, 2019 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
chwe Posted October 21, 2019 Posted October 21, 2019 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 ...
Recommended Posts