usual user
-
Posts
512 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
3 hours ago, tony013 said:
gpioinfo states the pin as unused
As "not used for GPIO", but not automatically available if the SOC has configured it for another function. This situation can change at runtime if, for example, one driver is unloaded and another is loaded. It is only available for GPIO if the pinctrl is set up for GPIO functinality for that pin. And this requires suitable properties in devicetree. Be it native in the base dtb or applied as overlay.
3 hours ago, tony013 said:Is that an overlay or what is it? Who processes that file?
It is a devicetree source code snippet, how you apply it is up to you. You can add it to your source or write it as an overlay and then apply it dynamically or statically.
3 hours ago, tony013 said:I would not have that key labeled "Power-key".
It's the label showing up in the listing:
Spoilerline 0: unnamed unused input active-high line 1: unnamed "vcc3v0-sd" output active-high [used] line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed "host-wakeup" input active-high [used] line 5: unnamed "Power-key" input active-low [used] line 6: unnamed "ir-receiver" input active-low [used] line 7: unnamed "cd" input active-low [used] line 8: unnamed unused input active-high line 9: unnamed "shutdown" output active-high [used] line 10: unnamed "reset" output active-low [used] line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed "status_led" output active-high [used] line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: unnamed unused input active-high3 hours ago, tony013 said:... anyway: does that "wakeup-source" mean, that the rockpi4 is able to wakeup on keypress after issuing a "poweroff"?
Only if this line is also wired up to the pmic. When the power is cut off, no code is executed any longer that could initiate actions.
Spoiler
3 hours ago, tony013 said:and last not least - how can I act on key-events in userspace?
As with any other keycode that the input event system outputs. If you had configured "linux,code = <KEY_A>;", you would not be able to tell if you have pressed the button or the "A" key on your keyboard.
-
1 hour ago, tony013 said:
Interestingly the pwm, which I use for fan control is not recognized by gpioinfo.
Of course not, it's probably pinmuxed on special pwm functionality and therefore no longer available for GPIO.
1 hour ago, tony013 said:Well the button is not of good quality and some kind of flaky, but that many events? Puh
Now I understand, why I had so many problems in detecting the right button states ...
For this there is the gpio-keys driver in the kernel. I would add something along this lines to the devicetree and leave anything else to the input event system:
#include <dt-bindings/input/linux-event-codes.h> gpio-keys { compatible = "gpio-keys"; autorepeat; power { debounce-interval = <100>; gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>; label = "Power-key"; linux,code = <KEY_POWER>; wakeup-source; }; };
I left out the pinmux settings as your GPIO already seems to be set up properly.
-
50 minutes ago, tony013 said:
but I can't follow your calculation.
You are absolutely right, I am off by one.
A starts at 0 not 1
Sory for the noise.2 hours ago, tony013 said:line 18 is used by "sysfs" and gpiomon fails with
gpiomon: error waiting for events: Device or resource busy
Your IO is exported by sysfs interface at that time, which probably prevents the use of gpiod. Only one user allowed at a time. Can you retry without sysfs export?
-
1 hour ago, tony013 said:
GPIO4_C2
You did your calculation wrong. Rockhip divides each gpiochip into four eight bit segments (A B C D). Therefore, the correct resolution is: gpiochip 4 line 26 (C+2 | 3*8+2)
-
4 hours ago, TRS-80 said:
I figured I might as well learn the "new / supported" way.
From a user space point of view, there is no either or. It depends on which interface is supported by any existing software. If your kernel provides gpiochip and your software requires sysfs, enable "CONFIG_GPIO_SYSFS=y" and your software won't tell any difference between native sysfs. Gpiochip and sysfs interfaces can work simultaneously. New developments should use gpiochip, as it essentially offers more functionality.
But before any IO functionalities can be used, the pin configuration of the SOC must be carried out correct. Almost no SOC uses single pins exclusively for IO, most of the time pins are able to perform several different dedicated functions. Of course, if a pin is configured for a different functionality, it is no longer available for IO at the same time. Gpiochip provides access to all possible IOs of the SOC, but only those really configured by pinctrl for IO are usable. How the pins on your specific device are wired is shown by the schematic. In order for the kernel drivers to know how the device is wired, this must be described in a kernel readable form. This is the reason why devicetree exists as it makes no sense to hard code it for any device.
-
51 minutes ago, lucky62 said:
My remote has the few special keys, like Youtube, Netflix, TV control keys. These are also in my toml file, but names are not recognized by driver. Seems that key names must be only from defined set. What are the allowed names?
You cannot invent keycodes randomly, you must use the keycodes known to the input event system. "man rc_keymap" SEE ALSO
Quote53 minutes ago, lucky62 said:Second point not clear to me - how are the KEYs mapped to system/program actions?
For example - I would like to open YouTube in the browser when I will press the YouTube KEY, how to do?
Same way as done for any emitted key of your keyboard. User space cannot distinguish which input device emitted the keycode. Desktop environments typically have "shortcut keys" setup tools in the Settings pane.
-
2 hours ago, RussianNeuroMancer said:
On NanoPC-T4 (which also equipped with rt5651) there is same issue, which same errors messages in dmesg. So maybe something else (besides rk3399-add-sclk-i2sout-src-clock.patch) is missing in Armbian?
I use since long time pure mainline kernel for rt5651 support. The kernel hack that Armbian is still applying is not really required. If you like, I can upload a kernel for a quick test to see if it is also working for you. Or even easier, try this image for your NanoPC-T4, it should already have everything in place.
-
3 hours ago, jock said:
@lucky62 The key mapping is stored in the kernel, and ir-keytable is a tool to test but also store the key mappings in the kernel, It also allows you to retrieve and restore the whole mapping table at once.
You should use ir-keytable to do the mapping, then retrieve the whole table from the kernel and save it in a file, then restore the table in the kernel on every reboot.
Wrong approach, use "ir-keytable -ts rc1" to collect the scancode for any key on your remote control. Drop them in a toml file (man rc_keymap) and assign your linux input key‐codes. When done, check with "ir-keytable --test-keymap=<whatever_name>.toml". If the test is error-free, move <whatever_name>.toml to /etc/rc_keymaps/<whatever_name>.toml and register the file in /etc/rc_maps.cfg such as
* rc-empty <whatever_name>.toml
as a new last line.
I recently did this for my FRIENDLYARM RC-100, see friendlyarm_rc-100.toml as reference. This way a udev rule picks up the keymap als soon as the rc kernel device is detected and the remote is working out of the box after every reboot.
Now start collecting of <whatever_name>.toml files for any available remote control with the prefered keymapping and drop them in your distribution. This way choosing a remote control is only a registration in rc_maps.cfg away. Replace "rc-empty" if your remote reports a different keymap:# ir-keytable Found /sys/class/rc/rc1/ (/dev/input/event2) with: Name: gpio_ir_recv Driver: gpio_ir_recv, table: rc-empty ... -
6 hours ago, tparys said:
But, I spun up several jobs, the kernel pegged the fan shortly after, and after a few minutes got up to just over 60 C.
This is only feeling and guesswork. I don't have your device model so can't check your setup by myself. Hence my request for a tmon log to see what is really going on. But if you are satisfied with your results, I have no further request and stop my curiosity.
-
5 hours ago, tparys said:
Would be interested to hear any thoughts/feedback
I'm curious how your thermal system performs, an opinion to post a tmon log while your device is being stressed?
This is mine running for three hours with all six cores at 100%:Spoiler
-
3 hours ago, nocrash said:
I was so happy thats there is some current software for my old hardware available.
i.MX6 support is feature complete since long time in mainline, I'm running fully flagged fedora on my i.MX6 devices for years. Not running current releases will missing bugfixes and latest features.
3 hours ago, nocrash said:I m not a dev, just a admin.
No i.MX6 development is required, only an administrator who knows how to integrate software in his system. So you are fully qualified.
3 hours ago, nocrash said:i tried to compile the code of xserver-xorg-video-imx-viv_6.2.2.p0+1.tar.xz
You want the xf86-video-armada driver as referenced in the other thread.
If you want to know how it fits together, see buffer-flow.pdf
3 hours ago, nocrash said:What do you mean with PR?
Armbian manages their build system with git. So you issue a pull request (PR) to get your modification discussed and hopefully finaly applied.
-
This is about i.MX6 SOC and the device it is equipped on does not matter. Since not many Armbian i.MX6 SOC users, even you till now not, contribute much to the Armbiban project, you can imagine why few improvements happen.
The same responses from "No gpu support on Udoo?" apply here, so I'll leave it to a moderator to possibly close this topic as a dublicate. To begin with, you can provide a PR to add the pointed out xorg driver to the Armbian build system.
-
On 1/14/2021 at 10:28 AM, RussianNeuroMancer said:
when HDMI support is disabled in uboot 2020.10 issue is not reproducible
I stumbled across a patch set that enables higher resolutions than FHD. I'm wondering if this has some impact on your HDMI issue. Since I built a kernel for other reasons, I pulled the patches also in. Is there an interest in trying it out with my uboot on your NanoPC-T4? It will be picked up by the test verbose option.
-
On 1/18/2021 at 11:41 PM, chrismade said:
I haven't heard back from kernel developers if/when we could expect a fix
The fix has landed in 5.11, but as I don't see any stable tag, you have to wait till Armbian moves to 5.11 or compose an Armbinan PR for the patch to have it backported for older kernels.
-
11 hours ago, tmountain said:
I could not get the aforementioned kernel to work
Sorry, but as this is working for me with Fedora userspace, I can't help any further.
But at least you found a solution for a working u-boot. -
1 hour ago, tmountain said:
And my boot log here (via UART):
Your log is only about kernel log. I wonder if your problem is a kernel build configuration. Any means to drop in my kernel also? Make sure you use the same kernel cmd line parameters as the defaut stanza as in the extlinux.conf. Of course, you need to adjust the PARTUUID.
-
5 hours ago, tmountain said:
The vanilla u-boot does not work out of the box.
Out of curiosity, does my mainline uboot without binary bloobs work for you?
-
10 hours ago, mbo said:
point me to a tutorial/documentation on how to setup a DS3231 RTC module
-
1 hour ago, tmountain said:
The full NanoPC-T4 pin spec is here: http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T4.
Restudy your referenced spec. The default serial console is located at "Debug UART".
-
20 hours ago, RussianNeuroMancer said:
Belkin dock is solution with most broad compatibility, and I have to choice but to stick with it for now.
You probably have a misunderstanding about what this thread is about. It is about to verify if my DT overlay is working in Armbian environment so it can be integrated in Armbian for out of the box operation of Armbian users. It is sufficient to aprove it is working in a similar manner as for me. If a special USB-C device does not work, this is possible to discuss with the patch autor. PD functionality is for NanoPC-T4 out of scope because it has no PD features desined in hardware. The NanoPC-T4 can e.g. operate an additional display via a cost-effective USB-C DP alternative mode adapter.
20 hours ago, RussianNeuroMancer said:Please clarify why you think this incompatibility is caused by patch, while even vendor kernel couldn't use this dock as video output on this specific board?
Vendor kernels are havy out of tree patched to showcase the key features of a specific hardware. But never implement everything perfect. Otherwise noone would have any demand for any update ever. The fact that the NanoPC-T4 vendor kernel does not have functional USB-C DP support is even understandable, as it already has three dedicated display connectors. Support for a fourth one is therefore likely to be a very low priority and left out. But the hardware is there and can be used with proper software, as proven for my environment. If other vendor kernels support your device they have probably some necessary modification in place and aprove the 3399 SOC can drive it.
Starting here and the following posts you can find success of using USB-C DP with legacy kernel.
-
IIUC the PINE64 and Firefly image use legacy kernel and don't use this particular kernel patch. Now that the only difference in our setups is the USB DP adapter, IMHO the only sensible way forward is to swap the dock for another DP alternate mode adapter. Swapping the board will not eliminate an incompatibility between the kernel patch and the dock. The USB-C hardware (DTB) seems to be set up correctly otherwise the USB functionality would not work. The DP alternate mode uses the same hardware lanes but only protocolly differently.
Off topic: Out of curiosity does the offered u-boot influence your Dell UP3017 incompatibility? -
Okay, I can only imagine two reasons for this still not working. Either the DP kernel patch doesn't support your DP hardware or u-boot doesn't set up the NanoPC-T4 as needed. To rule out u-boot, apply the extracted u-boot, which can be found here. E.g:
dd bs=512 seek=64 conv=notrunc if=u-boot-rockchip.bin of=${DEVICE} ; syncand test. Replace "${DEVICE}" by your micro-SD device.
-
4 hours ago, RussianNeuroMancer said:
I see menu but it's seems like it doesn't accept keyboard input, probably due to the fact that my keyboard is attached via USB dock.
IIUC the extlinux.conf is working with the current kernel for you. The USB keyboard is not expected to work, because mainline uboot does not yet have the necessary support enabled. Boot option selection is only available via serial console for now.
Extract the tar-gz kernel archive, which can be found here, in your /usr/lib/modules/ directory. E.g.:
tar -C /usr/lib/modules/ -xzf 5.10.0-98.fc34.aarch64.tgzand reboot. Extlinux.conf will pick it up by the default option. To fall back to original kernel without boot option selection, rename the symlink /usr/lib/modules/linux-default, e.g.: linux-default-disabled
-
9 hours ago, Ferdinand said:
As it's no longer available at the linked location, can you make it available to me somehow?
The image was provided to identify a boot.scr magic deficiency. Also Fedora 31 is EOL, so image RIP. Since there seems to be more shortage there, as long as no one who cares for Armbian shows up and maintain the boot.scr magic, you are on your own.
Getting started with GPIO, using "new" gpiod interface
in Beginners
Posted
I have written an overlay for my device to assign names to the GPIO lines wich are wired up to the extention connector. This facilitates the identification of the GPIOs to be selected.
gpiochip0 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed "vcc3v0-sd" output active-high [used] line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed "host-wakeup" input active-high [used] line 5: unnamed "GPIO Key Power" input active-low [used] line 6: unnamed "ir-receiver" input active-low [used] line 7: unnamed "cd" input active-low [used] line 8: unnamed unused input active-high line 9: unnamed "shutdown" output active-high [used] line 10: unnamed "reset" output active-low [used] line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed "status_led" output active-high [used] line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: unnamed unused input active-high line 22: unnamed unused input active-high line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed unused input active-high line 27: unnamed unused input active-high line 28: unnamed unused input active-high line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-high gpiochip1 - 32 lines: line 0: "con1-07" unused input active-high line 1: "con1-11" unused input active-high line 2: unnamed unused input active-high line 3: "con1-13" unused input active-high line 4: "con1-15" unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: "con1-12" unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: unnamed unused input active-high line 22: "con1-16" unused input active-high line 23: "con1-18" unused input active-high line 24: "con1-22" unused input active-high line 25: unnamed unused input active-high line 26: unnamed unused input active-high line 27: unnamed unused input active-high line 28: unnamed unused input active-high line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-high gpiochip2 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused output active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: unnamed unused input active-high line 22: unnamed unused input active-high line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed "device-wakeup" output active-high [used] line 27: unnamed unused input active-high line 28: unnamed unused input active-high line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-high gpiochip3 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed "PHY reset" output active-low [used] line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: unnamed unused input active-high line 22: unnamed unused input active-high line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed unused input active-high line 27: unnamed unused input active-high line 28: "con1-37" unused input active-high line 29: "con1-38" unused input active-high line 30: "con1-40" unused input active-high line 31: unnamed unused input active-high gpiochip4 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: "con1-10" unused input active-high line 17: "con1-08" unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: "con1-26" unused input active-high line 22: unnamed unused input active-high line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed "vbus-typec" output active-high [used] line 27: unnamed unused output active-high line 28: unnamed "Headphone detection" input active-high [used] line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-highI have also written a rk3399-rock-pi-4 one. It can be staticly applied to the base dtb like this:
[root]# mv rk3399-rock-pi-4a.dtb rk3399-rock-pi-4a.dtb.orig [root]# fdtoverlay --input rk3399-rock-pi-4a.dtb.orig --output rk3399-rock-pi-4a.dtb rk3399-rock-pi-4-con1.dtboThe wiring of the GPIOs differs substantially between my device and the rock-pi, but because of the chosen name format (con1-## with ## = connector pin number) this is not relevant for user space any longer. E. g.: "gpioget $(gpiofind con1-11)" always finds the correct line to request the state of pin 11 of the connector. Of course only GPIO supported pins can be used, e. g. my device has way less pins capable of GPIO than the rock-pi. Therefore, con1-03 may be for rock-pi, but never available for my device.
The only remaining task is now to create one-time corresponding overlays for all devices to be supported and to apply them accordingly.
rk3399-rock-pi-4-con1.dtbo