I am definetly having trouble with this board because there really is not that much information I could find on the internet.
The problem is I recently try to add a ADXL345 to the board but Dietpi doesn’t seem to have SPI turned on by default, and I have no idea where to start looking, I have checked Dietpi-Config, found nothing related to SPI there.
I had a look into the image. Similar like NanoPi 2 series, the S5P6818 SoC based NanoPi M3/Fire3 and NanoPC T3 have a hopelessly outdated kernel provided by FriendlyELEC only, support never made it into upstream Linux. We use the slightly newer Linux v4.14 by Armbian (vs v4.4 by FriendlyELEC), but there are no device tree overlays (anyway not supported by this Linux version) and the U-Boot config is very minimal with no hints about additional features. So I’m AFRAID if the SPI interface is not available OOTB, there is nothing we are able to do .
yeah,
but as Michalng mentioned up a few posts, the kernel does not have device tree overlays, that’s the tricky part.
and I asked friendlyarm official support about this issue, who have replied a not so friendly answer, that in order to use spi feature with this board, I have to write my own driver for it.
Then I ask if there were any technical supports or document related to spi specifically, they said not able to provide any of that because this board has simply gone out of production.
Devicetree overlays can be written, that’s not the problem, but if your kernel doesn’t have a driver for the SPI IP, then you lose. A look at the base devicetree may provide indications of unactivated SPI master nodes. But if there are no traces, there is a high probability that there is no support.
Since the SPI IP is usually part of the SOC, the TRM should provide all the necessary information, nothing is board-specific except ultimately the outer wiring. And this should be described by devicetree for the driver.
An overlay for spi0 would look something like this, but since I don’t know the real wiring, the values used (interrupt-parent, interrupts) are incomplete:
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/dts-v1/;
/plugin/;
Since no /proc/device-tree/**/status exist, is it possible to still enable it that way or may that kernel build simply not support device tree overlays? It is still based on the original kernel by FriendlyELEC Linux v4.4, Armbian just managed to raise the base version to 4.14. For this SoC I wasn’t able to find newer mainline Linux builds.
My overlay enables a fully defined SPI master device node, if no predefined node exists you have to provide all properties.
There is nothing a kernel needs to support for the application of a DTBO, the kernel uses a DTB and cannot even determine how it is maybe composed. The DTB is assembled before the kernel starts.
The absence of predefined nodes suggests that there is no driver support and adding the devicetree properties does not magically generate the driver code. Look in the sources for a driver that supports nexell,s5p6818-spi
Exactly, and since s5p6818 nor nexell is mentioned in mainline devicetree binding documentation, it can be assumed that the blog post refers to a legacy kernel fork. The available driver is probably in an unusable state for mainline usage, so that hardkernel answered like this: