sgjava

Yeah, I see it prompts once you add the CREATE_PATCHES="yes" It prompts twice. The only problem is the dts files do not contain the gpiomem section for some reason, but the downloaded image does. I'll figure it out eventually. Then where to put the PR

OK, found

@WernerI'm not sure where to make changes. The DTS files are in: ./cache/sources/u-boot-odroidxu/odroidxu4-v2017.05/arch/arm/dts/exynos5422-odroidxu4.dts ./cache/sources/linux-odroidxu4/odroid-5.4.y/arch/arm/boot/dts/exynos5422-odroidxu4.dts DTBs are in: ./cache/sources/u-boot-odroidxu/odroidxu4-v2017.05/arch/arm/dts/exynos5422-odroidxu4.dtb ./cache/sources/linux-odroidxu4/odroid-5.4.y/debian/tmp/usr/lib/linux-image-current-odroidxu4/exynos5422-odroidxu4.dtb ./cache/sources/linux-odroidxu4/odroid-5.4.y/debian/dtbtmp/boot/dtb-5.4.81-odroidxu4/exynos5422-odroidxu4.dtb ./cache/sources/linux-odroidxu4/odroid-5.4.y/arch/arm/boot/dts/exynos5422-odroidxu4.dtb So if I were a gambling man I'd change ./cache/sources/linux-odroidxu4/odroid-5.4.y/arch/arm/boot/dts/exynos5422-odroidxu4.dts before ./compile.sh CREATE_PATCHES="yes"?

@WernerPlease forgive me, but is there instructions somewhere to do this? I've never tried to build Armbian before.

I added a missing memory region from /dev/gpiomem and tested it. gpiomem { compatible = "samsung,exynos-gpiomem"; status = "okay"; reg = <0x13400000 0x1000 0x14010000 0x1000 0x03860000 0x1000>; }; I didn't see where to make PR on github.

OK, 0x03860000 looks to be missing from DT, so I'll test adding it. gpiomem { compatible = "samsung,exynos-gpiomem"; status = "okay"; reg = <0x13400000 0x1000 0x14010000 0x1000>; };

So I tried switching my MMIO GPIO to /dev/gpiomem from /dev/mem and it doesn't appear to support the GPZ block https://wiki.odroid.com/odroid-xu4/hardware/expansion_connectors#con_11_-_2x6_pins The address is 0x03860000. Hard Kernel's wiringPi doesn't seem to support this either. Should this be a question I ask Hard Kernel folks? https://wiki.odroid.com/odroid-xu4/software/gpio_register_map

@TRS-80I'm basically using the Armbian philosophy of making cross platform a reality. While SBCs like Raspberry Pi think they have a better ecosystem Armbian supports 100+ boards, so having software that can take advantage of that is more important in my opinion. I mean I'm basically using 15 Java classes to cover all the userspace IO stuff. Take a look around and you will see libraries with 100s of classes. In my mind it's pretty easy to support various devices, so I'm just concentrating on making the core solid and portable. In fact I just included the ODROID XU4 today which a lot of libraries do not support. Anyways, thanks for the recognition. Two home made ciders downed before dinner after today's commits. Back to work Monday...

I know, right? I had to power refactor the code after the S905 register madness. The good thing is the C2 (including J7) is supported generically.

I was able to build the property file for the NanoPi M1 in about 20 minutes, so now basically you can do ~2 MHz GPIO square wave on all Allwinner and S905 CPUs (you listening @TonyMac32?) without any special code or adapters. All other libraries require one off code to support GPIO register access thus they only support limited boards. In my mind this is the holy grail for cross platform GPIO performance. I plan on going through some more diverse boards, but I'm happy with the results so far. Since only one core is utilized you'll average 25% CPU utilization on quad core systems. That may be another goal using two threads to improve performance further. I have currently mapped Nano Pi Duo, Nano Pi M1, Nano Pi Neo Plus2 and Odroid C2. Check out Java Periphery for more information. Another thing to consider is that you can utilize the property files in other languages as well since there's Periphery APIs for C, Python and Lua as well.

