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?

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

Ok. Mystery solved (I think 🙂 The RockPI boards always prefer to boot from their on-board flash. If there's a valid u-boot image there, it will boot that. U-boot boots Linux preferentially from the SDcard (if both SDNAND and SDcard images are valid) My board was fetching a v2024.10 U-Boot from its built-in SDNAND flash, then pulling the kernel from the SDcard. There was only the v2022.04 U-boot on your RockPi-S, which explains why my RockPI-S always booted. I can simulate the failures you all saw by holding in the button to disable the SDNAND flash. In that case, my first stage loader pulls the v2022.04 U-Boot from the SDcard and fails to boot. Unfortunately, Neither apt update nor the armbian-install of the upgraded image can update the U-Boot to v2024.10. It simply is not present anywhere in the upgraded image. The simplest fix is to download https://dl.armbian.com/nightly/rockpi-s/Trixie_current_minimal and use it to update the boot loader on the broken apt upgraded image. You will need some way to mount the broken apt upgraded SDcard on your RockPI-S while the trixie SD-card is loaded. I used a USB sdcard adapter for this. Then: 0. boot the RockPI-S from the trixie SDcard, insert the USB SDcard adapter verify the broken image is at /dev/sda # cd /usr/lib # source u-boot/platform_install.sh #this is a script used by armbian-install # write_uboot_platform linux-u-boot-current-rockpi-s /dev/sda # mount /dev/sda1 /mnt # mkdir /mnt/usr/lib/original # mv /mnt/usr/lib/*u-boot* original # cp -a *u-boot* /mnt/usr/lib # poweroff replace the trixie SDcard with the upgraded one reset The first 4 steps replace the active bootloader with the one from trixie The remainder ensures that future armbian-installs will install trixie's v2024.10 bootloader rather than v2022.04 If you have no USB to SDcard adapter you can plug into your RockPI-S, the procedure above can be run on any Linux box. Just take care to note where it mounts your SDcards, as /dev/sda may be your boot filesystem!

@MaxT Thanks for catching this. You are correct, armbian-install is the proper command. What I'm not understanding is how, if I boot with the published armbian image on a freshly copied SDcard and run only apt upgrade, my system ends up rebooting with U-boot v2024.10 whereas others end up (failing to boot) U-Boot v2022.04. Can you explain this? This is what I'm going to try to figure out this evening...

No, my mistake. I missed the serial output in your posts. The system is not rebooting because, for some reason, it did not update to u-boot to v2024.10. However, mine did. It could be that my system is working because the last U-Boot I'd installed in a previous image was v2024.10. But, that implies that the image update did not update U-Boot??! You might try running armbian-config after the upgrade to explicitly update u-boot. Let me know what happens. I will look into it more this evening.

@Truenox Once you've gotten your serial console working, repeat the update process and attach a record of all the console output the RockPI-S emits after the reboot command.

@SteeManThe boot trace above after the apt upgrade alone indicates it updated to U-Boot v2024.10. The weird thing here is that others' RockPI-S will not boot after running apt upgrade alone, but mine will. Still, I noticed that my Armbian login screen still said it was running the old version, although the kernel and packages were cleared updated. This evening, I'll see if armbian-config fixes that glitch.

U-Boot was updated recently from v2022.04 to v2024.10, but apt upgrade should have taken care that. Do you make *any* changes to the /etc/armbianEnv.txt file? I do not for these tests. Remember that you need a 3.3V TTL level serial<->USB adapter. RS-232 voltage levels might damage the RockPI-S

Note this time I omitted the dist-upgrade. It seems to be unnecessary. When I ran it later, it did nothing.