On Wed, Jun 03, 2020 at 04:27:00PM +0100, Steve wrote:
> A pair of us have been using OpenBSB as our firewall for about 10
> years now, but the hardware is getting old and we want to replace
> it with a smaller / lower power device. With the new Arm boards out
> now we have been attempting to make a new version using the Nano Pi
> R2S from FriendlyElec which appears to be perfect, but we are not
> experienced in getting Arm SBC's working with OpenBSD.
>
> The R2S is an RK3328 based dual ethernet SBC and we have taken the
> rk3328-roc-cc.dts (Firefly board) as a base to modify, and compiled
> u-boot, with bl31 to get OpenBSD installed and running, as well as
> comparing the similar schematics.
>
> After OpenBSD boots, one of the ethernet ports which we believe to
> be connected directly to the RockChip is detected, giving a dwge0
> device, but the second ethernet port is not detected at all.
>
> From looking at the schematic diagram we think that the RTL8153 IC
> is connected via USB3.0 interface and we are not getting any USB3.0
> show up in the dmesg log.
>
> If were configured correctly, we think that we would expect to see a
> ure0 device. So this configuration needs to be added to the device
> tree.
>
> There is a working linux Armbian image which when checked allows
> access to both LAN ports. Converting their dtb->dts, there is a
> section for usb at 0xff6000000, which matches the RK3328 data sheet
> memory map for the USB3 register set.
>
> This, and the subsection dwc3, which we believe uses the phy's
> referenced as utmi and pipe, have many sections, such as the clocks,
> resets (and interrupts?) for which we can find no relevant information.
>
> Also of note is that on the schematic for the board, the pin GPIO2_C6
> seems to be required to be high to enable power to the USB subsystem,
> as VDD_5V_LAN powers the IO of the RTL8153 device.
>
> Further, the WAN-LED / LAN-LED from pins GPIO2_C2 / GPIO2_B7 remain
> off and unconfigured from the boot output even when we have attempted
> to direct them to be on.
>
> What are we are doing wrong in order to develop the dts to a working
> state? Any pointers to information on how to proceed and verify our
> progress would be appreciated. Especially, how do we set IO lines
> high so that we may power the USB3.0 subsystem and RTL8153 ?
>
>
> The defconfig is again based on the roc-cc one and contains:
>
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_EHCI_GENERIC=y
> CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_OHCI_GENERIC=y
> CONFIG_USB_DWC2=y
> CONFIG_USB_DWC3=y
> # CONFIG_USB_DWC3_GADGET is not set
> CONFIG_USB_GADGET=y
> CONFIG_USB_GADGET_DWC2_OTG=y
>
> Also, relevant sections of our dts file are shown below.
>
> Many thanks.
>
> syscon: syscon@ff460000 {
> compatible = "rockchip,usb3phy-grf", "syscon";
> reg = <0x0 0xff460000 0x0 0x1000>;
> };
>
> u3phy: u3phy@ff470000 {
> compatible = "rockchip,rk3328-u3phy";
> reg = <0x0 0xff470000 0x0 0x0>;
> rockchip,u3phygrf = <&syscon>;
> rockchip,grf = <&grf>;
> interrupts = <0x0 0x4d 0x4>;
> interrupt-names = "linestate";
> clocks = <0x2 0xe0 0x2 0xe1>;
> clock-names = "u3phy-otg", "u3phy-pipe";
> resets = <0x2 0x7d 0x2 0x7e 0x2 0x7f 0x2 0x7c 0x2 0x9e 0x2 0x9f>;
> reset-names = "u3phy-u2-por", "u3phy-u3-por", "u3phy-pipe-mac",
> "u3phy-utmi-mac", "u3phy-utmi-apb", "u3phy-pipe-apb";
> #address-cells = <0x2>;
> #size-cells = <0x2>;
> ranges;
> status = "okay";
>
> utmi: utmi@ff470000 {
> reg = <0x0 0xff470000 0x0 0x8000>;
> #phy-cells = <0x0>;
> status = "okay";
> };
>
> pipe: pipe@ff478000 {
> reg = <0x0 0xff478000 0x0 0x8000>;
> #phy-cells = <0x0>;
> status = "okay";
> };
> };
>
> usb30: usb@ff600000 {
> compatible = "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3";
> clocks = <0x2 0x60 0x2 0x84 0x2 0x61>; // Should contain &u3phy?
> // Are some phandles?
> clock-names = "ref", "bus_early", "suspend";
> #address-cells = <0x2>;
> #size-cells = <0x2>;
> ranges;
> clock-ranges;
> status = "okay";
> phy-supply = <&vcc_usb30>;
>
> dwc3@ff600000 {
> compatible = "snps,dwc3";
> reg = <0x0 0xff600000 0x0 0x100000>;
> interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; // OK?
> dr_mode = "host";
> phys = <&utmi &pipe>;
> phy-names = "u2phy", "u3phy";
> phy_type = "utmi_wide";
> snps,dis_enblslpm_quirk;
> snps,dis-u2-freeclk-exists-quirk;
> snps,dis_u2_susphy_quirk;
> snps,dis_u3_susphy_quirk;
> snps,dis-del-phy-power-chg-quirk;
> snps,dis-tx-ipgap-linecheck-quirk;
> snps,xhci-trb-ent-quirk;
> status = "okay";
> #address-cells = <0x1>;
> #size-cells = <0x0>;
>
> device@2 {
> compatible = "usbbda:8153";
> reg = <0x2>;
> local-mac-address = [00 00 00 00 00 00];
> };
> };
> };
>
> vcc-sys {
> compatible = "regulator-fixed";
> regulator-name = "vcc_usb30";
> regulator-always-on;
> regulator-boot-on;
> gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
> pinctrl-names = "default";
> pinctrl-0 = <&i2s1_sdio3>;
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> vin-supply = <&vcc_io>;
> };
>
> leds_all: leds {
> compatible = "gpio-leds";
>
> status {
> label = "r2s:red:status";
> linux,default-trigger = "heartbeat";
> gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
> default-state = "on";
> };
>
> wan {
> label = "r2s:green:wan";
> gpios = <&gpio2 RK_PC2 GPIO_ACTIVE_HIGH>;
> default-state = "on";
> };
>
> lan {
> label = "r2s:green:lan";
> gpios = <&gpio2 RK_PB7 GPIO_ACTIVE_HIGH>;
> default-state = "on";
> };
> };
>
> &vcc_usb30 {
> status = "okay";
> };
>
> &leds_all {
> status = "okay";
> };
> About 6 weeks ago I build my own U-Boot for the R2S, based on what's in U-Boot master, and also built a device tree based on Linux master, I think, and also the patches in FriendlyARM's repo. Here's the DTB, put this onto your MS-DOS partition and make sure that U-Boot loads that file (and not something else). The u-boot environment contains an fdtfile or fdt_file variable. You can either change that variable to reflect the filename, or you can put the file onto the MS-DOS partition with the name as in the variable. Patrick
rk3328-nanopi-r2-rev00.dtb
Description: Binary data