Ah, but it wasn't last build, it was a version off, but yes for other boards it has been correct. I should have captured that, but that's behind me now

@Igor @TonyMac32as a bonus when you install kernel headers from armbian-config you get the correct version now!

@IgorArmbian_20.11.0-trunk.41_Odroidc2_focal_current_5.9.10.img did the trick. No hangs or death after apt upgrade and reboot!

Will do Monday AM, thanks guys!

I tried Armbian_20.11.0-trunk.32_Odroidc2_focal_current_5.9.8.img and Armbian_20.11.0-trunk.32_Odroidc2_buster_current_5.9.8.img and both will not boot after apt upgrade. Armbian_20.08.22_Odroidc2_focal_current_5.9.6.img will not come up after sudo reboot and has to be power cycled. I believe the latter has been a persistent issue.

So my whole goal with java-periphery was to create a decent cross platform userspace IO library which I believe I have achieved. One of my other goals was to create a high performance GPIO API that's also cross platform. If you look around there aren't any from what I can tell. Most high performance GPIO libraries support only a few boards. What I've done is use a well known interface (GPIO device) and some MMIO code to detect deltas and generate the required resisters and masks from an input file. This surely beats doing this by hand which I tried at first. The result is code that supports Allwinner H2+/H3 and H5/H6 by using just an input file. I'm going to look at other CPU types next, but this is promising. For more info check out High performance GPIO using MMIO.

I have been bouncing ideas around with@diozerofor using MMIO in a generic way to achieve fast GPIO for times when performance (bit banging, software based PWM, low CPU latency, etc) is required. This is my first attempt using a NanoPi Duo (H2+) which should work on any H2+ or H3 based SBC. What I've done is write a register mapper, so I can extract the register masks without having to do it by hand from the datasheet. Hand mask making is tedious and error prone. The generic part will come in by externalizing the register offsets and masks. This will happen after I build my next project using an Odroid C2. Also, since the Duo didn't have PUDs, so I could not map those. That will come with the C2. Anyways, the benefits are: Cross platform based on chipset. Most other high performance libraries only support a few boards since they bypass the kernel. Some may be faster, but if you only support a few deprecated boards what good is it? Look at https://periph.io/platform, https://github.com/SilverThings/bulldog, etc. Everything is pre-calculated instead of hideous code like this you have elegant code like this. More room for improvement using various MMIO techniques. Using my c-periphery wrapper for now. Performance comparison (look at the code to see what each method does). Note this is write frequency, not square wave frequency. Also note maximum CPU utilization is 25% because only one core is used leaving the rest for your program: 09:08:32.940 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Running GPIOD write test with 10000000 samples 09:09:13.933 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - 488138.24 writes per second 09:09:13.954 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Running good MMIO write test with 10000000 samples 09:09:49.957 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - 555555.56 writes per second 09:09:49.958 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Running better MMIO write test with 10000000 samples 09:10:22.007 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - 624102.85 writes per second 09:10:22.009 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Running best MMIO write test with 10000000 samples 09:10:27.246 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - 3820439.35 writes per second And the register mapper: 09:08:32.044 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Configuration registers 09:08:32.146 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 4 GPIOA4 Port A Reg CFG0 Mask 00010000 09:08:32.180 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 5 GPIOA5 Port A Reg CFG0 Mask 00100000 09:08:32.211 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 11 GPIOA11 Port A Reg CFG1 Mask 00001000 09:08:32.255 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 12 GPIOA12 Port A Reg CFG1 Mask 00010000 09:08:32.279 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 13 GPIOA13 Port A Reg CFG1 Mask 00100000 09:08:32.311 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 14 GPIOA14 Port A Reg CFG1 Mask 01000000 09:08:32.347 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 15 GPIOA15 Port A Reg CFG1 Mask 10000000 09:08:32.380 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 16 GPIOA16 Port A Reg CFG2 Mask 00000001 09:08:32.417 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 198 GPIOG6 Port G Reg CFG0 Mask 01000000 09:08:32.441 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 199 GPIOG7 Port G Reg CFG0 Mask 10000000 09:08:32.468 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 203 GPIOG11 Port G Reg CFG1 Mask 00001000 09:08:32.494 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 1 Pin 3 BUTTON Port L Reg CFG0 Mask 00001000 09:08:32.525 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 1 Pin 11 GPIOL11 Port L Reg CFG1 Mask 00001000 09:08:32.545 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Data registers 09:08:32.559 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 4 GPIOA4 Port A Reg DAT Mask 00000010 09:08:32.592 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 5 GPIOA5 Port A Reg DAT Mask 00000020 09:08:32.620 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 11 GPIOA11 Port A Reg DAT Mask 00000800 09:08:32.648 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 12 GPIOA12 Port A Reg DAT Mask 00001000 09:08:32.676 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 13 GPIOA13 Port A Reg DAT Mask 00002000 09:08:32.712 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 14 GPIOA14 Port A Reg DAT Mask 00004000 09:08:32.752 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 15 GPIOA15 Port A Reg DAT Mask 00008000 09:08:32.780 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 16 GPIOA16 Port A Reg DAT Mask 00010000 09:08:32.804 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 198 GPIOG6 Port G Reg DAT Mask 00000040 09:08:32.832 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 199 GPIOG7 Port G Reg DAT Mask 00000080 09:08:32.856 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 0 Pin 203 GPIOG11 Port G Reg DAT Mask 00000800 09:08:32.888 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 1 Pin 3 BUTTON Port L Reg DAT Mask 00000008 09:08:32.917 [main] INFO com.codeferm.periphery.demo.DuoMmioMap - Chip 1 Pin 11 GPIOL11 Port L Reg DAT Mask 00000800

