I run a stock Debian system on a Banana Pi. Maybe this is stupid, I could be convinced; I’d suggest against the Allwinner chips unless there’s some reason you need features specific to them. The documentation and Linux support is… shoddy.

Hardware

CPU Temperature

Despite claims on Lemaker’s website, the file to read seems to be /sys/devices/platform/soc@01c00000/1c25000.rtp/hwmon/hwmon0/temp1_input.

I2C Busses

There are in fact five I2C busses exported on the A20 hardware, four of which are relevant to the Banana Pi. As the kernel ships (as of this writing, of course), only i2c0 (which is not exported) and i2c2 (which is) are enabled. You’ll want to add to the DTS:

&i2c1 {
        pinctrl-names = "default";
        pinctrl-0 = <&i2c1_pins_a>;
        status = "okay";
};

&i2c3 {
        pinctrl-names = "default";
        pinctrl-0 = <&i2c3_pins_a>;
        status = "okay";
};

The A20 calls the I2C bus “TWI” (as usual) and the busses are present on these pins; “multiplexer” means the pin mux system’s selection value as indicated in the datasheet. The bus number is also used in the DTS file, thankfully (though it seems that bus 4 is not enumerated there either).

BUS

0

1

2

3

4

SCK

PB0

PB18

PB20

PI0

PI2

SDA

PB1

PB19

PB21

PI1

PI3

Multiplexer

2

2

2

3

3

On the Banana Pi specifically, these map thusly:

BUS

0

1

2

3

4

SCK

n/a

CON1 P16

CON3 5

CON2 P04

n/a

SDA

n/a

CON1 P14

CON3 3

CON2 P02

n/a

CON3 is the GPIO pin header you’re probably interested in; the others are the camera (CON1) and LCD expansions (CON2) and are a pain, but maybe the busses are still of some utility.

SPI Busses

The hardware breaks out two SPI busses but for reasons beyond me doesn’t advertize the 2nd one.

BUS

Function

A20 Pin

BPI Pin

0

CLK

PI11

CON3 23

MOSI

PI12

CON3 19

MISO

PI13

CON3 21

CS0

PI10

CON3 24

CS1

PI14

CON3 26

1

CLK

PI17

CON3 15

MOSI

PI18

CON3 13

MISO

PI19

CON3 11

CS0

PI16

CON3 22

CS1

PI15

n/a

To use the second one, this stanza should go in the DTS file, I presume:

&spi1 {
      pinctrl-names = "default";
      pinctrl-0 = <&spi1_pins_a>,
                  <&spi1_cs0_pins_a>,
                  <&spi1_cs1_pins_a>;
      status = "okay";
};

Despite documentation on the Internet, you should be fine using spi-sun4i.ko rather than some mythical spi-sun7i.ko.

Unfortunately, late binding seems busted. So perhaps you will want to have the following stanza in the DTS file, replacing the existing spi0 stanza:

&spi0 {
      pinctrl-names = "default";
      pinctrl-0 = <&spi0_pins_a>,
                  <&spi0_cs0_pins_a>,
                  <&spi0_cs1_pins_a>;
      status = "okay";

      spidev@0 {
              compatible = "linux,spidev";
              reg = <0>;
              spi-max-frequency = <150000000>;
      };

      spidev@1 {
              compatible = "linux,spidev";
              reg = <1>;
              spi-max-frequency = <150000000>;
      };
};

Thanks mostly to https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg05893.html for that; 150MHz comes from the A20 datasheet.

Note

As of this writing there is some bug somewhere which causes a full-duplex loopback test to not always return the same data as it writes.

Software

Compiling a new DTB

You could run the DT compiler by hand (from the Linux tree):

./scripts/dtc/dtc -I dts -O dtb \
  -o arch/arm/boot/dts/sun7i-a20-bananapi.dtb \
     arch/arm/boot/dts/sun7i-a20-bananapi.dts

Or, if you’re in the Linux kernel tree (because of course you are):

make ARCH=arm sun7i-a20-bananapi.dtb