Research Rock Pi S, RK3308 CPU, is it supported by anything?

[ia64]

Am 20.6.2022 um 15:33 schrieb sbeaugrand:

Rockpi S is not supported and the last release is on 26-Aug-2021.
I have tested armbian 22.08 with bullseye and kernel 5.18 (edge), and it works. My usage: ethernet, usb, audio dac lineout, ir, i2c, spi, gpio.
With kernel 5.15 (current), module snd_soc_rk3308 is loaded, but there is no audio device.

How to build on debian with cross compilers installed :
 

df -h .  # 6,5G needed
git clone https://github.com/armbian/build.git armbian-build
cd armbian-build
sudo apt install debootstrap
sudo modprobe loop
systemd-run -p CPUQuota=$((`nproc`*50))% --scope bash -c './compile.sh BOARD=rockpi-s BRANCH=edge BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no CLEAN_LEVEL=, RELEASE=bullseye SKIP_EXTERNAL_TOOLCHAINS=yes'
cd output/images
ls -l Armbian_22.08.0-trunk_Rockpi-s_bullseye_edge_5.18.5_minimal.img
-rw-rw-r-- 1 root sudo 1061158912 19 juin  21:16 Armbian_22.08.0-trunk_Rockpi-s_bullseye_edge_5.18.5_minimal.img

 

Hallo sbeaugrand,

 

I am a bloody Newbie.

your how-to was very helpful, but how do I enable spi? the needed entry in the armbianEnv.txt does seem to have any effect. And if I type in dmesg|grep spi, the output is the following:

Zitat

[    1.632443] rockchip-pinctrl pinctrl: pin gpio1-22 already requested by ff0c0000.serial; cannot c
laim for ff140000.spi
[    1.632479] rockchip-pinctrl pinctrl: pin-54 (ff140000.spi) status -22
[    1.632499] rockchip-pinctrl pinctrl: could not request pin 54 (gpio1-22) from group spi2-miso  o
n device rockchip-pinctrl
[    1.632515] rockchip-spi ff140000.spi: Error applying setting, reverse things back

 

What steps do I have to make?

 

best regards

[brentr]

I noticed, along with a few others, that cpufreq was not working with the 5.18 kernel.

Turns out that this due to another device tree error in:

  /boot/dtb/rockchip/rk3308-rock-pi-s.dtb

I believe that earlier rk3308 silicon allowed clocking to 1.3Ghz, while the current (BS suffix) silicon only allows clocking to 1.01Ghz.

The rk3308-rock-pi-s.dtb was attempting to "enable" operating points for clock rates >1.01Ghz, which had been entirely deleted from the base device tree.  The cpufreq-dt device driver would try to process these enabled, but undefined, operating points and bail out, leaving cpufreq non-functional.

 

The attached /boot/dtb/rockchip/rk3308-rock-pi-s.dtb deletes all references to operating points faster than 1.01Ghz as well as enabling the SDnand.  By the way,  simple audio output works fine in my limited testing.  The audio mixer is very weirdly configured, but the defaults more or less work.

 

Running Armbian (5.18 kernel) with a working cpufreq using the "ondemand" governor,

my Rock PI S draws only an average of 0.39W (averaged over 9 hours) idling with built-in Ethernet connected.

👍

rk3308-rock-pi-s.dtb

Edited July 3, 2022 by brentr

[schwar3kat]

4 hours ago, brentr said:

earlier rk3308 silicon allowed clocking to 1.3Ghz

Hi Brentr,

 

There is a patch in Armbian build that appears to enable 1300mhz for rockpis.
build/patch/kernel/rockchip64-edge/board-rockpis-0028-arm64-dts-rk3308-add-opp-1300mhz.patch

adds the following lines to the DTS.  Are these your changes?
+&cpu0_opp_table {
+    opp-1200000000 {
+        status = "okay";
+    };
+    opp-1296000000 {
+        status = "okay";
+    };
+};

You may want to disable that patch and build to see if it fixes your issue, then perhaps submit a PR.

https://docs.armbian.com/Developer-Guide_Build-Preparation/

[brentr]

Hi Schwarekat,

 

It is precisely that patch that causes the failure as it assumes that there are already populated opp-12* nodes in the device tree.

These may have been there in older kernel versions, but they are gone in 5.18

[perhaps because the latest RK3308B-S chips don't support clocking this fast?]

It might be possible to overclock the new chips at these rates, but the required operating point definitions would have to be defined in full.

 

This document from Radxa :

https://dl.radxa.com/rockpis/docs/sw/RK3308B-S&RK3308H-S_Software_Compatibility_Introduction_V1.0.0_20211016.pdf

 

seems to imply that the Linux kernel is overvolting the B-S silicon.  It also shows a supported 1.104Ghz op point.

 

# cat /sys/kernel/debug/opp/opp_summary
device rate(Hz) target(uV) min(uV) max(uV)
-------------------------------------------------------------------
cpu0
408000000 850000 850000 1200000
600000000 900000 900000 1200000
816000000 1000000 1000000 1200000
1008000000 1125000 1125000 1200000
1104000000 1200000 1200000 1200000

 

I'm going to try these operating points, as I'm more interested on saving power than running faster.

 

There are also drive strength configurations in the dtb that are incorrect for the newer B-S suffix part.

 

Not really sure what to do with regards to a generally applicable patch.

There are still lots of older (B suffix) parts in the wild, correct?

 

In the pre devicetree days, one would query the part early in the boot and configure it appropriately.

Is this progress?

[brentr]

Good news!

 

The updated operating points for the RK3308B-S do work.

sysbench confirms a 10% speed improvement.

But, more importantly, idle power consumption is almost halved!!!!

[from 0.39W measured previously to about 0.20W when running the CPUs at 0.85V as opposed to 0.95V]

I need to run this overnight to confirm.

 

I'll look into the other B-S silicon device tree updates soon.

 

Does anyone have ideas on how best to package this?

 

I've read the docs here:

https://docs.armbian.com/User-Guide_Allwinner_overlays/

 

but they refer to Allwinner for 64-bit arm and some of the example dirs seem to be missing.

 

Are device tree overlays supported for Rockchip?

Can anyone point to an example of their use?

 

Do we end up with a magic rk3308bs.dtbo file that one moves into an overlay to optimize performance?

 

Is there a better approach?

Does the older (B) silicon even boot with these updated (BS) operating points?

 

Attached is the latest version of the rk-3308-rock-pi-s.dtb optimized for the BS chips.

rk3308-rock-pi-s.dtb

Edited July 4, 2022 by brentr

[schwar3kat]

Hi Brentr,

In the Armbian build system the Rockchip64 overlay dts files can be found in
build/cache/sources/linux-mainline/linux-x.xx/arch/arm64/boot/dts/rockchip/overlay/
There are examples of overclocking in the mix. rockchip-rk3399-opp-2ghz.dts/dtbo is possibly similar.

Note: to populate the cache you will need to build a Rockchip64 board. 
These files are compiled by the build system to produce dtbo files in the boot dtb overlay folder in the image, however they are refreshed every build.  You will need to generate a patch to build the image.

If you want to contribute by PR into Armbian, you will need a Git hub branch.   Instructions in the documentation.

Or if you just want to test it you could just build locally with the create patch option, and after adding your dts into the folder and setting the Makefile and updating the readme at the second pause in the build, continue the build.  The dtbo will be included in the image and the patch created can be included in future builds (and/or submitted in a PR).

Oh and you might need to remove the existing dtb overclock patch.

I'm happy to help you with Armbian build if you're interested.  (I don't have experience with dtbo's but they shouldn't be too difficult)
https://docs.armbian.com/Developer-Guide_Build-Preparation/

Regards K

[brentr]

Thanks for that info.

Update on testing:

   The power savings was seeing was largely due to my having forgotten that I'd disabled WiFi.

   The average power w/o WiFi measures  0.22W -- still impressively low.

   Average with WiFi and the optimized operating points for the BS chip is closer to 0.35W (about what one would expect)

 

[brentr]

I'm created two device tree overlays.

One enables the SDnand. 

The other optimizes the CPU operating points for the currently shipping rk3308B-S SOCs.

 

rk3308-rock-pi-s-sdnand.dts enables the SDnand.  I believe there is no problem with this even if the board lacks the SDnand chip.

I tested this by holding the MASK-ROM switch down during the whole boot, which effectively disables the SDnand.

Still, it would be better if someone with a board lacking the SDnand could verify the overlay has no ill effect.

 

rk3308bs-rock-pi-s.dts corrects the CPU operating points for the B-S parts.  It also restores the function of cpufreq.

The overlay includes overclocked operating points to 1.3Ghz, but all >= 1.2Ghz are disabled.

Just for fun, I overclocked to 1.3Ghz.  Everything seemed stable at 22C room temperature.  However, the chip got noticeably warmer during sysbench.

 

I'd rather wait to get some testing feedback from other users before preparing a pull request.

After all, the armbian-add-overlay script makes these dts files dead easy to install.

 

These fixes really belong in the Linux kernel, no?

Does Armbian even attempt to push these sorts of fixes upstream?

 

By the way, my PI-S draws 0.32W averaged over ten hours when idling with the B-S optimized CPU operating points and WiFi enabled.

I measured 0.39W average under the same conditions without the rk3308bs-rock-pi-s overlay.

 

rk3308-rock-pi-s-sdnand.dts rk3308bs-rock-pi-s.dts

[brentr]

Never mind my question about these fixes going into the mainline Linux kernel.

I see now that the mainline has no support specifically for the RockPi-S.

 

The offending Armbian patches seem to be:

build/patch/kernel/archive/rockchip64-5.18/board-rockpis-0028-arm64-dts-rk3308-add-opp-1300mhz.patch

and

build/patch/kernel/archive/rockchip64-5.18/board-rockpis-0030-disabled-emmc-fix-boot-sdcard.patch

 

So, a Pull Request would merely delete these two files.

 

Still not sure how to handle the optimized operating points for the current B-S silicon.

We certainly don't want two entirely different build targets (one for B silicon, the other for B-S)

 

To do it "right", is seems one would have to create a rk3308.scr (u-boot script) that would somehow determine whether it was running on the B-S silicon and, only then, apply the rtk3308bs specific dts overlays.

Is there any precedent for that sort of logic? 

Is there a better way?

Edited July 5, 2022 by brentr

[brentr]

I just submitted https://github.com/armbian/build/pull/3966

This just deletes the two erroneous .dts files that got added quite recently.

I'm still hoping to hear from someone about where/how best to deploy the operating point fixes for the B-S SOC only.

 

[brentr]

 

U-Boot and Linux now have no trouble accessing the EMMC, however my boards will not even begin booting from EMMC.

 

I've tried 3 different methods to get my Rock PI S boards to boot Armbian from their internal SDnand (aka EMMC) chips:

  first:  copying a working SD-Card filesystem to EMMC, then carefully copying the MBR and disk sectors from 0x40 to 0x8000.

  second:  Installed the whole working Rock PI S edge image directly onto the EMMC via USB with the rkdeveloptool

  third:  Finally discovered the easy way -- with the slick  nand-sata-install script!

 

In all cases, both ttyS0 and ttyS1 produced no output on reset.  The hearbeat LED never starts.

 

What are the typical reasons booting from EMMC fails on RockChip SOCs?

Did booting from EMMC ever work when the board was officially supported?  (am I looking for a regression?)

By the way, an older OpenWRT from the RockPI S based on Linux 5.4 kernel does boot from EMMC (=SDnand)

 

Again, I know the board is unsupported.  I'm just asking for some pointers so I can start digging into this issue.

 

Thanks in advance for any help

[brentr]

Just finished a bit of bisecting on the archived archive images here:

https://armbian.hosthatch.com/archive/rockpi-s/archive/

 

All images based on the legacy 4.4 kernel boot from EMMC successfully.

Armbian_21.02.1_Rockpi-s_buster_current_5.10.12_minimal boots from EMMC

Armbian_21.05.9_Rockpi-s_buster_current_5.10.43_minimal fails to boot from EMMC

although Armbian_21.05.9_Rockpi-s_buster_legacy_4.4.247_minimal starts booting from EMMC, but UBoot fails with the error:
 

ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
SCRIPT FAILED: continuing...
Card did not respond to voltage select!
mmc_init: -95, time 9

Device 0: unknown device

 

Would it be possible to boot a edge kernel with the last working U-Boot?

 

Specifically, could one reasonably expect be able to boot the 5.18 kernel with the U-Boot binary in Armbian_20.11.10_Rockpi-s_buster_current_5.9.14_minimal.img  ?

 

Armbian_21.05.9_Rockpi-s_buster_legacy_4.4.247_minimal.ubootErrors

[brentr]

SOLVED!

 

Just determined that, when their is no serial output after reset:
 

$ rkdeveloptool ld

DevNo=1    Vid=0x2207,Pid=0x330e,LocationID=103    Maskrom

 

This implies that the Rockchip ROM bootloader failed to find a suitable image, right?

 

So, why would an image that loads fine off the removable SD card fail to be recognized as valid when simply copied to the built-in SDnand?

 

I'm not familiar with Rockchips bootROM 1st stage boot loader.

Is there some checksum/verification operation in it that's storage device dependent, preventing the loading of a copied image?

 

Does this document describe the current Rockchip bootloader used by Armbian?

http://opensource.rock-chips.com/wiki_Boot_option

 

The instructions on the Wiki page mention updating the rkxx_loader_vx.xx.bin
 

$ rkdeveloptool db rk3308_loader_ddr589MHz_uart0_m0_v2.06.136sd.bin

$ rkdeveloptool ul rk3308_loader_ddr589MHz_uart0_m0_v2.06.136sd.bin

 

Updating the bootloader as above allows the 22.08.0-trunk to boot from the RockPI-S EMMC 🙂

 

Bootload binary available here:

https://dl.radxa.com/rockpis/images/loader/rk3308_loader_ddr589MHz_uart0_m0_v2.06.136sd.bin

 

IMPORTANT:  updating to this newer loader causes the reboot command to hang.

Reset or power cycling is required to restart the system 😞

 

Thoughts?

 

Edited July 9, 2022 by brentr

[brentr]

Any idea why u-boot is outputting gibberish on its serial (UART2) port until the Linux Kernel takes control of it?

The baud rate, if wrong, is nonstandard.

Could uboot be failing to initialize UART2 because it assumes that the previous stage had already done so?

But, the previous stage of the loader outputs to UART0

 

Is there any way, short of recompiling U-Boot, to force it to initialize the serial port?

 

[brentr]

Reboot hang might have something to do with this issue:

 

https://patchwork.kernel.org/project/linux-rockchip/patch/20191003215036.15023-3-smoch@web.de/

 

The bootloader has trouble coping with cards already in UHS mode?

 

In this case, the developer gave up and forced a hard reset:

https://lists.denx.de/pipermail/u-boot/2019-November/392197.html

Edited July 9, 2022 by brentr

[ia64]

Am 2.7.2022 um 19:40 schrieb ia64:

Hallo sbeaugrand,

 

I am a bloody Newbie.

your how-to was very helpful, but how do I enable spi? the needed entry in the armbianEnv.txt does seem to have any effect. And if I type in dmesg|grep spi, the output is the following:

What steps do I have to make?

 

best regards

Dear boys and girls,

 

can someone help me my problem please? 😅 I am stuck and not able find a solution to that.

I would be very thankful for any hint and/or help.

✌️

[brentr]

The hang up on reboot has been fixed.

The problem started when I installed:

23 hours ago, brentr said:

rk3308_loader_ddr589MHz_uart0_m0_v2.06.136sd.bin

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.

 

Edited July 10, 2022 by brentr

[Jen678]

I'm a newbie in it. Thank you for testing! It heled me a lot.

 

[ia64]

Am 10.7.2022 um 08:51 schrieb brentr:

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.

 

Hello Brentr,

 

could you make an step-by-step how I enable SPI2 on it for idiots like myself?😅🙏

thank you in advance

 

best regards:)

[sbeaugrand]

Two good news :
- Rockpi S is supported again
- There is a bugfix to get gpio values via sysfs and libgpiod
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/drivers/gpio/gpio-rockchip.c?h=linux-5.19.y&id=a11544efbcf5caa1c6e7ccc8e0f3bf1b63c9b500

Kernel must be >= 5.19.17, or wait the next release of armbian rockpi s.

I have two Rockpi S without SDNAND and one refuse to boot on SDcard.
If you have the same problem :

sed -i 's/^IDBLOADER_BLOB/#IDBLOADER_BLOB/' config/sources/families/rockpis.conf
touch .ignore_changes
sudo rm ./cache/sources/u-boot/v2022.04/idbloader.bin
./compile.sh ...

 

@ia64

If you use armbian 22.11, spi2 is disabled, see :
https://github.com/armbian/build/commit/d3a3afe3850861ceaeb44f3631251c764a28cd43
For the moment i don't use spi but this overlay :

overlay-rockpi-s.dts
You can replace "disabled" by "okay", and :

sudo /usr/sbin/armbian-add-overlay overlay-rockpi-s.dts && sudo reboot

In this overlay, gpio-line-names is usefull with libgpiod (sysfs is deprecated
https://www.thegoodpenguin.co.uk/blog/stop-using-sys-class-gpio-its-deprecated/)
to have the standard gpio pin between pin1 to pin24. I have equivalent overlays
for Orange Pi Zero and Nanopi Neo and access pins with their physical pin number.

[brentr]

@sbeaugrand:

Thanks for pointing out the upcoming gpio patch.

 

I have two v1.3 RockPI-S boards running the new

Quote

rk3308_idbloader_ddr589MHz_uart0_m0_v2.06.136sd.bin

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.

 

 

[sbeaugrand]

@brentr

"v12 20190910" on both boards. One of them doesn't seem to be working well. Never mind.

I agree to disable the spi2.

Best regards

[ia64]

@brentr

 

Hello brentr,

 

how are you doing?

How do I disable UART2, if I want to use SPI2?

 

Please do not disable any SPI 😢

 

Best regards

[brentr]

@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!

 

[ia64]

Hello @brentr

 

thank you for your quick response. Your approach did help to some extend, but it is not your fault. I use the v1.2 version, which doesnt have spi1 on the poinout table.  Can I just modify dts file to get the spi2 or spi0? I guess I have to disable UART0 or  UART1/UART2?

Thanks

 

best regards

[brentr]

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