Dietpi: Upgraded to 6.10, now cannot see ALLO Piano 2.1 card on Sparky

[mfeif]

I updated dietpi to 6.10 via the dietpi-upgrade script. There were no errors (that I could see).

Now my allo piano 2.1 card isn't present in the devices available to the kernel:

# aplay -l 
**** List of PLAYBACK Hardware Devices ****
shared memfd open() failed: Function not implemented
card 0: atm7059link [atm7059_link], device 0: ATC2603C PCM atc2603c-dai-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: atm7059link [atm7059_link], device 1: HDMI PCM atm7059-hdmi-dai-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: atm7059link [atm7059_link], device 2: SPDIF PCM atm7059-spdif-dai-2 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Required Information:

• DietPi version | 6.10
• Distro version | 9.4
• Kernel version | #22 SMP PREEMPT Fri Dec 22 10:45:41 IST 2017
• SBC device | Sparky SBC (armv7l)
• Power supply used | Allo supplied 5V wallwart
• SDcard used | on-board mmc card from Allo

Additional Information (if applicable):

• Software title | alsa
• Was the software title installed freshly or updated/migrated? updated from 6.9
• Can this issue be replicated on a fresh installation of DietPi? unknown

Steps to reproduce:

1. boot the computer; software playback fails; further investigation shows that my Allo isn't present to ALSA
2. aplay -l does not show the right stuff; just onboard HDMI and so on

Expected behaviour:

Actual behaviour:

• ...

Extra details:

I HAVE used the dietpi-config script to (re)set the audio device to the allo, but it's not sticking. Additionally, I can't find the confit.txt file to look for dtoverlay settings. Something new must be up, but I don't understand what has replaced it.

I see this: https://github.com/Fourdee/DietPi/pull/1863 But I don't know how my sparky is otherwise configured, since it's more or less an rPi clone.

Here is my /etc/modules:

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

atc260x_irkeypad
videobuf2-vmalloc
bc_example
pvrsrvkm

If I manually load the driver: modprobe snd-soc-allo-piano-dac-plus it shows up again, and I can force it to run by putting that in /etc/modules

[mfeif]

Note, I'm presuming that this affects other kinds of configuration as well: cpu governor, framebuffer settings, etc...

[Fourdee]

@mfeif

Thanks for the report 👍 I'll take a look at this tomorrow.

We have a hotfix due for tomorrow aswell, we should be able to get this resolved by then.

REF: https://github.com/Fourdee/DietPi/issues/1891

[Fourdee]

REF: https://github.com/Fourdee/DietPi/pull/1863#issuecomment-402528301

[Fourdee]

@mfeif

I'll check your system configuration + logs tomorrow aswell.
Please send us a bug report, and reply with the reference code:

[mfeif]

Sure thing: 94df705b-f681-420c-b01b-3217e7eeb3db

After lots of tinkering, I've been able to manually get my soundcard working again.

I hope my bugreport data isn't too noisy; I have removed or disabled lots of the stock stuff and added a couple of things that are probably not supported (I'm pretty familiar with Debian, so went to apt to turn off stuff I'll never use).

[MichaIng]

@mfeif @Fourdee
Hmm, rechecking the code, I can't find any need of config.txt existence for Sparky SBC settings.

Here the code that should apply allo-piano-dac: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-set_hardware#L1905-L1921

All the CPU governor related settings should not depend on config.txt at all, even not on RPi: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-set_cpu

config.txt, including dtoverlay values should be really only needed on RPi, Sparky should have it's own configuration files (e.g. /etc/modules), also according to the code on how we apply settings there. As DietPi was initially a RPi distro, we just scraped config.txt here and there to show some settings/value within our menus, but those should be without any effect on other devices.

Only idea would be that Sparky somehow uses config.txt internally, outside our scripts, inside their own scripts/commands. Easy test would be to manually download and place file again into /boot:
wget https://raw.githubusercontent.com/Fourdee/DietPi/master/config.txt -O /boot/config.txt

But I suggest the reason for your issue is coming from another direction. Though the above is worth testing, as it is easy and fast 😃.

---

Just offtopic: #22 SMP PREEMPT Fri Dec 22 10:45:41 IST 2017 this is the output of uname -v on Sparky? Hmm uname -r shows the package version (3.16.0-6-amd64 instead of 3.16.56 e.g.), not necessarily kernel version, how to reliably get kernel version like 4.14.48 on all devices?
Then maybe uname -a only covers it all.

[Fourdee]

Appears this is not being applied
https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-set_hardware#L1916

As yes, confirmed bug.

[Fourdee]

@mfeif

Many thanks for sending the bug report 👍

This is resolved for v6.11, which is slated for release today.

[mfeif]

Re your "offtopic" block above; on my Sparky:

# uname -v
#22 SMP PREEMPT Fri Dec 22 10:45:41 IST 2017

uname -r
3.10.38

uname -a
Linux PiFi 3.10.38 #22 SMP PREEMPT Fri Dec 22 10:45:41 IST 2017 armv7l GNU/Linux

[mfeif]

Thanks for looking into this!

[MichaIng]

@mfeif
Thanks for this. So jep, we need to stay with uname -a to be sure, that kernel version is inside.

[mfeif]

FWIW:

# uname --version
uname (GNU coreutils) 8.26
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

[MichaIng]

@mfeif
Jep, that's the version of coreutils then, the package containing the uname command 🙂.

Btw, as v6.11 is released, this does solve your issue, doesn't it?

[Fourdee]

@MichaIng

Thanks for this. So jep, we need to stay with uname -a to be sure, that kernel version is inside.

The kernel version on sparky never changes, as they use the same branch and patch it as needed. These kernel patches are applied by us during updates, however, they have no change in kernel version number.