DeviceTree problem: Enable SPI0, disable UART4

[AuerE]

As https://www.armbian.com/tinkerboard/ has a quite fresh 4.14 Linux kernel (in Armbian Stretch Next Desktop 5.50) I am trying to use that instead of the standard TinkerOS 2.0.7 with a 4.4.103 kernel.

 

However, Armbian is configured to provide only spidev2.0, while TinkerOS can have spidev0.0, spidev0.1, spidev2.0 and spidev2.1 all enabled at the same time as long as you disable UART4 which shares GPIO header pins with SPI0. In the TinkerOS case, there is a config tool which edits a small and straightforward text file in /boot/ containing lines such as "intf:spi0=on" or "intf:uart4=off". The corresponding Armbian file seems to be /boot/armbianEnv.txt - possibly with overlays=... lines and DTS files. There also is a tool called armbian-add-overlay to load (at runtime?) DTS files...

 

 

Given that the diff between the sorted device trees (using dtc to sort them) is 3200 lines, not counting context, compared to 3700 and 2600 lines respectively for the complete device trees of both distros in DTS format, it seems hopeless for me to write a DTS to switch UART4 off and SPI0 on and enable the second CS line on SPI2. But maybe I am missing something here and there is an already existing easy way to switch the following devices on and off?

 

• SPI0, SPI2
• PWM2, PWM3
• UART1, UART2, UART3, UART4
• I2C1, I2C4
• PCM_I2S
• and possibly other Armbian specific features :-)

 

I personally had everything except UART2 and UART4 on in the TinkerOS case and am trying to reproduce that in Armbian. The SPI items are my priority.

 

Another strange issue is that the package repositories contain, among others, the headers and source code of Linux 4.14.34 and 4.14.14 respectively, but I can not find the exact sources needed to rebuild the 4.14.52 kernel used by the current Armbian Stretch 5.50 desktop edition.

 

In general, the Armbian repositories seem to be quite up to date compared to TinkerOS which only has the sources on Github and still uses quite old 4.4 kernels, but I do need that full SPI connectivity, so I hope that the Armbian forum has some hints for me. Thank you!

 

[TonyMac32]

3 hours ago, AuerE said:

Another strange issue is that the package repositories contain, among others, the headers and source code of Linux 4.14.34 and 4.14.14 respectively, but I can not find the exact sources needed to rebuild the 4.14.52 kernel used by the current Armbian Stretch 5.50 desktop edition.

 

If you have a Bionic host, or Docker, you can simply clone the Armbian build system and build an image for the Tinker Board.  read up in docs.armbian.com for details.  I'm currently working on 4.18 and trying to restabilize 4.4, there were some... unfortunate events to happen with the Rockchip repo we were using.

[AuerE]

I neither have a Bionic host nor Docker, but I have the actual Tinker Board S and can compile kernels there - if I have the source code which I was hoping to be available via apt-get on Armbian. Are you saying that disk or VM images of the whole build server are available for more different kernel versions than deb packages of the kernel source code itself? I am quite sure that the kernel sources would take less space on the Armbian package servers... And I doubt that my Tinker Board has enough power to run Docker or Bionic or other system environments?

 

[TonyMac32]

I don't control the package system, I just do the dusting and upkeep of the kernel on the board.  As far as that goes, the newest 4.14 source available should not be significantly different to the current, and you can find the patches we use HERE

 

 

Any patches newer than the source package could be applied, then built. @Igor can speak to the source packages.

 

 

[Igor]

1 hour ago, TonyMac32 said:

can speak to the source packages.

 

Source packages are quite big and considering the number different kernels ... this needs some adjustments in packaging logic. Keeping only the most recent source packages or don't care about anything ... but the current download server is at 95% of capacity and is scheduled to move to a new location within two weeks. The main build server is also running low on space and needs some (fast and expensive) space upgrade.

 

It would also be possible to rent out some of our main server capacities. A virtual machine with ready to build Armbian. If there is an interest? This could be possible after space upgrade.

[AuerE]

As said, I assumed the safest choice would be the exact version used in the binary kernel package of the current Armbian distro. Or one of the updates which are available as binary kernel packages of course. That way, I know that I will not have to find out which values for newly introduced kernel config options are suitable for my hardware. Instead, I can rely on /proc/config.gz (or a package containing the config used for compiling a specific kernel version) to match the binary.

 

I agree that having all versions available as  both binary and source would consume too much server disk space.

 

So one of my questions is where to find either the sources for the exact kernel version used in the distro installer - or the sources and config of a newer version if that has already been tested to work on Tinker Board S.

 

However, the bigger question is how to tell the Armbian DeviceTree to switch off UART4 and switch on SPI0, because I am really hoping that there is a way to do that without re-writing large parts of the DTS sources to be more similar to the TinkerOS kernel versions on https://github.com/TinkerBoard/debian_kernel/tree/release ...

 

Instead, I am hoping to get hints how to do what TinkerOS does in /boot/hw_intf.conf by doing something equivalent in Armbian /boot/armbianEnv.txt and if necessary adding some dtb, dtbo or dts file somewhere, or by using another Armbian specific mechanism that I am still unaware of. That would be a very nice way to activate SPI0 

 

Once SPI0 and SPI2 are both active at all, I can return to my original plan to add some smaller modifications to spi, spidev and spi-rockchip in the kernel - if nothing speaks against using modules for that on my hardware, using modules to speed up the compile and test cycle.

 

Thanks for bearing with me on this issue!

 

[TonyMac32]

Requires device tree overlays, something not yet implemented in these kernels.

[AuerE]

Thanks for the warning! So I have to edit the static device tree instead? Do newer versions of the Armbian kernels implement such overlays? How about the /usr/sbin/armbian-add-overlay tool, can it help me to enable the other SPI and disable the pin-conflicting UART?

 

[TonyMac32]

This is more about the developer and less about the kernel. I haven't taken the time to learn enough about the overlays to get it done in a supportable way.

Sent from my Pixel using Tapatalk