############################## Notes on the Lemaker Banana Pi ############################## 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