brentr

This is a very well researched and thorough bug report. Thank you. Unfortunately, I don't have access to the hardware needed to verify it. I am the maintainer of this particular board. Do you believe this is a board specific problem, or one that is common to all Armbian Rockchip boards? Do you feel it is related to power-saving logic? (Have you tried replicating this problem on another Rockchip board?) To your last questions: I don't know the officially intended mainline policy. Could you explain what you mean by "physical I2C/SPI control loop?" Could you point me to an example of such?

Could you send me just the (short) list of packages you installed atop the base Armbian distro rather than a dump of every installed package? The goal is to provide me a simply procedure I can use to replicate the freeze you observe. You might also try running repeating the "free" command to monitor memory usage just after you start your tests. I expect you will see the swap usage steadily increasing. If you disable swap, the system will likely start killing processes.

Have you gotten bluetooth working with trixie and pipewire on other Armbian devices? I gave up on pipewire after trying it a year or so ago. Too many little audio glitches and bugs. Maybe it's better now? Anyway, if this is unique to the RockPI-S, I'll investigate further.

This looks like normal OOM behavior to me. If you want me to replicate, please provide a list of packages to apt install and the commands I need to run to start the passmark benchmark as you did.

I'm sure it is possible. I'd be happy to test your patch and submit it so it becomes part of the standard Armbian distro image. - brent

The uncompressed minimal image is about 1.5GB. How large is your trixie based image after you compress it with xz ?

Pull Request submitted: https://github.com/armbian/build/pull/8360

Look for a PR in the next few days

The bug arose with kernel commit: 21cfbeae7d7c54a6cdea4b00096150f438f4fbde ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback Committer Greg Kroah-Hartman<gregkh@linuxfoundation.org> Author Detlev Casanova<detlev.casanova@collabora.com> Author date 1/17/25 8:31 AM Parent RISC-V: Mark riscv_v_init() as __init Child io_uring/uring_cmd: use cached cmd_op in io_uring_cmd_sock() Branch kernel-rockchip64-6.12 (io_uring/uring_cmd: use cached cmd_op in io_uring_cmd_sock()) Follows test (ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83JX, 83MC...) ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback [ Upstream commit 5323186e2e8d33c073fad51e24f18e2d6dbae2da ] In commit 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates"), the set_sysclk callback was removed as considered unused as the mclk rate can be set in the hw_params callback. The difference between hw_params and set_sysclk is that the former is called with the audio sampling rate set in the params (e.g.: 48000 Hz) while the latter is called with a clock rate already computed with sampling_rate * mclk-fs (e.g.: 48000 * 256) For HDMI audio using the Rockchip I2S TDM driver, the mclk-fs value must be set to 128 instead of the default 256, and that value is set in the device tree at the machine driver level (like a simple-audio-card compatible node). Therefore, the i2s_tdm driver has no idea that another mclk-fs value can be configured and simply computes the mclk rate in the hw_params callback with DEFAULT_MCLK_FS * params_rate(params), which is wrong for HDMI audio. Re-add the set_sysclk callback so that the mclk rate is computed by the machine driver which has the correct mclk-fs value set in its device tree node. Fixes: 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates") Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://patch.msgid.link/20250117163102.65807-1-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

Further testing shows that Armbian 25.2.x through the current version all run the arecord -c 2 -r 192000 -f S32_LE test.wav without error, PROVIDED the 6.12.12 kernel is used. But, any kernel version after 6.12.12 fails. Now I've just got to find out what broke in 6.12.13 🙂

The breakage occurred between Armbian 25.2.1 and Armbian 25.2.2

I just verified that the arecord command fails also with kernel 6.12.15 So, we now know the breakage occurred between 6.12.12 and 6.12.15

I was able to duplicate this problem. Audio output appears to be working in both edge and current branches. But, The "arecord: set_params:1416: unable to install hw params" error occurs in the current branch as well. This is running kernel 6.12.28 the example arecord command you gave appears to work in kernel 6.12.12. So, the breakage occurred between 6.12.12 and 6.12.28

I will have a look at this over the weekend. Could you provide source code for your test case?

@gudvinr I just successfully flashed the nightly https://dl.armbian.com/nightly/rockpi-s/Trixie_current_minimal based on the 6.12 kernel with the 2024.10 u-boot I also successfully flashed an older image based on the 6.6 kernel and the 2022.04 u-boot. It "works for me" following the instructions at: https://www.armbian.com/rockpi-s/ What is the exact procedure you are using to flash the internal SDnand? Note that the legacy image (4.x kernel) my not boot from SDNAND. It's certainly unsupported at this point. The 6.6 and 6.12 based images should work. I'd expect the 6.1 based images to boot from SDNAND as well, but that is also unsupported. By the way, I have no B-S chips. Do you?