From owner-freebsd-arm@freebsd.org Tue Aug 28 11:50:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 999CC10890C9 for ; Tue, 28 Aug 2018 11:50:55 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from hraggstad.unrelenting.technology (hraggstad.unrelenting.technology [71.19.146.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hraggstad.unrelenting.technology", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B05B7FEB3 for ; Tue, 28 Aug 2018 11:50:54 +0000 (UTC) (envelope-from greg@unrelenting.technology) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unrelenting.technology; h=date:from:subject:to:message-id; s=default; bh=FhSvll9wpOvvjHeC8fsSm0O+xGu4vKa4WoMutOW+Huc=; b=O9HvbqqhcBxF6XBSDIPZCphZ6prMZips70XFYkGLJsCsDRJofE9SNdAbdj3/2HHBZTMyqaG+b+palUJM+Pn7Vsnc76/FwoIDP5TgTGm1KeEGGP8Y1gmQmGAhLGdxBmSE0Z6j5otgUEQ70Po2zH6EsNupgEIpXvCU7K5kZoj2d9I= Received: by hraggstad.unrelenting.technology (OpenSMTPD) with ESMTPSA id 260a2990 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Tue, 28 Aug 2018 11:50:49 +0000 (UTC) Date: Tue, 28 Aug 2018 14:50:47 +0300 From: Greg V Subject: Rockchip RK3399 update To: freebsd-arm@freebsd.org Message-Id: <1535457047.1823.0@hraggstad.unrelenting.technology> X-Mailer: geary/0.12.2 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 11:50:55 -0000 Hi, I've been trying to bring up various devices on the RK3399 SoC, here's=20 a little update. The WIP stuff is at https://github.com/myfreeweb/freebsd/commits/master The review for the basic support is at=20 https://reviews.freebsd.org/D16732 # CRU (clocks) A problem: the xin32k clock is described as a fixed clock in the=20 rockchip 4.4 device tree =97 in the *board* tree, so much later than=20 the Clock & Reset Unit. In the mainline version, it's an output of the=20 RK808 PMIC (o_0). Either way, mentioning it as a parent of some clock in the CRU driver=20 results in it not being found, which is a panic. # cpufreq / voltage regulators Currently works with a hack that makes voltage controllers optional =97 Somehow the big cores clock to 2.18ghz without changing voltage from=20 stock (which is apparently 1.0V). My driver for the big cores' voltage controller is registering the=20 regulators, but cpufreq_dt isn't finding them for some reason o_0 fanpwr0: at addr 0x80 on iicbus0 fanpwr0: regulator name: vdd_cpu_b fanpwr0: attached regulator fanpwr1: at addr 0x82 on iicbus0 fanpwr1: regulator name: vdd_gpu fanpwr1: attached regulator [=85] cpufreq_dt4: on cpu4 cpufreq_dt4: WARN no regulator for cpu@100 [=85] 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=20 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=20 connection haha) # xhci (USB 3.0) After changing xhci_mv to be a generic xhci_fdt driver (& adding=20 Synopsys DesignWare init code from OpenBSD) and writing a Rockchip glue=20 driver, it talks to the controller. The USB ports don't get power though. We need PHY drivers maybe?=20 OpenBSD gets away with no Rockchip PHY drivers, somehow it works for=20 them? dwc3_rk0: 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: mem=20 0xfe800000-0xfe8fffff irq 79 on dwc3_rk0 xhci0: 64 bytes context size, 32-bit DMA usbus2 on xhci0 xhci0: usbpf: Attached dwc3_rk1: 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: mem=20 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=20 talks to the controller. The system hangs when a card is inserted though: rockchip_dwmmc0: mem 0xfe320000-0xfe323fff irq 8 on ofwbus0 rockchip_dwmmc0: num-slots property is deprecated rockchip_dwmmc0: Hardware version ID is 270a [=85] mmc0: 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[=85]) mmc0: New card detected (CSD 400e003[=85]) [freeze here] # sdhci (eMMC module slot) After modifying sdhci_fdt to include 'arasan,sdhci-5.1', it talks to=20 the controller. I don't have an eMMC module, so can't test operation. (idk why it says=20 "card inserted" lol=85 ghost card) OpenBSD driver mentions some interesting quirks: https://github.com/openbsd/src/blob/d6d23d791f9c7b791834c6f85905dc7b93dc64e= 6/sys/dev/fdt/sdhc_fdt.c#L99-L115 sdhci_fdt0: mem=20 0xfe330000-0xfe33ffff irq 9 on ofwbus0 sdhci_fdt0: Hardware doesn't specify timeout clock frequency, setting=20 BROKEN_TIMEOUT quirk. sdhci_fdt0-slot0: 200MHz HS 8bits VDD: 1.8V VCCQ: 3.3V DRV: BACD DMA=20 embedded sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUMP = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0: 1 slot(s) allocated sdhci_fdt0-slot0: Card inserted mmc1: on sdhci_fdt0 # PCIe OpenBSD has a driver:=20 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=20 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=20 LinuxKPI doesn't look super easy. But of course not impossible either=85 # Chromebooks? There are some nice RK3399 based chromebooks available. I guess it should be possible to build a coreboot for them with the=20 TianoCore payload (or at least U-Boot). And we might have the EFI framebuffer on that, since the coreboot=20 source does have some RK3399 display stuff. We also already have a Chrome EC (&keyboard) driver in the tree, hidden=20 away in the 32-bit Samsung Exynos stuff=85 =