Can't move SPI-CS line to other GPIO

Volumio Information

Volumio Version: 2.834
Hardware: Raspberry Pi 2 Model B Rev 1.1
DAC: none

For a hardware project I have Volumio on a bare RPi (no DAC). Will later install the hardware into another Pi with Hifiberry DAC.
Due to an existing board layout of the hardware, I need to change the GPIO pin of SPI0-CS1 from GPIO7 to GPIO12.

According to dtoverlay -h spi0-cs I need to run sudo dtoverlay spi0-cs cs1_pin=12.
When I do that from the terminal it works and the overlay gets displayed when I call dtoverlay -l.
However, when I add the command to /boot/userconfig.txt, the overlay is not loaded. I do not see any entries in journalctl -b that indicate an overlay is installed.
/boot/userconfig.txt seems to be called, because the SPI is enabled due to dtparam=spi=on.
I also tried with the syntax dtoverlay=spi0-cs,cs1_pin=12, but the result is the same, no overlay.
If I comment out #dtparam=spi=on the spi is still enabled (as the device tree documentation says) but the overlay is still not loaded.

I read that there were some changes to dtoverlay handling in the 4.19 kernel, but could not figure out, if that affects my setup, too. And if yes what the correct syntax would be.

Any hints? Any alternative method to get my CS-line redirected? I can enable it everytime during development, but when I move the hardware to its final destination, it should load the correct config at boot, otherwise it is useless.

So, after some more digging and after connecting my scope, I found the solution to the problem - posting it, in case somebody is wondering about the same thing:

  1. RTFM :roll_eyes:
    Reading the device tree documentation for the Raspberry under Device Trees, overlays, and parameters I found the statement

3.5.1 The dtoverlay command
[…]
2. Only overlays and parameters applied at run-time can be unloaded - an overlay or parameter applied by the firmware becomes “baked in” such that it won’t be listed by dtoverlay and can’t be removed.

  1. Verification
    dtoverlay=spi0-cs,cs1_pin=12 inserted in /boot/userconfig.txt actuallay works, as I verified by connecting my oscilloscope to the pin and looking for a falling edge when I send a message. Double confirmed on the CS1 pin (GPIO8) - there is no falling edge there, so the CS1 is properly re-routed.

Can now start to debug my hardware :sunglasses: