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

Hi,

Well have been busy with other stuff for a while but thought I'd chime in anyways as I was pointed at this discussion.
I have uploaded the latest of what I use here on various RK3566/RK3568 boards for quite some time:

I'll try to answer questions etc as best I can, but still busy here so patience :)
 
Thanks Soren.

I wanted to mention on the EDK2 bootloader the offset needs to be larger than u-boot size of 16M (on rockchip).
EDK2 images seem to need 20M and flashing that to most FreeBSD arm images will destory the partition scheme.

I have been leaving 32M free space for EDK2 images.

gpart create gpt da0

gpart add -t efi -s 50M -b 65536 da0

My point is you cannot flash EDK2 bootloader to RockPro64 Image. The image is setup for 16M free space. Not 20M.
 
Actually that is not necessary, seems like it looks for the "uboot" part I more than one place, havn't looked at the code though...
The provided image starts at 32M btw so no danger there, the official images might be different.
I have several systems where I just have 1MB for the loader and 3 MB for the EDK2 "uboot" part fx for the NanoPi-R5S:

# Create boot partitions (SOC specific)
gpart add -b 64 -s 1984 -t linux-data -l loader ${MDFILE}
gpart add -b 2048 -s 3m -t linux-data -l uboot ${MDFILE}

# Copy EDK2 binaries in place
dd if=$MYROOT/boot/nanopi5/idblock.bin of=$IMG seek=64 conv=notrunc,sync
dd if=$MYROOT/boot/nanopi5/NANOPI-R5S_EFI.itb of=$IMG seek=2048 conv=notrunc,sync

That makes it possible to fit it into the SPI flash, havn't played with that yet as you have to take rockchips unusual layout into the equation as well.
 
I had BrowanMerryIOT Miner running FreeBSD from USB stick....

This is RK3568 board using EVB u-boot. 2022 build.

Then I erased thier u-boot from eMMC and my SD card build don't work....

Thiers was EVB6 and mine is just EVB build. Seems DDR3 build needed.

I had to solder on 3 pins for UART and use multimeter to find ground pin.

These are dirt cheap on ebay because they were a lorawan scam.

The LoraWAN radio is in a MiniPCIe slot so I ditched that.

The UART Header was 2mm pitch and my first time doing those. Getting smaller and smaller.
 
No wonder why it would not boot.
It uses an RK3566 and needs that DTB instead. I have it working but had to set a hint.
set hint.ohci.0.disabled=1
set hint ohci.1.disabled=1

I bought two new for ~$40.
Browan PantherX2 seems to be the same board.

I dont see any deals on new ones but here is used one:
 
I see. The one you listed has "may not ship to Norway". If I go for ones that ebay says will ship to Norway, the price is about USD 135.- and up. So that might be it.
 
I bought mine over a year ago and I am just getting to it.

I would keep an eye on them as deals do come up on these.

There does seem to be a problem with the Ethernet Driver eqos is not working.

Between that and soldering on a UART header it is not ideal.
 
I do have some updates to eqos, it does ~940Mbit in both directions now, give me a few days to get things cleaned up a bit
 
The problems here could be numerous. I am not even sure this board uses EQOS. I just tried it.
Is EQOS built in the SOC or separate chip?

dmesg snippit:
Code:
eqos0: <DesignWare EQOS Gigabit ethernet> mem 0xfe010000-0xfe01ffff irq 28,29 on ofwbus0
eqos0: reset timeout!
device_attach: eqos0 attach returned 60
 
What can anybody tell me about dual Ethernet interfaces on Arm Boards?
Boards like BananaPi R2-Pro with RK3568 probably use a bridge.

But what about dual interface boards? Dual EQOS interfaces?

Is EQOS actually a RealTek chipset?
 
The RK3568 can have two "native" ethernet interfaces and is built into the SOC (Synopsis IP's), an example is the Firefly Station P2 (RK3568 ROC PC).
The RK356X has several built in interfaces/peripherals but you need to program which ones to use as all cannot be active at one time due to pin limitations.
That's what the combophy's are used to select. You have a choice of USB3/SATA/EQOS/PCIe for the 3 combophys (rk3568 the rk3566 only has two).
So you need to decide which interfaces/peripherals you want on your board for the electric wiring and then program the SOC accordingly to match your HW.
That's also why things won't work properly if you don't have the right DTS/DTB for your exact board, then the kernel won't program the SOC to work with the given electric layout of your HW.
 
Just updated the release on https://people.freebsd.org/~sos/ARM64/RockChip to the latest.
Amongst other things the EQOS ether now supports ~940Mbit/s speeds FDX.
This time a "real" installable release, should work on most rk356X boards given the right DTS is delivered from the boot code (FDT).
Boot loaders (EDK2) for Quartz64 / Nanopi R5S / ROC-PC-RK3566 and ROC-PC-RK3568 provided.
enjoy :)
(edit: trimmed release a bit got way too big for just checking things out).
 
Hi,

Wow ! This is really impressive !
Do you know if there is any chance, based on freeBSD you've released, that I can build OPNSense ?

To be honest, I'm kinda new to this subject and there's a lot of concepts that I don't really understand for a Linux kid 😆

There is a project that provides some building tools but I don't know which parameter I should tweak to build on a NanoPi-R5S.
 
Well, I haven't played with OPNSense, I'm too old for al that GUI crap :)
But from a quick look at their site looks like it's possible, however you might need my sources or patches against stock 14-stable to build it properly for the NanoPi R5S or any of the other I listed, the stock code and DTS's won't work as is.
I really should get things cleaned up and uploaded together with the compiled version, give me a little time to get that ironed out.
 
I am happy to report that the eqos driver works great on Odroid-M1 with RK3568.

Using the New Years -CURRENT build.

Booting off NVMe with u-boot, built as a slave port, residing on eMMC.

I am using a patched sys/dev/pci/dwpci.c with good results on Odroid.

Radxa Rock3A seems to be the bastard with two busses. PCI2.1 and PCI3.0.
I have that booting nice now but had to revert back to @Sleepwakers UEFI EDK2 build.
That allows one bus for NVMe and it boots fine.

The Odroid M1 has a M.2-2280 slot on top and it gives you PCI3.0 with x2 Lanes.
Bigger board but no adapters for NVMe. Has SATA and it seems to work from U-Boot. Still testing.

PetiteBoot on SPI needs to be shutoff or erased.
sf erase 0 100000

pciconf -lvbce
Code:
pcib1@pci0:0:0:0:    class=0x060400 rev=0x01 hdr=0x01 vendor=0x1d87 device=0x3566 subvendor=0x0000 subdevice=0x0000
    vendor     = 'Rockchip Electronics Co., Ltd'
    device     = 'RK3568 Remote Signal Processor'
    class      = bridge
    subclass   = PCI-PCI
    bar   [10] = type Memory, range 64, base 0, size 1073741824, enabled
    cap 01[40] = powerspec 3  supports D0 D1 D2 D3  current D0
    cap 05[50] = MSI supports 32 messages, 64 bit, vector masks
    cap 10[70] = PCI-Express 2 root port MSI 8 max data 128(256) RO
                 max read 512
                 link x2(x2) speed 8.0(8.0) ASPM disabled(L1)
    cap 11[b0] = MSI-X supports 128 messages
                 Table in map 0x20[0x20000], PBA in map 0x20[0x28000]
    ecap 0001[100] = AER 2 0 fatal 0 non-fatal 0 corrected
    ecap 0019[148] = PCIe Sec 1 lane errors 0
    ecap 001e[160] = L1 PM Substates 1
    ecap 000b[1a0] = Vendor [1] ID 0002 Rev 4 Length 256
    ecap 000b[2a0] = Vendor [1] ID 0006 Rev 0 Length 24
nvme0@pci0:1:0:0:    class=0x010802 rev=0x01 hdr=0x00 vendor=0x1344 device=0x5410 subvendor=0x1344 subdevice=0x0100
    vendor     = 'Micron Technology Inc'
    device     = '2200S NVMe SSD [Cassandra]'
    class      = mass storage
    subclass   = NVM
    bar   [10] = type Memory, range 64, base 0x40000000, size 16384, enabled
    cap 10[80] = PCI-Express 2 endpoint max data 128(256) FLR RO NS
                 max read 512
                 link x2(x4) speed 8.0(8.0) ASPM disabled(L1)
    cap 11[d0] = MSI-X supports 32 messages, enabled
                 Table in map 0x10[0x3000], PBA in map 0x10[0x3200]
    cap 05[e0] = MSI supports 1 message, 64 bit
    cap 01[f8] = powerspec 3  supports D0 D3  current D0
    ecap 000b[100] = Vendor [1] ID 1556 Rev 1 Length 8
    ecap 0018[108] = LTR 1
    ecap 001e[110] = L1 PM Substates 1
    ecap 0001[200] = AER 1 0 fatal 0 non-fatal 0 corrected
    ecap 0019[300] = PCIe Sec 1 lane errors 0

kenv snipped:
Code:
smbios.bios.reldate="01/01/2025"
smbios.bios.revision="25.1"
smbios.bios.vendor="U-Boot"
smbios.bios.version="2025.01-rc4"
smbios.chassis.type="Desktop"
smbios.planar.maker="hardkernel"
smbios.planar.product="Hardkernel ODROID-M1"
smbios.socket.enabled="1"
smbios.system.maker="hardkernel"
smbios.system.product="Hardkernel ODROID-M1"
smbios.system.serial="3e544868918eaac2"

Create a slave port in directory: /usr/ports/sysutils/u-boot-odroid-m1/ and create these files inside it.
Makefile
Code:
MASTERDIR=    ${.CURDIR}/../u-boot-master

MODEL=        odroid-m1
BOARD_CONFIG=    odroid-m1-rk3568_defconfig
FAMILY=        rk356X

.include "${MASTERDIR}/Makefile"

pkg-descr
Code:
U-Boot loader and related files for the Odroid-M1.

To install this bootloader on an sdcard just do:
dd if=/usr/local/share/u-boot/odroid-m1/idbloader.img of=/path/to/sdcarddevice seek=64 bs=512 conv=sync
dd if=/usr/local/share/u-boot/odroid-m1/u-boot.itb of=/path/to/sdcarddevice seek=16384 bs=512 conv=sync
 
Back to the EQOS driver and this:
Is EQOS actually a RealTek chipset?
So when you see 1GB interfaces with RK356x they are EQOS through the combphy.

But when you see 2.5GB Interfaces advertised I think they are PCIe interfaces and you use the realtek-kmod ports driver.

Does that sound right?

So two more candidates to test run FreeBSD:

NanoPi R5S
So the big brother offers two 2.5GB Interfaces and One 1GB interface.
Guessing realtek-kmod on the 2.5GB PCIe interfaces and EQOS on the 1GB interface

NanoPi R5C
I think this uses the Realtek kmod for both interfaces?
Wonder how it works with optional M.2 Slot and PCIe buses.
With PCIe3 x2 lanes you divide that and give PCIe3x1 to each Realtek controller and still have full EQOS.

Anybody with these boards care to leave info or pciconf output???

Odroid M1 dmeg snipped:
Code:
rk3568_combphy0: <RockChip combo PHY> mem 0xfe830000-0xfe8300ff on ofwbus0
rk3568_combphy1: <RockChip combo PHY> mem 0xfe840000-0xfe8400ff on ofwbus0
rk3568_pciephy0: <RockChip PCIe PHY> mem 0xfe8c0000-0xfe8dffff on ofwbus0
rk3568_combphy2: <RockChip combo PHY> mem 0xfe820000-0xfe8200ff on ofwbus0
 
Eureka I have SPI booting u-boot on Odroid M1 with NVMe. Look ma no (removable) boot medium.

The SPI flash does not show up under FreeBSD so I had to use U-Boot console.

From the root of my u-boot build I copied the flash bin to a fat32 formatted partition on sdcard.
gpart create -s mbr da0
gpart add -t fat32 -s 33M -b 32768 da0
newfs_msdos -F 32 -c 1 /dev/da0s1
mount -t msdosfs /dev/da0s1 /mnt
cp /usr/ports/sysutils/u-boot-odroid-m1/work/u-boot-2025.01-rc4/u-boot-rockchip-spi.bin /mnt
umount /mnt

Flash u-boot to it so you can boot off microSD.
dd if=/usr/local/share/u-boot/u-boot-odroid-m1/idbloader.img of=/dev/da0 seek=64 bs=512 conv=sync
dd if=/usr/local/share/u-boot/u-boot-odroid-m1/u-boot.itb of=/dev/da0 seek=16384 bs=512 conv=sync

Now boot up our card and escape to u-boot command prompt and flash the SPI.
sf probe
load mmc 1:1 $kernel_addr_r u-boot-rockchip-spi.bin
sf update $fileaddr 0 $filesize

That is it. Reset and remove power.

dd the ROCKPRO64 -CURRENT image to the NVMe and that is it. No dtb is required because it is built into our u-boot via FIT.
 
I have been making use of U-Boot bootflows instead of u-boot scripts.

I use the same procedure as script and manually fire up PCIe bus and scan for NVMe.
pci
pci enum
pci
nvme scan
nvme info

Then I modify the u-boot env for booting.
env print boot_targets
env set boot_targets nvme
Unless you saveenv this setting will not stick, but on first booting it tells the bootflow what device to use and that sticks.

This example is for NVMe. You could also try boot_targets=scsi for SATA booting.
 
My foray into SPI flashing led me to a problem. My Rock3A Toybrick is different than Okdo/Radxa Rock3A. Toybrick earlier.

With Okdo Rock 3A the SPI firmware fails. On Toybrick it works... So weird.

On top of all this I had to use Rock3C u-boot to bootup to flash the Rock3A. It seems u-boot for Rock3C is built differently.
It recognizes the SPI chip whereas Rock3A u-boot fails at sf probe.
So its all down to dts/dtb problems and different versions of Rock3A. The later boards are more in sych with Rock3C.

I also flashed Rock3C SPI sucessfully with u-boot provided flash bin.

So I have Rock3C and Odroid booting off SPI to NVMe. Rock3A has problems and I must use @sleepwalkers UEFI for NVMe.

I mis-stated above that FreeBSD -CURRENT works out of box. That was wrong. I must apply dwpci.c patch. In all cases here.
I am using Poudriere Image so I am sorry about my misleading statement. -CURRENT must be patched.
 
Back
Top