An interesting fact (at least from what I can tell), the NanoPi Duo (v1.0 and v 1.1) has no builtin PUDs. Checking http://wiki.friendlyarm.com/wiki/images/8/8a/Schematic_NanoPi_Duo-v1.1.pdf and I see no PUDs on the GPIO schematic. Is this true? Is the Orange Pi Zero the same way?

OK, playing around with NanoPi Duo (H2+) to see what kind of performance boost I can get using MMIO (/dev/mem) instead of gpiod (forget sysfs) and it was pretty impressive. I used pre-calculated offset to run a square wave (rapid on/off) on pin 203 IOG11 and I hit ~3.8 MHz compared to ~500 KHz using gpiod. You can take a peek at the source at https://github.com/sgjava/java-periphery/blob/master/src/main/java/com/codeferm/periphery/demo/MmioTest.java. So the idea is how to make this generic with boards with multiple GPIO chips and different register configurations. The cool thing is the underlying MMIO stuff is kernel cross platform. Any ways I've been thinking about this for a while and now it's more of a reality. This was with 32 bit writes, I haven't tried 8 bit writes to see what the difference is. 18:20:05.423 [main] INFO com.codeferm.periphery.demo.MmioTest - 3832959.62 writes per second

So I'm working on a generic way to do MMIO GPIO on Armbian and chatting with @diozeroit seems like a wiringPi implementation is a good place to start for ideas. Armbian supports many FriendlyArm boards, so I took a look at https://github.com/friendlyarm/WiringNP. Of course out of the box it fails because it's probing for things found only in its home made OS distros. I found a way to hack the getBoardType function to hard code your board type for Armbian and probably other distros. This will work only on the board you hack it for. Honestly there should have been a way to pass in a parameter to override the detection code. In any event here's the method to use. Look up your board in BoardHardwareInfo in my case it's a NanoPi Duo, so I'd use this. Since arrays are zero based it falls on element 32. Now I hack getBoardType and right after that line add: *retBoardInfo = &gAllBoardHardwareInfo[32]; return gAllBoardHardwareInfo[32].boardTypeId; Then follow normal build instructions here. gpio readall +-----+-----+----------+------+---+-NanoPi-Duo--+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | MIC_N | | | 1 || 2 | | | EPhySPD | | | | | | MIC_P | | | 3 || 4 | | | EPhyLinK | | | | | | LineOutR | | | 5 || 6 | | | EPhyTXP | | | | | | LineOutL | | | 7 || 8 | | | EPhyTXN | | | | | | CVBS | | | 9 || 10 | | | EPhyRXP | | | | 198 | 8 | GPIOG6 | ALT5 | 0 | 11 || 12 | | | EPhyRXN | | | | 199 | 9 | GPIOG7 | ALT5 | 0 | 13 || 14 | | | USB-DP2 | | | | 15 | 7 | GPIOA15 | ALT5 | 0 | 15 || 16 | | | USB-DM2 | | | | 16 | 0 | GPIOA16 | ALT5 | 0 | 17 || 18 | | | USB-DP3 | | | | 14 | 2 | GPIOA14 | ALT5 | 0 | 19 || 20 | | | USB-DM3 | | | | 13 | 3 | GPIOA13 | ALT5 | 0 | 21 || 22 | 0 | OFF | GPIOG11 | 16 | 203 | | 12 | 12 | GPIOA12 | ALT5 | 0 | 23 || 24 | 0 | IN | GPIOL11 | 18 | -1 | | 11 | 13 | GPIOA11 | ALT5 | 0 | 25 || 26 | | | 0v | | | | | | 0v | | | 27 || 28 | | | 3.3v | | | | 4 | 14 | GPIOA4 | ALT5 | 0 | 29 || 30 | | | 5v | | | | 5 | 15 | GPIOA5 | ALT4 | 0 | 31 || 32 | | | 5v | | | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM | +-----+-----+----------+------+---+-NanoPi-Duo--+------+----------+-----+-----+ If you search there were other solutions by using /etc/sys_info, but I was too lazy to create that file.

