sgjava

@martinayotte OK, tried this and no luck on duo: ls /boot/dts/overlay/ sun8i-h3-gpio-line-names.dtbo cat /boot/armbianEnv.txt verbosity=1 bootlogo=false console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=usbhost2 usbhost3 rootdev=UUID=d1e6e420-cd58-46c8-aa52-0f8cd59dabb7 rootfstype=ext4 overlays=gpio-line-names usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u cat sun8i-h3-gpio-line-names.dts /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@1 { target = <&pio>; __overlay__ { gpio-line-names = "", "", "", "", "GPIOA4 DTX", "GPIOA5 DRX", "", "", "", "", "", "GPIOA11 SCL", "GPIOA12 SDA", "GPIOA13 CS", "GPIOA14 CLK", "GPIOA15 MO", "GPIOA16 MI", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "GPIOG6 TX1", "GPIOG7 RX1", "", "", "", "GPIOG11 IOG11"; }; }; }; I suspect it has something to do with multiple pin controllers? pinctrl@1c20800 and pinctrl@1f02c00? Also noticed Duo has compatible = "allwinner,sun8i-h3-r-pinctrl";

@martinayotte do you have an example for /boot/armbianEnv.txt gpio-line-names? This is generated board specific, correct? How would I do it that way for Duo? I'll try my grep-fu and google-fu in the meantime. I assume you are talking about loading the overlay from armbianEnv.txt i.e. https://docs.armbian.com/User-Guide_Allwinner_overlays

@martinayotteI finally got my VM cranking and build pulled down. Looking around based on what you said wouldn't something duo specific be better off in something like ./patch/kernel/sunxi-dev/board-h2plus-nanopi-duo-add-device.patch? I still need to look at Makefile, but this should only impact Duo.

OK, let me try that. Working on a new build VM today.

@martinayotte yes, and in that case XU3 had same lines, but my question was how do I do this for Duo using overlay, but make it part of normal build process?

@martinayotte so I'm trying to make this part of the build like https://github.com/armbian/build/pull/2449 so it's part of the image. How would that work?

@martinayotte I need to know how to do overlay. I already know how to do gpio-line-names already, thanks.

@martinayotteis this documented somewhere? I'll give that a try.

@IgorI plan on doing other allwinner boards, so a universal solution would be nice. Having the GPIO line names are a big help when using the kernel userspace tools.

@IgorYep, go ahead and reject that PR. How would a do an overlay for just the NanoPi Duo?

@Werner done https://github.com/armbian/build/pull/2505

Maybe my grep-fu is not powerful or following endless includes, but I ended up changing build/cache/sources/linux-mainline/orange-pi-5.9/arch/arm/boot/dts/sunxi-h3-h5.dtsi which seems like it would change other boards. Is there a surefire way to make the changes in the proper place for the Duo? I tested the image I built and indeed this changes the dtb correctly, but will it effect orange pi, etc boards too (h3-h5 boards)? @Igor I have the changes ready to commit, but I didn't want to do something that effects multiple boards.

It looks like someone already has run Armbian on this board according to the reviews, but it looks like the headers are not soldered on as pictured. Probably why it's $10.

I didn't see support specifically for NanoPi NEO-LTS https://www.friendlyarm.com/index.php?route=product/product&product_id=132 Does one of the other images work on this particular board?

@Wernercheck out https://github.com/sgjava/patchbian I just submitted another PR, so I'd have it down exactly. I'll add this to the official docs when I have some more time. For now this is a fresh core dump of the process. Let me know if there's any improvements. I was done all cli without using GitHub web UI.

So if you look at the device tree you'll see pin controllers like GPA0, GPA1, etc. I'm not sure how the kernel gpio device enumerates them, but basically a chip is a pin controller and lines are the pins. The main thing is soon you'll be able to look at a pin map and know exactly which physical pin it is. Also gpioinfo seems to sort by chip string instead of int, thus 2, 21, 22, etc. are all 2s

OK, so while documenting the Armbian patch process I needed something actual to patch. I added gpio-line-names to the device tree, so now all lines are defined. Once I finish the documentation I'll PR this patch. No more guessing what physical pin is! At some point it might make sense to put in jumper and physical pin #.

I'm going to try github command line, so you don't have to fork, etc. on the web UI. Hopefully I can do it all command line.

I'll do that after write doc I build the readm.md. I'm just using the markdown editor in Eclipse. I don't have to put it on github.

@TRS-80OK, I'll do a readme.md and post to my github, so you can scarf that. You need to configure gpg and other junk I wasn't expecting. On the plus side I still have my Ubuntu VM console history!

@IgorSo I'm thinking about documenting the steps since I didn't see a detailed description in the docs (maybe I missed it). Also, going to try to add pin descriptions for gpio device, so gpioinfo is fully populated. Is this info in the device tree as well?

@WernerOK hopefully https://github.com/armbian/build/pull/2438 is correct or I'm sure @Igorwill be by to smack me around

OK, makes sense.

OK, almost there. Looks like I had to mod an include and it generated build/output/patch/kernel-odroidxu4-current.patch, but if I look at https://github.com/armbian/build/tree/master/patch/kernel/odroidxu4-current I see patches with what looks like kernel version suffixes. Should I rename this file. I'm at the last mile!

So I make change before kernel is built? Or is dts part of uboot (since it's in /boot :)) process?