indianajones

@tparys my apologies, I missed that. I'll give it a go, maybe I'll learn something.

@tparys yes that's how I'm doing it. I boot a working image, and try to add the overly using armbian-add-overlay, which throws no errors, and I get the message that a reboot is required to make it live. It never recovers from the reboot (at least it never recovers far enough to ping it, I don't have HDMI connected).

It says "one period per irq bank found in the controller". My interpretation of that is I would need three values - one each for GPIO A, G, and L, e.g. input-debounce <1 1 1>. However, other posts imply only two values are required. But unfortunately my biggest problem is that any attempt to change the main pio (pinctrl@1c20800) section bricks the device. I can make changes to sub-sections inside pinctrl@1c20800, so I *almost* know what I'm doing. But the optional input-debounce is a property of the main pinctrl@1c20800 itself. I believe that once I get that resolved, I'll be able to troubleshoot my way to learning the proper debounce values.

I'm trying to add the optional input-debounce to the GPIO G ports of my NanoPi NEO (AllWinner H3) with a device tree overlay, but my overlay merely manages to brick the device. Here is my overlay, of which I've tried several tweaked versions: /dts-v1/; /plugin/; / { fragment@0 { target = <&pio>; __overlay__ { input-debounce = <1 1>; }; }; }; I create the file on the running device and I use 'sudo armbian-add-overlay <file.dts>' and reboot to test my changes. I'm using <&pio> as the target because I see in the device tree that &pio is a symbol to "/soc/pinctrl@1c20800". As for the actual input-debounce values, I'm not 100% sure what should go in there, or how many arguments I need. I've experimented with two or three values inside the <> (always a 1), and those tweaks always brick the device. It's as if the device tree compiler is treating it as a complete device tree subsection rather than an overlay. Does anyone have suggestions of what I might be doing wrong? Thanks!

Good news! I was able to follow the devmem2 instructions in this forum article posted by @Ohms, and get all 26 pulses (by modifying the debounce timer). Result!

I'm writing a wiegand protocol handler in a Linux Kernel Module for the NanoPi NEO (AllWinner H3). I have the code working, meaning the interrupt handlers for the D0 and D1 pins do in fact get called when I swipe a prox card. However, I'm missing usually about half or more of the 26 bits. The wiegand protocol is 26 pulses, each pulse 50uS wide, and separated by 2000us, so yeah it has to be fast. I've set the debounce value to zero using gpio_set_debounce(), so it's running as quickly as I can make it without patching Linux source. After doing some reading, I think I need to modify the device tree to make the default polling speed for GPIOA pins faster. Or maybe I need to make the debounce values shorter, not sure which. But this is the first time I will have messed with the device tree, and I could use some pointers on the H3 device tree. Thanks!

Indeed. I am still curious.

I was able to successfully build and run PREEMPT_RT with a current kernel running Ubuntu focal on a nanopineo, getting these results in cyclictest: sudo cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 1.41 1.40 1.11 1/154 3261 T: 0 ( 3242) P:80 I:200 C:4589037 Min: 18 Act: 30 Avg: 25 Max: 125 T: 1 ( 3243) P:80 I:200 C:4588573 Min: 17 Act: 23 Avg: 26 Max: 105 T: 2 ( 3244) P:80 I:200 C:4588088 Min: 18 Act: 32 Avg: 27 Max: 111 T: 3 ( 3245) P:80 I:200 C:4587408 Min: 18 Act: 30 Avg: 25 Max: 105 Steps to build your own: 1. Build a normal armbian image, using current kernel and ubuntu focal for nanopineo (or your board), mostly to discover the full kernel version that gets built. Note that, as is mentioned in this thread, the AllWinner-based boards do not get their code from the mainline Linux github repo, but rather from a forked repo at https://github.com/megous/linux/. This repo is specified in ~/build/config/sources/families/include/sunxi_common.inc. You do not need to make any changes to that file, I'm just noting it as an FYI. ./compile.sh BOARD=nanopineo BRANCH=current RELEASE=focal KERNEL_ONLY=no BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_CONFIGURE=no AUFS=no 2. Check the kernel version from the build output. Currently, that version is 5.10.21. Download the PREEMPT_RT patch that most closely matches the kernel version. NOTE: maybe you can download *any* RT patch file version that's at least the same or newer, but I went with the same because it makes sense to me: cd build/userpatches/kernel/sunxi-current # You'll probably have to mkdir the sunxi-current folder the first time wget https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/5.10/older/patch-5.10.21-rt34.patch.gz gunzip patch-5.10.21-rt34.patch.gz 3. Build another armbian image, this time with an extra parameter, EXTRAWIFI=no. I've discovered that the patch-5.10.xx-rtYY.patch files somehow cause at least one of the Realtek Wifi drivers to throw a compiler error (in the rt_spinlock code). If you need Realtek Wifi (and any other Wifi built by EXTRAWIFI=yes, you'll have to find another solution. Sorry. Also, I now set KERNEL_CONFIGURE=yes because I think that it won't let you choose "Full PREEMPT_RT" without you setting KERNEL_CONFIGURE=yes. So when prompted during the build, choose option 4 (full PREEMPT): ./compile.sh BOARD=nanopineo BRANCH=current RELEASE=focal KERNEL_ONLY=no BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_CONFIGURE=yes AUFS=no EXTRAWIFI=no 4. From there, just deploy the image like you do any other image. uname -a Linux nanopineo 5.10.21-rt34-sunxi #trunk SMP PREEMPT_RT Sun Apr 18 22:21:06 EDT 2021 armv7l armv7l armv7l GNU/Linux Note that I also created a ~/build/userpatches/lib.config file that limited the CPU frequency to a paltry 480Mhz fixed value because I don't have a heat sink on the H3: GOVERNOR=performance CPUMIN=480000 CPUMAX=480000 Q: Is this possible with the legacy kernel? A: Probably, if you use EXTRAWIFI=no, but I haven't tested it. Both legacy and current kernels had compiler failures for various reasons, but most frequently with RealTek. Q: Will this work for any AllWinner SoC? A: I'm pretty sure that any H2/H3 AllWinner will work, as they are the same chipset as the nanopineo I'm using. I don't know about H5 or A-series. Q: I thought tparys told you that any version of PREEMPT_RT might not give you the determinism you need to read wiegand? A: Yes, and I still agree, but this was just bugging me that I couldn't successfully build one.

I've thought using a PIC chip as a dedicated wiegand-to-serial converter, then just read serial off the H3 GPIO. Maybe that's my best bet after all, as I do need reliability.

Thanks for the link and information. To be honest, I'm approaching this from a position of ignorance. I need to be able to read wiegand data from GPIO pins on the H3, but (a) I'm not creating some toy with a while() loop, I'm creating a real product that will be doing real things while reading wiegand data, and (b) I assume that RT will give me the most reliable determinism for reading pins at 50-200uS timings that wiegand uses. I believe that one way to do that is with a more deterministic kernel. I've tried 5.4 and 5.10 variants, and all of them fail to compile when I include an RT patch, regardless of which RT patch version I pick. Do you think v5.10 includes sufficient improvements for GPIO pin reading?

C language was all I did - last century! I'd love to contribute any changes I need to make, but at the moment, the language is barely recognizable anymore. Such a shame.

NicoD, your YouTube videos are why I chose Armbian. I think the Armbian tools are awesome, and I'm grateful to those who created and maintain it.

So that explains the reference to https://github.com/megous/linux/tree/orange-pi-5.4 inside sunxi_common.inc. I assume this also means that since I'm trying using an RT patch file on a fork of mainline Linux rather than the actual mainline Linux, that there's a good chance that the patch will produce a compiler error. (As an aside, I wonder how @mycnc was able to use "tag:v5.4.28" successfully since he was also using the AllWinner H3.) Now that I understand why I got this error, I'll see if I can resolve it. Thanks, Igor.

I realize it's almost exactly one year later, but I'm trying to same thing for nanopineo. I copied patch-5.4.28-rt19.patch (to userpatches/kernel/sunxi-legacy), and put KERNELBRANCH="tag:v5.4.28" into lib.config, and the build tool says that tag v.5.4.28 doesn't exist: [ o.k. ] Using config file [ /home/armbian/build/userpatches/config-example.conf ] [ o.k. ] Command line: setting BOARD to [ nanopineo ] [ o.k. ] Command line: setting BRANCH to [ legacy ] [ o.k. ] Command line: setting RELEASE to [ focal ] [ o.k. ] Command line: setting KERNEL_ONLY to [ no ] [ o.k. ] Command line: setting BUILD_MINIMAL to [ yes ] [ o.k. ] Command line: setting BUILD_DESKTOP to [ no ] [ o.k. ] Command line: setting KERNEL_CONFIGURE to [ yes ] [ o.k. ] Command line: setting DEFAULT_HOSTNAME to [ eid-00000000 ] [ o.k. ] Command line: setting AUFS to [ no ] [ o.k. ] Using user configuration override [ /home/armbian/build/userpatches/lib.config ] [ o.k. ] Preparing [ host ] [ o.k. ] Build host OS release [ focal ] [ o.k. ] Syncing clock [ host ] [ o.k. ] Checking for external GCC compilers [ o.k. ] Downloading sources [ o.k. ] Checking git sources [ u-boot v2021.04 ] [ .... ] Cleaning .... [ 99 files ] [ o.k. ] Checking git sources [ linux-mainline v5.4.28 ] [ .... ] Fetching updates fatal: couldn't find remote ref tags/v5.4.28 Can anyone tell what I'm doing wrong? Thanks. PS - these tools are awesome

My apologies, I didn't realize I was posting in the bugs forum. Regarding documentation, I've read plenty of the documentation - it is excellent. However, I didn't find references to the config files used to build the supported images. My apologies for not finding them.