Quoting Dieter (2020-08-14 09:03:22) > On 08/08/2020 14:48, Jonas Smedegaard wrote: > > 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.
Yes - I was excited too seeing that package update appear today I filed a bugreport requesting an update which possibly helped speed this up, but maybe it would have been done by now regardless. > >> 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! Thanks! To be honest, I could test this myself as well - I do have those boards lying around, but some of them are in active use, and I keep finding other things more important/exciting, so really appreciate your help here! Another benefit of this being done between the two of us is that we get the details more carefully laid out and documented. At least for me it has been an eye-opener in just how complex a seemingly simple "LIME2 is flaky at high speeds" turns out to be, if we wanna do better than "then just avoid those flaky modes". > >> 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. Thanks for confirming! > >> 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. Yeah - except it is not really "drivers" in u-boot. > Likely independent of network functionality when the OS is brought up. Cold-booting u-boot is certainly independent of Linux. But Warm-booting u-boot after rebooting from a loaded Linux is *not* independent of Linux. Neither is Linux loaded from u-boot independent of u-boot. > I arrived at this conclusion, as u-boot without the MICREL Phy has > working ethernet in Linux with the TX-Delay being set. Imagine Micrel PHY needs pins X and Y enabled to work well, and u-boot sets X and flips Y, and Linux flips X and sets Y. Cold-booting u-boot would fail, but then loading Linux would work. Rebooting into u-boot from working linux would fail. Rebooting into u-boot from failing u-boot would work. Cold-booting u-boot, rebooting u-boot, then loading Linux would fail. If however neither u-boot nor linux flips anything, only sets flags without probing first, then... (but they _need_ to probe _something_ e.g. to decide that the board has a Micrel chip at all, and we are in this mess because some of the probing and/or settings are undocumented). In short: 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. > > 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. Makes some sense, especially if you hope to "cut through" to a working setting without sifting through all possible combinations of options. On the other hand, if the combinations to test is large it is more tedious to load both u-boot and linux. > -> Configuring a tftp-server on the laptop to serve the netboot images > to the OLinuXino should help here. Yes. Simplest least reliable u-boot test seems to be to ping something. Possibly slightly better might be to issue dhcp requests repeatedly, as I imagine that would send larger packets. Most reliable (using only generally available u-boot commands) seems to be fetching something over tftp and then sending it back over tftp again, as that should measure actual transfer speed in either direction. > > 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... This trick should work: sudo FK_MACHINE='Olimex A20-OLinuXino-LIME2-eMMC' flash-kernel ...and then reboot (and cross your fingers and knock on wood) > Booting the device works fine in both cases, and i did not encounter > any error as of yet. Thanks for confirming. I have thought some more on this, and adjusted my logic: In the past I thought "use the -eMMC if your board has eMMC soldered on" but now realize that the better way to look at it is this: Use the -eMMC dtb for modern boards that *optionally* can hold an eMMC - i.e. the optimal dtb to use is the -eMMC one for rev. F and newer - regardless if your specific board has eMMC soldered on and regardless if you intend on using eMMC - the "eMMC" in the dtb name is simply a distinguishing trait of the board design. By that new (to me) logic, it makes sense to include the force-master workaround only for the non-eMMC dtb: It is irrelevant for any of the two PHYs used in more modern boards. Until now I was considering that to be an oversight. > I wonder if flash-kernel will take care of updated the dtb in /boot > upon a kernel update. flash-kernel will by default use the device-tree of the running kernel (but the "by default" might no longer apply, depending on how exactly you mess with symlinks or configfile contents). So I recommend trying above trick. - 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
