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

Raxda Toybrick V1.31 Rock3A 2G Purchased Oct/2022 from China.
Raxda Logo and Toybrick silkscreened in Black
 

Attachments

  • Toybrick1.JPG
    Toybrick1.JPG
    1.6 MB · Views: 100
  • Toybrick2.JPG
    Toybrick2.JPG
    2 MB · Views: 99
Raxda Rock3A 2G No Branding on board (bought from Okdo 6/2023).
Raxda Logo No Version Silkscreened in White 'Rock3A' in same area of board.
 

Attachments

  • okd0.JPG
    okd0.JPG
    927.5 KB · Views: 84
  • okd02.JPG
    okd02.JPG
    1.7 MB · Views: 85
Notice the above pictures of the bottom side. The Toybrick board is missing a chip under the USB port.
 

Attachments

  • pair.JPG
    pair.JPG
    1.9 MB · Views: 82
What I don't understand is what is Toybrick.

About Toybrick - Toybrick EN

About Toybrick ,Toybrick EN
t.rock-chips.com
This seems to indicate they are an integrator for RockChip.

So Raxda is the designer?
Who is Okdo? They seem affiliated with Raxda. Maybe distribution arm?
www.okdo.com

About us

WE ARE OKDO We are ordinary people, serving an extraordinary cause; creating assets and hubs where innovators learn and build cutting-edge solutions that
www.okdo.com www.okdo.com
They have separate stores for US/UK and all US orders ship from UK.
Strange arrangement. They had my boards in hand in 3 days for $20 shipping.
I have to manually adjust URL to get to US store. Maybe because my geo-location info is off.

I just ordered more Rock3A. I need a platform to build things on with a reliable supply.
The NVMe kit Okdo sold me was missing cable. 10 bucks I ain't complaining. They are 25 bucks on ebay.
I got the POE hat to try out.
I want to power the board with outside supply. USB3 power is not convenient for me.
 
Phishfry said:
Notice the above pictures of the bottom side. The Toybrick board is missing a chip under the USB port.
Click to expand...
Toybrick board is missing chip under USB-C connector, but has (bigger) chip near mounting hole.
Okdo board has chip under USB-C connector, but is missing one near mounting hole.
They are probably PMIC chips.
There were some blog/news post about it but I cant find it now
 
easiest way is to
pull arm trusted firmware from github and build for the platform
you can get prebuilt ATF binaries from rockchip
pull u-boot from github,
edit the board's defconfig and append
CONFIG_EFI_LOADER=y
make yourBoard_defconfig
BL31=/path/to/armtrustedfw/soc/bl31.bin make CROSS_COMPILE=aarch64-linux-gnu-
follow board instructions on how to dd results to disk
depending on the u-boot disk offset you can use a prebuilt arm64 usb stick image
u-boot data should fit between first gpt end and first partition start
for convenience i did it on a linux box but it should be the same on freebsd
just use gmake instead of make and CROSS_COMPILE=aarch64-none-elf-

so you can follow board's instruction for linux just build u-boot with efi support
 
Phishfry said:
I agree but as SleepWalker mentioned in another post, there is no support for PCIe on RK356x with u-boot currently.
With EDK2 BIOS PCIe and NVMe work..

OrangePi 5 uses RK3588 and I don't think that is in the official u-boot yet is it?
Click to expand...
Yes, I also realized that it is not in the main line. Sad...:'‑(
 
EDK2 Tianocore UEFI is currently available for rk3588 - WIP.
github.com

GitHub - edk2-porting/edk2-rk3588: EDK2 UEFI firmware for Rockchip RK3588 platforms

EDK2 UEFI firmware for Rockchip RK3588 platforms. Contribute to edk2-porting/edk2-rk3588 development by creating an account on GitHub.
github.com github.com

HDMI, USB, PCIe work.
gmac v4.2 coming soon.
Only ACPI mode works
With this UEFI you can even run FreeBSD 13.2 on RK3588.
For 2.5 Gbps Ethernet RTL8125 to work, you need to use the net/realtek-re-kmod port.

In fact we will soon have FreeBSD on
Radxa-ROCK-5/A/B
FriendlyElec - NanoPi R6S/R6C, NanoPC-T6
OrangePi-5/5B/5Plus

To test FDT mode,
just put the DTB file in the /boot/dtb directory and SPECIFY THE PATH TO IT
in the /boot/loader.conf file

#
# Hack to get loader to find dtb.
#
dtbfile_load="YES"
dtbfile_type="dtb"
dtbfile_name="rk3588.dtb"
 
SleepWalker said:
EDK2 Tianocore UEFI is currently available for rk3588 - WIP.
github.com

GitHub - edk2-porting/edk2-rk3588: EDK2 UEFI firmware for Rockchip RK3588 platforms

EDK2 UEFI firmware for Rockchip RK3588 platforms. Contribute to edk2-porting/edk2-rk3588 development by creating an account on GitHub.
github.com github.com

HDMI, USB, PCIe work.
gmac v4.2 coming soon.
Only ACPI mode works
With this UEFI you can even run FreeBSD 13.2 on RK3588.
For 2.5 Gbps Ethernet RTL8125 to work, you need to use the net/realtek-re-kmod port.

In fact we will soon have FreeBSD on
Radxa-ROCK-5/A/B
FriendlyElec - NanoPi R6S/R6C, NanoPC-T6
OrangePi-5/5B/5Plus

To test FDT mode,
just put the DTB file in the /boot/dtb directory and SPECIFY THE PATH TO IT
in the /boot/loader.conf file

#
# Hack to get loader to find dtb.
#
dtbfile_load="YES"
dtbfile_type="dtb"
dtbfile_name="rk3588.dtb"
Click to expand...

Hi SleepWalker!

Thanks very much for your efforts so far on the FreeBSD Radxa board support and for your previous help with the Rock-Pi-E FreeBSD image!

I have a Rock-5b and managed to get your FreeBSD-aarch64-14.0-RELEASE-Rock-5B-20231209.img.xz image booting ok and then followed your YT video on how you setup the RAID stripe - very, very cool!

From that, I have a 32GB eMMC mounted on the Rock5b and tried bsdinstall (as per your YT) but it couldn't find the eMMC ... I then used the USB 3.0 eMMC Reader and then bsdinstall found it!

I know the setup is for a RAID however, I tried bsdinstall using the USB-eMMC and it seemed to be able to install and I managed to get it to boot but placing the eMMC back onto the back of the Rock5b and then switching to the eMMC device (boot1 and boot2 did not do anything but, User Data got it going!) via the EFI boot manager menu on the Rock5b.

It got as far as trying to mount zfs:zroot/ROOT/default but stopped with Error 5 - cannot find pool etc... I tried specifying zfs:zroot/ROOT/default manually but still didn't work ... typing '?' at the prompt show no boot devices.

I rebooted again from your img and as far as I could tell, FreeBSD could not detect the eMMC - I wanted to mount it to check the /boot/loader.conf and see if there was anything I could do in there to get past this problem... I am fairly new to FreeBSD and tried to find if there was a ko that I could kldload to probe the eMMC but no found anything yet and don't even know if that's possible ...

I was just wondering you could please let us know if there may be a way to use bsdinstall on Rock5b to install directly onto the eMMC and boot from there or if there may be something else that I could try to get the eMMC booting and mounting zfs:zroot correctly?

Thanks very much!
Cheers,
Rodney
 
Hi Rodney872 !

I am very pleased that there is interest in my efforts
to increase the popularity of FreeBSD on the aarch64 platform.

I really want to simplify the process of installing FreeBSD on new boards, available to users.

Now I will try to explain, why eMMC does not work.

And yes, the bad news, is that it cannot work, until new drivers for the RK3588 are written.

You can see eMMC devices and even SD card in bootloader,
but these devices are visible because they are supported in Tianocore EDK2 UEFI.
And they are in loader.efi.

Currently FreeBSD does not have any drivers specifically for the RK3588 SoC
and there is no support for clock drivers for this SoC.

Therefore,
We can run FreeBSD on Rock-5A/B (RK3588s/88)
only in ACPI mode using Tianocore EDK2 UEFI as the primary bootloader.
And use generic drivers, in our case some will work.
What will work (and you can see it yourself) is USB 3.0, PCIe.
Therefore, devices connected via these buses will work.

They work because their descriptions in ACPI tables are similar to those for AMD64 or other AARCH64 SoCs.
There are generic drivers for them. For eMMC/SPI flash/SD card there is a description in the ACPI tables,
but they are specific to the RK3588 SoC, and it is necessary to write interlayer drivers.
My image has such a driver for USB 2.0, and therefore devices connected to the black USB port work.

The good news is that devices on the PCIe bus, RTL8125 Ethernet, M.2 NVMe, and M.2 WiFi card will work.

Enjoy FreeBSD on RK3588, it's really cool.
 
Hi SleepWalker!

Thanks very much for you reply! I am very grateful!

Thanks for your help on this - hopefully the eMMC drivers will get written soon for the RK3588 (I am a developer so, I really should be look into seeing if I can help the community with getting that done...I'll try look at the kernel repo and go from there...) ...?

I will look to see if I can use PCIe or NVMe for non-volatile (mass) storage for the time being. I have been happily purchasing my Rock-pi-E, Rock-5b and also, Rock-4C+ boards from https://shop.allnetchina.cn/ along with the eMMC modules for those boards and the USB-3.0 eMMC reader - I will see what other storage boards they have for SATA and NVMe ...

I am very keen to be working on getting FreeBSD working on these Radxa boards and I managed to get your FreeBSD-aarch64-13.1-RELEASE-Rock-Pi-E-20220524.img.xz image up and running on my Rock-Pi-E, yesterday (Thank-you!) :-

1703990200069.png


My main focus at the moment is on the rk3328 (Rock-pi-E) but I would like to ultimately use the rk3588 (Rock5b) as a build/development server and I am now getting the Rock-pi-E setup for kernel module development (currently downloading /usr/src as we speak!) as I have a hardware project that I am working on that uses i2c, SPI, serial and GPIO pins that connects to the Rock-pi-e 40-pin header (PoC already done and working on Armbian, now I am porting it to FreeBSD).

I am next going to try and learn how to make an img for Rock-pi-E ... the "traditional" method of using "release.sh" takes many hours to build so, I will try to learn 'crochet' and see if I can build a 13.1-RELEASE img using that ...

I much prefer the Rockchip processors over other (embedded) arm64's and I would like to contribute where I can to the FreeBSD project/s for the Radxa boards and any other boards that are using Rockchip cpus.

Thanks again, SleepWalker!
Cheers,
Rodney
 
Rodney872 said:
Hi SleepWalker!

Thanks very much for you reply! I am very grateful!

Thanks for your help on this - hopefully the eMMC drivers will get written soon for the RK3588 (I am a developer so, I really should be look into seeing if I can help the community with getting that done...I'll try look at the kernel repo and go from there...) ...?

I will look to see if I can use PCIe or NVMe for non-volatile (mass) storage for the time being. I have been happily purchasing my Rock-pi-E, Rock-5b and also, Rock-4C+ boards from https://shop.allnetchina.cn/ along with the eMMC modules for those boards and the USB-3.0 eMMC reader - I will see what other storage boards they have for SATA and NVMe ...

I am very keen to be working on getting FreeBSD working on these Radxa boards and I managed to get your FreeBSD-aarch64-13.1-RELEASE-Rock-Pi-E-20220524.img.xz image up and running on my Rock-Pi-E, yesterday (Thank-you!) :-

View attachment 17787

My main focus at the moment is on the rk3328 (Rock-pi-E) but I would like to ultimately use the rk3588 (Rock5b) as a build/development server and I am now getting the Rock-pi-E setup for kernel module development (currently downloading /usr/src as we speak!) as I have a hardware project that I am working on that uses i2c, SPI, serial and GPIO pins that connects to the Rock-pi-e 40-pin header (PoC already done and working on Armbian, now I am porting it to FreeBSD).

I am next going to try and learn how to make an img for Rock-pi-E ... the "traditional" method of using "release.sh" takes many hours to build so, I will try to learn 'crochet' and see if I can build a 13.1-RELEASE img using that ...

I much prefer the Rockchip processors over other (embedded) arm64's and I would like to contribute where I can to the FreeBSD project/s for the Radxa boards and any other boards that are using Rockchip cpus.

Thanks again, SleepWalker!
Cheers,
Rodney
Click to expand...

Update: I managed to get a 14.0-RELEASE img built using crochet (SleepWalker's version) but so far, it only works with SleepWalker's u-boot-rock-pi-e-2020.07 - the latest u-boot 2023.10 boots but has problems with the Ethernet and FreeBSD eventually kernel-panics saying:

U-Boot 2023.10 (Dec 29 2023 - 13:57:01 +1000)

Model: Radxa ROCK Pi E
DRAM: 1 GiB (effective 1022 MiB)
PMIC: RK8050 (on=0x40, off=0x01)
Core: 239 devices, 25 uclasses, devicetree: separate
MMC: mmc@ff500000: 1, mmc@ff520000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In: serial@ff130000
Out: serial@ff130000
Err: serial@ff130000
Model: Radxa ROCK Pi E
Net: Could not get PHY for ethernet@ff540000: addr -1
No ethernet found.

Hit any key to stop autoboot: 0
.
. <SNIP>
.
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
Using DTB from loaded file '/boot/dtb/rk3328-rock-pi-e.dtb'.
.
.
. <SNIP>
.
dwc0: <Rockchip Gigabit Ethernet Controller> mem 0xff540000-0xff54ffff irq 44 on ofwbus0
dwc0: Can't reset DWC.
device_attach: dwc0 attach returned 6
dwc0: <Rockchip Gigabit Ethernet Controller> mem 0xff550000-0xff55ffff irq 45 on ofwbus0
Fatal data abort:
x0: 0
x1: ffff00000084c927 (digits + c26d)
x2: 0
x3: 6
x4: ffff000000ea171c (initstack + 371c)
x5: ffff000000ea16cc (initstack + 36cc)
x6: 13000000
x7: 13000000
x8: 0
x9: 6e
x10: ffff0000012d94a8 (_end + 4374a8)
x11: fefefefefefefeff
x12: 8
x13: 0
x14: 1d
x15: 0
x16: 0
x17: 0
x18: ffff000000ea1770 (initstack + 3770)
x19: ffffa00000cf4000
x20: ffff000089d97000 (_end + 88ef5000)
x21: 4b50
x22: 0
x23: 80040001
x24: ffff0000009b4f00 (ofw_bus_get_node_desc + 0)
x25: ffff0000008122d1 (cam_status_table + 1d3c9)
x26: ffff000000864ab1 (console_pausestr + a124)
x27: ffffa00000d5b3e0
x28: ffff000089da3130 (_end + 88f01130)
x29: ffff000000ea1770 (initstack + 3770)
sp: ffff000000ea1770
lr: ffff0000007e2588 (if_dwc_rk_init + 17c)
elr: ffff000000522ed4 (strcmp + 8)
spsr: 600000c5
far: 0
esr: 96000004
panic: vm_fault failed: ffff000000522ed4
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x30
pc = 0xffff00000079edcc lr = 0xffff000000109830
sp = 0xffff000000ea11c0 fp = 0xffff000000ea13c0

db_trace_self_wrapper() at vpanic+0x174
pc = 0xffff000000109830 lr = 0xffff000000407dfc
sp = 0xffff000000ea13d0 fp = 0xffff000000ea1430

vpanic() at panic+0x44
pc = 0xffff000000407dfc lr = 0xffff000000407c84
sp = 0xffff000000ea1440 fp = 0xffff000000ea14f0

panic() at data_abort+0x244
pc = 0xffff000000407c84 lr = 0xffff0000007c1580
sp = 0xffff000000ea1500 fp = 0xffff000000ea1580

data_abort() at handle_el1h_sync+0x10
pc = 0xffff0000007c1580 lr = 0xffff0000007a1810
sp = 0xffff000000ea1590 fp = 0xffff000000ea16e0

handle_el1h_sync() at if_dwc_rk_init+0x178
pc = 0xffff0000007a1810 lr = 0xffff0000007e2584
sp = 0xffff000000ea16f0 fp = 0xffff000000ea1770

if_dwc_rk_init() at if_dwc_rk_init+0x178
pc = 0xffff0000007e2584 lr = 0xffff0000007e2584
sp = 0xffff000000ea1780 fp = 0xffff000000ea17d0

if_dwc_rk_init() at dwc_attach+0x260
pc = 0xffff0000007e2584 lr = 0xffff0000007c9db0
sp = 0xffff000000ea17e0 fp = 0xffff000000ea1870

dwc_attach() at device_attach+0x3fc
pc = 0xffff0000007c9db0 lr = 0xffff000000448a68
sp = 0xffff000000ea1880 fp = 0xffff000000ea18f0

device_attach() at bus_generic_new_pass+0x120
pc = 0xffff000000448a68 lr = 0xffff00000044ab54
sp = 0xffff000000ea1900 fp = 0xffff000000ea1950

bus_generic_new_pass() at bus_generic_new_pass+0xb0
pc = 0xffff00000044ab54 lr = 0xffff00000044aae4
sp = 0xffff000000ea1960 fp = 0xffff000000ea1990

bus_generic_new_pass() at bus_generic_new_pass+0xb0
pc = 0xffff00000044aae4 lr = 0xffff00000044aae4
sp = 0xffff000000ea19a0 fp = 0xffff000000ea19d0

bus_generic_new_pass() at root_bus_configure+0x40
pc = 0xffff00000044aae4 lr = 0xffff00000044cc34
sp = 0xffff000000ea19e0 fp = 0xffff000000ea1a10

root_bus_configure() at mi_startup+0x11c
pc = 0xffff00000044cc34 lr = 0xffff00000037d664
sp = 0xffff000000ea1a20 fp = 0xffff000000ea1a50

mi_startup() at virtdone+0x6c
pc = 0xffff00000037d664 lr = 0xffff0000000008a8
sp = 0xffff000000ea1a60 fp = 0x0000000000000000

KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at kdb_enter+0x44: undefined f905811f
db>

I suspect it will probably come down to configuration so I'll try and see what I can find by doing a diff on SleepWalker's u-boot-rock-pi-e-2020.07 and u-boot-2023.10 and try figure it out that way...

Cheers,
Rodney
 
I'm also trying to get FreeBSD working on a RK35xx board, the Orange Pi 3B. Which uses RK3566, I pretty new to this, so I must confess I'm a little bit lost. I'd like to build an image that wouldn't require users to flash a new bootloader, so I'm trying to get this working with the onboard U-Boot bootloader. I've chose this board because it's a very cheap one and I could by from local resellers, I can in fact easily afford more expensive boards, but I wanted to have more people involved on this without the price barrier.

I'll try to register my progress on this thread. My goal is to have pfSense + WiFi working on this board, so this will probably be very difficult, but it should be very fun as well.
 
you don't need to flash a new boot loader to the spi flash, you can have u-boot on the sdcard (or emmc)
forget about the integrated wifi (unisoc chip on mmc controller)
 
you don't need to flash a new boot loader to the spi flash, you can have u-boot on the sdcard (or emmc)
Click to expand...
I definitely will, I'm trying to understand different boot modes for uboot.

forget about the integrated wifi (unisoc chip on mmc controller)
Click to expand...
Not a problem for now, I'll try to make a driver on my own, tho that's probably too naive of me. But time is not a problem and it'll be fun to try even it I fail miserably.
 
After followed some of these steps I could get to the boot loader of the ROCK64 image, I couldn't boot the kernel tho. After I realized it couldn't detected the SD card, I noticed it was detecting only the SPI flash, so I changed the mmc0 alias from the SPI flash to the SD card and it worked.

Doing this basically. I also copied the orange pi 3b dtb into the boot partition.

fdt chosen fdt set /aliases mmc0 "/sdhci@fe310000" load mmc 0 ${fdt_addr_r} dtb/orangepi-3b-rk3566.dtb load mmc 0 ${kernel_addr_r} efi/boot/bootaa64.efi bootefi ${kernel_addr_r} ${fdt_addr_r}

But the boot crashed after trying to relocate the kernel to a absolutely weird address, I tried skipping relocation by skipping this step and it worked. The kernel boots, but it panics with an error related to setting up clock.

I'll add more details later. But I believe it's some problem related to dtb not being correctly loaded, or not even the correct dtb being loaded.
 
You must log in or register to reply here.
Back
Top