Date: Sun, 5 Jul 2020 10:07:39 +1000 From: Peter Jeremy <peter@rulingia.com> To: Oleksandr Tymoshenko <gonzo@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r362736 - head/sys/arm64/rockchip Message-ID: <20200705000739.GE30039@server.rulingia.com> In-Reply-To: <20200703002623.GA18584@bluezbox.com> References: <202006282111.05SLBAAq025544@repo.freebsd.org> <20200701085747.GA23928@server.rulingia.com> <20200701124738.GA30133@server.rulingia.com> <20200703002623.GA18584@bluezbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--sXc4Kmr5FA7axrvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-Jul-02 17:26:23 -0700, Oleksandr Tymoshenko <gonzo@freebsd.org> wro= te: >Could you try kernel with this patch? It's mostly debug output, >with one possible clock-related fix. > >https://people.freebsd.org/~gonzo/patches/rk3328-gmac-debug.patch It's still not working for me. I get the following: dwc0: <Rockchip Gigabit Ethernet Controller> mem 0xff540000-0xff54ffff irq = 44 on ofwbus0 setting RK3328 RX/TX delays: 24/36 >>> RK3328_GRF_MAC_CON1 (00000413): >>> gmac2io_gmii_clk_sel: 0x0 >>> gmac2io_rmii_extclk_sel: 0x1 >>> gmac2io_rmii_mode: 0x0 >>> gmac2io_rmii_clk_sel: 0x0 >>> gmac2io_phy_intf_sel: 0x1 >>> gmac2io_flowctrl: 0x0 >>> gmac2io_rxclk_dly_ena: 0x1 >>> gmac2io_txclk_dly_ena: 0x1 >>> RK3328_GRF_MAC_CON0 (00000c24): miibus0: <MII bus> on dwc0 rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on miibus0 rgephy0: OUI 0x00e04c, model 0x0011, rev. 6 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-F= DX, 1000baseT-FDX-master, auto >I have Rock64 v2, which, as you mentioned, has a known issue with GigE, so >my tests are not reliable. I'll try to get another RK3328 board for tests, >but it may take some time. I've asked on -arm if anyone else has tried this on a Rock64 v2 or v3. >If the clock fix doesn't help, I'll make >delays configuration run-time configurable with off by default until >more hardware is tested. That sounds like a good way forward - maybe boot and run-time configurable. It's a pity that there doesn't seem to be any documentation on what the numbers represent (or what the "default" value is) - which means that actually adjusting the delay numbers would be very time consuming. --=20 Peter Jeremy --sXc4Kmr5FA7axrvy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE2M6l8vfIeOACl4uUHZIUommfjLIFAl8BGctfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQ4 Q0VBNUYyRjdDODc4RTAwMjk3OEI5NDFEOTIxNEEyNjk5RjhDQjIACgkQHZIUommf jLJjFQ/+IgzUBQZjUTUd4kgS739w6XR2uORohPk3ClK4x/rlqyvmOgYX98RR9ull bVI5/IUIcvbGynWEgpdHrYXxj6vRr38hiownDLb/TV9gB5SjYLSEX/uoALY/PpaQ jPEMRsIBnQpR+AXa29dHSO9R4554SxbOy0SVczzR2dyiPRBrl+AhLOD9h5T+7z1M 4z/WLm7OE/8U8eRPxr6srV7Vd9tDpHXiAI5AGZhGEWvLvaZvtp4stBZaV4ipg62X HzWp5HazUrkOv+tA94R0ahzFDcJnffFniMgFUcZ1kjxhhv+FoRo27f4c4rykaaqh azwOB/F8whXqr/w8oC4EMdwiZ1PYVwSOy27pO5DKaOt0rS5vXO9tvb0z4Fpxt6Px rv088cygimB6ebDFzz37snogH4QiOFvIibeHloLnPIA5mh/Ai7SGU64XwKauBWlx 0tDnBb5eJDJjnbZf5GNxSru395HKo1hoA3GRL1jN5pBPfM77NV5fJOHSI3T5rVcN JXuFF6Us8GjrLKX4NFaMzaliw34yjHWsFA0NrqxNU8+Skc8nNdTGyMqTZ/zf8+3v ngJMi9zVy9WvP9jcXUCYVYgjC5JjrmDzsKrXcO0nEGs+T5/ebbgiBweXwRfVPqAR P+NoztKlRjFPs/FHvENdZpBFH9VdM+XtuTAuumkKkI30OHJMXRE= =TTrl -----END PGP SIGNATURE----- --sXc4Kmr5FA7axrvy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200705000739.GE30039>