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 .
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.
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: