brentr

Well.... I suspect that the apt upgrade procedure is not compatible with the 6.6.63 kernel. This just worked fine for me: 1. Flash https://dl.armbian.com/rockpi-s/Noble_current_server to an SDcard. 2. Then, run 3. apt update 4. apt upgrade 5. apt dist-upgrade 6. reboot. Note that the apt dist-upgrade step is probably not necessary, but it is the documented procedure. The system ends up running kernel 6.12.9 Audio works. But, you have two audio codecs. The default is not the one you want. (It is only appropriate for another, similar RockPI board) So, here's how you disable the it: If you are using the RockPI-S POE hat (as I am), you'll also need to run these commands to enable its headphone output: I put them in my /etc/rc.local file. I then rebooted and set the mixer levels with alsamixer. Tested audio by playing mpg files via the mpg321 package. If you confirm this works for you, I'll add the blacklist instructions to the rockpi-s webpage.

What hardware version of the Rock PI-S board do you have? (I have v1.3)

Please confirm... to duplicate this one just needs to: Flash https://dl.armbian.com/rockpi-s/Noble_current_server to an SDcard. Then, run apt update apt upgrade and, subsequent reboot will fail. Correct? One strange thing here is that the description of these images on https://www.armbian.com/rockpi-s/ say they run the 6.6.62 kernel, but @Truenox claimed to be running 6.63.

Sorry to hear this. I should have time to look into next week. Are you using Debian or Ubuntu? Exactly which image did you start from? (Can you provide a link to the image?) Did you try a fresh install of the latest stable image?

I think I have seen this before, but wasn't sure whether it was a bug. On your system, what is the output of: # ls -l /dev/mmcblk*

Applying the overlays manually works. I use the s0-ext-antenna and b@1.3ghz overlays frequently. I've never done it any other way.

There is an audio fix for the RockPI S going into the 6.6 "current" kernel. Try reinstalling "current" after the next time it updates (in a few days) Kernels later >6.10 switched to the mainline support for this audio chip. It sort of works, but the audio level controls do not.

More research showed that this was fixed in v2024.10 of U-Boot slated for the next RockPI-S armbian release. [The current release uses the older v2022.04 U-Boot.] When you see you are booting with v2024.10 U-Boot, you may remove the MAC fix for the built-in ethernet interface. You will still need it for the WiFi, however.

The 6.8.11-edge kernel looks good. Can you get audio from that?

Confirmed that the 6.9 kernel still supports RK3308 audio It is still buildable within the current Armbian -- with proper configuration. Investigating how best to publish this.

Well, there's really no mystery here after all. The relevant audio patches were disabled because they had been allegedly mainlined. Did anyone test after making these wholesale changes? Looks like the support got disabled then put back and disabled again. Version 6.9 might be the last one that worked.

Opened Jira issue for tracking this: https://armbian.atlassian.net/issues/AR-2542

@eselarm I'm seeing that both the 6.6 and 6.12 kernels have broken RK3308 audio support. In both, with the Auto Hat installed, ls /dev/snd shows only the seq and time device nodes. With older kernels I see: # ls /dev/snd by-path controlC0 pcmC0D0c pcmC0D0p seq timer Does this agree with what you are seeing? Do you also see these device nodes when running the 6.7 and 6.8 kernels? If so, could you send me the output of $uname -a for those working kernels. Sound support for the RK3308 is provided via a fairly large patch. It's gotten broken before. Finding the last working version will be _very_ helpful. What's really odd here is that 6.6 doesn't work and 6.7 does and, then, 6.11 fails?! I'll make some time in the coming weeks to look into this.

Verified that RockPi-S and Rock S0 build-in Ethernet MAC are derived from something in the image, rather than a unique hardware address. The fix will be to make standard what @grixm has done, which will derive the MAC addresses of all the built-in network peripherals from the unique CPU serial number. The built-in WiFi MAC was coming up different on each boot, which was obviously wrong and has already been fixed. I'll submit a pull request shortly. It should make into the next release. Thanks for catching this.

I confirmed that the RockPI-S built-in ethernet will not communicate at 10Mbit/s. (tested with an embedded board whose Ethernet is limited to 10Mbit/s) Will look into this in the coming weeks. Thanks for the report.