Java diozero on Armbian

[diozero]

Hi there, I'm, the maintainer of the Java library diozero and am looking to test the library on Armbian. I have quite a few devices but am looking to test with a TinkerBoard and Odroid C2.

 

The library includes support for GPIO, I2C, SPI and serial. It includes very high performance memory mapped GPIO control (~10MHz) as well as sysfs and more recently GPIO character device.

 

I've test the GPIO character device code on the Raspberry Pi and just looking at adding support for Armbian. I'm seeing gpioinfo doesn't include GPIO names which I see on the Raspberry Pi (everything is "unnamed") - is there anyway to fix that?

[JMCC]

@martinayotte Any insights on this?

[martinayotte]

3 hours ago, diozero said:

I'm seeing gpioinfo doesn't include GPIO names

 

2 hours ago, JMCC said:

Any insights on this?

 

I not very familiar with libgpiod and how gpio names are coming from the kernel.

It seems that all gpios are uname on both Allwinner and Rockchip SoC, but seems that some are present in AmLogic.

But looking at some of my AmLogic boards, it seems pretty dependent of pin headers of the specific boards by using "gpio-line-names" property in "pinctrl" node in DT.

This is why Allwinner and Rockchip don't have names, there is no "gpio-line-names" property present in the DT ...

 

EDIT: BTW, my AmLogic boards are NanoPi-K2 and Odroid-N2 ...

[diozero]

Ok. Given that I am completely new to device tree overlays... It seems the dts file is missing the GPIO labels. I've been doing a bit of searching and have located the rk3288-tinker.dts and .dtsi files for my kernel version (5.8.16).

 

Attempting to run:

sudo armbian-add-overlay rk3288-tinker.dts

I get this strange error:

Overlays are not supported on Rockchip based boards

 

I'm unable to "compile" this dts file:

dtc -I dts -O dtb -o matt.dtbo rk3288-tinker.dt

FATAL ERROR: Couldn't open "dt-bindings/gpio/gpio.h": No such file or directory

 

Any help here would be greatly appreciated.

[martinayotte]

1 hour ago, diozero said:

FATAL ERROR: Couldn't open "dt-bindings/gpio/gpio.h": No such file or directory

This error is there because you tried to compile original DTS outside kernel tree.

 

You should rather decompile existing/working DTB into temporary DTS, edit this one, and recompile it into new DTB.

[sgjava]

@diozeroif you look at my library java-periphery you will see some Armbian related info there (including device tree stuff). I ended up just wrapping c-periphery since it supports deprecated sysfs and currently supported gpiod. I abandoned libgpiod because it was more difficult to compile and c-periphery can be compiled inline using hawtjni. It would be interesting if you got MM GPIO working on Armbian in a generic way, but I didn't see an easy way to do it. I'm OK with gpiod since it has decent performance and is cross platform out of the box.

[diozero]

That's brilliant, thank you. I added this to the gpio0 definition:

gpio-line-names =
                                "","","","","","","","",
                                "","","","","","","","",
                                "line16","GPIO0_C1","line18","","","","","";

Rebooted and gpioinfo gpiochip0 now outputs:

gpiochip0 - 24 lines:
    line   0:      unnamed       unused   input  active-high
    line   1:      unnamed       unused   input  active-high
    line   2:      unnamed       unused   input  active-high
    line   3:      unnamed      "led-2"  output  active-high [used]
    line   4:      unnamed       unused   input  active-high
    line   5:      unnamed "GPIO Key Power" input active-low [used]
    line   6:      unnamed       unused   input  active-high
    line   7:      unnamed       unused   input  active-high
    line   8:      unnamed       unused   input  active-high
    line   9:      unnamed       unused   input  active-high
    line  10:      unnamed       unused   input  active-high
    line  11:      unnamed        "dvs"  output  active-high [used]
    line  12:      unnamed        "dvs"  output  active-high [used]
    line  13:      unnamed       unused   input  active-high
    line  14:      unnamed       unused   input  active-high
    line  15:      unnamed       unused   input  active-high
    line  16:     "line16"       unused   input  active-high
    line  17:   "GPIO0_C1"       unused   input  active-high
    line  18:     "line18"       unused   input  active-high
    line  19:      unnamed       unused   input  active-high
    line  20:      unnamed       unused   input  active-high
    line  21:      unnamed       unused   input  active-high
    line  22:      unnamed       unused   input  active-high
    line  23:      unnamed       unused   input  active-high

I just need to update all of the other GPIOs now.

To answer your question, yes I do have memory mapped GPIO control working in a generic way in diozero - tested and working on BBB, Odroid C2, and Raspberry Pi. I get ~25MHz toggle speed on my RPi4. It used to work on the TinkerBoard - reads still work but writes no longer work. I see that the C library has been updated to invoke inline ASM code instead now. I have gpio character device fully working in my latest snapshot build, just working on fully integrating it into my library - handle all possible scenarios, e.g. where they are named properly as per the Pi ("GPIO18"), have no names and have logical names (e.g. "GPIO0_C1").

Here's the mmap code that used to work on the TinkerBoard:

https://github.com/mattjlewis/diozero/blob/master/diozero-core/src/main/java/com/diozero/internal/board/tinkerboard/TinkerBoardMmapGpio.java

[sgjava]

@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.

[diozero]

Ok, I see what you're saying. I don't believe you can do completely generic and board independent mmap GPIO I/O - even if you could work out a dynamic register mapping with associated bit masks that could be externalised into config files, the mechanism are quite different between boards. The best you can do would be board specific plugins as I've done. Note that my implementation allows for external plugins to be dynamically added via separate JAR files.

 

