testers wanted Testers wanted: sunxi Device Tree overlays

[zador.blood.stained]

From Armbian documentation (https://docs.armbian.com/User-Guide_Allwinner_overlays/)

 

Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, …) don’t have a mechanism for detecting and identifying devices connected to the bus, so Linux kernel has to be told explicitly about the device and its configuration details.

 

While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default.

 

What do we want?

 

We want to add Device Tree overlays for the onboard interfaces and tested external devices so that they appear in future mainline Armbian images. This means that activating this type of hardware will not require recompiling the Device Tree or will require compiling just the overlay file which will be compatible with future kernel updates.

 

What kind of help do we expect?

 

We want people to participate in making and testing overlays for the hardware that they have.

Participation requirements:

• An A10, A20 or H3 board that can boot the current mainline kernel
• Serial console adapter for getting the u-boot logs if they are needed
• Extra SD card to use for booting the nightly/beta images
• I2C, SPI or I2S (only A10 and A20 based boards since I2S driver is not present on H3 yet) device that you can connect to the board and that requires either generic driver (like SPIdev) or a special driver (available in the mainline kernel), with an exception of custom built boards that don't have commercially available compatible alternatives and devices that don't have in-tree kernel drivers.
• Some generic Linux knowledge (i.e. how to obtain a dmesg log, how to check file contents)
• At least a basic understanding of the hardware that you have and how does it integrate into Linux. For example I have no idea how to calibrate a resistive touch screen even if I can write a DT overlay for it.
• Please note that some hardware limitations (i.e. number of SPI chip selects, missing SPI DMA support) may affect possibility of supporting some devices

 

What overlays are already available?

 

Please check the README in the subdirectory for your SoC in the overlays repository: https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian

Edited April 1, 2017 by zador.blood.stained
Updated the documentation link

[vlad59]

Hi,

 

Just to be sure to understand, to make some test on A20 (Banana Pi in my case), I simply need latest Armbian (either 5.25 or 5.26) as you can see here :

root@marvin:~# dpkg -l | grep kernel
ii  cpufrequtils                    008-1                      armhf        utilities to deal with the cpufreq Linux kernel feature
ii  kmod                            18-3                       armhf        tools for managing Linux kernel modules
ii  libcpufreq0                     008-1                      armhf        shared library to deal with the cpufreq Linux kernel feature
ii  linux-headers-next-sunxi        5.26                       armhf        Linux kernel headers for 4.9.12-sunxi on armhf
ii  linux-image-next-sunxi          5.26                       armhf        Linux kernel, version 4.9.12-sunxi
ii  rsyslog                         8.4.2-1+deb8u2             armhf        reliable system and kernel logging daemon
root@marvin:~# cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=bananapi
BOARD_NAME="Banana Pi"
VERSION=5.25
LINUXFAMILY=sunxi
BRANCH=next
ARCH=arm
IMAGE_TYPE=stable
root@marvin:~# uname -a
Linux marvin 4.9.12-sunxi #4 SMP Thu Feb 23 19:46:51 CET 2017 armv7l GNU/Linux

Or do I need a nightly build ?

 

