How to run FreeBSD on new boards built on Rockchip 35XX..

covacat · Nov 4, 2025

none said:
Thanks, does FreeBSD support it?

no, but you can use a vm inside a supported os
still performance will rock compared with other boards

none · Nov 4, 2025

covacat said:
no, but you can use a vm inside a supported os
still performance will rock compared with other boards

That crossed my mind ...

Looks like Santa will have work to afford that little beast ...

Thanks for the tip.

tingo · Nov 4, 2025

covacat said:
no, but you can use a vm inside a supported os

But I don't want that - I want to run FreeBSD on the bare metal...

ZioMario · Nov 6, 2025

WhatsApp Image 2025-11-06 at 07.49.03.jpeg

none · Nov 6, 2025

tingo said:
But I don't want that - I want to run FreeBSD on the bare metal...

Hi tingo, me too. But I am considering that. If i find a good buying option on that Oragne pi 6 plus I will really consider. Now I am looking for the ethernet chip to see if its compatible, and for firmware options (u-boot and edk2, so far nothing found - had not much time on that though). The Orange Pi 5 Plus is an option as well, but also not supported. OpenBSD supports it with everything working, so I may try running VM's on it, as its closer to FreeBSD then Linux. I don't dislike Linux, I just like BSD* better, way better.

Orange pi 6 Plus uses 5 Gbps ethernet, that may not help and that's what I will look for now.

There is always the hope for future support, and then I can use FreeBSD bare metal

Phishfry · Nov 6, 2025

This whole ARM thing seems to be on a doom loop. When new CPU's are released every 6 months with almost no manufacturer support or BSP.
Heck most using thier own u-boot tree from whenever. Contribute back nothing and volunteers port it to u-boot.
Thats a pretty pathetic development pipeline.
Race to where???
The bottom?

tingo · Nov 6, 2025

or to (eventually) be replaced with RISC-V, once that side gets their performance up.

ZioMario · Nov 8, 2025

I've integrated and modified the vop2 driver ported by covacat inside the JSM222 drm-subtree :

GitHub - jsm222/drm-subtree: WIP drm drivers for FreeBSD

WIP drm drivers for FreeBSD. Contribute to jsm222/drm-subtree development by creating an account on GitHub.

github.com

using his modular structure instead of embedding the driver inside the kernel. In this way I have produced all the modules necessary for enabling the panfrost driver for FreeBSD 15.0 on the Radxa Zero 3W board :

Code:

marietto# pwd
/mnt/zroot2/zroot2/OS/BSD/FreeBSD/arm64/socs/Radxa-3W/Stuff/drm-subtree
marietto# find . -name "*.ko"
./modules/panfrost/panfrost.ko
./modules/drm_kmod/drm_kmod.ko
./modules/rockchip/rk_drm/rk_drm.ko
./modules/rockchip/rk_vop2/rk_vop2.ko
./modules/rockchip/rk_dw_hdmi/rk_dw_hdmi.ko

Now,I would like to have my ideas clear about what to do next. I mean.

At this point should I perform a fresh installaton of FreeBSD 15.0 on the sd card using a kernel config that does not enable the panfrost driver,right ?

Which dtb file should I use ? I imagine one that does not enable the panfrost driver,because I will load it later via kldload,but I suspect that I can't use the kernel config GENERIC,because I need to keep some options inside of it.

I'm also curious to know in which order those modules should be loaded in memory,because I'm sure that the order does matter.

Phishfry · Nov 8, 2025

Why not build images with Poudriere Image. You can fine tune each step. You want to build an appliance you need to learn the building tools.

ZioMario said:
I'm also curious to know in which order those modules should be loaded in memory,because I'm sure that the order does matter.

This don't sound right to me.
For example you call up a module that needs another module it will start it too.
For example enable I2C module on a PC and it will also load required i2c bus driver.
A module is a module. User should not have to worry about load order. Load the top level device and let the linker work.

i915drm is another example. Load it and watch all the other modules that get loaded.

ZioMario · Nov 9, 2025

Can I upgrade 14.3-RELEASE to 15.0-BETA 5 at this time ? As far as I know,I can upgrade only from a RELEASE to another one. If this is true,why I can actually grab the source code of the 15.0-RELEASE,if RELEASE will start on 28 November 2025 ? Infact this command works :

Code:

git clone -b releng/15.0 https://git.freebsd.org/src.git /usr/src

releng is RELEASE,right ? I tried to upgrade 14.3 to 15 with the freebsd-update script,but I got an error...

ZioMario · Nov 24, 2025

Hello.

I realized that it's too hard for me to debug the errors hidden in the panfrost driver implementation for the Radxa Zero 3W board if I embed it inside the kernel,so I'm trying to modularize all the necessary components,so that I can debug them later,when FreeBSD (15) has landed. I've already reached a good point in the development,but at the moment I'm braked by the frequently errors that I got when FreeBSD tries to boot from the sd card :

This kind of error happens often but not every time. It seems that it started to happens after having applied this Soren's patch :

Code:

diff --git a/sys/dev/sdhci/sdhci_fdt_rockchip.c b/sys/dev/sdhci/sdhci_fdt_rockchip.c
index 44a5e2ffe271..b6b916bbb40a 100644
--- a/sys/dev/sdhci/sdhci_fdt_rockchip.c
+++ b/sys/dev/sdhci/sdhci_fdt_rockchip.c
@@ -74,14 +74,17 @@
 #define    RK3399_GRF_EMMCCORE_CON11        0xf02c
 #define     RK3399_CORECFG_CLOCKMULTIPLIER        0xff
 
+#define RK35XX_CTRL_HS400            0x7
 #define    RK3568_EMMC_HOST_CTRL            0x0508
 #define    RK3568_EMMC_EMMC_CTRL            0x052c
+#define  RK35XX_CARD_IS_EMMC            0x1
 #define    RK3568_EMMC_ATCTRL            0x0540
 #define    RK3568_EMMC_DLL_CTRL            0x0800
 #define     DLL_CTRL_SRST                0x00000001
 #define     DLL_CTRL_START                0x00000002
 #define     DLL_CTRL_START_POINT_DEFAULT        0x00050000
 #define     DLL_CTRL_INCREMENT_DEFAULT        0x00000200
+#define  DLL_CTRL_BYPASS            0x01000000
 
 #define    RK3568_EMMC_DLL_RXCLK            0x0804
 #define     DLL_RXCLK_DELAY_ENABLE            0x08000000
@@ -95,7 +98,12 @@
 #define    RK3568_EMMC_DLL_STRBIN            0x080c
 #define     DLL_STRBIN_DELAY_ENABLE        0x08000000
 #define     DLL_STRBIN_TAPNUM_DEFAULT        0x00000008
-#define    DLL_STRBIN_TAPNUM_FROM_SW        0x01000000
+#define     DLL_STRBIN_TAPNUM_FROM_SW        0x01000000
+#define  DLL_STRBIN_DELAY_NUM_SEL        0x04000000
+#define  DLL_STRBIN_DELAY_NUM_OFFSET        0x10
+#define  DLL_STRBIN_DELAY_NUM_DEFAULT        0x16
+
+#define RK3568_EMMC_DLL_CMDOUT            0x0810
 
 #define    RK3568_EMMC_DLL_STATUS0            0x0840
 #define     DLL_STATUS0_DLL_LOCK            0x00000100
@@ -164,67 +172,82 @@ static int
sdhci_fdt_rockchip_set_clock(device_t dev, struct sdhci_slot *slot, int clock)
 {
     struct sdhci_fdt_softc *sc = device_get_softc(dev);
+    uint32_t uval;
     int32_t val;
     int i;
 
if (ofw_bus_search_compatible(dev, compat_data)->ocd_data ==
         SDHCI_FDT_RK3568) {
-        if (clock == 400000)
-            clock = 375000;
-
-        if (clock) {
-            clk_set_freq(sc->clk_core, clock, 0);
-
-            if (clock <= 52000000) {
- bus_write_4(sc->mem_res[slot->num],
-                    RK3568_EMMC_DLL_CTRL, 0x0);
- bus_write_4(sc->mem_res[slot->num],
-                    RK3568_EMMC_DLL_RXCLK, DLL_RXCLK_NO_INV);
- bus_write_4(sc->mem_res[slot->num],
-                    RK3568_EMMC_DLL_TXCLK, 0x0);
- bus_write_4(sc->mem_res[slot->num],
-                    RK3568_EMMC_DLL_STRBIN, 0x0);
-                return (clock);
-            }
-
- bus_write_4(sc->mem_res[slot->num],
-                RK3568_EMMC_DLL_CTRL, DLL_CTRL_START);
-            DELAY(1000);
- bus_write_4(sc->mem_res[slot->num],
-                RK3568_EMMC_DLL_CTRL, 0);
- bus_write_4(sc->mem_res[slot->num],
-                RK3568_EMMC_DLL_CTRL, DLL_CTRL_START_POINT_DEFAULT |
-                DLL_CTRL_INCREMENT_DEFAULT | DLL_CTRL_START);
-            for (i = 0; i < 500; i++) {
- val = bus_read_4(sc->mem_res[slot->num],
-                    RK3568_EMMC_DLL_STATUS0);
-                if (val & DLL_STATUS0_DLL_LOCK &&
-                    !(val & DLL_STATUS0_DLL_TIMEOUT))
-                    break;
-                DELAY(1000);
-            }
- bus_write_4(sc->mem_res[slot->num], RK3568_EMMC_ATCTRL,
-                (0x1 << 16 | 0x2 << 17 | 0x3 << 19));
- bus_write_4(sc->mem_res[slot->num],
-                RK3568_EMMC_DLL_RXCLK,
-                DLL_RXCLK_DELAY_ENABLE | DLL_RXCLK_NO_INV);
- bus_write_4(sc->mem_res[slot->num],
-                RK3568_EMMC_DLL_TXCLK, DLL_TXCLK_DELAY_ENABLE |
- DLL_TXCLK_TAPNUM_DEFAULT|DLL_TXCLK_TAPNUM_FROM_SW);
- bus_write_4(sc->mem_res[slot->num],
-                RK3568_EMMC_DLL_STRBIN, DLL_STRBIN_DELAY_ENABLE |
-                DLL_STRBIN_TAPNUM_DEFAULT |
-                DLL_STRBIN_TAPNUM_FROM_SW);
-        }
-    }
-    return (sdhci_fdt_set_clock(dev, slot, clock));
+                if (clock == 400000)
+                        clock = 375000;
+                if (clock) {
+                        clk_set_freq(sc->clk_core, clock, 0);
+ uval = bus_read_4(sc->mem_res[slot->num],
+                            RK3568_EMMC_HOST_CTRL) & (~1);
+ bus_write_4(sc->mem_res[slot->num],
+                            RK3568_EMMC_HOST_CTRL, uval);
+               
+                        if (clock <= 52000000) {
+ bus_write_4(sc->mem_res[slot->num],
+                                    RK3568_EMMC_DLL_CTRL,
+                                    DLL_CTRL_START | DLL_CTRL_BYPASS);
+ bus_write_4(sc->mem_res[slot->num],
+                                    RK3568_EMMC_DLL_RXCLK, DLL_RXCLK_NO_INV);
+ bus_write_4(sc->mem_res[slot->num],
+                                    RK3568_EMMC_DLL_TXCLK, 0x0);
+ bus_write_4(sc->mem_res[slot->num],
+                                    RK3568_EMMC_DLL_CMDOUT, 0x0);
+
+                                uval = DLL_STRBIN_DELAY_ENABLE |
+                                    DLL_STRBIN_DELAY_NUM_SEL |
+                                    DLL_STRBIN_DELAY_NUM_DEFAULT <<
+                                    DLL_STRBIN_DELAY_NUM_OFFSET;
+ bus_write_4(sc->mem_res[slot->num],
+                                    RK3568_EMMC_DLL_STRBIN, uval);
+                                return (clock);
+                        }
+
+ bus_write_4(sc->mem_res[slot->num],
+                            RK3568_EMMC_DLL_CTRL, DLL_CTRL_START);
+                        DELAY(1000);
+ bus_write_4(sc->mem_res[slot->num],
+                            RK3568_EMMC_DLL_CTRL, 0);
+ bus_write_4(sc->mem_res[slot->num],
+                            RK3568_EMMC_DLL_CTRL, DLL_CTRL_START_POINT_DEFAULT |
+                            DLL_CTRL_INCREMENT_DEFAULT | DLL_CTRL_START);
+                        for (i = 0; i < 500; i++) {
+ val = bus_read_4(sc->mem_res[slot->num],
+                                    RK3568_EMMC_DLL_STATUS0);
+                                if (val & DLL_STATUS0_DLL_LOCK &&
+                                    !(val & DLL_STATUS0_DLL_TIMEOUT))
+                                        break;
+                                DELAY(1000);
+                        }
+ bus_write_4(sc->mem_res[slot->num], RK3568_EMMC_ATCTRL,
+                            (0x1 << 16 | 0x3 << 17 | 0x3 << 19));
+ bus_write_4(sc->mem_res[slot->num],
+                            RK3568_EMMC_DLL_RXCLK,
+                            DLL_RXCLK_DELAY_ENABLE | DLL_RXCLK_NO_INV);
+ bus_write_4(sc->mem_res[slot->num],
+                            RK3568_EMMC_DLL_TXCLK, DLL_TXCLK_DELAY_ENABLE |
+                            DLL_TXCLK_TAPNUM_DEFAULT | DLL_TXCLK_TAPNUM_FROM_SW|
+                            DLL_RXCLK_NO_INV);
+ bus_write_4(sc->mem_res[slot->num],
+                            RK3568_EMMC_DLL_STRBIN, DLL_STRBIN_DELAY_ENABLE |
+                            DLL_STRBIN_TAPNUM_DEFAULT |
+                            DLL_STRBIN_TAPNUM_FROM_SW);
+                }
+        }
+        return (clock);
+
 }
 
 static int
sdhci_fdt_rockchip_attach(device_t dev)
 {
     struct sdhci_fdt_softc *sc = device_get_softc(dev);
-    int err, compat;
+    int i, err, compat;
+    char *rk35xx_clocks[] = {"bus", "timer", "axi", "block" };
 
     sc->dev = dev;
     compat = ofw_bus_search_compatible(dev, compat_data)->ocd_data;
@@ -257,6 +280,19 @@ sdhci_fdt_rockchip_attach(device_t dev)
             return (ENXIO);
         }
         clk_enable(sc->clk_core);
+
+        for (i = 0; i < nitems(rk35xx_clocks);i++) {
+                    clk_t clk_tmp;
+       
+            if (clk_get_by_ofw_name(dev, 0,rk35xx_clocks[i], &clk_tmp)) {
+                            device_printf(dev, "cannot get %s clock\n",
+                                    rk35xx_clocks[i]);
+                            return (ENXIO);
+                    }
+                    err = clk_enable(clk_tmp);
+                    if (err)
+                            break;
+            }
         break;
     default:
         break;

AND / OR when I started using the DTB file called "rk3568-nanopi-r5s.dtb" that has been patched by Soren with the following patch :

Code:

diff --git a/sys/contrib/device-tree/src/arm64/rockchip/rk3568-nanopi-r5s.dtsi b/sys/contrib/device-tree/src/arm64/rockchip/rk3568-nanopi-r5s.dtsi
index 93189f830640..e7df980d2c74 100644
--- a/sys/contrib/device-tree/src/arm64/rockchip/rk3568-nanopi-r5s.dtsi
+++ b/sys/contrib/device-tree/src/arm64/rockchip/rk3568-nanopi-r5s.dtsi
@@ -146,18 +146,22 @@
 
 &cpu0 {
     cpu-supply = <&vdd_cpu>;
+    clocks = <&cru ARMCLK>;
 };
 
 &cpu1 {
     cpu-supply = <&vdd_cpu>;
+    clocks = <&cru ARMCLK>;
 };
 
 &cpu2 {
     cpu-supply = <&vdd_cpu>;
+    clocks = <&cru ARMCLK>;
 };
 
 &cpu3 {
     cpu-supply = <&vdd_cpu>;
+    clocks = <&cru ARMCLK>;
 };
 
 &gpu {
@@ -232,6 +236,7 @@
                 regulator-name = "vdd_logic";
                 regulator-always-on;
                 regulator-boot-on;
+                regulator-init-microvolt = <900000>;
                 regulator-initial-mode = <0x2>;
                 regulator-min-microvolt = <500000>;
                 regulator-max-microvolt = <1350000>;
@@ -245,6 +250,7 @@
             vdd_gpu: DCDC_REG2 {
                 regulator-name = "vdd_gpu";
                 regulator-always-on;
+                regulator-init-microvolt = <900000>;
                 regulator-initial-mode = <0x2>;
                 regulator-min-microvolt = <500000>;
                 regulator-max-microvolt = <1350000>;
@@ -268,6 +274,7 @@
 
             vdd_npu: DCDC_REG4 {
                 regulator-name = "vdd_npu";
+                regulator-init-microvolt = <900000>;
                 regulator-initial-mode = <0x2>;
                 regulator-min-microvolt = <500000>;
                 regulator-max-microvolt = <1350000>;
@@ -470,6 +477,7 @@
     pmuio1-supply = <&vcc3v3_pmu>;
     pmuio2-supply = <&vcc3v3_pmu>;
     vccio1-supply = <&vccio_acodec>;
+    vccio2-supply = <&vcc_1v8>;
     vccio3-supply = <&vccio_sd>;
     vccio4-supply = <&vcc_1v8>;
     vccio5-supply = <&vcc_3v3>;
@@ -487,6 +495,7 @@
     bus-width = <8>;
     max-frequency = <200000000>;
     non-removable;
+    disable-wp;
     pinctrl-names = "default";
     pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd>;
     status = "okay";

Anyway,these latest patches improved the previous scenario,where most of the time the kernel was not detected at all.

Forgot to say that this fstab file :

Code:

/dev/mmcsd0p4   /               ufs     rw,noatime              1 1
#/dev/gpt/efi   /boot/firmware  msdosfs rw,noatime              0 0
md              /tmp            mfs     rw,noatime,-s64m        0 0
md              /var/log        mfs     rw,noatime,-s32m        0 0
md              /var/tmp        mfs     rw,noatime,-s8m         0 0

is not good for some reason,because this is what happens when I turn on the board :

the sd card is not recognized at the first shot,maybe this line is not correct inside the fstab file ?

Code:

/dev/mmcsd0p4   /               ufs     rw,noatime              1 1

that's odd because I can boot it manually later,by writing :

Code:

ufs:/dev/mmcsd0p4

covacat · Monday at 4:55 PM

i have iommu experimentally working. for now just the framebuffer part not synced with gpu's mmu so no advantage as of now.
now to hack the panfrost driver to get rid of contig malloc and use its own mmu

jsm · Monday at 4:58 PM

covacat said:
i have iommu experimentally working. for now just the framebuffer part not synced with gpu's mmu so no advantage as of now.
now to hack the panfrost driver to get rid of contig malloc and use its own mmu

Sounds really nice, is it the rk3399,iommu or what is the compat? Can you share the code?

covacat · Monday at 5:02 PM

rk3399 has iommu v1 and rk356x is v2 but the code supports both (its a linux driver reap off / my rk manuals have no iommu docs)
the code if full of crappy debug printf but ill post it. rk_plane needs to be hacked accordingly to use the mmu iova. also rk_vop needs some hacks to ack the iommu)
i use rockchip_vop2 which is a combined rk_plane and rk_vop

covacat · Monday at 5:15 PM

rk_iommu.c needs to be added into build tree
i use it on 14.3 so for 15 maybe some stuff needs to be changed.
for the the rk_iommu driver is probably just to remove the /extres/ stuff from some includes

the rk_gem stuff is a mess some unused functions warnings, etc
the tests ive done is just starting lxde and closing it so not extensive by a long shot but the basics (ie using random pages for the fb seems to work)
a nice artifact was before setting VM_MEMATTR_WRITE_COMBINING on the pages. it took about 10 seconds for the writes to pass to fb and it looked like typing kanjis that animated back to latin letters

covacat · Monday at 5:40 PM

at first I wanted to integrate with the cvasi generic sys/arm64/iommu/ framework but it adds too much complexity for little gain (it links to dev/iommu/ and stuff). so i just hardwired the iommu domain to the actual devices (no domains and no contexts)

covacat · 2026-01-07T07:52:08+0000

iommu_unmap is broken in the code above and the fix creates other problems
when Xorg exits and the gem object is destroyed the memory gets iommu unmapped but somehow the vop still accesses the memory and causes a flood of iommu faults
like the object is destroyed before the video address is changed in atomic_plane_update

in a no iommu scenario such a situation will may cause some temporary on screen garbage until the vt code switches to its own fb but in practice it is not visible (the memory may be set to zero before, no idea)

How to run FreeBSD on new boards built on Rockchip 35XX..

Attachments