Date: Wed, 29 Aug 2018 21:46:34 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Greg V <greg@unrelenting.technology> Cc: freebsd-arm@freebsd.org Subject: Re: Rockchip RK3399 update Message-ID: <20180829214634.b894c03131ec7b2fe384ed17@bidouilliste.com> In-Reply-To: <1535457047.1823.0@hraggstad.unrelenting.technology> References: <1535457047.1823.0@hraggstad.unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Greg, On Tue, 28 Aug 2018 14:50:47 +0300 Greg V <greg@unrelenting.technology> wrote: > Hi, >=20 > I've been trying to bring up various devices on the RK3399 SoC, here's=20 > a little update. >=20 > 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 >=20 > # CRU (clocks) >=20 > A problem: the xin32k clock is described as a fixed clock in the=20 > rockchip 4.4 device tree ? 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). >=20 > 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. >=20 > # cpufreq / voltage regulators >=20 > Currently works with a hack that makes voltage controllers optional ? > Somehow the big cores clock to 2.18ghz without changing voltage from=20 > stock (which is apparently 1.0V). >=20 > 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 >=20 > 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 >=20 > # if_dwc (Ethernet) >=20 > Getting up to 510Mbit/s performance. Not bad, but are we missing=20 > anything to make it go even faster, actually closer to gigabit? >=20 > (The 90Mbit/s figure mentioned in the review was because of a bad cable=20 > connection haha) >=20 > # xhci (USB 3.0) >=20 > 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. >=20 > 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? >=20 > 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=20 > 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=20 > 0xfe900000-0xfe9fffff irq 80 on dwc3_rk1 > xhci1: 64 bytes context size, 32-bit DMA > usbus3 on xhci1 > xhci1: usbpf: Attached >=20 > # ochi (USB 1.0) >=20 > Ports aren't powered too, and we're getting this: >=20 > ohci_interrupt: unrecoverable error, controller halted > ohci_interrupt: blocking intrs 0x10 > ohci_interrupt: unrecoverable error, controller halted > ohci_interrupt: blocking intrs 0x10 >=20 > # dwmmc (SD card slot) >=20 > After modifying dwmmc_rockchip to include 'rockchip,rk3399-dw-mshc', it=20 > talks to the controller. >=20 > The system hangs when a card is inserted though: >=20 > rockchip_dwmmc0: <Synopsys DesignWare Mobile Storage Host Controller=20 > (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] >=20 > # sdhci (eMMC module slot) >=20 > After modifying sdhci_fdt to include 'arasan,sdhci-5.1', it talks to=20 > the controller. >=20 > I don't have an eMMC module, so can't test operation. (idk why it says=20 > "card inserted" lol? ghost card) >=20 > OpenBSD driver mentions some interesting quirks: > https://github.com/openbsd/src/blob/d6d23d791f9c7b791834c6f85905dc7b93dc6= 4e6/sys/dev/fdt/sdhc_fdt.c#L99-L115 >=20 > sdhci_fdt0: <Arasan generic fdt SDHCI controller> 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 DUM= P =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: <MMC/SD bus> on sdhci_fdt0 >=20 > # PCIe >=20 > OpenBSD has a driver:=20 > https://github.com/openbsd/src/blob/master/sys/dev/fdt/rkpcie.c >=20 > Maybe I'll try porting, but I don't really know what I'm doing with all=20 > this stuff :D >=20 > ( BTW, they also have one for the Marvell Armada 8K already too! > https://github.com/openbsd/src/blob/master/sys/dev/fdt/dwpcie.c ) >=20 > # Display/GPU >=20 > I have the radeon driver building and loading on aarch64: >=20 > https://github.com/myfreeweb/kms-drm/tree/aarch64 >=20 > So having a PCIe driver would allow me to actually test it :) >=20 > As for the onboard display system, adding OpenFirmware/clocks/etc. to=20 > LinuxKPI doesn't look super easy. > But of course not impossible either? >=20 > # Chromebooks? >=20 > There are some nice RK3399 based chromebooks available. >=20 > 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. >=20 > We also already have a Chrome EC (&keyboard) driver in the tree, hidden=20 > away in the 32-bit Samsung Exynos stuff? >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Sorry, I don't have time to review all this for now, I'll try to look at it soon. Keep up the good work !! --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180829214634.b894c03131ec7b2fe384ed17>