Odroid N2 | SPI unavailable

[keypunch416]

Creating a bug report/issue

Required Information

• DietPi version | 8.6.1
• Distro version | bullseye
• Kernel version | Linux DietPi 5.10.123-meson64 #22.05.3 SMP PREEMPT Wed Jun 22 07:23:04 UTC 2022 aarch64 GNU/Linux
• SBC model | Odroid N2 (aarch64) (N2+ 4GB)
• Power supply used | ALLPOWER 15VDC/4A
• SD card used | 32GB Kingston CANVAS Select Plus MicroSD 100MB/s A1

Additional Information (if applicable)

• Software title | DietPi
• Was the software title installed freshly or updated/migrated? Freshly installed and up to date as of this issue
• Can this issue be replicated on a fresh installation of DietPi? Yes

• Bug report ID | N/A

Steps to reproduce

1. dietpi-config has no option to enable SPI
2. I have done alot of research and testing to find solution for last 2 days resulting in the below noted dietpiEnv.txt and modprobes in various combinations during say boot and across multiple boots of DietPi
3. dietpiEnv.txt added:
   overlays=spi-spidev
   param_spidev_spi_bus=0
   param_spidev_max_freq=100000000
4. sudo modprobe spi-gpio
5. sudo modprobe spidev spi_meson_spicc
6. ls -ls /dev/spi

Expected behaviour

• expect that SPI would be enabled with ls -ls /dev/spi showing at least one SPI of /dev/spidev0.0
• expect should be simple to enable SPI like on Raspberry Pi where takes only seconds via raspi-config or adding the required lines to Pi config.txt file and not two days of research and many different combinations of tests that still result in not being able to enable SPI on dietPi
• I do not really need dietpi-config to have function to enable SPI as I generally have various CLI interface scripts that install packages and apply the various script customization I do with Unix systems, not just SBCs.
• the I2C interface is enabled by default so either the SPI interface should be enabled by default or should be only less than half minutes to enable SPI as is case on Raspberry Pi.

Actual behaviour

• After two days and alot of research and testing of what research states should enable SPI on DietPi and/or N2 still no SPI enabled

Extra details

• ...

[keypunch416]

I cannot see links or files I attached to this issue.
Opps I did not attach any files or links, my error and none needed.

[MichaIng]

Many thanks for your report.

Note that RPi with its config.txt, custom bootloader and kernel are very different from upstream U-Boot with boot.src (which loads dietpiEnv.txt as environment file) and kernel. So it is expected that you cannot follow guides/steps that work on RPi on any other SBC.

I'll take a look when I'm home: There are device tree overlays in /boot/dtb/meson/overlay which can be loaded with respective line in /boot/dietpiEnv.txt skipping the file ending and prefix. If there is one for SPI, the respective kernel module should be loaded automatically.

[keypunch416]

Yes the RPi approach is different, but in essence what I read multiple places for how I tried to enable the SPI for N2 (not Pi) with commands I added to the dietpiEnv.txt is not working. I would not expect unless stated that Pi config.txt could be used for example with N2.

Point is it should be easy to enable, and does not have to be exactly done same as Pi.

The Pi does have many many extra special DTBs that happen to have extra I2C definitions and SPI agmonst the many DTBs one can use. All one has to do is either load the DTB post boot via CLI command or include in the config.txt. Either of these ways work just fine and I have used both. I use the load via CLI first as test to see if I have chosen correct for what I want and once confirmed then add to Pi config.txt. I should not have to spend days with no success to enable basic elements such as SPI. On Pi done in few seconds and then one can then compile the code one has for the SPI devices one has.

This lack of ease for such basics via non Pi OS is likely causing many to just stay with a Pi despite the many shortfalls of Pi. Why I want to use N2 and only later Rock 3A, M1, et al as so much better hardware than Pi. As long as making enabling basics and alternate SPI and I2Cs difficult to impossible just drives people back to Pi with its many many issues of Pi's primary OS and many issues related to Pi hardware design rather than use better OS and many better than Pi hardware designs. The N2 and M1 are just two examples of many better hardware designs compared to Pi.

[MichaIng]

I agree. We cannot change something about how device trees and related hardware features can be enabled in mainline U-Boot and mainline Linux, but we can add dietpi-config options for those.

For SPI however, sadly there is no device tree overlay 😞. However, I think I found the device we need to toggle:

cat /proc/device-tree/__symbols__/spicc0; echo
cat /proc/device-tree/soc/bus@ffd00000/spi@13000/status; echo

