Quoting Dieter (2020-08-08 11:37:39) > as we found out here > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845128#63), > FORCE_MASTER was disabled in 2019.01+dfsg-7. > > I therefore downloaded u-boot-2020.07+dfsg-1 and did some testing. > System: debian buster > > > Results are attached.
Thanks! Valuable! > u-boot without FORCE_MASTER and different TX-Delays: > No difference can be seen i guess. I would have expected this, as the > FORCE_MASTER switch should only work for realtek-PHYs, and the REV K > uses the Micrel PHY. Right. That's why I omitted above test for rev. H-L boards in my list of TODOs at https://linux-sunxi.org/Olimex_A20-OLinuXino-Lime2#GMAC_quirks > 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. > 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 > 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? > 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... :-) > 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. 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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
