usual user

  • Posts

    164
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

usual user's Achievements

  1. Thanks for moving it, I wouldn't have known how else I could have split it appropriately.
  2. I am running on fedora as can be seen here. Fedora is not device-specific, only architecture-specific. If you want to experiment, drop in a distro-boot capable u-boot for your device in the firmware area and you should be good enough to go. I have never tested my image on a different device so YMMV.
  3. Sure thing, the attached overlays are written in absolut path notation. That is, they apply to any target base dtb regardless of whether they are built with the "@" switch or not. They can serve as a basis to collect overlays for all types of devices. Gpiochip is configured in rk3399.dtsi, i.e. the overlays can be used as a template for all dtbs which include this file. Therefore, the compatible must be adjusted, and the con1-## names must be inserted in the right place. Because libgpiod provides python bindings, it should be easy to make use of the con1-## names. Now you can forget about WiringPi. All you need is a devicetree overlay that assigns the con1-## names, and you can make any device with gpiochip support usable without changing the user space software. The first step would be to look at the schematic to see if it's really wired that way. If so, you need to decide which feature you prefer and configure devicetree in the appropriate way. Maybe is this a solution to use a spare GPIO. If the wireing is ok, there is still the possibility it is misconfigured in the devicetree but only looking at the source will tell. rk3399-nanopc-t4-con1.dts rk3399-rock-pi-4-con1.dts
  4. 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. I 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.dtbo The 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
  5. 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. 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. It's the label showing up in the listing: 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. 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.
  6. Of course not, it's probably pinmuxed on special pwm functionality and therefore no longer available for GPIO. 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.
  7. You are absolutely right, I am off by one. A starts at 0 not 1 Sory for the noise. 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?
  8. 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)
  9. 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.
  10. You cannot invent keycodes randomly, you must use the keycodes known to the input event system. "man rc_keymap" SEE ALSO 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.
  11. 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.
  12. 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 ... friendlyarm_rc-100.toml
  13. 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.
  14. 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%:
  15. 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. No i.MX6 development is required, only an administrator who knows how to integrate software in his system. So you are fully qualified. 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 Armbian manages their build system with git. So you issue a pull request (PR) to get your modification discussed and hopefully finaly applied.