We can write an overlay for this. This spidev node needs to be created as well, I guess: https://wiki.odroid.com/odroid-n2/application_note/gpio/spi#tab__odroid-n2

[keypunch416]

I had seen and read the N2 link you noted in your last entry. Rather messy compared to Pi one just enters line to enable SPI in config.txt and then good to go. I did not attempt as frankly which all I have read of what to do that is suppose to enable SPI not enabling the SPI I had no desire to try. Having to mess with compiler tree, edit DTBs and such is rather messy. Is there no way to create a SPI DTB that can then be loaded with option of which SPI (0 or 1) or both that can be enabled? Again is can be made simple it is best.

[keypunch416]

Unlike Raspberry Pi at least the N2 (all I know as only alternate to PI SBC I have three of now as of week ago) has I2C enabled by default. Would it make sense to have SPI enabled by default on N2 and other alternate SBCs or to have both disabled by default and one chooses if want I2C and or SPI enabled and how many of those want enabled?

[MichaIng]

Is there no way to create a SPI DTB that can then be loaded with option of which SPI (0 or 1) or both that can be enabled?

This is what a device tree overlay does, which can then be enabled with a single value in /boot/dietpiEnv.txt. But we need to write it first. I hope I find time tomorrow.

Would it make sense to have SPI enabled by default on N2 and other alternate SBCs or to have both disabled by default and one chooses if want I2C and or SPI enabled and how many of those want enabled?

If we enable it, others may wonder why the GPIO pins are not working and ask the other way round. If it's easy to toggle an interface, I prefer to have it disabled by default, i.e. less kernel drives are loaded when not needed.

[keypunch416]

I asked as at moment I2C appears enabled by default. I would agree makes sense for I2C and SPI to be disabled by default and then one can choose which of these one needs. By allow both disabled by default as you noted allows more GPIO pins for other uses that may need those GPIO pins and not I2C and/or SPI.

No major rush and solution. I rather have right solution based on decisions such as off by default be vetted. As FYI the reason SPI is important in my case and maybe for others later is for ADCs normally used for seismic based use, i.e. measuring earthquakes. That said as you know there are many SPI devices on break out boards that then could be use by the many excellent alternate choices to Raspberry Pi that in my opinion are much better. The N2 is especially well suit for seismic type applications where common to process 20,000,000 records of seismic data multiple times (for different manners of data presentation) every 10-15 minutes. My hope is the 4GB N2+ will have enough RAM to do so. All done with CLI so no DE/GUI installed on the SBC. These no need for DE/GUI on SBC for such use. I only use SBC in CLI.

[keypunch416]

Some Additional Testing:

Manjaro-ARM no SPI defined no can find how to.

Official Hardkernel 22.04 has SPI defined by default, but sould have set of pins defined for SPI not just one pin:

Sun Jul 31 22:13:40 UTC 2022
Linux odroid 4.9.312-22 https://github.com/MichaIng/DietPi/pull/1 SMP PREEMPT Mon Jun 20 17:12:03 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

