Rockchip RK3399 update

Tue Aug 28 11:50:55 UTC 2018

Hi,

I've been trying to bring up various devices on the RK3399 SoC, here's 
a little update.

The WIP stuff is at https://github.com/myfreeweb/freebsd/commits/master
The review for the basic support is at 
https://reviews.freebsd.org/D16732

# CRU (clocks)

A problem: the xin32k clock is described as a fixed clock in the 
rockchip 4.4 device tree — in the *board* tree, so much later than 
the Clock & Reset Unit. In the mainline version, it's an output of the 
RK808 PMIC (o_0).

Either way, mentioning it as a parent of some clock in the CRU driver 
results in it not being found, which is a panic.

# cpufreq / voltage regulators

Currently works with a hack that makes voltage controllers optional —
Somehow the big cores clock to 2.18ghz without changing voltage from 
stock (which is apparently 1.0V).

My driver for the big cores' voltage controller is registering the 
regulators, but cpufreq_dt isn't finding them for some reason o_0

fanpwr0: <Silergy SYR827 Voltage Regulator> at addr 0x80 on iicbus0
fanpwr0: regulator name: vdd_cpu_b
fanpwr0: attached regulator
fanpwr1: <Silergy SYR828 Voltage Regulator> at addr 0x82 on iicbus0
fanpwr1: regulator name: vdd_gpu
fanpwr1: attached regulator
[…]
cpufreq_dt4: <Generic cpufreq driver> on cpu4
cpufreq_dt4: WARN no regulator for cpu at 100
[…]
fanpwr0: 1.00 V / f4240 uv
fanpwr1: 1.00 V / f4240 uv

# if_dwc (Ethernet)

Getting up to 510Mbit/s performance. Not bad, but are we missing 
anything to make it go even faster, actually closer to gigabit?

(The 90Mbit/s figure mentioned in the review was because of a bad cable 
connection haha)

# xhci (USB 3.0)

After changing xhci_mv to be a generic xhci_fdt driver (& adding 
Synopsys DesignWare init code from OpenBSD) and writing a Rockchip glue 
driver, it talks to the controller.

The USB ports don't get power though. We need PHY drivers maybe? 
OpenBSD gets away with no Rockchip PHY drivers, somehow it works for 
them?

dwc3_rk0: <Rockchip DWC3 USB 3.0 Controller> on ofwbus0
dwc3_rk0: enabling clock clk_usb3otg0_ref
dwc3_rk0: enabling clock clk_usb3otg0_suspend
dwc3_rk0: enabling clock aclk_usb3otg0
dwc3_rk0: enabling clock aclk_usb3_grf
dwc3_rk0: deasserting reset
xhci0: <Synopsys DesignWare USB 3.0 controller> mem 
0xfe800000-0xfe8fffff irq 79 on dwc3_rk0
xhci0: 64 bytes context size, 32-bit DMA
usbus2 on xhci0
xhci0: usbpf: Attached
dwc3_rk1: <Rockchip DWC3 USB 3.0 Controller> on ofwbus0
dwc3_rk1: enabling clock clk_usb3otg1_ref
dwc3_rk1: enabling clock clk_usb3otg1_suspend
dwc3_rk1: enabling clock aclk_usb3otg1
dwc3_rk1: enabling clock aclk_usb3_grf
dwc3_rk1: deasserting reset
xhci1: <Synopsys DesignWare USB 3.0 controller> mem 
0xfe900000-0xfe9fffff irq 80 on dwc3_rk1
xhci1: 64 bytes context size, 32-bit DMA
usbus3 on xhci1
xhci1: usbpf: Attached

# ochi (USB 1.0)

Ports aren't powered too, and we're getting this:

ohci_interrupt: unrecoverable error, controller halted
ohci_interrupt: blocking intrs 0x10
ohci_interrupt: unrecoverable error, controller halted
ohci_interrupt: blocking intrs 0x10

# dwmmc (SD card slot)

After modifying dwmmc_rockchip to include 'rockchip,rk3399-dw-mshc', it 
talks to the controller.

The system hangs when a card is inserted though:

rockchip_dwmmc0: <Synopsys DesignWare Mobile Storage Host Controller 
(RockChip)> mem 0xfe320000-0xfe323fff irq 8 on ofwbus0
rockchip_dwmmc0: num-slots property is deprecated
rockchip_dwmmc0: Hardware version ID is 270a
[…]
mmc0: <MMC/SD bus> on rockchip_dwmmc0
mmc0: Probing bus
mmc0: SD 2.0 interface conditions: OK
mmc0: SD probe: OK (OCR: 0x00ff8000)
mmc0: Current OCR: 0x00ff8000
mmc0: Probing cards
mmc0: New card detected (CID 2750485[…])
mmc0: New card detected (CSD 400e003[…])
[freeze here]

# sdhci (eMMC module slot)

After modifying sdhci_fdt to include 'arasan,sdhci-5.1', it talks to 
the controller.

I don't have an eMMC module, so can't test operation. (idk why it says 
"card inserted" lol… ghost card)

OpenBSD driver mentions some interesting quirks:
https://github.com/openbsd/src/blob/d6d23d791f9c7b791834c6f85905dc7b93dc64e6/sys/dev/fdt/sdhc_fdt.c#L99-L115

sdhci_fdt0: <Arasan generic fdt SDHCI controller> mem 
0xfe330000-0xfe33ffff irq 9 on ofwbus0
sdhci_fdt0: Hardware doesn't specify timeout clock frequency, setting 
BROKEN_TIMEOUT quirk.
sdhci_fdt0-slot0: 200MHz HS 8bits VDD: 1.8V VCCQ: 3.3V DRV: BACD DMA 
embedded
sdhci_fdt0-slot0: ============== REGISTER DUMP ==============
sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version:  0x00001002
sdhci_fdt0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci_fdt0-slot0: Present:  0x1fff0000 | Host ctl: 0x00000000
sdhci_fdt0-slot0: Power:    0x0000000b | Blk gap:  0x00000080
sdhci_fdt0-slot0: Wake-up:  0x00000000 | Clock:    0x00002007
sdhci_fdt0-slot0: Timeout:  0x00000000 | Int stat: 0x00000000
sdhci_fdt0-slot0: Int enab: 0x027f003b | Sig enab: 0x00000000
sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_fdt0-slot0: Caps:     0x44edc880 | Caps2:    0x800020f7
sdhci_fdt0-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000
sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000
sdhci_fdt0-slot0: ===========================================
sdhci_fdt0: 1 slot(s) allocated
sdhci_fdt0-slot0: Card inserted
mmc1: <MMC/SD bus> on sdhci_fdt0

# PCIe

OpenBSD has a driver: 
https://github.com/openbsd/src/blob/master/sys/dev/fdt/rkpcie.c

Maybe I'll try porting, but I don't really know what I'm doing with all 
this stuff :D

( BTW, they also have one for the Marvell Armada 8K already too!
https://github.com/openbsd/src/blob/master/sys/dev/fdt/dwpcie.c )

# Display/GPU

I have the radeon driver building and loading on aarch64:

https://github.com/myfreeweb/kms-drm/tree/aarch64

So having a PCIe driver would allow me to actually test it :)

As for the onboard display system, adding OpenFirmware/clocks/etc. to 
LinuxKPI doesn't look super easy.
But of course not impossible either…

# Chromebooks?

There are some nice RK3399 based chromebooks available.

I guess it should be possible to build a coreboot for them with the 
TianoCore payload (or at least U-Boot).
And we might have the EFI framebuffer on that, since the coreboot 
source does have some RK3399 display stuff.

We also already have a Chrome EC (&keyboard) driver in the tree, hidden 
away in the 32-bit Samsung Exynos stuff…