≡
[02:30:30] <nedko> if i get it right forces software setup of the TX/RX delays, while before it was used as configured via pull-up resistors
[02:30:42] <nedko> *the commit forces
[02:36:53] <nedko> the change was introduced in 5.8.15, 5.8.14 works
[05:02:56] <nedko> so with realtek phy lime2 boards and vanilla kernels newer than 5.8.14, phy-mode in the dts/dtb has to be rgmii-id instead of rgmii
[05:06:58] <jo0nas> nedko: as I understand it, it is important also which u-boot you use, and (obviously) if either u-boot or linux has some additional patches of config changes applied deviating from mainline defaults - notably if you set u-boot parameter CONFIG_GMAC_TX_DELAY=2 (or use the Olimex fork of u-boot which applies the equivalent of that)
[05:17:33] <nedko> jo0nas: U-Boot 2018.09, everything mainline. To check whether CONFIG_GMAC_TX_DELAY=2 was set would be somewhat hard because I have to first find the source tree... I'd rather check with latest U-Boot
[05:18:34] <jo0nas> as I recall, CONFIG_GMAC_TX_DELAY is _not_ set by default in mainline u-boot
[05:19:07] <nedko> this U-Boot build should have ethernet/dhcp disabled, as i usually do
[05:21:11] <jo0nas> ACTION added the change to linux Realtek driver to the growing list at https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks
[05:21:48] <nedko> the linux kernel realtek phy driver reconfigures the delays
[05:21:57] <jo0nas> yes
[05:22:17] <nedko> since 5.8.16, it was not doing this before
[05:22:37] <nedko> with the dts phy-mode value of "rgmii"
[05:22:41] <jo0nas> yes - but before that change the rev. G board was broken already
[05:22:52] <nedko> how so?
[05:22:56] <nedko> i have G2
[05:23:28] <jo0nas> uhm - shortest answer is to please see https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks
[05:24:13] <jo0nas> rev. F-G2 is broken at gigabit speeds with mainline u-boot and mainline linux
[05:25:31] <jo0nas> if you are saying that it was _not_ broken with mainline linux v5.8.14 and broke with v5.8.15, then I highly suspect that either linux or u-boot was _not_ mainline
[05:25:51] <nedko> so far it works for me, my internet connection is 12mb/s anyway :)
[05:26:12] <jo0nas> i.e. that you have some custom adjustment applied
[05:26:36] <nedko> well, i read the driver code and figured how to change my dts (also mainline stock for the board)
[05:26:40] <jo0nas> "works for me" is nice - but not really what I am talking about
[05:27:15] <jo0nas> the reliable "works for me" that I have found is to _avoid_ gigabit speeds
[05:27:39] <nedko> i guess there have to/could be dts modifications for each revision, but then the arm-dts directory will get huge :]
[05:28:04] <jo0nas> not sure what you are saying
[05:28:06] <nedko> i have K revision boards too
[05:28:22] <jo0nas> rev. K has similar but not identical issue
[05:29:11] <nedko> my kernels are newer than 5.1
[05:29:50] <jo0nas> what is your point?
[05:31:23] <nedko> "A possible cause for packet loss only for Micrel PHY is a bug fixed since mainline linux v5.1 and unfixed in mainline u-boot (as of v2020.07)."
[05:32:28] <jo0nas> if you are referring to the sunxi wiki mentioning v5.1, then it does not say that the fix at v5.1 _solved_ _all_ issues for rev. K, only that _maybe_ it solved _some_ packet loss - there continue to be problems at gigagbit speed with later linux releases
[05:32:36] <nedko> ACTION glad to have 5.9.3 running
[05:32:58] <jo0nas> "Apossible cause" - not "the only cause"
[05:34:50] <jo0nas> I am glad to have various versions running - would be more happy to have reliably identified the actual cause of the experienced issues and _know_ that they are fixed
[05:36:52] <nedko> the actual issue for me was that after upgrading to 5.8.15 eth0 stopped working
[05:37:46] <nedko> the fix for me was to change the dts/dtb in /boot
[05:38:49] <jo0nas> change how exactly? switch to use rgmii-id?
[05:38:54] <nedko> yes
[05:39:10] <jo0nas> ACTION has speculated about that change for some time, but not played with it yet
[05:39:30] <jo0nas> just make that change - not aplying any additional tuning?
[05:40:14] <nedko> yup
[05:40:33] <jo0nas> exciting!
[05:43:00] <jo0nas> would be great if you could stress-test at gigabit speeds (e.g. running on a LAN against a another host) - and also if you could test how that same simple change affects rev. K boards
[05:46:15] <nedko> i can see how this could be useful, but I have openbsd-6.8 and quite other stuff to setup with higher priority
[05:47:57] <nedko> the rgmii vs rgmii-id on K boards test will be easier to carry after more boards are set up
[05:48:05] <nedko> will keep you informed
[05:48:12] <jo0nas> thanks!
[05:48:40] <jo0nas> ACTION updated wiki to reference backport of Realtek delays to v5.8.15
[05:48:59] <jo0nas> sounds promising
[09:30:30] <leon-anavi> morning
[11:39:38] <Tsvetan> nedko: thanks for the note, I confirm this issue and have notified our developers
[16:33:16] <Tsvetan> nedko try this http://images.olimex.com/testing/a20/A20-OLinuXino-buster-minimal-20201105-110358.img.7z
[23:58:55] <nedko> Tsvetan: so far i tried A20-OLinuXino-buster-minimal-20201105-110358.img with rev C & rev L lime2 boards. network works with later and does not with former
IRC #olimex 2020-11-05
[02:28:32] <nedko> it seems the linux mainline commit "net: phy: realtek: fix rtl8211e rx/tx delay config" breaks my lime2 rev G2 ethernet[02:30:30] <nedko> if i get it right forces software setup of the TX/RX delays, while before it was used as configured via pull-up resistors
[02:30:42] <nedko> *the commit forces
[02:36:53] <nedko> the change was introduced in 5.8.15, 5.8.14 works
[05:02:56] <nedko> so with realtek phy lime2 boards and vanilla kernels newer than 5.8.14, phy-mode in the dts/dtb has to be rgmii-id instead of rgmii
[05:06:58] <jo0nas> nedko: as I understand it, it is important also which u-boot you use, and (obviously) if either u-boot or linux has some additional patches of config changes applied deviating from mainline defaults - notably if you set u-boot parameter CONFIG_GMAC_TX_DELAY=2 (or use the Olimex fork of u-boot which applies the equivalent of that)
[05:17:33] <nedko> jo0nas: U-Boot 2018.09, everything mainline. To check whether CONFIG_GMAC_TX_DELAY=2 was set would be somewhat hard because I have to first find the source tree... I'd rather check with latest U-Boot
[05:18:34] <jo0nas> as I recall, CONFIG_GMAC_TX_DELAY is _not_ set by default in mainline u-boot
[05:19:07] <nedko> this U-Boot build should have ethernet/dhcp disabled, as i usually do
[05:21:11] <jo0nas> ACTION added the change to linux Realtek driver to the growing list at https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks
[05:21:48] <nedko> the linux kernel realtek phy driver reconfigures the delays
[05:21:57] <jo0nas> yes
[05:22:17] <nedko> since 5.8.16, it was not doing this before
[05:22:37] <nedko> with the dts phy-mode value of "rgmii"
[05:22:41] <jo0nas> yes - but before that change the rev. G board was broken already
[05:22:52] <nedko> how so?
[05:22:56] <nedko> i have G2
[05:23:28] <jo0nas> uhm - shortest answer is to please see https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks
[05:24:13] <jo0nas> rev. F-G2 is broken at gigabit speeds with mainline u-boot and mainline linux
[05:25:31] <jo0nas> if you are saying that it was _not_ broken with mainline linux v5.8.14 and broke with v5.8.15, then I highly suspect that either linux or u-boot was _not_ mainline
[05:25:51] <nedko> so far it works for me, my internet connection is 12mb/s anyway :)
[05:26:12] <jo0nas> i.e. that you have some custom adjustment applied
[05:26:36] <nedko> well, i read the driver code and figured how to change my dts (also mainline stock for the board)
[05:26:40] <jo0nas> "works for me" is nice - but not really what I am talking about
[05:27:15] <jo0nas> the reliable "works for me" that I have found is to _avoid_ gigabit speeds
[05:27:39] <nedko> i guess there have to/could be dts modifications for each revision, but then the arm-dts directory will get huge :]
[05:28:04] <jo0nas> not sure what you are saying
[05:28:06] <nedko> i have K revision boards too
[05:28:22] <jo0nas> rev. K has similar but not identical issue
[05:29:11] <nedko> my kernels are newer than 5.1
[05:29:50] <jo0nas> what is your point?
[05:31:23] <nedko> "A possible cause for packet loss only for Micrel PHY is a bug fixed since mainline linux v5.1 and unfixed in mainline u-boot (as of v2020.07)."
[05:32:28] <jo0nas> if you are referring to the sunxi wiki mentioning v5.1, then it does not say that the fix at v5.1 _solved_ _all_ issues for rev. K, only that _maybe_ it solved _some_ packet loss - there continue to be problems at gigagbit speed with later linux releases
[05:32:36] <nedko> ACTION glad to have 5.9.3 running
[05:32:58] <jo0nas> "Apossible cause" - not "the only cause"
[05:34:50] <jo0nas> I am glad to have various versions running - would be more happy to have reliably identified the actual cause of the experienced issues and _know_ that they are fixed
[05:36:52] <nedko> the actual issue for me was that after upgrading to 5.8.15 eth0 stopped working
[05:37:46] <nedko> the fix for me was to change the dts/dtb in /boot
[05:38:49] <jo0nas> change how exactly? switch to use rgmii-id?
[05:38:54] <nedko> yes
[05:39:10] <jo0nas> ACTION has speculated about that change for some time, but not played with it yet
[05:39:30] <jo0nas> just make that change - not aplying any additional tuning?
[05:40:14] <nedko> yup
[05:40:33] <jo0nas> exciting!
[05:43:00] <jo0nas> would be great if you could stress-test at gigabit speeds (e.g. running on a LAN against a another host) - and also if you could test how that same simple change affects rev. K boards
[05:46:15] <nedko> i can see how this could be useful, but I have openbsd-6.8 and quite other stuff to setup with higher priority
[05:47:57] <nedko> the rgmii vs rgmii-id on K boards test will be easier to carry after more boards are set up
[05:48:05] <nedko> will keep you informed
[05:48:12] <jo0nas> thanks!
[05:48:40] <jo0nas> ACTION updated wiki to reference backport of Realtek delays to v5.8.15
[05:48:59] <jo0nas> sounds promising
[09:30:30] <leon-anavi> morning
[11:39:38] <Tsvetan> nedko: thanks for the note, I confirm this issue and have notified our developers
[16:33:16] <Tsvetan> nedko try this http://images.olimex.com/testing/a20/A20-OLinuXino-buster-minimal-20201105-110358.img.7z
[23:58:55] <nedko> Tsvetan: so far i tried A20-OLinuXino-buster-minimal-20201105-110358.img with rev C & rev L lime2 boards. network works with later and does not with former