I can test the various i2c buses (I'm currently using i2c-1 with 3 sensors). I could also test i2s but I don't think it's available on the Banana Pi.

 

 

[zador.blood.stained]

1 hour ago, vlad59 said:

Or do I need a nightly build ?

You need to build the image or use a nightly build (I can add nightlies for the boards that don't have them enabled)

 

1 hour ago, vlad59 said:

I can test the various i2c buses (I'm currently using i2c-1 with 3 sensors).

What sensors exactly? Some of them may have in-kernel drivers (which may be more interesting than reading them via i2c)

 

1 hour ago, vlad59 said:

I could also test i2s but I don't think it's available on the Banana Pi.

Yes, not available according to the schematics.

[vlad59]

There is a nightly build for Banana pi so it should be ok for me. About my i2c sensors I have SI7021 (Temperature, humidity), BH1750 (Illuminance), BME280 (Temperature, Humidity, Pressure) I don't think there are kernel drivers for any of them, I personally use a python script to use them.

 

I may also have a couple of DS1307 RTC clock (never used them) that should have kernel drivers if you prefer.

[zador.blood.stained]

7 minutes ago, vlad59 said:

SI7021 (Temperature, humidity)

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/iio/humidity/si7020.c

 

9 minutes ago, vlad59 said:

BH1750 (Illuminance)

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/iio/light/bh1750.c

But doesn't look like this one is DT-aware.

 

11 minutes ago, vlad59 said:

BME280 (Temperature, Humidity, Pressure)

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/iio/pressure/bmp280-i2c.c

12 minutes ago, vlad59 said:

DS1307 RTC clock

Will be added too

[vlad59]

Oh boy ..... ok .... coming from Arduino, I never even thought of looking for a kernel module.

 

Anyway I'll get a spare SD card, prepare a breadboard and make some test. The BME280 could also work with SPI (never tried it before), I'll try that also.

[vlad59]

I thought about all your question about kernel drivers / DT aware kernel drivers, etc. Do you plan to create overlays in Armbian like the Raspberry pi folks did, I looked at this one for example where bmp085 bme80 and si7020 are included :

https://github.com/ajtucker/linux/blob/rpi-4.4.y/arch/arm/boot/dts/overlays/i2c-sensor-overlay.dts

Great idea !

[zador.blood.stained]

8 minutes ago, vlad59 said:

I thought about all your question about kernel drivers / DT aware kernel drivers, etc. Do you plan to create overlays in Armbian like the Raspberry pi folks did, I looked at this one for example

https://github.com/ajtucker/linux/blob/rpi-4.4.y/arch/arm/boot/dts/overlays/i2c-sensor-overlay.dts

Yes. Main problems / considerations here are:

• We have multiple platforms/SoCs, and most overlays will need modifications / adjustments for each platform
• Compared to RPi we don't have support for overlay parameters, so instead we use u-boot scripts which have some limitations
• Compared to RPi SoCs, Allwinner A20, for example, has 4 SPI controllers, 5 I2C controllers and 8 UART controllers, and for I2C/SPI devices we have to support attaching devices to each of potentially available bus/controller

So instead of blindly trying to port all existing RPi overlays it will be easier to add them by user requests.

[zador.blood.stained]

Current nightlies (with 4.10.x kernel for sunxi devices) should already have the overlay for DS1307

 

[vlad59]

After sending 2 old SD card on the bin (even if Etcher was saying that everything was alright my Banana pi did not like them), I booted my Banana pi with latest nightly (4.10.3-sunxi).

By default I still have i2c-1 available and no overlay loaded in armbianEnv.txt.

 

I checked every other i2c channel in https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun7i-a20.dtsi#L1141-L1159

and https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian/tree/master/sun7i-a20

Conclusion : either I'm blind or I can't enable another i2c channel on the banana pi (and no I don't want to fiddle with the DSI interface to get PI0/1). So I'll cancel any i2c test for now.

 

It's getting late for me (so I may be blind) but tomorrow I'll grab a couple of DS18B20 and test one wire overlay, that should be easier.

 

[zador.blood.stained]

41 minutes ago, vlad59 said:

I checked every other i2c channel in https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/sun7i-a20.dtsi#L1141-L1159

and https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian/tree/master/sun7i-a20

Conclusion : either I'm blind or I can't enable another i2c channel on the banana pi (and no I don't want to fiddle with the DSI interface to get PI0/1). So I'll cancel any i2c test for now.

I2C2 on PB20 and PB21 should be available according to the schematics and yes, for some reason it is enabled by default even though it shouldn't be. I2C0 is enabled by default and used for the PMIC, I2C1 is wired to the CSI and I2C3 is wired to the LCD connectors. I2C4 is wired to the test point and LCD connector (again).

 

Still you can test RTC overlay on I2C2.

 

41 minutes ago, vlad59 said:

It's getting late for me (so I may be blind) but tomorrow I'll grab a couple of DS18B20 and test one wire overlay, that should be easier.

I tested 1-wire on H3 with a DS18B20 so it should work in general. Changing the default pin and enabling the internal pull-up are the most interesting things to test.

[martinayotte]

15 hours ago, zador.blood.stained said:

Changing the default pin and enabling the internal pull-up are the most interesting things to test.

Since Dallas Semiconductor strongly suggest to use 4K7 Pull-Up for OneWire bus, I wouldn't rely on weak internal Pull-Ups which one some SoC are greater than 30K, especially if there are multiple sensor on the same bus or if those have long wires.

[zador.blood.stained]

2 hours ago, martinayotte said:

Since Dallas Semiconductor strongly suggest to use 4K7 Pull-Up for OneWire bus, I wouldn't rely on weak internal Pull-Ups which one some SoC are greater than 30K, especially if there are multiple sensor on the same bus or if those have long wires.

https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian/blob/master/sun7i-a20/README.sun7i-a20-overlays#L254-L257 

 

But internall pull-up is enough for testing purposes with non-parasite powering, 1-2 devices and short wiring

[martinayotte]

Of course !

[vlad59]

21 hours ago, zador.blood.stained said:

I2C2 on PB20 and PB21 should be available according to the schematics and yes, for some reason it is enabled by default even though it shouldn't be. I2C0 is enabled by default and used for the PMIC, I2C1 is wired to the CSI and I2C3 is wired to the LCD connectors. I2C4 is wired to the test point and LCD connector (again).

 

 

Another way would be to tweak the default DTS to disable I2C, additional UART (and maybe others like audio, SPI) and add the appropriate overlay by default, that way users could reuse I2C, UART pins as normal GPIO by removing the overlays. It feels a little weird to add patches to remove things from mainline DTS (that's usually the other way around) but I don't know how you see the future of Armbian.

 

21 hours ago, zador.blood.stained said:

Still you can test RTC overlay on I2C2.

 

I tested 1-wire on H3 with a DS18B20 so it should work in general. Changing the default pin and enabling the internal pull-up are the most interesting things to test.

 

About DS1307, I looked for them, saw them in my order history but I really don't know where they are sorry I must have lend them to a friend. I'll continue to look for them.

 

About One wire, I've added these lines to /boot/armbianEnv.txt :

overlays=w1-gpio
param_w1_pin=PH2
param_w1_pin_int_pullup=1

I'm using PH2 so pin 12.

dmesg show the driver being loaded :

root@bananapi:~# dmesg | grep wire
[   10.387893] Driver for 1-wire Dallas network protocol.

And everything seems to be working fine :

root@bananapi:~# cat /sys/bus/w1/devices/28-0000064cff2f/w1_slave
46 01 4b 46 7f ff 0a 10 85 : crc=85 YES
46 01 4b 46 7f ff 0a 10 85 t=20375

Putting my finger on the sensor change the temperature reported so everything seems to be fine.

That is without any external pullup (and 15cm dupont cables).

 

After removing the internal pullup (removing param_w1_pin_int_pullup) and using a real pullup everything is still fine but reading the temperature is faster so using only the internal should slow things.

 

Next I can try spidev and simply putting a cable between MISO and MOSI (I remember reading post by Martin where he explained there was a program to test SPI like that) or try on a Nanopi M1 depending on what you prefer ?

[martinayotte]

Quote

(I remember reading post by Martin where he explained there was a program to test SPI like that)

Yes, the spidev_test.c can be found on any kernel tree under tools/spi/spidev_test.c or on Linus mainline https://github.com/torvalds/linux/blob/master/tools/spi/spidev_test.c

 

[zador.blood.stained]

8 minutes ago, vlad59 said:

Another way would be to tweak the default DTS to disable I2C, additional UART (and maybe others like audio, SPI) and add the appropriate overlay by default, that way users could reuse I2C, UART pins as normal GPIO by removing the overlays. It feels a little weird to add patches to remove things from mainline DTS (that's usually the other way around) but I don't know how you see the future of Armbian.

Things like audio (if it is wired to the 3.5mm jack) and actually used (i.e. for the PMIC) interfaces should be enabled by default, but interfaces exposed only on pin headers should be disabled.

I guess Banana Pi is relatively old (sun7i-a20.dtsi was added 2013-08-20 and sun7i-a20-bananapi.dts was added 2014-10-20), so this wasn't enforced back then and now simply nobody cares (or people don't want to break the backwards compatibility)

14 minutes ago, vlad59 said:

About DS1307, I looked for them, saw them in my order history but I really don't know where they are sorry I must have lend them to a friend. I'll continue to look for them.

I bought one today myself so I'll try to test it when I find the oscillator and a piece of perfboard for it (I bought just a chip, not a premade board)

 

16 minutes ago, vlad59 said:

Next I can try spidev and simply putting a cable between MISO and MOSI (I remember reading post by Martin where he explained there was a program to test SPI like that) or try on a Nanopi M1 depending on what you prefer ?

This should work. Again, the interfaces themselves should work fine, I'm mostly concerned about additional parameters or copy-paste mistakes

[vlad59]

With the default DTS, I think SPI-1 cannot be enabled as the pins are used by a UART, so I'll only test SPI-0. Then I'll check your overlays with Nanopi M1.

[zador.blood.stained]

1 minute ago, vlad59 said:

Then I'll check your overlays with Nanopi M1.

Currently there are no nightlies available for this board. Do you need prebuilt nightlies or can you build an image by yourself?

[vlad59]

@zador I found out which friend got my DS1307 and in fact I gave them to him because DS1307 need 5V VCC and my usecase was some Arduino Nano powered by lipo and step down converter (so 3.3V). I checked the datasheet and his memory is good (and mine not so good). You may need some level shifter on SCL and SDA if you want to test yours.

[zador.blood.stained]

11 minutes ago, vlad59 said:

You may need some level shifter on SCL and SDA if you want to test yours.

It's not a big deal. It can be powered from 5V, but SCL and SDA needs to be pulled up to 3.3V and connected directly, no level shifters required.

[willmore]

Quote

Things like audio (if it is wired to the 3.5mm jack) and actually used (i.e. for the PMIC) interfaces should be enabled by default, but interfaces exposed only on pin headers should be disabled.

May I ask for a slight modification to this policy?  Since we've already made a small exception for UART headers, could we go so far as to include:

1) Included in design but not populated parts like CIR receivers?

2) Dedicated use headers--I'm thinking specifically of the 1x13 header on the Orange Pi Zero(s).  It's looking to become a standard.

 

or, do we want to do these via overlays as well?  I truely don't understand the pro's and con's of going one way or the other on this decision.  If this has been discussed before, please ignore my comments and refer me to the other posts and I'll go get educated on the issue.

[zador.blood.stained]

4 minutes ago, willmore said:

May I ask for a slight modification to this policy?  Since we've already made a small exception for UART headers, could we go so far as to include:

1) Included in design but not populated parts like CIR receivers?

2) Dedicated use headers--I'm thinking specifically of the 1x13 header on the Orange Pi Zero(s).  It's looking to become a standard.

It (upstream/mainline policy) is not up to us (armbian devs) - it was asked several times before and the answer was "use overlays": https://irclog.whitequark.org/linux-sunxi/2016-12-17#18436549

I believe Maxime Ripard is the "main" sunxi maintainer for the mainline kernel, so these decisions are up to him, and in addition there may be generic Device Tree policies that affect this.

 

4 minutes ago, willmore said:

I truely don't understand the pro's and con's of going one way or the other on this decision.  If this has been discussed before, please ignore my comments and refer me to the other posts and I'll go get educated on the issue.

For the multiplexed pins (IR, UARTs, SPI, I2C) the advantage is having as many free GPIOs by default as possible. For other things like USB or audio it may result in small consumption decrease, but still still it's more a standard/policy than actual power consumption considerations.

[zador.blood.stained]

@tkaiser

Regarding your IRC comments

I don't think these DT overlays are "a real problem currently only community can solve" and that they can be useful to the linux-sunxi community in general. This is mostly Armbian specific problem that IMO is already solved (here are some premade overlays, you can request more overlays in this thread if they can be useful for other people or you can make your own ones) and this most likely won't be upstreamed to be used by other distributions (even Raspberry Pi overlays live in their own kernel fork).

[tkaiser]

1 hour ago, zador.blood.stained said:

This is mostly Armbian specific problem that IMO is already solved

Hmm... thanks for the discouraging correction, I really hoped for a broader adoption of this approach. On the other hand it's good to know that you consider the work as already (almost) done.

[selfbg]

Hello,

 

I have one question. What about using 2 SPI busses?

if test -n "${param_spidev_spi_bus}"; then
	test "${param_spidev_spi_bus}" = "0" && setenv tmp_spi_path "spi@01c05000"
	test "${param_spidev_spi_bus}" = "1" && setenv tmp_spi_path "spi@01c06000"
	test "${param_spidev_spi_bus}" = "2" && setenv tmp_spi_path "spi@01c17000"
	fdt set /soc@01c00000/${tmp_spi_path} status "okay"
	fdt set /soc@01c00000/${tmp_spi_path}/spidev status "okay"
	if test -n "${param_spidev_max_freq}"; then
		fdt set /soc@01c00000/${tmp_spi_path}/spidev spi-max-frequency "<${param_spidev_max_freq}>"
	fi
	if test "${param_spidev_spi_bus}" = "0" && test "${param_spidev_spi_cs}" = "1"; then
		fdt set /soc@01c00000/${tmp_spi_path}/spidev reg "<1>"
	fi
	env delete tmp_spi_path
fi

With this existing code how I'm supposed to do this? Maybe needs rework?

[zador.blood.stained]

5 minutes ago, selfbg said:

What about using 2 SPI busses?

...

With this existing code how I'm supposed to do this?

Then you need to write a custom overlay for one or both SPI controllers. Since the most popular boards expose only one SPI bus, provided overlays should be good enough for most scenarios, and trying to handle every possible bus and device combination will just make things overly complicated.

 

[g40]

@selfbg

 

Slightly off-topic: I've not seen that FDT command before. How is it installed/built?

 

fdt set /soc@01c00000/${tmp_spi_path} status "okay"

TAIA.

[martinayotte]

"ftd set" is a u-boot command to alter existing DT, here, in this case, changing status to "okay".

 

[g40]

@martinayotte

 

Thank you.