Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SND_BCM2835 audio not working on 4.19 kernel version #3181

Closed
NguyenTrongThinh opened this issue Aug 24, 2019 · 23 comments
Closed

SND_BCM2835 audio not working on 4.19 kernel version #3181

NguyenTrongThinh opened this issue Aug 24, 2019 · 23 comments

Comments

@NguyenTrongThinh
Copy link

Describe the bug
Build 64 bit kernel with these configuration
CONFIG_SND_BCM2835=y
CONFIG_VIDEO_BCM2835=y
CONFIG_VIDEO_CODEC_BCM2835=y
but the on board audio (Jack 3.5) was not working, when run command $ aplay -l; it shows no audio card

To reproduce
Build 64 bit kernel with the configuration above

Expected behaviour
Audio on Jack 3.5 can work

Actual behaviour
No audio out and no sound card found when run command aplay -l

System
Raspberry Pi 3 B+
Host Machine: Ubuntu 18.04

@NguyenTrongThinh NguyenTrongThinh changed the title SND_BCM2835 audio not working on latest kernel version SND_BCM2835 audio not working on 4.19 kernel version Aug 24, 2019
@6by9
Copy link
Contributor

6by9 commented Aug 24, 2019

Which defconfig did you start from before seting those 3 modules as built in?

bcmrpi3_defconfig already has those drivers defined as being modules. Is there a specific need to make them built in? Did it work for you with them as modules?
Is there anything useful in the kernel log? Please provide the log.

@NguyenTrongThinh
Copy link
Author

NguyenTrongThinh commented Aug 24, 2019

bcmrpi3_defconfig already has those drivers defined as being modules.
=> Yes. default they are "m"

Is there a specific need to make them built in?
=> No, I have changed them to test; because "m" not work and aplay -l shows very strange output. I am sure that I did not connect raspberry PI to any HDMI monitor; And No HDMI cable plugin
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi [vc4-hdmi], device 0: MAI PCM vc4-hdmi-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

Did it work for you with them as modules?
=> No, below are dmesg log and I also change the config to "m" in this log

dmesg.txt

defconfig_rpi3b_plus.txt

config.txt

@sakaki-
Copy link

sakaki- commented Aug 24, 2019

You appear to be using vc4-kms-v3d (in /boot/config.txt): does the problem still arise with vc4-fkms-v3d?

@asavah
Copy link

asavah commented Aug 24, 2019

Out of curiosity I tested this on my own build of 4.19.y arm64:

with no overlay or with vc4-fkms-v3d -> works
with vc4-kms-v3d -> I get same output as op.

@NguyenTrongThinh
Copy link
Author

@sakaki- @asavah
Thank you for your answer! It is correct.

So now the on board audio card appear but HDMI audio is still there. I am sure that no HDMI cable is plugged in

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
Subdevices: 7/7
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0

@floion
Copy link

floion commented Aug 29, 2019

I confirm the same bug on 4.19.66. On 4.19.58 the bug is not present.
Using vc4-fkms-v3d instead of vc4-kms-v3d as @sakaki- and @asavah pointed out above, the problem is fixed on 4.19.66

@6by9
Copy link
Contributor

6by9 commented Aug 29, 2019

vc4-hdmi is the upstream audio driver provided as part of the full DRM/KMS driver (vc4-kms-v3d).
The HDMI peripheral only accepts IEC958 formatted data, hence your output

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi [vc4-hdmi], device 0: MAI PCM vc4-hdmi-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0

In theory you can get ALSA to do the relevant repacking of the data, but upstream never seemed to fully resolve the issues. See #2988

Using snd_bcm2835 (dtparam=audio=on) will expose one audio device that can be switched between multiple outputs (audio, HDMI0, and HDMI1 (on a Pi4 only)), and also HDMI passthrough subdevices. The HDMI passthrough devices are not runtime checked - they will always be present.

@lategoodbye
Copy link
Contributor

There is no relation between vc4-kms-v3d and snd_bcm2835. But maybe there is some kind of regression in the VCHIQ driver which prevent probing of snd_bcm2835 in case vc4-fkms-v3d is not probed.

@asavah
Copy link

asavah commented Aug 29, 2019

@lategoodbye With no *kms overlay at all snd_bcm2835 is probed and works correctly.

Note that dtoverlay is commented out in config.txt:

grep kms /boot/config.txt && aplay -l
#dtoverlay=vc4-fkms-v3d
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

kernel 4.19.68 arm64

@floion
Copy link

floion commented Sep 5, 2019

@6by9 so is this considered a bug after all?

@6by9
Copy link
Contributor

6by9 commented Sep 5, 2019

64 bit kernels are in the early stages still. I haven't had a chance to look as most of my time is on Pi4 at present.

rpi-update does now include a 64bit kernel, admittedly aimed more at Pi4 than Pi3, so retesting with a standard kernel would be useful. See https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=250730 for more details.

@lategoodbye
Copy link
Contributor

Looking at the dmesg from @NguyenTrongThinh shows there is no attempt to load snd_bcm2835.
Can someone how is affected verify that the status of snd_bcm2835 devicetree node is really set to "okay"?

@6by9
Copy link
Contributor

6by9 commented Sep 5, 2019

I've rpi-updated by Pi3, added arm_64bit=1, dtparam=audio=on, and dtoverlay=vc4-kms-v3d to config.txt.

pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi [vc4-hdmi], device 0: MAI PCM vc4-hdmi-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 1: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
  • omxplayer plays audio happily, so the VPU can produce sound (bypasses alsa).
  • VLC plays audio happily if directed at [bcm2835 ALSA] default device (it can't support the IEC958 format required by vc4-hdmi).
  • aplay -v -D plug:iec958 foo.wav plays happily through vc4-hdmi, but having done that snd_bcm2835 is distorted, probably because the two drivers are now fighting for the audio part of the HDMI peripheral.

Disable vc4-hdmi audio (dtoverlay=vc4-kms-v3d,audio=off) with dtparam=audio=on, and we have the full KMS driver with snd_bcm2835.

I fail to see any form of bug there. Back to those reporting it to give more details of what they are doing differently.

@floion
Copy link

floion commented Sep 5, 2019

I have the following:

vcgencmd version
Nov  4 2018 16:31:07 
Copyright (c) 2012 Broadcom
version ed5baf9520a3c4ca82ba38594b898f0c0446da66 (clean) (release)

My config.txt is the following (I'm on 32 bits):

dtoverlay=vc4-kms-v3d,audio=off
dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
disable_splash=1
avoid_warnings=1

and aplay -l is:

**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi [vc4-hdmi], device 0: MAI PCM vc4-hdmi-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

@6by9
Copy link
Contributor

6by9 commented Sep 5, 2019

vcgencmd version
Nov 4 2018 16:31:07

Why such an ancient firmware?
What kernel version (uname -a)? You previously mentioned 4.19.66 which was 9th Aug 2019. 4.19.69 is the latest on this branch.

And if that is what aplay -l is reporting, then the audio=off part of dtoverlay=vc4-kms-v3d is not working. Where have your device tree files come from? They obviously don't include e8e84b7

@floion
Copy link

floion commented Sep 5, 2019

Updated the kernel again to 4.19.66 (I had temporarily downgraded) and indeed, I do have that commit included. So now if I'm disabling hdmi audio as you suggested, I do have the devices listed by aplay and audio playback works as expected.

Thanks for all the input, much appreciated.

@floion
Copy link

floion commented Sep 6, 2019

Sorry to revisit this, seems there is something strange going on. Can't make it work today anymore. Wondering if there was any obscure config.txt setting I had that made it work.

vcgencmd version
Aug 28 2019 15:08:27 
Copyright (c) 2012 Broadcom
version 31098ceed842ca10c8ffd02ffe3640bf6c0190b4 (clean) (release) (start)
uname -a
Linux 68d00bf 4.19.66 #1 SMP Thu Sep 5 21:09:51 UTC 2019 armv7l GNU/Linux
config.txt:

avoid_warnings=1
disable_splash=1
dtoverlay=vc4-kms-v3d,audio=off
dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
gpu_mem=396

I do have e8e84b7 applied.

aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi [vc4-hdmi], device 0: MAI PCM vc4-hdmi-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Wondering if somebody else can reproduce this

@6by9
Copy link
Contributor

6by9 commented Sep 6, 2019

If you have vc4-hdmi ALSA device then somewhere you haven't disabled audio. Check for the file /proc/device-tree/soc/hdmi@7e902000/dmas.

It should be 0 bytes in size if audio=off has applied correctly.

If still enabled then I'd expect it to be 8 bytes

pi@raspberrypi:~ $ xxd /proc/device-tree/soc/hdmi@7e902000/dmas
00000000: 0000 000a 0000 0011

For snd_bcm2835, check /proc/device-tree/soc/audio/status contains the string "okay" (as lategoodbye commented yesterday).

@warpme
Copy link
Contributor

warpme commented Nov 12, 2019

Hi,
I'm using current rpi kernel with mainline U-boot and no matter what I can't get sound on RPI3 as I'm always ending with vc4-hdmi upstream audio driver. I already tried this comment but I'm constantly getting like this comment + there is no audio in /proc/device-tree/soc
It looks like entries in config.txt are ignored...
May somebody hint me how to move forward with this?

@pelwell
Copy link
Contributor

pelwell commented Nov 12, 2019

Unless U-boot is configured to pass through the firmware-supplied DTB, the DTB will be loaded from scratch by U-boot. This will lose any overlays and parameters set in config.txt.

@warpme
Copy link
Contributor

warpme commented Nov 12, 2019

hmm,
here is what i done:

  1. build my OS for armv7 arch
  2. built mainline u-boot with rpi_3_32b_defconfig
  3. copy u-boot.bin to /boot
  4. add kernel=u-boot.bin to config.txt
  5. prepare boot.scr with this:
fatload mmc 0:1 ${kernel_addr_r} kernel7.img
setenv bootargs earlyprintk dwc_otg.lpm_enable=0 console=serial0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
bootz ${kernel_addr_r} - ${fdt_addr}
  1. copy boot.scr to /boot
  2. use kernel7.img from here

powering-on rpi3 gives me u-boot initial u-boot log entries on screen and then all hangs on "Loading kernel...."

probably is still missing something :-(

so Q is: how to achieve

"U-boot configured to pass through the firmware-supplied DTB"
?

@pelwell
Copy link
Contributor

pelwell commented Nov 12, 2019

The firmware treats U-boot as a kernel and passes it a pointer to the DTB it has constructed. If U-boot and boot.scr are correctly configured I believe the firmware's DTB can be passed on to the Linux kernel, but you are more likely to find help for your problem on a U-boot forum.

@JamesH65
Copy link
Contributor

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants