Running FreeBSD on Radxa Rock 3C RK3566 board

here is the patch
SFC (serial flash controller) is similar with SPI but not quite the same
my patch is based on the linux driver with dma support removed (maybe I'll add it later)
freebsd has no sense of transfer direction on SPI bus and thats problematic for SFC because SFC is half duplex and you have to know the
transfer direction.
i detected direction by looking at the command code which i pulled from the spi-nor driver
because there are probably no other devices connected to SFC this will probably be ok

you may need to add your particular flash type to sys/dev/flash/mx25l.c ( i added the ones found on my orange pi 3b and my orange pi zero3)
 

Attachments

covacat said:
here is the patch
SFC (serial flash controller) is similar with SPI but not quite the same
my patch is based on the linux driver with dma support removed (maybe I'll add it later)
freebsd has no sense of transfer direction on SPI bus and thats problematic for SFC because SFC is half duplex and you have to know the
transfer direction.
i detected direction by looking at the command code which i pulled from the spi-nor driver
because there are probably no other devices connected to SFC this will probably be ok

you may need to add your particular flash type to sys/dev/flash/mx25l.c ( i added the ones found on my orange pi 3b and my orange pi zero3)
Click to expand...
Thanks, this is great work.
What about the eMMC module, does it work?
 
ok, so if i force read write via dtb writes fail on emmc, various time outs and cache flush fails

eqos driver looks like a quick hack so it does not have support for speed
i partially fixed the missing fdt parts but set speed fails because the clock tree is broken so setting the gmac clock wont select the correct parent
probably adding some flags in the cru driver for the clocks will fix it but i don't really cared about lower speed so stopped investigating
 
SleepWalker can you test this patch
its against 14-RC1
now the mmc works in hs200 mode but still readonly and the stare register reports the card is readonly
will try tomorrow with the official opi image and/or reinsert the card
could not find any gpio pins that force it r/o so no idea as of now
 

Attachments

Hi covacat
All done except - rk3568_cru.c
--------------------------
|diff --git a/home/titus/builds/freebsd-src/sys/arm64/rockchip/clk/rk3568_cru.c b/sys/arm64/rockchip/clk/rk3568_cru.c
|index f599232..0fe0cf2 100644
|--- a/home/titus/builds/freebsd-src/sys/arm64/rockchip/clk/rk3568_cru.c
|+++ b/sys/arm64/rockchip/clk/rk3568_cru.c
--------------------------
Patching file sys/arm64/rockchip/clk/rk3568_cru.c using Plan A...
Hunk #1 failed at 480.
Hunk #2 failed at 497.
Hunk #3 failed at 784.
3 out of 3 hunks failed--saving rejects to sys/arm64/rockchip/clk/rk3568_cru.c.rej
done

Just show your version rk3568_cru.c
 
here it is
this is less important anyway, just is has some bugs that prevents some clocks to be set at the desired freq but i think only opi 3b needs them by default
they are specified in the cru dts node but not present in quartz64
 

Attachments

@covacst

Thank you. I'll definitely try to understand how it works.
I don’t have an OrangePi 3b yet, but there are many other boards on rk3566/68 and recording on eMMC is impossible on all of them. I'll check the suggested patches and post them. I would like to note that if you assemble the GENERIC-MMCCAM kernel, the recording will work but is very unstable.

I have several patches that allow rk3566/68/88 to run in ACPI mode using Tianocore EDK2 UEFI. This works great especially on OrangePi 5 Plus. These patches were written by sos@freebsd.org and a few by me. If they are interesting, just let me know.

I really want to fix the error with Ethernet, because my Internet provider provides an Ethernet port of 100Mbps and this speed does not work because there is no correct clock.. I have an OPNsense build for Rockchip which I have been using for a long time on the RK3399, now it’s time for the RK3566/68/88 :cool:
 
here are my findings so far on the opi 3b
the emmc seems to work if the clock is higher than 50Mhz, if its lower it will fail attachment with a crc error.
because sdhci_fdt.c does not provide timing setting, voltage setting an tune/retune it wont go > 50 MHz.
i included the functions in the patch
while testing i found some bugs in the clock tree code and i fixed them too
i have no idea why it would not work @ 50MHz
in linux works at 198Mhz
read performance is about 150MB/s
 
Hi covacat!

Thanks for your work.
I build the RC2 test kernel and the suggested patches.
I tested on Radxa E25(RK3568). https://wiki.radxa.com/Rock3/CM3p/e25/getting_started

eMMC read speed has increased from 80Mbps to 159Mbs. WOW :eek:

root@Radax-E25:~ # dmesg | grep ^mmc1 mmc1: <MMC/SD bus> on sdhci_fdt0 mmc1: Probing bus mmc1: SD probe: failed mmc1: MMC probe: OK (OCR: 0x40ff8080) mmc1: Current OCR: 0x00ff8080 mmc1: Probing cards mmc1: New card detected (CID 88010344394431364787b1166ba02800) mmc1: New card detected (CSD d0ffff329f5903ffffffffe796400000) mmc1: Card at relative address 0x0002 added: mmc1: card: MMCHC D9D16G 8.7 SN B1166BA0 MFG 02/2021 by 136 0x0003 mmc1: quirks: 0 mmc1: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) mmc1: memory: 30310400 blocks, erase sector 1024 blocks, read-only mmc1: setting transfer rate to 200.000MHz (HS200 timing) root@Radax-E25:~ # dd if=/dev/mmcsd1 of=/dev/zero bs=1m status=progress count=1000 952107008 bytes (952 MB, 908 MiB) transferred 6.001s, 159 MB/s 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 6.619144 secs (158415662 bytes/sec) root@Radax-E25:~ #
Full of information (dmesg and much more) is here
Probe URL: https://bsd-hardware.info/?probe=db96ffb93a
I guess I need to work on my DTS and compare it with DTS for OrangePi 3B.
Many cloсks are still not defined or described correctly.
Unfortunately eMMC is still in read-only mode.

Thank you for your work, this is a great advancement.
 
Hi.
This may be of interest to OrangePi 3B owners.
There is an alternative way (not U-boot) to run FreeBSD on OrangePi 3B. This is using Tianocore EDK2 UEFI.
Recently, code for the OrangePi 3B was included in the UEFI code.
github.com

Add Orange Pi 3B platform (#62) · jaredmcneill/quartz64_uefi@747c6fe

Tested to be working: - UART - HDMI - USB - eMMC - GMAC (in NetBSD and VMware ESXi) - PCIe - PMIC & CPU voltage regulator Limitations: - SD card gets detected but var...
github.com github.com

One of the benefits you get by using UEFI is that HDMI works in frame buffer mode, even when you use FDT mode.
And also ease of debugging DTS, because you can always use ACPI mode to reliably start your device,
and replace your DTB with the correct one.
Switching between ACPI and FDT can be done in the UEFI setup menu before the OS starts or in the FreeBSD loader.efi command line or in /boot/loader.conf
root@OrangePi-5P:~ # head /boot/loader.conf # # Hack to get loader to find dtb. # #dtbfile_load="YES" #dtbfile_type="dtb" #dtbfile_name="rk3566-rock3b.dtb" # ACPI or FDT kern.cfg.order="acpi" # Kernel params hw.regulator.disable_unused="0" kern.geom.label.gptid.enable="0" kern.geom.label.disk_ident.enable="0"
For these terms in loader.conf to work, DTB must be placed in the /boot/dtb directory and not in /boot/dtb/rockchip

The easiest way to test UEFI is to write it to an SD card with the dd command,
use a USB flash to write a FreeBSD image in which there should be an ESP partition with efi/boot/bootaa64.efi this is copy of loder.efi.

At the moment the UEFI repository does not contain binary code for OrangePi 3B, but it can be easily compiled.
At the moment I do not have an OrangePi 3B, I have already assembled UEFI for it. You can test it and share the results.
ORANGEPI3B_EFI.img

UEFI can be written to eMMC using the rkdeveloptool utility via USB OTG.

Or create an image of a bootable SD card in which U-boot is replaced with UEFI.
 
I've been running -CURRENT on ROCK 3C for the last few days.
Everything seems to be working fine.

1. powerd / freq control is working thanks to covacat patch - do you plan to upstream that into FreeBSD base?

2. Ethernet speed I get around 400MBit/s

3. NVMe works. My drive is kind of cheap, but
Transfer rates:
outside: 102400 kbytes in 0.496869 sec = 206091 kbytes/sec
middle: 102400 kbytes in 0.349048 sec = 293369 kbytes/sec
inside: 102400 kbytes in 0.347641 sec = 294557 kbytes/sec
Asynchronous random reads:
sectorsize: 55661 ops in 3.007276 sec = 18509 IOPS
4 kbytes: 23177 ops in 3.026735 sec = 7657 IOPS
32 kbytes: 20945 ops in 3.016515 sec = 6943 IOPS
128 kbytes: 5928 ops in 3.095425 sec = 1915 IOPS
1024 kbytes: (this one causes controller to timeout and reset, but it's gone after that, need to reboot board to have it back)

nvme0: Resetting controller due to a timeout.
nvme0: resetting controller

4. 2 bottom usb port work. Some tests on my USB3.0 old stick connected to blue port:
Transfer rates:
outside: 102400 kbytes in 0.738719 sec = 138618 kbytes/sec
middle: 102400 kbytes in 0.791158 sec = 129431 kbytes/sec
inside: 102400 kbytes in 1.573646 sec = 65072 kbytes/sec

Asynchronous random reads:
sectorsize: 5233 ops in 3.077608 sec = 1700 IOPS
4 kbytes: 4910 ops in 3.081414 sec = 1593 IOPS
32 kbytes: 3252 ops in 3.124578 sec = 1041 IOPS
128 kbytes: 1527 ops in 3.282887 sec = 465 IOPS
1024 kbytes: 344 ops in 4.607022 sec = 75 IOPS

The same stick connected to USB2.0 port:
Transfer rates:
outside: 102400 kbytes in 3.028623 sec = 33811 kbytes/sec
middle: 102400 kbytes in 3.227679 sec = 31726 kbytes/sec
inside: 102400 kbytes in 3.052265 sec = 33549 kbytes/sec

Asynchronous random reads:
sectorsize: 4173 ops in 3.095614 sec = 1348 IOPS
4 kbytes: 3688 ops in 3.109559 sec = 1186 IOPS
32 kbytes: 2155 ops in 3.190242 sec = 675 IOPS
128 kbytes: 797 ops in 3.574948 sec = 223 IOPS
1024 kbytes: 218 ops in 7.172139 sec = 30 IOPS

5. 2 up usb ports are giving power, on radxa page they say that one of those is OTG, but the other should be normal host port (I've did change in DTS for that), but it's not working. There's some error about USB:
snps_dwc3_fdt0: <Synopsys Designware DWC3> mem 0xfcc00000-0xfcffffff irq 10 on ofwbus0
snps_dwc3_fdt0: XHCI_PAGESIZE 0x00000000 (that's my debug message added, I was looking for the source of the error in sources, that's the value read from the controller, weird)
snps_dwc3_fdt0: Controller does not support 4K page size.
snps_dwc3_fdt0: Failed to init XHCI, with error 6
device_attach: snps_dwc3_fdt0 attach returned 6

6. My board don't have SPI flash, so can't that
7. Also I don't own any eMMC (those are quite expensive, dunno why)
8. Booting from NVMe works, but SD card with newest u-boot is needed (could be avoided by eMMC/SPI)
9. WiFi/BT is not working - my board have AzureWave AM-CM256SM chip with CYW43455, so this should work thourh SDIO), but FreeBSD lacks support for this.
10. I'm attaching my DTS
11. There's one error about cru:
rk3568_pmucru0: <Rockchip RK3568 PMU Clock & Reset Unit> mem 0xfdd00000-0xfdd00fff on ofwbus0
rk3568_cru0: <Rockchip RK3568 Clock & Reset Unit> mem 0xfdd20000-0xfdd20fff on ofwbus0
rk3568_cru0: cannot get parent at idx 0

Don't know if this is needed by/for something.

12. I've tried to add missing unresolved clocks, I'm left with those:
Unresolved linked clock found: clk_32k_pvtm
Unresolved linked clock found: i2s0_mclkin
Unresolved linked clock found: i2s1_mclkin
Unresolved linked clock found: gpu_pvtpll_out
Unresolved linked clock found: npu_pvtpll_out
Unresolved linked clock found: dummy
 

Attachments

played a bit with u-boot on spi flash
u-boot loads and runs but there is no easy way to load efi code from an efi partition on the spi flash
not quite a big deal as you still need to have another device with the kernel so you can have efi on that device
 
covacat said:
played a bit with u-boot on spi flash
u-boot loads and runs but there is no easy way to load efi code from an efi partition on the spi flash
not quite a big deal as you still need to have another device with the kernel so you can have efi on that device
Click to expand...
All the same, having u-boot on SPI flash is very convenient.
I've been using this for a long time on several boards on the RK3399.
This allows you to use different devices to run the OS.
EDIT:
To launch the secondary bootloader from, you can use different devices with an efi partition.
Such devices can be SD/eMMC/USB/NVMe.
EDIT:

It is important that the U-boot code contains the drivers for these devices.
Here is an example FreeBSD port for building u-boot for Radxa Rock 4

https://github.com/S199pWa1k9r/ports/blob/master/sysutils/u-boot-rock-pi-4-2020.07
He also builds u-boot for spi flash.

The disadvantage is that it is difficult to change the order of selecting devices from which the secondary bootloader and OS will be launched.
This can only be done by a qualified user.

Tianocore EDK2 UEFI is free from these shortcomings.
There you freely select the device to start the OS.
 
Last edited:
i wonder what happens if i dd the boot the efi boot loader to a raw partition and load it to an address an run it
you can load random data from the spi/mtd to memory so it might work
 
That is the first I have heard of that. So you have u-boot and EFI on SPI formatted as fat32. GPT or MBR?
Regular U-Boot files (u-boot.itb, idbloader.img) or something different for SPI?
SleepWalker said:
also builds u-boot for spi flash.
Click to expand...

I bought some 128Mbit modules so the full u-boot will fit.
 
Szczepan said:
3. NVMe works. My drive is kind of cheap, but
Transfer rates:
outside: 102400 kbytes in 0.496869 sec = 206091 kbytes/sec
middle: 102400 kbytes in 0.349048 sec = 293369 kbytes/sec
inside: 102400 kbytes in 0.347641 sec = 294557 kbytes/sec
Click to expand...
I suggest you check dmesg and make sure it is running at Gen2 PCIe.
Here is mine RockPi4B with overlay applied. Gen2 PCIe. It defaulted to Gen1

Code: 
nda0 at nvme0 bus 0 scbus0 target 0 lun 1
nda0: <MTFDHBA256TCK-1AS1AABHA HPS0V23 UHPVN0153EQ7K5>
Trying to mount root from ufs:/dev/nda0p2 [rw]...
nda0: Serial Number UHPVN0153EQ7K5
nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen2 (max Gen3) link
nda0: 244198MB (500118192 512 byte sectors)

diskinfo -t abridged.
Code: 
Transfer rates:
    outside:       102400 kbytes in   0.250837 sec =   408233 kbytes/sec
    middle:        102400 kbytes in   0.170032 sec =   602240 kbytes/sec
    inside:        102400 kbytes in   0.231137 sec =   443027 kbytes/sec
 
when you build u-boot it creates u-boot-rockchip-spi.bin which you can dd directly to the spi flash
this will obviously overwrite any partititon table that you had on the flash but you can skip the first 32k if you need to keep and existing partition table
the first 32k of that file are filled with 0xff

the ondisk offset between idbloader.img and u-boot.itb seem to be different (set at compile time) for spi and sd card
the default offset for u-boot.itb for sd cards is 16M which will obviously wont work on a 16M flash (like i have)

the problem is there is no way or no way that i know of for u-boot to read fat file systems from spi/mtd devices so if you have an efi partition on spi
uboot just does not care
so you cant use the u-boot load command to load something from the flash
however you can use mtd read to read random blocks from the mtd (flash)
so if you know where bootaa64.efi is on your flash you can load it (assuming it is a contiguous strech of blocks)
so i created a "linux-data" partition on the flash and then just dd bootaa64.efi to it (without any fs whatsover)
and then from u-boot prompt
mtd read raw0 $kernel_addr
bootefi $kernel_addr:100000 (100000 stand for the binary length / does not work without it)
also ihave this in u-boot defconfig

Code: 
CONFIG_CMD_MTD=y
CONFIG_MTD=y
CONFIG_SPI_FLASH_MTD=y
CONFIG_SPL_MTD_SUPPORT=y
CONFIG_DM_MTD=y
CONFIG_CMD_MTDPARTS=y
CONFIG_MTDPARTS_DEFAULT="mtdparts=nor0:32k(filler),3m(u-boot),4m(efi),2m(raw0)"
looks like mtd partitions can be defined at u-boot runtime with mtdparts or specified somehow in the dtb so you don't really have to define them at compile time
i think it may work without all the MTD_ crap added to defconfig and just use u-boot sf command to read the efi loader into memory
you just need to "sf probe" before you do anything with the flash via "sf". mtd's are autoconfigure
however it will read partitions from the flash partition table they do not have to be defined like the mtd ones
 
You must log in or register to reply here.
Back
Top