brentr

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.

RockPI-S Armbian_23.5.0-trunk.219_Rockpi-s_bookworm_current_6.1.29_minimal.img is unusable. It drops keystrokes from the serial console if one types quickly and appears to put the terminal emulator into a strange state. If one is patient enough with the keyboard, one can get through the setup, but the nmtui for connecting to WiFi cannot be used. Pressing down arrow in nmtui exits it. Is anyone else having trouble configuring the minimal bookworm images? The corresponding full image is fine. Tested: Bluetooth Ethernet WiFi audio (at least the audio devices appear and the mixer works) Boot up messages on the serial console appear to be truncated at 70 columns or so. But, that's probably someone's idea of "progress" (or, am I the only one noticing this?) As noted earlier, the system failed to assign a repeatable wlan0 MAC address due to its missing ifconfig. I'll submit a PR to fix this.

RockPI-S patch to assign wlan0 a unique MAC address derived from the rk3308 serial number relied on ifconfig I need to submit a patch to switch it to use ip link set wlan0 address aa:bb:...

I will message you with a link to the image I'd like you to test with your PoE HAT. Once you confirm the fix, I'll get it incorporated into the standard Rock Pi-S images. ( [Thought I'd be able to build the test image this weekend, but the weather here got too nice to stay inside. 🙂

I inadvertently removed the rk3808 audio patches from the Armbian 6.1.x kernel patches. I'll be fixing this in the next few days. @d0pefish Would you be able to verify this audio fix with your POE hat? I don't have one.

Audio should work with an older kernel. I'll look into why it broken with the 6.x kernel. If you are using the headphone jack on the POE hat, be sure to read this: https://wiki.radxa.com/ROCKPI_S_PoE_HAT

I'm seeing the same thing with the newer kernels. I'll look into it in the coming weeks and post when I know more. Thanks for catching this. - brent

Here's a version that replaces UART2 with SPI2. This should work with v1.2 boards. Per instructions found here: https://www.emcraft.com/som/stm32f7-240/accessing-spi-devices-in-linux https://www.kernel.org/doc/Documentation/spi/spidev Created the attached devicetree overlay file Installed it with: # armbian-add-overlay rk3308-rock-pi-s-spi2.dts Rebooted To create the /dev/spidev2.0 node: # cd /sys/bus/spi # echo spidev > devices/spi2.0/driver_override # echo spi2.0 > drivers/spidev/bind That's as far as I went. Good luck! rk3308-rock-pi-s-spi2.dts

@ia64 SPI1 does not conflict with any of the UARTs. I just had a quick try enabling it. Got as far is creating the /dev/spidev1.0 node. Keep in mind that I have no SPI peripherals here. I cannot test this. Per instructions found here: https://www.emcraft.com/som/stm32f7-240/accessing-spi-devices-in-linux https://www.kernel.org/doc/Documentation/spi/spidev Created the attached devicetree overlay file Installed it with: # armbian-add-overlay rk3308-rock-pi-s-spi1.dts Rebooted To create the /dev/spidev1.0 node: # cd /sys/bus/spi # echo spidev > devices/spi1.0/driver_override # echo spi1.0 > drivers/spidev/bind That's as far as I went. Good luck!

@sbeaugrand: Thanks for pointing out the upcoming gpio patch. I have two v1.3 RockPI-S boards running the new IDBLOADER_BLOB Both boards routinely boot both from SDcards and their built-in SDnands. Unfortunately, could not test with an RockPI-S board that lacks SDnand. But, I did try holding the MASKROM button down while booting from the SDcard. The MASKROM button inhibits the clock to the SDnand, effectively disabling it in hardware. If you have a board that boots from its SDcard and another that does not, there must be some hardware difference between them. Is your board that won't boot with the new idbloader v1.2 hardware (or older)? Note: RockPI-S SPI2 shares pins with USART2. The original DTS was trying to enable both, which lead to kernel configuration errors being reported on each boot. I opted to disable SPI2.