Gunjan Gupta

@robertoj, all,
 
apparently, it may be possible to name the lines in the DTS
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpiolib.c?h=v6.7.4#n456
 
Example: gpio-controller@00000000 { compatible = "foo"; reg = <0x00000000 0x1000>; gpio-controller; #gpio-cells = <2>; ngpios = <18>; gpio-reserved-ranges = <0 4>, <12 2>; gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R", "LED G", "LED B", "Col A", "Col B", "Col C", "Col D", "Row A", "Row B", "Row C", "Row D", "NMI button", "poweroff", "reset";  
I'm not sure though if the gpio-line-names assignment can be used in pin-control devices that is currently present in the existing DTS.
 
note also that the line/pin functions are actually defined in the source codes for the pin-control driver, just that this won't automatically appear as gpio-line-names.
 
you may want to start experimenting, post your findings and perhaps make a PR?
 
note that there is another source tree to commit though , which is in linux-sunxi - that would be directly mainlining / upstreaming the changes.
https://linux-sunxi.org/Main_Page
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/
they have a google groups here:
https://groups.google.com/g/linux-sunxi
https://linux-sunxi.org/Mailing_list
 
I'm not too sure about the procedure to commit changes in mainline though.

This thread inspired me to tinker with GPIO again. I was curious to see how I would realize the example for myself. Since python is not my strong point, I chose a poor man's solution with "dnf install libgpiod-utils".
I then ran this command:
gpioset --toggle 100ms,100ms,100ms,100ms,100ms,300ms,300ms,100ms,300ms,100ms,300ms,300ms,100ms,100ms,100ms,100ms,100ms,700ms --consumer panic con1-08=active I'm wondering now what the flashing code could say, but I think a ham radio operator would know for sure what it means 😉
Recreating the python example wasn't really challenging with:
gpioset -t1000 -Cblink-example con1-08=1 And besides, I find my flashing pattern much more interesting. I would be interested to know how something like this would be implemented with sysfs. Certainly not with a one-liner.
These commands work the same way on all my different devices, i.e. it is used for all pin 8 of the first expansion connector. I find it more pleasant to address the pins with con1-xx than to deal with some device-specific gpio-lines again and again. Generated code is therefore portable and can be used on any device without modification, provided that the device can provide GPIO functionality on the corresponding pins.
The only requirement is that the same gpio-line-name is used for the corresponding GPIO of the extension port. But this can be ensured by a simple DTB overlay. Creating such an overlay is a one-time effort for any device and the first thing I do for a device that I care off.

The most recent CI job got failed in the stage that updates the website. Hence the image got missing from the web page. It will be back in few hours. Until then you can download them from the link that @ag123shared above.
 
The CI jobs finds what board images need to be rebuilt based on the changes made in the build repository. As there are no changes merged for zero3 in last two days, no new Images were generated for the same.

I have the same experience based on my last 7 months of being here. I totally agree with you.
 
I also don't disagree with the idea of making it simpler for the non-techie user as long as its not something that is going to increase development and maintenance burden for Armbian. I know no matter how simple we make for them, a lot of them will just try it once and will say its easier to do things on raspberry pi and move on. Simply because its easier for them to find guides for it and they are more geared towards end result than the learning they gather in the process.

A short comment on the discussion.
 
I never use armbian-config. It doesn't help me figure out the essence of the problem.
I am considering the overlays that are provided by Armbian as a template for possible use.
A script that switches something can be harmful. I'm just turning it off.
Next, I pull out the DTB from the working system, which was actually applied.
 
I open the schematic diagram of the printed circuit board and the schematic diagram of the device that I want to attach to the board.
I write out the available pin numbers in the table that I could use.
I take an overlay file found on the Internet or an existing one as a basis and rewrite it to suit my needs.
 
Next, compile this file, add it to the download and check its operability.
This algorithm ensures that nothing superfluous appears in the applied device tree.
 
We can add a lot of automation. We can even connect neural networks to recognize circuit diagrams.😁
But an experienced user will still try to get around (ignore) all this.
And an inexperienced user will not understand why something is not working for him.
He just did not extract the DTB from the running OS and he does not see the real state of things.
 
It seems to me that helping the user to start thinking with his own head is the best solution.

When you have been involved with Armbian for a length of time (and read a few of igor's rants 🙂 ) you will realize why what was said here will not be received well by many within Armbian.
It isn't that what you are saying isn't a reasonable comment.  The problem is that Armbian is under resourced by probably an order of magnitude.  Discussions are continually occurring on how the project can survive let alone move forward.  Many of those conversations involve discussing how more can be done with less resources, ways to cut features/scope to make what exists manageable.  So by you saying to "put [more work] onto developers in Armbian is far better than ..." you are hitting a nerve.  In the current environment that will never pass muster.  Any proposed solution needs to maintain or reduce developer work in the long term.  So any feature suggestion is going to be measured first against that metric, then secondarily by the merits of that feature. 
 
This whole dtd discussion is fundamentally a request for a new feature for Armbian.  Regardless of the merits of your focus on the end user experience, that isn't the way Armbian has handled dtbs in any of the existing boards that are supported.  I'm not saying that what exists is good or desireable, but it is what it is.  Can it be improved, sure.  Can it be improved and at the same time not increase maintenance costs going forward, maybe.
 

@VioletGiraffeI don't remember the changes I made, but if its status is marked as disabled in dts, then probably yes. For the module, if you are ok to do your own build, you can use "./compile.sh BOARD=orangepizero3 BRANCH=current kernel-config" to modify kernel configuration and then proceed with building the image. Current branch will give you 6.6 kernel, you can use edge if you want to use 6.7 kernel as well. Once you get it to work, feel free to raise a PR

TV out might work, its not tested though. The DTS changes for the same was part of HDMI changes that were merged. But there is no audio support added yet so you will not have any audio.

Yeah response was based on me being confused from the overall message. I hope there is not hard feeling over it either

I had most of the commits running on my orange pi 3 lts and as they were tested I included the same. I do have some leftover commits for zero3 in my local git that I have still not pushed. I was planning to test everything and push them on the coming weekend. Is it ok if I defer this to be included in that as well?

Debian seems to use the following
CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12  
Fedora has the following
CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12  

$ grep 'CONFIG_LOG.*SHIFT' config/kernel/linux-sunxi64-*.config config/kernel/linux-sunxi64-current.config:CONFIG_LOG_BUF_SHIFT=14 config/kernel/linux-sunxi64-current.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 config/kernel/linux-sunxi64-edge.config:CONFIG_LOG_BUF_SHIFT=14 config/kernel/linux-sunxi64-edge.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 config/kernel/linux-sunxi64-legacy.config:CONFIG_LOG_BUF_SHIFT=14 config/kernel/linux-sunxi64-legacy.config:CONFIG_LOG_CPU_MAX_BUF_SHIFT=12  
you can also use './compile.sh BOARD=orangepizero3 BRANCH=<branch> kernel-config' to get to the kernel menuconfig and change the same.

No I don't know everything. Infact I always say that "Knowledge is like an ocean and we spend our whole life to get a drop out of it"
 
But you seem to lack common sense of not touching things that are not needed to be touched. And it seems you get offended when someone tells you otherwise.
 
Because I am maintainer of only one H618 device i.e. Orange Pi Zero 3 which is quite new community supported device. I have other platinum support and standard support devices that I am maintainer of to support and that take more priority than this device.
 
Let me know if you need help with it.

Thanks @Gunjan Gupta.
 
I get following output:

a@bananapicm4io:~$ sudo cat /sys/kernel/debug/pinctrl/ff634400.bus:pinctrl@40-pinctrl-meson/pinmux-pins
Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
pin 0 (GPIOZ_0): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_mdio
pin 1 (GPIOZ_1): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_mdc
pin 2 (GPIOZ_2): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_rgmii_rx_clk
pin 3 (GPIOZ_3): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_rx_dv
pin 4 (GPIOZ_4): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_rxd0
pin 5 (GPIOZ_5): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_rxd1
pin 6 (GPIOZ_6): ff3f0000.ethernet periphs-banks:518 function eth group eth_rxd2_rgmii
pin 7 (GPIOZ_7): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_rxd3_rgmii
pin 8 (GPIOZ_8): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_rgmii_tx_clk
pin 9 (GPIOZ_9): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_txen
pin 10 (GPIOZ_10): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_txd0
pin 11 (GPIOZ_11): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_txd1
pin 12 (GPIOZ_12): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_txd2_rgmii
pin 13 (GPIOZ_13): ff3f0000.ethernet (GPIO UNCLAIMED) function eth group eth_txd3_rgmii
pin 14 (GPIOZ_14): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 15 (GPIOZ_15): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 16 (GPIOH_0): ff600000.hdmi-tx (GPIO UNCLAIMED) function hdmitx group hdmitx_sda
pin 17 (GPIOH_1): ff600000.hdmi-tx (GPIO UNCLAIMED) function hdmitx group hdmitx_sck
pin 18 (GPIOH_2): ff600000.hdmi-tx (GPIO UNCLAIMED) function hdmitx group hdmitx_hpd_in
pin 19 (GPIOH_3): ff800280.cec (GPIO UNCLAIMED) function cec_ao_b_h group cec_ao_b_h
pin 20 (GPIOH_4): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 21 (GPIOH_5): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 22 (GPIOH_6): ffd1e000.i2c (GPIO UNCLAIMED) function i2c1 group i2c1_sda_h6
pin 23 (GPIOH_7): ffd1e000.i2c (GPIO UNCLAIMED) function i2c1 group i2c1_sck_h7
pin 24 (GPIOH_8): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 25 (BOOT_0): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_d0
pin 26 (BOOT_1): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_d1
pin 27 (BOOT_2): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_d2
pin 28 (BOOT_3): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_d3
pin 29 (BOOT_4): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_d4
pin 30 (BOOT_5): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_d5
pin 31 (BOOT_6): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_d6
pin 32 (BOOT_7): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_d7
pin 33 (BOOT_8): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_clk
pin 34 (BOOT_9): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 35 (BOOT_10): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_cmd
pin 36 (BOOT_11): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 37 (BOOT_12): (MUX UNCLAIMED) periphs-banks:549
pin 38 (BOOT_13): ffe07000.mmc (GPIO UNCLAIMED) function emmc group emmc_nand_ds
pin 39 (BOOT_14): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 40 (BOOT_15): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 41 (GPIOC_0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 42 (GPIOC_1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 43 (GPIOC_2): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 44 (GPIOC_3): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 45 (GPIOC_4): ffe05000.mmc (GPIO UNCLAIMED) function gpio_periphs group GPIOC_4
pin 46 (GPIOC_5): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 47 (GPIOC_6): (MUX UNCLAIMED) periphs-banks:559
pin 48 (GPIOC_7): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 49 (GPIOA_0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 50 (GPIOA_1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 51 (GPIOA_2): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 52 (GPIOA_3): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 53 (GPIOA_4): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 54 (GPIOA_5): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 55 (GPIOA_6): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 56 (GPIOA_7): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 57 (GPIOA_8): (MUX UNCLAIMED) periphs-banks:569
pin 58 (GPIOA_9): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 59 (GPIOA_10): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 60 (GPIOA_11): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 61 (GPIOA_12): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 62 (GPIOA_13): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 63 (GPIOA_14): ffd1c000.i2c (GPIO UNCLAIMED) function i2c3 group i2c3_sda_a
pin 64 (GPIOA_15): ffd1c000.i2c (GPIO UNCLAIMED) function i2c3 group i2c3_sck_a
pin 65 (GPIOX_0): ffe03000.mmc (GPIO UNCLAIMED) function sdio group sdio_d0
pin 66 (GPIOX_1): ffe03000.mmc (GPIO UNCLAIMED) function sdio group sdio_d1
pin 67 (GPIOX_2): ffe03000.mmc (GPIO UNCLAIMED) function sdio group sdio_d2
pin 68 (GPIOX_3): ffe03000.mmc (GPIO UNCLAIMED) function sdio group sdio_d3
pin 69 (GPIOX_4): ffe03000.mmc (GPIO UNCLAIMED) function sdio group sdio_clk
pin 70 (GPIOX_5): ffe03000.mmc (GPIO UNCLAIMED) function sdio group sdio_cmd
pin 71 (GPIOX_6): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 72 (GPIOX_7): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 73 (GPIOX_8): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 74 (GPIOX_9): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 75 (GPIOX_10): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 76 (GPIOX_11): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 77 (GPIOX_12): ffd24000.serial (GPIO UNCLAIMED) function uart_a group uart_a_tx
pin 78 (GPIOX_13): ffd24000.serial (GPIO UNCLAIMED) function uart_a group uart_a_rx
pin 79 (GPIOX_14): ffd24000.serial (GPIO UNCLAIMED) function uart_a group uart_a_cts
pin 80 (GPIOX_15): ffd24000.serial (GPIO UNCLAIMED) function uart_a group uart_a_rts
pin 81 (GPIOX_16): ffd19000.pwm (GPIO UNCLAIMED) function pwm_e group pwm_e
pin 82 (GPIOX_17): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 83 (GPIOX_18): (MUX UNCLAIMED) periphs-banks:595
pin 84 (GPIOX_19): (MUX UNCLAIMED) periphs-banks:596
 
So my GPIOX_18 pin number is 595

One possible option can be to convert the configs that are creating problems to be built as modules and then blacklist the modules using MODULES_BLACKLIST in board config.

Theoretically modules should get loaded automatically based on the compatible string in the dts. But we can always check if that is not the case and add MODULES to board config to force loading them.
 
Another option can also be to add status=disabled for the dts node in LonganPi's dts to disable the dts node belonging to the kernel module to prevent the module from coming into action.

@krrmbnWere these boards using a fresh image or were they upgraded from some previous version? if they were upgraded, check if /etc/modules list a module like sprdwl_ng. If yes remove the same. Then enable aw859a-wifi.service service for wifi support. Now reboot and your problem should be resolved.

Wow, load is so much lower on all of the boards now. Previously under normal circumstances, load: 1.0. Pre-crash circumstances, load: 4.0 or 5.0. Now after removing sprdwl_ng from /etc/modules, load: 0.01. Thank you so much!

Alright let me give you an example of cases where a generic overlay will be helpful. There can be cases where someone will just add a board that they have to armbian and disappear afterwards without adding overlay for it. Now users will come to the forum asking for what overlay they can use to enable i2c for example on header and such. If we have generic overlays, then the same can be avoided. Also its makes adding new boards easier for the same soc easier. Overlays will already be there and just can be straight forwardly tested or tweaked for the new board.
 
Thats where fixup scripts and parameters come in. You can see we have a lot of parameters for spi overlays for other socs like H3. Those gets documented in the readme file. User enables the overlay and add parameter in the armbianEnv.txt file. I do agree this can be further improved and armbian-config can be made to handle those parameters with some work, but it is still better than have 10+ overlays per board for say for say 5-10 boards per socs with 5-10 socs per kernel. You can imagine the amount of files that will be there if we keep adding overlays per board per soc. Also imagine if something changes in mainline kernel and due to that you need to say add a new configuration value to the overlay. How many files would need to be checked and modified?

I created the download page for it. So it should be even easier now - https://www.armbian.com/orange-pi-zero-3/

There is actually no need to build the image yourself. You can just download the latest nightly release from https://github.com/armbian/os/releases/latest

Player left the game. Case closed.

As you mentioned you had a serial adapter plugged into zero2 but not to the pc, its possible that the uart adapter might have sent some garbage character just when it says press any key to stop booting and hence it got stopped there. I have seen that happens sometimes when my serial adapters usb plug touches some metal or when I touch the same.

As this is not orange pi 4 that is being used, moved the thread to community forum and removed orange pi 4 label

Well.. one small line for orangepizero3.wip, one giant leap for Orange Pi Zero 3

The overlay PR fix from @Stephen Graf has been merged into Armbian.. thanks for sticking with it.. awesome to have more people contributing 
https://github.com/armbian/build/commit/08623d0e37dc02cb728b264f1e64771ddaba8025