Date: Tue, 28 Aug 2018 14:50:47 +0300 From: Greg V <greg@unrelenting.technology> To: freebsd-arm@freebsd.org Subject: Rockchip RK3399 update Message-ID: <1535457047.1823.0@hraggstad.unrelenting.technology>
index | next in thread | raw e-mail
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@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…help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1535457047.1823.0>