@Korben_DallasYou can use https://github.com/vsergeev/python-periphery if you want to use pure Python. I'd definitely stick with Python 3 and skip Python 2. I modeled my code for Java after the *-periphery stuff, so once you learn one you can do JVM languages (Java, Groovy, Scala, etc.), C, Python and Lua using a similar API. This probably gives you the most language choices out there for device IO stuff using a unified API. Please note python-periphery is a lot slower than the C or my Java equivalent. You'll find Python in general is slow, so it depends on what you are doing. Also using kernel device IO you code will port to most boards Armbian supports and many other OS distributions. In my mind you want cross OS, cross board and cross language compatibility. As far as using a GUI IDE there's some hacks you can use. Under Ubuntu desktop (my dev PC) I just open a file window and use Ctrl+L and type ssh://board_ip to browse the dev board's file system. Obviously you can open files in Eclipse, NetBeans, etc. and dev source directly on the board. Just use a command shell to compile/run on the command line. Honestly though I just do all my dev on my PC and copy/compile the code on the target platform. There are some IDE solutions that will allow a seamless dev environment, but they are usually language and board specific.

Or maybe use hardware PWM if your board supports that? https://github.com/sgjava/java-periphery/blob/master/src/main/java/com/codeferm/periphery/demo/LedFlash.java

This is basically what https://github.com/sgjava/java-periphery uses. You could use C directly or my Java wrapper.

I sent you an email, so as not to pollute this thread. I believe it's possible to do MMIO GPIO based on some projects I've seen. I just need to do the mappings.

@diozeroWhen I say generic I mean there's not a particular class tied to a board (even if you use an interface to abstract away the implementation). I'd be OK with some common C or ASM code, but only the memory mapping would be board specific and require no custom code. If you look at my library there's no board specific code in it, thus it's cross platform (like your sysfs provider). I'll dig into your code some more, but this is basically what I was trying to stay away from. It may not be possible to do what I'm describing i.e. use MMIO to do GPIO.