brentr

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?

RockPI-S and RockS0 utilize flash memory chips with integrated controllers that emulate an SD-Card. The RockPI-S has a flash chip marketed as "SDNAND" But, it's actually an EMMC with a 4-bit wide bus interface. (just like an SDcard) None of these boards utilize "raw" NAND flash memory. I haven't verified that SDnand and EMMC booting still works with the latest versions. I'll give it a try in the coming days.

@ValdikSS Please clarify... Are you still having trouble booting after upgrading, even after following the procedure earlier in this post flagged "solution"? Until you follow those instructions, armbian-install will install the older u-boot version, which is incompatible with the new kernel that apt upgrade installs.

placeholder