Distributor ID: Ubuntu
Description: Ubuntu 22.04 LTS
Release: 22.04
Codename: jammy
gpiochip0 - 16 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed "line_mute" output active-high [used]
line 3: unnamed unused input active-high
line 4: unnamed unused input active-high
line 5: unnamed unused input active-high
line 6: unnamed unused input active-high
line 7: unnamed unused input active-high
line 8: unnamed unused input active-high
line 9: unnamed "amlsd" output active-high [used]
line 10: unnamed "pwm" output active-high [used]
line 11: unnamed "?" output active-high [used]
line 12: unnamed unused input active-high
line 13: unnamed unused input active-high
line 14: unnamed unused input active-high
line 15: unnamed unused input active-high
gpiochip1 - 86 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed unused input active-high
line 3: unnamed unused input active-high
line 4: unnamed unused input active-high
line 5: unnamed unused input active-high
line 6: unnamed unused input active-high
line 7: unnamed unused input active-high
line 8: unnamed unused input active-high
line 9: unnamed unused input active-high
line 10: unnamed unused input active-high
line 11: unnamed unused input active-high
line 12: unnamed unused input active-high
line 13: unnamed unused input active-high
line 14: unnamed unused input active-high
line 15: unnamed unused input active-high
line 16: unnamed unused input active-high
line 17: unnamed unused input active-high
line 18: unnamed unused input active-high
line 19: unnamed unused input active-high
line 20: unnamed unused input active-high
line 21: unnamed "usb_hub" output active-high [used]
line 22: unnamed "usb_hub_en" output active-high [used]
line 23: unnamed "ffe09080.usb3phy" output active-high [used]
line 24: unnamed unused input active-high
line 25: unnamed unused input active-high
line 26: unnamed unused input active-high
line 27: unnamed unused input active-high
line 28: unnamed unused input active-high
line 29: unnamed unused output active-high
line 30: unnamed unused input active-high
line 31: unnamed unused input active-high
line 32: unnamed unused input active-high
line 33: unnamed unused input active-high
line 34: unnamed unused input active-high
line 35: unnamed unused input active-high
line 36: unnamed unused input active-high
line 37: unnamed unused input active-high
line 38: unnamed "amlsd" output active-high [used]
line 39: unnamed unused input active-high
line 40: unnamed unused input active-high
line 41: unnamed unused input active-high
line 42: unnamed unused input active-high
line 43: unnamed unused input active-high
line 44: unnamed unused input active-high
line 45: unnamed unused output active-high
line 46: unnamed unused input active-high
line 47: unnamed unused input active-high
line 48: unnamed "amlsd" input active-high [used]
line 49: unnamed unused input active-high
line 50: unnamed unused input active-high
line 51: unnamed unused input active-high
line 52: unnamed unused input active-high
line 53: unnamed unused input active-high
line 54: unnamed unused input active-high
line 55: unnamed unused input active-high
line 56: unnamed unused input active-high
line 57: unnamed unused input active-high
line 58: unnamed unused input active-high
line 59: unnamed unused input active-high
line 60: unnamed unused input active-high
line 61: unnamed unused input active-high
line 62: unnamed unused input active-high
line 63: unnamed unused input active-high
line 64: unnamed unused input active-high
line 65: unnamed unused input active-high
line 66: unnamed unused input active-high
line 67: unnamed unused input active-high
line 68: unnamed unused input active-high
line 69: unnamed unused input active-high
line 70: unnamed unused input active-high
line 71: unnamed unused input active-high
line 72: unnamed unused input active-high
line 73: unnamed unused input active-high
line 74: unnamed unused input active-high
line 75: unnamed unused input active-high
line 76: unnamed "spi0.0" output active-high [used]
line 77: unnamed unused input active-high
line 78: unnamed unused input active-high
line 79: unnamed unused input active-high
line 80: unnamed unused input active-high
line 81: unnamed unused input active-high
line 82: unnamed unused input active-high
line 83: unnamed unused input active-high
line 84: unnamed unused input active-high
line 85: unnamed unused input active-high

[keypunch416]

I have missed a number of, including the significant events in the Indonesia Area 20220911-1855+0000-UTC-IndonesiaArea-Example-001 in last 36 hours due to this issue. It means the hundreds of dollars of investment in SPI based devices two years ago is useless and that work in RPi with usual SPI programming. The 1GB limit of pre RPi4B imposes serious limits due to the need to record and create graphs from the about 9,000,000 records that need to be logged every 24 hours at sampling rate typical for Seismic instruments.

I am now having to seriously consider in next few days investing over $125 in new ICs as well as time and cost of developing PCBs for inferior solution that only SPI devices are suitable for. This means very reduced detail and data would be recorded for seismic events about world not to mention the development time of new PCBs, the time to develop, order, and test new PCBs and PCB revisions on top of 3-4 months of developing new code for new and inferior for seismic application ICs.

Using a RPi4B is not option due to the many issues with RPi4B that I will not explain and why a N2+ was a much better solution unaware there is no SPI, and various issue related to GPS that all specific to the N2+ images, not just dietpi, but all N2+ images for basics such as SPI devices that are commonly used on RPi for non-seismic uses and reasons that SPI is only or best choice.

[MichaIng]

With a device tree like this, we can get the bus and a dummy node enabled, but that does not result in a functional SPI device:

/dts-v1/;
/plugin/;
/ {
        compatible = "amlogic,g12b";
        fragment@0 {
                target = <&spicc0>;
                __overlay__ {
                        status = "okay";
                        spidev@0 {
                                status = "okay";
                        };
                };
        };
};

We'd need to look into the vendor kernel device tree to see how it is solved there.

Similarly to the GPIO issue, the Odroid forum is probably the best place to bring up the question how to enable SPI with mainline kernel: https://forum.odroid.com/viewforum.php?f=176

And as workaround, also here, downgrading to legacy vendor Linux 4.9 should help:

apt install linux-{image,dtb}-legacy-meson64