I'm hoping that I can simply provide two versions (32bit and 64 bit) of my internal C abstraction library (for the I2C, SPI, gpiod,  and serial stuff that you can't do in pure Java) so that my library can work on most boards. I'm just doing a little refactoring to the API - the GPIO API was based on there being well defined GPIO numbers - this has worked well to date, however, cannot be relied upon for gpiod.

 

Armbian is proving absolutely fantastic, kudos to those maintaining it. I have an Odroid C2 and TinkerBoard that were feeling a bit unloved.

 

Odroid C2 pinout - I see that the GPIO numbering is completely different in Armbian to the original Kernel:

+-----+-----------------+--------+----------+--------+-----------------+-----+
+ GP# +            Name +  gpiod + Physical + gpiod  + Name            + GP# +
+-----+-----------------+--------+----------+--------+-----------------+-----+
|     |            3.3V |   :    |  1 || 2  |   :    | 5V              |     |
| 447 |       I2C A SDA |  1:69  |  3 || 4  |   :    | 5V              |     |
| 448 |       I2C A SCK |  1:70  |  5 || 6  |   :    | GND             |     |
| 491 |  J2 Header Pin7 |  1:113 |  7 || 8  |  1:104 | J2 Header Pin8  | 482 |
|     |             GND |   :    |  9 || 10 |  1:105 | J2 Header Pin10 | 483 |
| 489 | J2 Header Pin11 |  1:111 | 11 || 12 |  1:102 | J2 Header Pin12 | 480 |
| 481 | J2 Header Pin13 |  1:103 | 13 || 14 |   :    | GND             |     |
| 479 | J2 Header Pin15 |  1:101 | 15 || 16 |  1:100 | J2 Header Pin16 | 478 |
|     |            3.3V |   :    | 17 || 18 |  1:97  | J2 Header Pin18 | 475 |
| 477 | J2 Header Pin19 |  1:99  | 19 || 20 |   :    | GND             |     |
| 474 | J2 Header Pin21 |  1:96  | 21 || 22 |  1:95  | J2 Header Pin22 | 473 |
| 472 | J2 Header Pin23 |  1:94  | 23 || 24 |  1:93  | J2 Header Pin24 | 471 |
|     |             GND |   :    | 25 || 26 |  1:89  | J2 Header Pin26 | 467 |
| 449 |       I2C B SDA |  1:71  | 27 || 28 |  1:72  | I2C B SCK       | 450 |
| 470 | J2 Header Pin29 |  1:92  | 29 || 30 |   :    | GND             |     |
| 461 | J2 Header Pin31 |  1:83  | 31 || 32 |  1:88  | J2 Header Pin32 | 466 |
| 476 | J2 Header Pin33 |  1:98  | 33 || 34 |   :    | GND             |     |
| 456 | J2 Header Pin35 |  1:78  | 35 || 36 |  1:82  | J2 Header Pin36 | 460 |
|   1 |            AIN1 |   :    | 37 || 38 |   :    | 1.8V            |     |
|     |             GND |   :    | 39 || 40 |   :    | AIN0            | 0   |
+-----+-----------------+--------+----------+--------+-----------------+-----+

 

TinkerBoard pinout having added the GPIO labels to the dtb:

+-----+----------+--------+----------+--------+----------+-----+
+ GP# +     Name +  gpiod + Physical + gpiod  + Name     + GP# +
+-----+----------+--------+----------+--------+----------+-----+
|     |     3.3V |   :    |  1 || 2  |   :    | 5V       |     |
| 252 | GPIO8_A4 |  8:4   |  3 || 4  |   :    | 5V       |     |
| 253 | GPIO8_A5 |  8:5   |  5 || 6  |   :    | GND      |     |
|  17 | GPIO0_C1 |  0:17  |  7 || 8  |  5:9   | GPIO5_B1 | 161 |
|     |      GND |   :    |  9 || 10 |  5:8   | GPIO5_B0 | 160 |
| 164 | GPIO5_B4 |  5:12  | 11 || 12 |  6:0   | GPIO6_A0 | 184 |
| 166 | GPIO5_B6 |  5:14  | 13 || 14 |   :    | GND      |     |
| 167 | GPIO5_B7 |  5:15  | 15 || 16 |  5:10  | GPIO5_B2 | 162 |
|     |     3.3V |   :    | 17 || 18 |  5:11  | GPIO5_B3 | 163 |
| 257 | GPIO8_B1 |  8:9   | 19 || 20 |   :    | GND      |     |
| 256 | GPIO8_B0 |  8:8   | 21 || 22 |  5:19  | GPIO5_C3 | 171 |
| 254 | GPIO8_A6 |  8:6   | 23 || 24 |  8:7   | GPIO8_A7 | 255 |
|     |      GND |   :    | 25 || 26 |  8:3   | GPIO8_A3 | 251 |
| 233 | GPIO7_C1 |  7:17  | 27 || 28 |  7:18  | GPIO7_C2 | 234 |
| 165 | GPIO5_B5 |  5:13  | 29 || 30 |   :    | GND      |     |
| 168 | GPIO5_C0 |  5:16  | 31 || 32 |  7:23  | GPIO7_C7 | 239 |
| 238 | GPIO7_C6 |  7:22  | 33 || 34 |   :    | GND      |     |
| 185 | GPIO6_A1 |  6:1   | 35 || 36 |  7:7   | GPIO7_A7 | 223 |
| 224 | GPIO7_B0 |  7:8   | 37 || 38 |  6:3   | GPIO6_A3 | 187 |
|     |      GND |   :    | 39 || 40 |  6:4   | GPIO6_A4 | 188 |
+-----+----------+--------+----------+--------+----------+-----+

 

BTW, apologies for the delayed response - I'm still limited to 1 post per day...

[sgjava]

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.