Jump to content

Search the Community

Showing results for 'gpio'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Categories

  • Official giveaways
  • Community giveaways

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. Hi, I've build an SD card image with in a buildroot myself, used the stable branch as suggested. "For stable branch use --branch=v23.11"..and that all worked good so far. I'm no linux guy at all and begun some investigations, installed packages and configured the system, this was an desktop variant with xfce. Somewhere in the middle of work I've got the message that a security update is available and I should do an apt upgrade..done that. Interresting for me was, that I've got an Update to Armbian 24.2.1 jammy.. ok ..then this is so. I've noticed later that I don't have any video output from X11 anymore, after the login prompt the screen gets black with an cursor above left and later is shut off entirely, but the Xserver is still running, [pre] 1125 tty7 Ssl+ 0:06 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/ru n/lightdm/root/:0 -nolisten tcp vt7 -novtswitch [/pre] xrandr output: [pre] xrandr Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 16384 x 16384 DVI-I-0 disconnected primary (normal left inverted right x axis y axis) DVI-I-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 60.00 59.93 1680x1050 59.95 1600x1200 60.00 1440x900 74.98 59.89 1280x1024 75.02 72.00 60.02 1024x768 75.03 70.07 60.00 800x600 75.00 72.19 60.32 640x480 75.00 72.81 65.99 59.94 DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DVI-D-0 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.00 1680x1050 59.95 1600x900 60.00 1440x900 59.89 1280x1024 75.02 60.02 1280x800 59.81 1280x720 60.00 50.00 1152x864 75.00 1024x768 75.03 70.07 60.00 800x600 75.00 72.19 60.32 56.25 720x576 50.00 720x480 59.94 640x480 75.00 72.81 59.94 DP-2 disconnected (normal left inverted right x axis y axis) DP-3 disconnected (normal left inverted right x axis y axis) [/pre] I've fiddeled around with some commands, but I'm unable to restore the Xserver Output on the DVI Output of the Cubieboard2. I have an DVI to VGA Connector plugged in and an TFT Display with the VGA Input to the converter. I'm unable to use the vga output that is provided at the DVK521 Board (WaveShare) too and already had planned to ask here how I can switch between the Video connectors with an actual Armbian. The last thing I've done where some entries in the armbianEnv to get an 2nd uart and the 1wire Interface enabled, that worked so far, but I was logged in with ssh from my host and haven't seen the X-Display from the Cubieboard2 since the monitor was switched to DVI which is connected to the host as 2nd monitor. I don't think that there is something wrong: [pre] armbianEnv: verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 rootdev=UUID=42951d58-2c17-42a5-af83-c6eaf7357967 rootfstype=ext4 overlay_prefix=sun7i-a20 overlays=uart3 w1-gpio param_uart2_rtscts=1 param_w1_pin=PB10 param_w1_pin_int_pullup=1 #extraargs=video=HDMI-A-1:1920x1080M@60 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u [/pre] The commented out extraargs line was from Igor suggested in another thread for a problem w/o connected monitor..but changed nothing. Can someone help me please? I hadn't much todo with Xserver setup in the last years..I'm tapping around pretty much in the dark.. Kind Regards, Holm
  2. I've seen this question asked quite frequently here and all the posts end before there is a solution. I think it's time we had a crystal clear discussion on how it can be done. Not just for my curiosity, but for the people who've asked before and for the people who will ask in the future. The reason: Many hats/shields designed for RaspberryPi would otherwise be compatible with OrangePi if Armbian/u-boot didn't direct the debug output to UART0. UART0 is the most commonly used serial connection for hats/shields designed for RaspberryPi. OrangePi has multiple UART gpio so it would make sense for the O.S. (Armbian) to use the one that least impacts the users ability to actually use their hardware. Debug output is important but not so much so that the user cannot easily disable it.
  3. The only thing I haven't been able to eliminate is this message [ 5.019754] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file I tried setting the GPIO flag for GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN but unfortunately, it doesn't work but it doesn't affect the operation of w1-gpio It seems that the GPIO pins do not have an "open drain" mode, they do outputs and inputs. It is a warning about what something sees as an invalid or incomplete configuration in Device Tree, rather than a real problem with the hardware.
  4. Hi, for me w1-gpio on OZPI v3 working now very well via overlay dts file please read my last post in:
  5. I don't think the Orange Pi Zero 3 supports w1-gpio. The only 1-wire overlay that I know of is for H5-equipped boards.
  6. @gen ha it's happnd because you're using a RK3568 DTS to build an RK3566 DTS and it will mess with Mdio this is your solution: &mdio1 { rgmii_phy1: phy@0 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0x0>; }; }; &gmac1 { phy-mode = "rgmii"; clock_in_out = "input"; snps,reset-gpio = <&gpio2 RK_PD1 GPIO_ACTIVE_LOW>; snps,reset-active-low; /* Reset time is 20ms, 100ms for rtl8211f */ snps,reset-delays-us = <0 20000 100000>; assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>; pinctrl-names = "default"; pinctrl-0 = <&gmac1m1_miim &gmac1m1_tx_bus2 &gmac1m1_rx_bus2 &gmac1m1_rgmii_clk &gmac1m1_rgmii_bus &gmac1m1_clkinout>; tx_delay = <0x4f>; rx_delay = <0x26>; phy-handle = <&rgmii_phy1>; status = "okay"; };
  7. Reading many others documents about OPEN DRAIN flag , OZPI v3 and others like Raspberry Pi don't support Open DRAIN, but they should work in emulated mode, switching between input and output-driving-low. So for this reason if we set flag for GPIO with OPEN DARIN it looks not influence and not need setting this flag for w1-gpio for this SBC
  8. I have got the same issue. Orange Pi Zero H2+ Linux moblink 6.6.16-current-sunxi #1 SMP Fri Feb 23 08:25:28 UTC 2024 armv7l GNU/Linux Armbian 24.2.1 I used some software which is 1) playing some sound into embedded sound card 2) processing interrupts on gpio (gpio event with GPIO API V2) During sysstat-collect.service failing for 1min 47.293s: +sound playing OK - gpio interrupts proccessing freeze I had to stop and disable sysstat-collect.service Also apt remove sysstat It helped. cat armbian-image-release cat armbian-release cat os-release
  9. Hello, to avoid this error, you can disable strict mode in the pin controller driver https://elixir.bootlin.com/linux/v6.7.12/source/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c But I'm not sure that the driver for this touchscreen can work on allwinner processors without changes, because their "gpio_in" and "irq" are different multiplexer states I think they cannot work simultaneously, so something similar is needed PS Of course you can use different pins for interrupts and gpio and then everything should work out of the box.
  10. Hi, I managed to make w1-GPIO work in Orange Pi Zero v3 for, for example, the DS18B20 sensor. However, I have some doubts about setting the GPIO flags for w1-gpio. Many examples provide flags in the form gpios = <&pio 0 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; but in the dts file when I use this form it does not work (syntax error) so I have to provide the flags in digital form. A description of flags and bits is here https://elixir.bootlin.com/linux/v6.6.30/source/include/dt-bindings/gpio/gpio.h If I would like to set GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN then the digital value for these bits will be for set bits: 0110000 = 48 because GPIO_OPEN_DRAIN it is (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN) Please help me and confirm whether I understood it correctly I wanted to get rid of the message in the logs for w1-gpio [ 4.994183] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file which understands that I need to set the GPIO flag GPIO_OPEN_DRAIN in the dts file I see one problem with this source https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt where a number of bits to set is 6 in source https://elixir.bootlin.com/linux/v6.6.30/source/include/dt-bindings/gpio/gpio.h number of bits to set is 7 I hope I posted this question in the right section, if not please move it
  11. I used simple dts file as possible : /dts-v1/; /plugin/; / { model = "OrangePi Zero3"; compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618"; fragment@0 { target-path = "/"; __overlay__ { w1: onewire@0 { compatible = "w1-gpio"; pinctrl-names = "default"; gpios = <&pio 2 7 0>; status = "okay"; }; }; }; }; compiled: armbian-add-overlay w1-gpio.dts and works 🙂 with armbianEnv.txt user_overlays=w1-gpio param_w1_pin=PC10 param_w1_pin_int_pullup=0 demsg show [ 5.015541] Driver for 1-wire Dallas network protocol. [ 5.019754] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 5.046831] w1_master_driver w1_bus_master1: Attaching one wire slave 28.03165129ecff crc 24 and cat /sys//bus/w1/devices/28-03165129ecff/w1_slave 76 01 4b 46 7f ff 0c 10 d3 : crc=d3 YES 76 01 4b 46 7f ff 0c 10 d3 t=23375 SBC DS18B20 VCC (3V3) Pin 1 ---------- VCC DS18B20 | R1 = 4k7 | GPIO74 Pin 26 --------- Data DS18B20 GND Pin 6 ---------- GND DS18B20
  12. Dear Community, Currently Im playin with my Banana Pi M2 Berry and therefore I need a fusion of the LATEST Armbian -System with the compilers needed by the Boards Offical "GPIO-Libarys", which are outdated 7years ago. The most important libary would be the RPi.GPIO. RPi.GPIO The problem is, that this libary was using python2 and python3, python2 isnt my future i think, but for compiling the lib with python3 I need some pip-packages and the right arm-gcc compiler = 4.8 i think. DO i may need a cross-compile libary or whats are the requirements to build the lib on the latest system? To avoid hardware-determiner ERRORS, Im using the folder and its scripts/configs used in the offical Raspbian build for this device. The goal: The Latest Armbian-build with re-supported libarys like rpi.gpio or wiringpi! If there is someone who would like to update the GPIO-Controlling Libarys for Banana Pi with me, i'd be gratefull if some people let me know by pn, e-mail or github! Thanks, BlackLeakz
  13. I would like to ask about the entry in armbiaEnv.txt in the ArmBian distribution for Orange Pi Zero 3 overlay_prefix=sun50i-h616 does it have anything to do with the file in the directory? /boot/dtb-6.6.30-current-sunxi64/allwinner/sun50i-h618-orangepi-zero3.dtb For OZPI version 3 there is a prefix sun50i-h618 and in armbianEnv.txt there is overlay_prefix=sun50i-h616 shouldn't it be sun50i-h618 ?? I'm asking about this because I have a problem with using overlay for w1-gpio for OZPI v3, so I am looking for the source of the problem in various places
  14. I try to understand problem [ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74 and I see this message is generate by: https://github.com/torvalds/linux/blob/master/drivers/pinctrl/pinmux.c#L102 /** * pin_request() - request a single pin to be muxed in, typically for GPIO * @pctldev: the associated pin controller device * @pin: the pin number in the global pin space * @owner: a representation of the owner of this pin; typically the device * name that controls its mux function, or the requested GPIO name * @gpio_range: the range matching the GPIO pin if this is a request for a * single GPIO pin */ ...... if ((!gpio_range || ops->strict) && desc->mux_usecount && strcmp(desc->mux_owner, owner)) { dev_err(pctldev->dev, "pin %s already requested by %s; cannot claim for %s\n", desc->name, desc->mux_owner, owner); goto out; } if ((gpio_range || ops->strict) && desc->gpio_owner) { dev_err(pctldev->dev, "pin %s already requested by %s; cannot claim for %s\n", desc->name, desc->gpio_owner, owner); goto out; } .....
  15. Maybe I need a change in my w1-gpio.dts looking to https://elixir.bootlin.com/linux/v6.6.30/source/arch/arm64/boot/dts/allwinner compatible = "allwinner,sun50i-h616"; to model = "OrangePi Zero3"; compatible = "xunlong,orangepi-zero3", "allwinner,sun50i-h618"; and add #include "sun50i-h616-orangepi-zero.dtsi" like in https://elixir.bootlin.com/linux/v6.6.30/source/arch/arm64/boot/dts/allwinner/sun50i-h618-orangepi-zero3.dts
  16. Unfortunately, my programming knowledge is low and knowledge of DTS Overlays + source code of w1-gpio linux kernel does not allow me to find the source of the problem [ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74
  17. Ha, interesting ... I have put in armbianEnv.txt instead pc10 now param_w1_pin=gpio71 where gpio71 is number line for PC7 which is not connected DS18B20 🙂 at current is nothing connected and working w1-gpio with info log where is show PC10/gpio-74 [ 4.957396] Driver for 1-wire Dallas network protocol. [ 4.960325] w1-gpio onewire@0: there is not valid maps for state default [ 4.960433] gpio-74 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file [ 4.986579] w1_master_driver w1_bus_master1: Attaching one wire slave 28.03165129ecff crc 24 cat /sys/bus/w1/devices/28-03165129ecff/w1_slave 5f 01 4b 46 7f ff 0c 10 12 : crc=12 YES 5f 01 4b 46 7f ff 0c 10 12 t=21937 I can not understand this
  18. Summary, In all examples to use w1-gpio in Armbian in armbinaEnv.txt always is name of gpio is write in capital letters for example PC10 param_w1_pin=PC10 but when we use PC10 w1-gpio not works and in log is message: [ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74 command cat /sys/kernel/debug/gpio did not show that gpio 74 / PC10 is used command but when we use name gpio in lowercase letters pc10 w1-gpio works and show data from DS18B20 but show message in log [ 9.366246] w1-gpio onewire@0: there is not valid maps for state default command cat /sys/kernel/debug/gpio show gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl: gpio-74 ( |onewire@0 ) out hi and we can see data from DS18B20 cat /sys/bus/w1/devices/28-03165129ecff/w1_slave 53 01 4b 46 7f ff 0c 10 2d : crc=2d YES 53 01 4b 46 7f ff 0c 10 2d t=21187 for me, it is bug or in kernel 6.6.30 or overlay for Ornage Pi Zreo v3
  19. I have checked what hapen when on Ornage Pi Zero v1 with kernel 6.1.63 in armbianEnv.txt use pa14 instead PA14 in log I see [ 9.358693] Driver for 1-wire Dallas network protocol. [ 9.366246] w1-gpio onewire@0: there is not valid maps for state default [ 9.368019] gpio-110 (onewire@0): enforced open drain please flag it properly in DT/ACPI DSDT/board file and w1-gpio not working and no files in /sys/bus/w1/devices/ but we see marked in red the same information that I have on OZPI v3 when I use pc10 instead of PC10 but on OZPI v3 DS18B20 works and on OZPI v1 it doesn't work when I use the lower case name gpio This looks like some kind of bug in kernel 6.6.30 on OZPI v3
  20. dts overlay aren't 'perfect' https://elinux.org/Device_Tree_Source_Undocumented#:~:text=Node can be deleted with,%2Fdelete-property%2F directive.&text=If a delete is specified,with the overlay source file. If a delete is specified in an overlay source file, the delete only impacts the files compiled in association with the overlay source file. The delete does not result in an opcode in the resulting .dtb, thus applying the overlay will not delete the node or property in the base tree. and it may take using those 'hacks' described at that page to attempt a 'fix' hence, you may like to just note that those messages are 'benign' and w1-gpio works normally.
  21. Yes, that's right, I can ignore it when I have a working w1-gpio on OZPI v3, but it would be nice to see how to fix it so that it works correctly. But what's strange to me is that I have to use the gpio name in lower case and not in upper case as it was always described in the w1-gpio examples. I tried to use the name with gpiod, i.e. "gpio74", instead of names like PC10, but it didn't work, so it occurred to me to try writing the name in lower case "pc10" instead of capital letters as usual, and I found that it worked, but I think it's not normal since capital letters have been used so far, I will check on OZP v1 whether it will work if I change to lowercase letters Thank you for exchanging ideas and tips on solving the problem
  22. rather pinctrl could be related to pinctrl or maybe gpiod. I'm not too sure if that message means that w1-gpio is using that pin so pinctrl cannot use it. if that is the case, I think it is ok if pinctrl don't use it for gpio. that message is likely safe to ignore as long as your w1-gpio works. to 'fix' that it may take editing other dts to exclude that pin from pinctrl which could be a hassle.
  23. But I am not use gpio PC10 by another application etc, I define PC10 only for w1-gpio in armbianEnv.tx but when I use PC10 instead pc10 w1-gpio is not working and I can not read data DS18B20. When I use pc10 all working and I read atat from DS18B20 so info in log: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74 give me that w1-gpio is not working
  24. it may help to look in codes https://github.com/torvalds/linux/blob/master/drivers/w1/masters/w1-gpio.c https://github.com/torvalds/linux/tree/master/drivers/w1 [ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74 seem to suggest that pinctrl tries to map that pin but onewire@0 is using it, so i guess this is ok as long as you are not using that as normal gpio pin. that "no maps for state" is found here https://github.com/torvalds/linux/blob/cf87f46fd34d6c19283d9625a7822f20d90b64a4/drivers/pinctrl/devicetree.c#L175 ret = ops->dt_node_to_map(pctldev, np_config, &map, &num_maps); if (ret < 0) return ret; else if (num_maps == 0) { /* * If we have no valid maps (maybe caused by empty pinctrl node * or typing error) ther is no need remember this, so just * return. */ dev_info(p->dev, "there is not valid maps for state %s\n", statename); return 0; } my guess is it may be related to pinctrl-names = "default"; some related stuff https://www.kernel.org/doc/Documentation/devicetree/bindings/w1/ https://www.kernel.org/doc/Documentation/devicetree/bindings/w1/w1-gpio.txt as it works as you mentioned, I'd guess that "not valid maps for state default" can be ignored.
  25. But it is interesting most of examples armbianEnv.txt for parameters param_w1_pin=PC10 show name of gpio in use capital letters but when I use name in capital letters is problem and show in demsg info [ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74 and 1-Wire not working but when I use name of gpio in lowercase letters pc20 1-Wire works and show temperature from DS18B20 but is info [ 4.994076] w1-gpio onewire@0: there is not valid maps for state default It maybe any bug ?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines