Hi Jonas,
On 08/08/2020 14:48, Jonas Smedegaard wrote: >> However: I was not able to force the other partner (my old lenovo T500) >> of the connection to a certain mode. >> I thought ethtool would allow me to force the T500s, but i could not >> find the option. > > Whoa, setting master/slave mode was implemented only since Linux v5.7: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649 > > Corresponding userspace support was introduced in ethtool v5.8: > https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d > > Ethtool v5.8 is not yet in Debian - was released upstream only 4 days > ago. > Sorry, I thought master/slave was same as MDI/MDI-X, but those are > independent: The former is which end provides clock source, then latter > is which wires are used: > https://en.wikipedia.org/wiki/Gigabit_Ethernet#1000BASE-T > > According to > https://www.speedguide.net/articles/network-adapter-optimization-3449 > when auto-negotiated "multi-port devices such as switches become the > master when connected to a single port device. If both ends are > multi-port devices, the one with higher seed bits becomes the master." > > That seems to indicate that you should reliably put the device in slave > mode by simply plugging it into a gigabit switch. Still not sure how to > force master mode (other than at the other end run Linux 5.7 and compile > and use ethtool 5.8), as the above does not tell which end "wins" when > both are single-port devices. Thanks for the information. Since ethtool 5.8 is now available, i can install debian unstable on the laptop and test different combinations. >> u-boot with FORCE_MASTER and TX-Delay 4: >> Same as above. >> >> >> u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK > > Ohhh, good point - I totally missed that detail! > > Seems more optimal to enable CONFIG_PHY_MICREL_KSZ9031. > > Would be helpful if you could test... > > * CONFIG_PHY_MICREL_KSZ9031 instead of CONFIG_PHY_MICREL > * enabling both CONFIG_PHY_REALTEK and CONFIG_PHY_MICREL_KSZ9031 > * above, with various values for TX-Delay Yes, i can test that! >> Good performance with TX-Delay = [3,4]. >> The results with TX-Delay = 2 could not be reproduced. >> >> >> Summed up: TX-delay = 3/4 seems useful for the Micrel phy. >> With TX-delay = 0, no connection was possible at all. > > I would expect TX-delay = 0 to behave same as TX-delay not set at all - > is that your experience as well? To be honest, i did not disable the configuration, as i always started from A20-OLinuXino..._defconfig, and there the Delay is set to 0 by default. But i just checked, if the line with GMAC_TX_DELAY is commented out in the config, make will ask for a value, 0 being the default. -> Yes, TX-Delay 0 is equal to this config not being set at all. >> Do you know what the switch regarding PHY_MICREL or PHY_REALTEK does? >> Is this possibly only used in u-boot, and therefore irrelevant as soon >> as linux boots? > > those switches enable code chunks in u-boot. My (vague!) understanding > is that some but not all such code chunks does some initialization of > hardware chips, and that Linux may or may not do its own > (re)initialization of same bits. > > In other words: Possibly - it depends... :-) I see, in that case i would suppose that network functionality in u-boot might depend on the compiled in drivers. Likely independent of network functionality when the OS is brought up. I arrived at this conclusion, as u-boot without the MICREL Phy has working ethernet in Linux with the TX-Delay being set. >> As you mentioned this commit >> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2) >> earlier in this thread, i would guess we should re-tests this with a >> linux-image > 5.2? > > Ideally we should test network quality from within u-boot, and if we > identify some u-boot setup that fails from within u-boot but works from > some Linux, then try identify what initialization the Linux code does > and try figure out how that could be done in u-boot as well. > > ...because ideally we want u-boot to work reliably not only for > initializing what Linux misses, but also for netbooting Linux. I agree, i would propose to test the values for TX_DELAY from within Linux, as there measuring upload / download performance is easier. As soon as we find a good configuration there, we can test the netbooting from u-boot. -> Configuring a tftp-server on the laptop to serve the netboot images to the OLinuXino should help here. > Another test that would be helpful is if you test your board with u-boot > built with A20-OLinuXino-Lime2-eMMC_defconfig (even if you do not have > and/or use eMMC): My suspicion is that the added options enabled for > that defconfig is harmless for non-eMMC boards, and knowing if in fact > they are harmless is helpful to figure out how many binaries we really > need to build in Debian, and if e.g. possible to say "use the -eMMC one > for Micrel-based boards regardless of eMMC". > > > - Jonas > You were right, the -eMMC boots find, one just needs to: - either symlink the non-eMMC.dtb to the *-eMMC.dtb in /boot/dtbs... - install the real -eMMC.dtb to /boot/dtbs... Booting the device works fine in both cases, and i did not encounter any error as of yet. I wonder if flash-kernel will take care of updated the dtb in /boot upon a kernel update. Best regards, Dieter
