brentr

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.

I ran into the same issue... This might be a fix... A udev script assigns an Ethernet address derived from the UUID of the root partition. So, each machine's WiFi should be unique and unchanging -- until its root partition is reformatted. Note that that ‘42’ argument in macaddr.rules should be unique to each network interface whose Ethernet address is being assigned this way. Further, this prefix less 2 should be exactly divisible by 4 /etc/udev/rules.d/05-wlan0-macaddr.rules: KERNEL==“wlan0”, ACTION==“add” RUN+=“fixEtherAddr %k 42” /lib/udev/fixEtherAddr: #!/bin/sh #Assign specified interface a fixed, unique Ethernet MAC address constructed #as given prefix byte followed by 1st five bytes of the root partition’s UUID. #Ethernet prefix byte value less 2 should be exactly divisible by 4 #e.g. (prefix - 2) % 4 == 0 [ “$2” ] || { echo “Specify network interface and first Ethernet address byte in hex” >&2 exit 1 } ethaddr() { echo -n “$1” /bin/lsblk -no UUID /bin/findmnt -no SOURCE / | /bin/tr -d ‘-’ | /bin/fold -b2 | for byte in 1 2 3 4 5; do read hex; echo -n “:$hex”; done } /usr/sbin/ifconfig $1 hw ether ethaddr $2 This file must be made executable (chmod +x /lib/udev/fixEtherAddr) reboot and you should see the wlan0 interface's Ethernet address like this: brent@pebble:/etc/udev/rules.d$ /sbin/ifconfig wlan0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ... ether 42:bb:a9:cc:8a:e9 txqueuelen 1000 (Ethernet) brent@pebble:/etc/udev/rules.d$ /sbin/blkid /dev/mmcblk0p1: UUID="bba9cc8a-e9bb-499a-a089-e5394b7a4fde"

I think I'm finally managing to understand this Armbian build system. It's an amazing piece of work! However, after the build, many source files end up owned by the root user. There's just a lot of activity going on "as root" that probably doesn't need to be run with that privilege. Disaster seems just one build script error away. Am I doing something wrong? Is there a simple way to avoid this (without resorting to virtualization of the build environment). Has this not bothered anyone else?

The hang up on reboot has been fixed. The problem started when I installed: so the RockPI-S could boot linux from its built-in SDnand (EMMC) chip. Trouble is that this bootloader opens UART0, not UART2 This caused all u-boot console output to be gibberish, and, it somehow caused reboot to hang. As soon as I switched both u-boot and the kernel consoles back to UART0, both problems disappeared. I've been unable to find a version of the new rk3308_loader that uses UART2, so we're kind of stuck with UART0. Further, UART2 uses the same pins reserved for the CTS and RTS handshakes of UART1, which is the *only* UART with handshaking! So, I'd wanted to switch back to UART0 before I encountered these bugs. [UART0 shares one of the SPI ports, but the RD3308 has 2 or 3 more identical ones.] I'll create a PR, but for my own notes, here's a summary of the changes: rk3308_loader_ddr589MHz_uart0_m0_v2.06.136sd.bin replaces idbloader.bin rk3308-rock-pi-s-u-boot.dtsi --> switch to uart0 rk3308-rock-pi-s.dts --> switch to serial0 rock-pi-s-rk3308_defconfig --> DEBUG_UART_BASE=0xFF0A0000 boot.cmd --> switch to ttyS0 I did verify that Linux could open /dev/ttyS2 and write on it without causing subsequent reboots to hang.