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